headers
Antonio Maña | 1 Jul 1999 12:12
Picon

Re: Charter Revision


Larry,

first of all thank you for your comments,

Larry Stoddard escribió:
> 
> The problem with the key/cert management approach is that it requires
> many keys. This will eliminate smart card based solutions as there is
> not enough space to hold multiple keys and key histories. Unless you use
> multiple smart cards, which would mean playing musical smart cards to
> read all your mail.  Lending a token means that you are giving access to
> everything protected by the token, including the ability to sign. The
> problem with lending encryption keys is that some authentication schemes
> use encryption keys instead of signing keys to do anonymous
> authentication.

You are right about smart cards, but I think that the identity problem
can be solved without smart cards. Also it depends on the type of key
(specially the 'container' of the key not the key itself) that you can
store several keys in a smart card.

> Also for those that lease PKI services there will be an additional
> charge for each cert issued, so there is an incentive to minimize the
> number of certificates required. The goal is to separate authorization
> from identity as any change in authorization will result in revocation
> of the identity certificate. Also the management of roles is something
> that should be handled in as distributed a fashion as possible, ideally
> the role owner should be able to delegate his role without involving the
> CA.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Flanigan, Bill | 1 Jul 1999 16:33
Picon

RE: Charter Revision

Hello Larry,

	Decided to add my nickel's worth.  Please see "BF:" inline comments
below.

Best regards,

Bill Flanigan
> ----------
> From: 	Larry Stoddard[SMTP:m.stoddard <at> ieee.ca]
> Sent: 	Wednesday, June 30, 1999 5:32 PM
> To: 	Antonio Maña
> Cc: 	ietf-smime <at> imc.org
> Subject: 	Re: Charter Revision
> 
BF:  Don't see a "business case" yet for a charter revision.

> The problem with the key/cert management approach is that it requires
> many keys. 
> 
BF:  Yes, and I currently don't see anyway to avoid this in the foreseeable
commercial future (but see last comment below).

> This will eliminate smart card based solutions as there is
> not enough space to hold multiple keys and key histories. 
> 
BF:  Memory growth and cleaver memory use/management will help.  Then there
is physical size:  I wonder how many cert/key sets would fit into a palmtop
or kneetop?  Probably as many as one needs.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Internet-Drafts | 2 Jul 1999 14:23
Picon
Favicon

