Clearance Sponsor Attribute
draft-turner-clearancesponsor-attribute-03

[Ballot discuss]
If this is supposed to be a definitive name of a person or organization, don't we have ways for expressing that in certificates? I am not in favor of using a string that has only local significance given machine (not humans) will be making authorization decisions based on this. The complexity of agreeing on local identifiers is not fun and they tend to leak out of the domain where they were defined.

[Ballot comment]
I agree with both Cullen's and Pasi's discusses. This document is not clear on where it can really be used or what a receiver of the attribute really can do. If it is intended for machine use and point at location where information can be verified, then it should be a locator and with specified request mechanism. If it is for human consumption then it should say that and be clear that machines are not intended to act on the attribute.

[Ballot comment]
1. I support Pasi's part of the DISCUSS about 32 lenght strings being too short for proper identification of organizations, and Jari's COMMENT about lack of definition of the term 'sponsor'.

2. Same comment as with the other turner draft about the normative reference to superseded version of the X.680 Recommendation

[Ballot comment]
Some of the same comments apply here as in the other draft-turner.

In addition, the document seems to lack a definition of a "sponsor".
When I followed the references I understood what was meant by
"clearance". But it is still unclear what a sponsor is. Is this an
entity that performed the clearance evaluation, or the entity that
paid for it?

Also, I support Cullen's comments on DirectoryString and its length.
My main issue with DirectoryString is that I have no idea what I should
be putting to the sponsor attribute. If I put in "NSA", will it help
me get through access controls at some place? :-)

[Ballot comment]
Abstract

  This document defines the clearance sponsor attribute.  This
  attribute may be included in locations or protocols that support
  X.500 attributes.

"Protocols"?

2. Clearance Sponsor

  The clearance sponsor attribute indicates the sponsor of the
  clearance of the subject with which this attribute is associated. 
  This attribute is only meaningful if the clearance attribute
  [RFC3281bis] is also present.  The clearance sponsor attribute is a
  DirectoryString [RFC5280], which MUST use the UTF8String CHOICE,
  string with a minimum size of 1 characters and a maximum of 32
  characters.

Did you mean Unicode characters or octets?

3. Security Considerations

  If this attribute is used as part of an authorization process, the
  procedures employed by the entity that assigns each value

Did you mean clearance values?

  must ensure
  that the correct value is applied.

[Ballot discuss]
I don't understand what goes in the directory string or how a machine is going to do anything with it. Why is it so short? I'm not asking for a change to the drat - I'm just confused. If you can clear this up with an email to me, I can easily imagine clearing this discuss with no change to draft.

[Ballot discuss]
I have reviewed draft-turner-clearancesponsor-attribute-02, and have a
couple of questions/concerns that I'd like to discuss before
recommending approval of the document:

- 32 characters seems an awfully short limit for the maximum length.
For example, "National Institute of Standards and Technology" is
46 characters, and presumably, that's not the only agency with
a long name...

- Is the intent that the clearance sponsor name is scoped by the
certificate issuer? Or in other words, could one certificate issuer
use e.g. "DSAC" to mean "Defence Scientific Advisory Council" (UK),
and another "Domestic Security Alliance Council" (in US)?
(If this is the intent, it probably needs some explanation
about how to process these...)

- Same as deviceowner-attribute: the ASN.1 module should probably
import everything on page 6.

1.a - Carl Wallace  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 Russ Housley, Jim Schaad, and Kurt Zelienga, who were considered to be experts with ASN.1 and/or directories.  There are no concerns about depth or breadth of the reviews.

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

1.d - There are no specific concerns of which the AD and/or IESG should
be aware.

1.e - This is not a product of a WG.

1.f - This is not a product of a WG.

1.g - I have personally verified that the document satisfies all ID nits (although it does generate several spurious warnings).

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

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

1.j - Sean Turner verified the ASN.1.

1.k - Write-up is as follows:

Technical Summary

This document defines the clearance sponsor attribute.  This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes.

Discussion Summary

The -00 version was reviewed by Kurt Zeilenga.  He suggested instead of using UTF8String that the attribute be a DirectoryString and use the caseIgnoreMatch matching rule.  These changes were adopted, as they were more than reasonable.

Document Quality

This document is a short document that defines an attribute and uses an already defined matching rule.

Personnel

Carl Wallace is the shepherd.  Tim Polk is the sponsoring AD.