Bill,
I had made similar comments before about "ESSCertID" in ESS-09 and
"SMimeEncryptionCert" in CERTDIST-02, since in both cases "certHash"
mandates the use of SHA-1 only. The reply I received from Jim Schaad for
ESS-09 at the time was:
"There are currently a large number of items which are assuming that SHA-1
will not ever be effectively broken. This is just another of those items.
If SHA-1 ever does get broken then the algorithm here can be updated by
creating a new OID to define a new version of ESSCertID. The problem with
making it flexible is that you then need to start stating which algorithms
can and cannot be used leading to the same problem of a new draft when SHA-1
is broken anyway."
However, I still think that none of the S/MIME standards should be bound in
any way to SHA-1, although SHA-1 can still be the recommended standard
specified in [MSG] for interoperability at this time.
Francois Rousseau
AEPOS Technologies
Sorry only to be bringing this up at the Last Call stage, but I
don't have any record of it being discussed before.
I'm concerned that the draft-ietf-smime-x942-04 document does not
provide for the use of any hash algorithm other than SHA-1 when deriving
the key from the shared secret. X9.42 provides the KeyDerivationHash
AlgorithmIdentifier. Would it be possible to change the
KeyAgreeRecipientInfo ASN.1 to read (apologies for poor ASN.1 style):
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
keyDerivationHash KeyDerivationHashAlgorithmIdentifier
DEFAULT sha1Identifier,
recipientEncryptedKeys RecipientEncryptedKeys }
We would then change section 2.1.2 of the draft-ietf-smime-x942-04
document so that the line
H is the message digest function SHA-1 [FIPS-180]
becomes
H is a message digest function. In [CMS], the message digest function
is identified by the keyDerivationHash field of the KeyAgreeRecipientInfo
if this is present, and is SHA-1 if this field is absent.
Again, my apologies if it's too late to be bringing up this kind of point.
Cheers,
William