I-D ACTION:draft-ietf-smime-password-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-00.txt
	Pages		: 
	Date		: 01-Jul-99
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords
(and, by extension, any form of variable-length keying material which
isn't necessarily an algorithm-specific fixed-format key).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-password-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-password-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Jul 1999 18:55
Picon
Favicon

I-D ACTION:draft-ietf-smime-password-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the S/MIME Mail Security
Working Group of the IETF.

	Title		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-00.txt
	Pages		: 8
	Date		: 01-Jul-99
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords
(and, by extension, any form of variable-length keying material which
isn't necessarily an algorithm-specific fixed-format key).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-password-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-password-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
CMS'99 | 14 Jul 1999 16:10
Picon
Picon

CMS'99 - Communications and Multimedia Security

[apologies if you receive this mail multiple times]

Communications and Multimedia Security is a joint working conference
of IFIP TC6 and TC11.

CMS'99 will be organized September 20-21, 1999
at the Katholieke Universiteit Leuven, Belgium.

On-line registration can be done at
http://www.esat.kuleuven.ac.be/cosic/cms99/

Reduced fee of 250 EURO until August 1, 1999.

Draft program:

-----------------------------------------------------------------------

Monday, September 20

  8u00-8u45 Registration

  8u45-9u00 Welcome

  9u00-10u30 Network security: ATM and ISDN

    Security On ATM Networks 
    Stelios Karanastasis, Ahmed Patel 

    ISDN Security Services 
    Herbert Leitold, Karl Christian Posch, Reinhard Posch
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Mione | 15 Jul 1999 17:43
Picon

Quick comment on the Small Subgroup Attack draft


I noticed a subtle problem in the text in section 3.3. The first paragraph
reads:

 The prime p could be chosen such that p-1=2*q*j where j is the product 
                                                 ^^^^^^^^^^^^^^^^^^^^^^
 of large primes (large means greater than or equal to q).  This will 
 ^^^^^^^^^^^^^^^

 prevent an attacker from being able to find an element of small order 
 modulo p, thus thwarting the small-subgroup attack.  One method to 
 produce primes of this form is to run the prime generation algorithm 
 multiple times until an appropriate prime is obtained.  As an example, 
 the value of j could be tested for primality.  If j is prime, then the 
                                                ^^^^^^^^^^^^^
 value of p could be accepted, otherwise the prime generation algorithm 
 would be run again, until a value of p is produced with j prime.
                                                    ^^^^^^

Last time I read the definition, a number cannot be both prime and the
product of 2 primes at the same time. Are we talking about j in the last
sentence or one of the other variables in the expression 'p-1=...'?

Tnx.

Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione <at> noc.rutgers.edu                        W3: http://noc.rutgers.edu/~mione/
PGPFP:D4EEA987E870277C  24AAE6E9E6ABD088     ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darren Harter | 15 Jul 1999 18:48

RE: Quick comment on the Small Subgroup Attack draft

Tony,

I believe it should read

The prime p could be chosen such that p-1=2*q*j where j is a large prime (large means greater than or equal to
q). i.e. (p-1) is a product of large primes.

Regards,

Darren

------------------------------------------------------------------------
Darren Harter B.Sc (Hons) CEng MBCS
Application Development Group, UK
Entegrity Solutions Corp.
Tel: +44 1452 371383
Fax: +44 1452 371384
Cell: +44 7801 812850
Email: mailto:darren.harter <at> entegrity.com
http://www.entegrity.com
http://www.entegrity.co.uk

-----Original Message-----
From:	Tony Mione [SMTP:mione <at> hardees.Rutgers.EDU]
Sent:	Thursday, July 15, 1999 4:44 PM
To:	ietf-smime <at> imc.org
Cc:	Tony Mione
Subject:	Quick comment on the Small Subgroup Attack draft

I noticed a subtle problem in the text in section 3.3. The first paragraph
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Zuccherato | 15 Jul 1999 19:19
Favicon

RE: Quick comment on the Small Subgroup Attack draft

The first sentence should read:

The prime p could be chosen such that p-1=2*q*j where j is prime or the
product of large primes (large means greater than or equal to q).

That should make more sense.

> ----------
> From: 	Tony Mione[SMTP:mione <at> hardees.Rutgers.EDU]
> Sent: 	Thursday, July 15, 1999 11:43 AM
> To: 	ietf-smime <at> imc.org
> Cc: 	Tony Mione
> Subject: 	Quick comment on the Small Subgroup Attack draft
> 
> 
> I noticed a subtle problem in the text in section 3.3. The first paragraph
> reads:
> 
> 
>  The prime p could be chosen such that p-1=2*q*j where j is the product 
>                                                  ^^^^^^^^^^^^^^^^^^^^^^
>  of large primes (large means greater than or equal to q).  This will 
>  ^^^^^^^^^^^^^^^
> 
>  prevent an attacker from being able to find an element of small order 
>  modulo p, thus thwarting the small-subgroup attack.  One method to 
>  produce primes of this form is to run the prime generation algorithm 
>  multiple times until an appropriate prime is obtained.  As an example, 
>  the value of j could be tested for primality.  If j is prime, then the 
>                                                 ^^^^^^^^^^^^^
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexey Shamov | 17 Jul 1999 14:35
Picon

draft-ietf-smime-examples-01.txt question

Hi, all

I've tried to verify RC2 key wrap example from the
draft-ietf-smime-examples-01.txt document. The results I've got were
identical with ones from the document when RC2 effective keylength for KEK
was set to 40. When I tried to set it to 128 results were completely
different (see below).

Alexey

======================================
10.1 Wrapping RC2

This example shows how to wrap an RC2 key.

The CEK to be wrapped is
b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9

The hash of the CEK is
0a6f f19f db40 4988

The random value used is
4845 cce7 fd12 50

The CEK initialization vector is
c7d9 0059 b29e 97f7

The KEK is
fd04 fd08 0607 07fb 0003 feff fd02 fe05
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 16 Jul 1999 15:08

Updated Charter Revision

I have finally taken all of the comments that I received in e-mail and at 
the Oslo meeting.and combined them with stuff that I made up out of thin 
air.  Here is the updateded revised charter.  Please comment by 25 July 1999.

Russ

= = = = = = = = = =

S/MIME Mail Security (smime)

Chair:
      Russ Housley <housley <at> spyrus.com>

Security Area Director:
      Jeffrey Schiller <jis <at> mit.edu>
      Marcus Leech <mleech <at> nortel.ca>

Mailing Lists:
      General Discussion: ietf-smime <at> imc.org
      To Subscribe:       ietf-smime-request <at> imc.org
      Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed five Proposed Standards that
comprise the S/MIME version 3 specification.  Current efforts build
on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement
key establishment mechanism may expose some implementations to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane