Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt

["Turner, Sean P." <turners@xxxxxxxx>]

Comments as follows (r=replace):

1. Abstract: To the sentence beginning with "The X.509 v3 CRL format is
described in detail," add "an Internet specific extension is defined,".  AIA
is an internet specific extension. 

2. Sec 1 para 7 last sentence: replace a conforming certificate/conforming
certificates.  There are three cert examples in Appendix C.

3. Sec 1 last *, Sec 8, and Sec 10: r RFC 2510/RFC 4210

4. Sec 4 1st para last sentence: remove required to support a PKI.  All of
the internet defined extensions are optional so they can't be required to
support a PKI for the internet community.

5. Sec 4.1.2.4 last para penultimate and last sentence: r section
7.1/section 7.1 and 7.3.  7.3 needs to be added as issuer names can be
expressed using the domainComponent attribute.

6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key id
generation? How about striking SHA-1 from the methods and adding the new
sentence to both: The hash algorithm employed can be the same algorithm
paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384).

7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that since
the SAN is bound to the public key that the CA MUST verify the each part of
the SAN. I think a similar statement ought to be added to the subject
section (4.1.2.6) to indicate that "All parts of the subject name MUST be
verified by the CA as it is bound to the public key".

8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
constraints on ediPartyName or registeredID but the 14th para (the one
before the ASN.1) indicates that ediPartyName and registeredId are not
defined in this spec but MAY be defined in another spec. Sounds to me like
it would be hard to convince a customer that you could write a name
constraints that can ever be 3280bis compliant since whatever you wrote MUST
NOT be imposed/implemented. It's not clear that the name constraints
shouldn't be imposed because they're not defined in the spec or whether they
should never ever be imposed.

9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
constraints on x400Address name forms but the last sentence in the 10th para
last says X400Address MUST be applied to x.400 addresses. See #8.

10. Sec 4.2.2.1 4th to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP
[RFC 2255] URI. Makes it consistent with AIA in CRL section.

11. Sec 4.2.2.2 3rd to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP
[RFC 2255] URI.  Makes it consistent with AIA sections.

12. Sec 5 3rd to last para: r This profile does not define any private
Internet CRL extensions or CRL entry extensions/This profiles defines one
CRL extension and no CRL entry extensions.  AIA is defined in this spec.

13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the
onlyContainsAttributeCerts seems to hang. Recommend adding "In either case"
to the beginning of the sentence to address the case when either
onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. Additionally,
recommend adding the following for completeness as a new last paragraph: "If
the scope of the CRL only includes attribute certificates then the
onlyContainsAttributeCerts MUST be set to TRUE and both
onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE."

14. Sec 5.2.7: Remove ASN.1.  It's already referenced in the 1st para,
duplication leads to errors, and the other sections that reused ASN.1 from
certificate sections did not duplicate the ASN.1 (see AKI/IAN).

15. Sec 5.3.1: Can we add an ASN.1 comment to say the enumerated value #7 is
never used?

16. Sec 4.2.1.6 1st para: r These identities may be included in addition to
or in the place of the identity/These identities may be included in addition
to or in the place of, in the case of non-CAs, the identity.  The paragraph
mixes SAN and IAN, but assumed the 2nd sentence addressed SAN.

17. Sec 4.2.1.6: Add the following to clarify that there is no dependency in
this spec between SAN and IAN: This specification places no requirement on
CAs, whose certificate includes Issuer Alterative name, to include Subject
Alternative names in certificates issued by the CA. 

18. Sec 4.2.1.7: Add the following three sentences to be explicit about the
checks not made: Issuer Alternative names are not constrained by name
constraints. If a CA certificate has a Subject Alternative name, the
specification does not require CAs to populate the Issuer Alternative name
in certificates issued by the CA. Further, the chain of Issuer Alternative
and Subject Alternative names, as is done with issuer and subject names, is
not checked during the certificate path validation algorithm in section 6.

19. Sec 5.2.2: Add the following: Issuer Alternative names are not
constrained by name constraints. If a CA certificate has a Subject
Alternative name, this specification does not require CAs to populate the
Issuer Alternative name in CRLs issued by the CA.

Feel free to wordsmith any of the suggested text.

spt