Subject: [Gen-art] Gen-ART Review of draft-ietf-pkix-acpolicies-extn-07

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 30 Dec 2005 17:27:42 -0600

I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary: This document is very close to being ready for publication as a 
Proposed Standard.

Details: I found some text that wasn't particularly clear, but nothing 
that's not easily fixed, I think. My only significant question is the first 
one in the Security Considerations section - the rest is just editing.

Thanks, and Happy New Year,

Spencer

Detailed Notes:

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"?

Spencer:

   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?

Annex A (normative): ASN.1 Definitions

Spencer: I've been confused before... much of Annex A duplicates definitions 
given in Section 2.1, but not all of Annex A appears in Section 2.1, and 
there is no pointer to Annex A anywhere in the document (that I could find). 
If the idea is to pull some of the ASN.1 definitions into Section 2.1 for 
ease of explanation, at minimum it would be nice if Section 2.1 included 
words like, "The complete ASN.1 definitions are given in Annex A". Having a 
normative Annex with no explicit connection to the rest of the specification 
seems odd...

Spencer: from idnits 1.84

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  * The document seems to lack an IANA Considerations section.

    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. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art