Clearance Attribute and Authority Clearance Constraints Certificate Extension
RFC 5913

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    pkix mailing list <pkix@ietf.org>, 
    pkix chair <pkix-chairs@tools.ietf.org>
Subject: Protocol Action: 'Clearance Attribute and Authority Clearance Constraints 
Certificate Extension' to Proposed Standard

The IESG has approved the following document:

- 'Clearance Attribute and Authority Clearance Constraints Certificate 
   Extension '
   <draft-ietf-pkix-authorityclearanceconstraints-03.txt> as a Proposed Standard


This document is the product of the Public-Key Infrastructure (X.509) Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-authorityclearanceconstraints-03.txt

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

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

Personnel

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

RFC Editor Note

Please make the following subsitutions:

In Section 1:

OLD

     Since [RFC3281bis] does not permit chain of ACs

NEW

    Since [RFC3281bis] does not permit chains of ACs

In Section 1.2

OLD

   All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680].  
   All X.509 AC [RFC3281bis] extensions are defined using ASN.1 [X.680]. 

NEW 

   All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680].  
   All X.509 AC [RFC3281bis] extensions are defined using ASN.1 [X.680]. 
   Note that [X.680] is the 2002 version of ASN.1, which is the most
   recent version with freeware compiler support.

In Section 2:

OLD

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





NEW

    The ASN.1 syntax for the Clearance attribute is defined in [PKI-ASN]
and
    that RFC provides the normative definition.  The ASN.1 syntax for
    Clearance attribute is as follows:

In Section 5.1:

OLD

   Authority Clearance Constraints are collected from the user input,
   the trust anchor and all the PKCs in a PKC certification path.

NEW

   Authority Clearance Constraints are collected from the user input,
   the trust anchor and all the PKCs in the AA PKC certification path.

In Section 7:

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

NEW

   The algorithm described in here has the idempotency, associative, and
   commutative properties

In Section 9:

OLD

   Certificate issuers must recognize that absence of the
   AuthorityClearanceConstraints in a CA or AA certificate means that in
   terms of the clearance, the subject Authority is not constrained.

NEW

    Certificate issuers must recognize that absence of the
    AuthorityClearanceConstraints in a TA, in a CA certificate, or in an
    AA certificate means that in terms of the clearance, the subject
    Authority is not constrained.

in Appendix A:

OLD

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

NEW

-- The following is an '02 ASN.1 version for clearance.