[Top] [All Lists]

Re: Way Forward

2000-08-01 09:25:23


Regarding data structures, 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

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.


Date: Mon, 31 Jul 2000 17:04:52 -0400
To: ietf-smime(_at_)imc(_dot_)org
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
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 

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.


<Prev in Thread] Current Thread [Next in Thread>