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: 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
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