draft-ietf-smime-rfc2632bis-00.txt

Blake:

I have some comments on rfc2632bis-00.  I did not expect to have so many, 
but here we go...
Section 1, 1st paragraph. Son-of-2459, which should be reference [KEYM], 
does not include algorithm specifics any more.  They were moved to a 
separate document.  You should also reference it: 
draft-ietf-pkix-ipki-pkalgs-05.txt.
Section 1, 2nd paragraph. You should reference [CMSALG] as well as [CMS].

Section 1.1, Attribute Certificate (AC) definition.  Please reference 
draft-ietf-pkix-ac509prof-09.txt.  This document is in the RFC Editor 
queue, and it will get a number soon.  It depends on Son-of-2459, which is 
also in the RFC Editor queue.
Section 2.1, 1st paragraph.  I would like to begin ithe: "Receiving agents 
MUST support PKIX v1 and PKIX v2 CRLs."
Section 2.1, last paragraph.  I agree with the statements, but I think the 
whole paragraph belongs in a section on certificates.  Perhaps is belongs 
in section 2.3.
Section 2.2, 1st paragraph, last sentence.  This references section 
3.1.  There is not a section 3.1.  Should it reference section 3 or 
something else?
Section 2.2, last paragraph.  Please change it to: "Receiving agents SHOULD 
support X.509 version 2 attribute certificates [PKIXAC]."
Section 2.2.1, only paragraph.  rfc2630bis supports three types of 
certificates: PKIX, PKCS #6 Extended Certificates, version 1 Attribute 
Certificates, and version 2 Attribute Certificates.  The version 1 
Attribute Certificates are obsolete, and they were not widely 
implemented.  The paragraph needs to say that PKCS #6 Extended Certificates 
and version 1 Attribute Certificates MUST NOT be used.
Section 2.3, 4th paragraph.  Please change "Also note that in the case of 
DSA certificates the parameters may..." to "Also, when certificates 
containing DSA public keys, the parameters may..."
Section 2.3, 4th paragraph.  Please delete "but are not currently 
recommended."  In my opinion, the use of subjectKeyIdentifier and 
authorityKeyIdentifer is recommended.  However, support of chain building 
based on distinguished names is the required technique.
Section 2.3, last paragraph.  Please add "version 2" before "attribute 
certificates."
Section 2.3, last paragraph.  Please add a reference to 
draft-ietf-smime-seclabel-04.txt.  I suggest replacing the last sentence 
with:  "All other issues regarding the generation and use of X.509 version 
2 attribute certificates are outside of the scope of this specification; 
however, [SECLABEL] offers guidance on one use." This document is in the 
RFC Editor queue, so including this reference will not delay progression of 
this document.
Section 3, 2nd paragraph.  Please add a reference for the PKCS#9 
emailAddress attribute.
Section 4.1, 1st paragraph.  Please change "certificate-revocation list" to 
"certificate revocation list" in three places.
Section 4.1, 2nd paragraph.  Please change "certificate chain" to 
"certification path."
Section 4.1, 2nd paragraph.  Please change "draft" to "specification."

Section 4.1, 2nd paragraph.  Please change "... with particular certificate 
hierarchies" to "... with particular certification paths."
Section 4.2, whole.  Please change "certificate chain" to "certification 
path" in many places, including the section title.  In two places, toward 
the end of the 2nd paragraph, also replace "chain" with "certification path."
Section 4.3, 1st paragraph.  Please change "certificate-revocation list" to 
"certificate revocation list."
Section 4.3, 2nd paragraph.  Please replace the paragraph with the 
following:  "A receiving agent MUST be capable of verifying the signatures 
on certificates and CRLs made with sha-1WithRSAEncryption signature 
algorithms, using key sizes from 512 bits to 2048 bits, as described in 
[CMSALG].  A receiving agent SHOULD be capable of verifying the signatures on
certificates and CRLs made with md2WithRSAEncryption and 
md5WithRSAEncryption signature algorithms, using key sizes from 512 bits to 
2048 bits, as described in [CMSALG]."
Section 4.4, 2nd paragraph.  Please replace the paragraph with the 
following:  "Sending and receiving agents MUST correctly handle the basic 
constraints, key usage, authority key identifier, subject key identifier, 
and subject alternative names certificate extensions when they appear in 
end-entity certificates. Some mechanism SHOULD exist to gracefully handle 
other certificate extensions when they appear in end-entity or CA certificates.
Section 4.4.1, 1st paragraph.  Please change "chain of certificates" to 
"certification path."
Section 4.4.2, 2nd paragraph.  Please change "end user certs" to 
"certificates."  The extension does not distinguish between the signing of 
subordinate CA certificates or end-entity certificates.
Section 4.4.2, last paragraph.  Son-of-2459 says: "When this extension 
appears, it SHOULD be marked critical."  Why do we change this to MUST?
Section 5, last paragraph.  Please delete "[TBD] -- PKCS #1 v1.5 
warnings?"  I do not believe that this is an issue for this document.  RSA 
PKCS#1 v1.5 and RSA OAEP use the same public key, so the million message 
attack issue is properly handled in rfc2633bis.
References.  Please update [KEYM] to reference 
draft-ietf-pkix-new-part1-12.txt.  This document is now in the RFC Editor 
queue, so it will get a number soon.
References.  Please update [CMS] to reference rfc2630bis.  The IESG 
discussed this document last week, and only editorial issues were 
raised.  I hope it will transition to the RFC Editor queue very soon.
References.  Please add draft-ietf-pkix-ac509prof-09.txt, with a tag of 
[PKIXAC].  This document is now in the RFC Editor queue, so it will get a 
number soon.
References.  Please add draft-ietf-smime-seclabel-04.txt., with a tag of 
[SECLABEL].  This document is now in the RFC Editor queue, so it will get a 
number soon.
Enjoy the Olympics,
  Russ