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