Attribute Certificate (AC) Policies Extension
Note: This ballot was opened for revision 08 and is now closed.
(Russ Housley) Yes
(Brian Carpenter) (was Discuss) No Objection
Comments from Gen-ART review by Spencer Dawkins (these are not blocking comments): 2. AC Policies Extension Semantics It should thus be noticed that an Attribute Authority (AA) does not necessarily support one single ACP. However, for each AC that is delivered it SHALL make sure that the policy applies to all the attributes that are contained in it. Spencer: darned pronouns... (1) you lost me on who/what "it" is, in "it SHALL make sure", and (2) I'm not totally clear on what the "it" in "contained in it" is, either. Is this text saying something like "Each Attribute Authority (AA) SHALL ensure that the ACP applies to all the attributes which are included in the ACs that the AA issues" - which is almost exactly repeated in the Security considerations, anyway? ("AAs SHALL ensure that the ACP applies to all the attributes which are included in the ACs they issue") 2.1 AC Policy Extension Syntax Spencer: is there a bad paragraph break in the following text (should it be all one sentence)? This specification defines two policy qualifier types for use by ACP writers and AAs. The qualifier types are the ACPS Pointer and the AC User Notice qualifiers. Spencer: is it clear to those skilled in the art what "local" scope is, in the following text? Within an AA, or ...? Since an URI could end up anywhere on the Internet, I'm not sure what this text is saying. The ACPS Pointer qualifier contains a pointer to an Attribute Certification Practice Statement (ACPS) published by the AA. The pointer is in the form of a URI. Processing requirements for this qualifier are a local matter. 3. Security Considerations Spencer: there's a lot of general good operational advice for AAs on page 4 - but I'm wondering if the Security Considerations section of the ACP extensions specification is the right place to publish this information (it's not where *I* would have first looked for operational BCP)... perhaps in its own document, called "Recommended Operational Practices for Certificate Attribute Authorities"? If an AC is tied to the holder's PKC using the baseCertificateID component of the Holder field and the PKI in use includes a rogue CA with the same issuer name specified in the baseCertificateID component, this rogue CA could issue a PKC to a malicious party, using the same issuer name and serial number as the proper holder's PKC. Then the malicious party could use this PKC in conjunction with the AC. This scenario SHOULD be avoided by properly managing and configuring the PKI so that there cannot be two CAs with the same name. Another alternative is to tie ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field. Failing this, AC verifiers have to establish (using other means) that the potential collisions cannot actually occur, for example, the CPSs of the CAs involved may make it clear that no such name collisions can occur. Spencer: "ACPS" is spelled out, earlier in the document, but CPS is not - is this more or less the same thing? Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present MUST be ignored. AC verifiers SHALL support means of being provided with this information. The AA controls PKC extension is one possibility, but is optional to implement. Spencer: got a reference for "the AA controls PKC extension", or do all skilled in the art know where this is defined? ... Spencer: from idnits 1.84 ... Checking conformance with RFC 3978/3979 boilerplate... * Found RFC 3978 Section 5.4 paragraph 1 boilerplate (on line 324), which is fine, but *also* found RFC 2026 Section 10.4C paragraph 1 boilerplate on line 34. It should be removed. * There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Sam Hartman) (was Discuss) No Objection
(Scott Hollenbeck) No Objection
Comment (2006-01-03 for -)
It might be helpful if the PKC acronym were expanded on first use in the Introduction.