ietf-smime
[Top] [All Lists]

draft-ietf-smime-rfc2632bis-00.txt

2002-02-14 14:35:46

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

<Prev in Thread] Current Thread [Next in Thread>
  • draft-ietf-smime-rfc2632bis-00.txt, Housley, Russ <=