Attribute Certificate (AC) Policies Extension
draft-ietf-pkix-acpolicies-extn-08

[Ballot discuss]
This document needs to be significantly more clear.  I found it hard
to follow and I know what it is trying to do and roughly how.  I'm not
a PKIX insider, but I am probably as good at reading this type of
document as some of the people writing implementations so if I'm
finding it hard to follow then we still have work to do.

To improve the clarity I'd start by expanding all acronyms the first
time they are used.  Also, with the exception of the abstract, include
a reference to documents like 3280 and 3281 when an acronym is
introduced explaining where a reader can get more information on that
acronym.


2) Your reference to the ITU ASN.1 standards needs to make it clear
which version (1988?) you are using.




3) The OIDs in this document are specified relative to OIDs defined
elsewhere.  Please actually fully expand the OIDs; many PKIX and
S/MIME documents do a better job of this.  I'm more concerned about
when the OIDs are introduced in the text than in the normative ASN.1
module.


4) The semantics of unknown policy qualifiers are under specified.
  The syntax does not seem to allow anything besides the two OIDs
  specified in this document.  What happens when we want to add a new
policy qualifier later?  Giving us the ability to do this seems like
it requires defining behavior for receivers if they receive a
qualifier they do not understand.


5) Section 2 makes reference to a policy anyPolicy.  While that policy
is given an OID in the ASN.1 module, there are no semantics for this
policy in section 2.  There are semantics for policy qualifiers
associated with that policy, but not for the policy itself.

6) The semantics of the extension are unclear.  What exactly does it
mean for me as an AC using application to determine if the list of AC
policies in the AC are appropriate for the application?  If I
recognize none of the policy OIDs, what should I do?  Reject the AC?

[Ballot comment]
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.

[Ballot discuss]
No IANA Considerations section. Needed even if null.

No reference in text to Annex A, which appears to be normative,
so for clarity there should be a reference (e.g. immediately after
the citation of [ASN1].