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