[Top] [All Lists]

Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt

2002-03-18 15:52:34

----- Original Message -----
From: "Jim Schaad" <jimsch(_at_)nwlink(_dot_)com>
To: "'Blake Ramsdell'" <blake(_at_)brutesquadlabs(_dot_)com>; 
Sent: Monday, March 18, 2002 1:55 PM
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt

There is a difference between what we consider to be good practice and
how backwards compability works.  I think that making it a MAY (or
omitting entirely) and adding a note that this is a common algorithm
still (is that really true? 11 out of 108 with what types of experation
dates) is sufficent to address your needs without having an endorsement
of this as a good algorithm on our (the WG) part.

This was 11 of 108 certificates that ship with Windows XP.  Since everyone
seems to be treating expiration dates in self-signed root certificates as a
joke (2028, 2039, etc.), then I presume that this isn't really relevant.

Remember that md2 is not an acceptable PKIX algorithm.  I think we
should follow that lead.

My point is that current, deployed, popular roots are using MD2.  I agree
that new signatures SHOULD/MUST NOT be created using MD2, but I can't say
that you shouldn't support verification with it.

Perhaps a separation of verifying vs. creating in this case would be in