Subject: Re: Way Forward

From: "David P. Kemp" <[email-masked]>
Date: Tue, 1 Aug 2000 12:24:46 -0400 (EDT)

Russ,

Regarding data structures, http://www.ietf.org/ID-nits.html says:

  "For documents advancing in grade
  
   At least two complete, independent implementations must be tested and
   reported on, of each role (client/server/peer), and of each feature."

I believe this implies that EncryptedData, DigestedData, and
AuthenticatedData cannot be simply reduced to MAY status, but must be
moved to a different document if RFC 2630 is to proceed to Draft.  And
attractive as it might be to require AES instead of 3DES, this clause
precludes that option at this time.

Regarding RSA, if OAEP is specified for RSA key transport, should not
PSS be specified for signatures?  That said, I agree with Erik that
PKCS#1 v1.5 is sufficient for key transport, and if there are not two
independent implementations of X9.31, PKCS#1 is probably sufficient for
signatures.

Regarding key establishment, I believe it would be good engineering to
require a key agreement protocol such as DH, ECDH, a fully-public KEA,
or a future FIPS key agreement algorithm in CMS-based systems, in
addition to RSA key transport.  If someone proposed that both RSA and
X9.42 be mandatory, I would support that proposal if there were two
tested implementations of X9.42.  Are there?

Regarding terminology, I suggest that the term "Key Establishment" be
used in lieu of "Key Management" in RFC 2630 section 12.3 and elsewhere.
OAEP and DH have very little to do with "managing" keys; they are used
to establish a shared session key.  See HAC Definition 12.2.

Dave

> Date: Mon, 31 Jul 2000 17:04:52 -0400
> To: [email-masked]
> From: Russ Housley <[email-masked]>
> Subject: Way Forward
> 
> At the face-to-face meeting today, we had a fair amount of discussion about 
> the best way to proceed.  This message states each of the issues and the 
> proposed way forward.  This message is intended to give everyone an 
> opportunity to provide their input, even if they were unable to attend the 
> meeting.
> 
> RFC 2630 Interoperability Testing
> 
> Issue:  Two implementations have been tested for EnvelopedData and 
> SignedData.  These two data structures are required to implement S/MIME, so 
> this is not surprising.  RFC 2630 includes other data structure that are 
> MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do 
> not have two implementations for these data structures.
> 
> Proposed way forward:  Change the implementation requirements so that:
> 	- EnvelopedData and SignedData MUST be implemented; and
> 	- EncryptedData, DigestedData, and AuthenticatedData MAY be implemented.
> 
> Mandatory To Implement Algorithms
> 
> Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested 
> that the RSA algorithm become the mandatory to implement algorithm for key 
> management and signature.  It was pointed out that the current RSA key 
> management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique 
> should be employed instead.  While we were discussing algorithms, it was 
> suggested that AES should be the mandatory to implement symmetric cipher 
> instead of Triple-DES.  About half of the people thought that this was a 
> good idea.  The other half was concerned that the AES has not been 
> published yet.
> 
> Proposed way forward:  Change the mandatory to implement algorithm set to:
> 	One-way Hash:	SHA-1 (no change)
> 	Signature:	Both DSA and RSA (PKCS#1 v1.5)
> 	Key Mgmt:	RSA (OAEP)
> 	Eencryption:	Triple-DES in CBC mode
> 
> All comments on either of these proposals is most welcome.
> 
> Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 03 Aug 2000 11:29:04 -0400

Dave:

>moved to a different document if RFC 2630 is to proceed to Draft.

I will discuss this with the Security ADs.

>And

Given the flack associated with backward compatibility and OAEP, I will let 
you defend the AES.  However, I think that AES with RSA-OAEP will be very 
attractive.

>independent implementations of X9.31, PKCS#1 is probably sufficient for

I am unaware of any security issues with PKCS#1 v1.5 RSA signatures.  I am 
aware of the alternative format, but I do not know of any security reason 
to make a switch.

>tested implementations of X9.42.  Are there?

I know of at least two Ephemeral-Static Diffie-Hellman implementations.  I 
am not sure if any interoperability testing has been done.

>to establish a shared session key.  See HAC Definition 12.2.

Probably a good idea.  I am not going to start a son-of-RFC2630 until we 
have a clear direction.  Please remind me when the direction is clear.

Russ