ietf-smime
[Top] [All Lists]

Re: Way Forward

2000-08-03 09:59:12
Dave:

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.

I will discuss this with the Security ADs.

And
attractive as it might be to require AES instead of 3DES, this clause
precludes that option at this time.

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.

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.

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.

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?

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

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.

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



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