jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com wrote:
Sorry this took so long, they keep trying to get me to ship something
here.
1. I don't like the use of MD2 and I know of no Cryptographer who
does. I realize that some companies are still using it and that is
why I am not suggesting a complete elimiation of it from the document,
however I would like the have the following changes made:
Section 4.3 changed the second sentence to:
A receiving agent MUST be capable of verifying the signatures on
certificates andCRLs made with md5WithRSAEncryption and
sha-1WithRSAEncryption signature algorithms with key sizes from 512
bits to 2048 bits described in [SMIME-MSG]. A receiving agent SHOULD
be capable of verifying the signatures on certificates and CRLs made
with the md2WithRSAEncryption signature algorithm with key sizes from
512 bits to 2048 bits.
Section 5.2 Third paragraph, second sentence to:
Certification authorities MUST support sha-1WithRSAEncryption and
md5WithRSAEncryption and SHOULD support MD2WithRSAEncryption for
verification of signatures on certificate requests as described in
[SMIME-MSG].
Section 5.2 Fourth paragraph is replace with:
For the creation and submission of certification-requests, RSA keys
SHOULD be identified with the rsaEncryption OID and signed with the
sha-1WithRSAEncryption signature algorithm. Certification-request
MUST NOT be signed with the md2WithRSAEncryption signature algorithm.
Part of the reason for still accepting MD2-based signatures at
all is because there are hardware devices still in use that only
support this. The MUST NOT above is antithetical to the purpose
of supporting it at all. Anyone that can avoid MD2 should.
I think SHOULD NOT fits better above.
2. I don't think that any certificates other than End-User
certificates should be required to have an Internet mail address.
Section 2.2 Change Certificates to End-User certificates in the
second sentence.
I think this was the intent, and deserves this clarification.
3. I don't have a good idea for how to change this, but I don't like
the fact that sections 2.2 and 2.3 are so related and appear at first
glance to have the same title, but are not the same. Perhaps section
2.2 and 2.2.1 should become subsections in 2.3.
4. Delete paragraph 2 in section 2.3. This has already been covered
in section 2.2 and is also covered in 3.1.
5. Section 4.4 Since we have removed all of the other references to
certificatePolices, it should also be removed from the last sentence
of the first paragraph. Nobody knows how to correctly deal with
certificatePolices anyway.
6. Section 5.1
It appears to me that the last two paragraphs are contradictory with
respect to MUST and SHOULD. I suggest that the MUST in the next to
last paragraph be changed to a SHOULD to make them match. I don't see
how a client application can do a good job of supporting multiple
valid CA certificates with different keys without supporting the
AuthorityKeyIdentificer extension.
Yes, I pushed for the MUST position initially at the pre-draft meeting
that happened at Netscape, but I think the argument raised was that one
could do trial and error and maybe there are some other means as well.
I backed down to SHOULD based on this pushback.
I noted either at that meeting or in a subsequent e-mail exchange
that an implementation not using key identifiers for chain
formation loses the ability to distinguish (with reasonable accuracy)
between a signature verification failure and not having a required
CA cert.
--a.
Jim Schaad
--
Anil R. Gangolli
Structured Arts Consulting Group
mailto:gangolli(_at_)StructuredArts(_dot_)com
http://www.StructuredArts.com