RE: TSCP Comments on draft-ietf-pkix-authorityclearanceconstraints-02.txt

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

Rob,

See responses in-line below. 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Rob Sherwood
> Sent: Tuesday, August 11, 2009 12:35 PM
> To: ietf-pkix@xxxxxxxx
> Subject: TSCP Comments on 
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
> 
> 
> I am writing this message on behalf of the TSCP 
> (http://www.tscp.org), to present our thoughts on the draft 
> specification "Clearance Attribute and Authority Clearance 
> Constraints Certificate Extension"
> (draft-ietf-pkix-authorityclearanceconstraints-02.txt). Based 
> on review of the specification with our TSCP membership and 
> discussion of the proposal, we wish to raise the following 
> concerns regarding this
> specification:
> 
> 1. Firstly, there is no articulation of intent for use of 
> this standard in an implementation. It is unclear whether 
> this is a solution in search of a problem, or whether a use 
> case has been articulated. Given the close relationship 
> between the CertiPath/TSCP membership and the DoD, we are 
> concerned that the unknown use case may impact the 
> certificate profile or policy currently implemented within 
> the A&D Community.
> Accordingly, the A&D community represented in the TSCP would 
> like to have visibility regarding the intent of the standard.
[Santosh] Last two paragraphs of Section 1 of the I-D provide when
clearance constraints may be useful.  Once clearance constraint is used,
the relying parties need to enforce the intent of the clearance
constraint during certificate path validation.
 
> 
> 2. In many cases, individuals are forbidden to disclose the 
> fact that they hold a clearance. This proposal, if adopted 
> for use in human subscriber certificates, would either force 
> violation of this rule or create the need for individuals to 
> maintain multiple certificates.
[Santosh] Section 9 of the I-D deals with how to use this information.
Please note that the I-D is not proposing that clearance or clearance
constraint will be a mandatory requirement for certificates.

> 
> 3. The list of clearances (ClassList) is incorrect. It 
> appears to be a mixture of clearances and data sensitivity 
> markings. This makes the intent of the specification unclear, 
> as it seems to be applicable to both individuals and resource 
> managers.
[Santosh] The classification list is from an existing vetted clearance
attribute defined in RFC 3281.

> 
> 4. Clearance level declarations are incomplete. Declaration 
> of clearance without investigation level (NACI, Poly, etc) 
> and issuer (DoD, Treasury,
> etc.) is insufficient to determine what resources may be shared.
[Santosh] The policyID object identifier in the clearance structure
defines the security policy to which the clearance relates.  That should
cover issuer and investigation level.  

> 
> 5. A specification of sensitivity/clearance in a certificate 
> may be useful for device certs or attribute certs, as a way 
> to ensure that networks of a certain classification are 
> closed, and that communication within and between them is 
> protected, however the issues with the clearance list suggest 
> that this proposal may not serve this need.
[Santosh] The I-D deals with "subject".  Subject can be human or
non-human entity.

> 
> We are not necessarily opposed to the specification, but we 
> would first like to understand the details of the intent 
> behind the specification, and would like to discuss the 
> issues with the draft specification documented above.
> 
> Robert Sherwood
> Design Authority | Transglobal Secure Collaboration Authority 
> 13530 Dulles Technology Dr, Ste 200, Herndon, VA 20171 PH 
> +1.703.793.7705 (W) +1.703.362.2329 (M)
> 
> 
>