Clearance Attribute and Authority Clearance Constraints Certificate Extension
draft-ietf-pkix-authorityclearanceconstraints-03

[Ballot discuss]
The 2002 edition of the X.680 ITU-T receommendation defining ASN.1 basic notation was superseeded by the 2008 edition. Is there any reason not to include the newer version as Normative Reference?

[Ballot comment]
Section 7 says:

  The algorithm described in here has the idempotency, associative, and
  commutative properties, like the rest of the processing rules in this
  document.     

I am not sure that all of the processing rules in the document are
idempotent, associative, and commutative. Maybe best to drop the final
clause?

---

Appendix
I don't object, but...
  This appendix provides the normative ASN.1 definitions for
  the structures described in this specification using ASN.1 as defined
  in X.680.
If the material is normative, perhaps it should be moved into the main
body of the document.

---

Appendix

  -- The following is a '02 version for clearance.

Do we really need this in the RFC? I assume this is from the -02
revision of the I-D.

---

Nit

Section 1
Since [RFC3281bis] does not permit chain of ACs,
s/chain/ chain/

[Ballot discuss]
Section 2

  The ASN.1 syntax for the Clearance attribute is as follows [PKI-ASN]:

I don't think it is a good idea to repeat this definition here. It
appears to create to normative definitions of the same thing, and
could cause an issue if some difference creeps in.

[Ballot comment]
Section 5.1: there are potentially two certification paths of interest
when using ACs (one for the AA, another for the end-entity); it would
be helpful if the text said "certification path for the AA" whenever
it talks about paths here.

Section 9: "If there is no Clearance associated with a TA, it means
that the TA has not been assigned any clearance." Should this be
"..., it means the TA is not constrained"?

Responses to questions 1.a-1.h in RFC 4858:

1.a - Steve Kent is the Shepherd. I have personally reviewed the
document and assert that it is ready for IESG publication.

1.b - The document has been reviewed by key WG members. There are no
concerns about depth or breadth of the reviews.

1.c - I see no need for wider review.

1.d - My co-chair, Stefan Santesson, has not been enthusiastic about
this work. He initially expressed the concern that the extension is
not widely applicable, e.g., that it was focused only on the U.S DoD
application context. This was not true, e.g., the format is already
adopted in ISO standards and, presumably, used by other entities that
employ document sensitivity markings. After extensive discussion,
Stefan now seems (more) comfortable with the document's content.
There are no substantive criticisms from other WG members. There are
no other concerns of which the AD and/or IESG should be aware.

1.e - The WG consensus is solid (but see comments on 1.d above).

1.f - There has been no threat of an appeal by an WG members.

1.g - I have personally verified that the document satisfies all ID
nits. (the document refers to old versions of two I-Ds, but includes
text directing the RFC Editor to update these references as needed.)

1.h - The document splits it references into normative and informative
as required.

1.i - The document has an IANA consideration and it is consistent with
the main body (there are no IANA considerations).

1.j - Sean Turner assures me that the ASN.1 has been verified .

1.k - Write-up is as follows:

Technical Summary

This document defines the syntax and semantics for the Clearance
attribute and the Authority Clearance Constraints extension in X.509
certificates. The Clearance attribute is used to indicate the
clearance held by the subject. The Clearance attribute may appear in
the subject directory attributes extension of a public key
certificate or in the attributes field of an attribute certificate.
The Authority Clearance Constraints certificate extension values in a
Trust Anchor (TA), CA public key certificates, and an Attribute
Authority (AA) public key certificate in a public key certification
path constrain the effective Clearance of the subject.

Working Group Summary

This ID was discussed on the mailing list and at multiple meetings.
There was initially some controversy about whether or not these
extensions were reasonable. Eventually, the working group agreed
that they were applicable and important to a set of internet users.
All PKIX WG Last Call issues have been resolved. Discussion during
PKIX WG Last Call demonstrated working group consensus. This
document has strong PKIX WG support.

Document Quality

Russ Housley also reviewed this document. There are no known
implementations, but some WG members have expressed interest in
implementing this ID.


Personnel

Steve Kent is the document Shepherd. Tim Polk is the responsible
Security Area AD.