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

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

For Item 1,
See paragraph 3 of Section 1 of the I-D.  Also, note that the I-D also
covers when the clearance is NOT asserted in a public key certificate
and is asserted in an attribute certificate.  Finally, this topic has
been discussed during the I-D formulation and review.  For that, see
PKIX archives.

For Item 3,
The I-D works independent of the specific meaning of the bits.  The bits
may be required due the default value of unclassified.  This may be a
legitimate comment against the current I-D that revises RC 3281.
 

> -----Original Message-----
> From: Skedd, Richard (UK) [mailto:Richard.Skedd@xxxxxxxxxxxxxx] 
> Sent: Wednesday, August 12, 2009 7:25 AM
> To: Santosh Chokhani
> Cc: Rob Sherwood; ietf-pkix@xxxxxxxx
> Subject: RE: TSCP Comments on 
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
> 
> Two comments on the points and responses below:
> 
> 1.  Intent - I understand the value of clearance constraints 
> if you are going to include clearance attributes in PKCs but 
> don't understand the use case for the inclusion of clearance 
> attributes in PKCs.  Perhaps you could explain further.
> 
> 3.  Clearances - I was interested in the comments regarding 
> the ClassList at item 3 below as the proposed list, to UK 
> eyes, appears to be completely arbitrary in scope and order.
> 
> I looked at RFC 3281 as suggested, this appears to just adopt 
> X.501-1993.  I could not find anything in X.501-1993 refering 
> to clearance.  RFC2634 and X.411-1997 refer to a very similar 
> list as Security Classifications:
> 
>   unmarked (0),
>   unclassified (1),
>   restricted (2),
>   confidential (3),
>   secret (4),
>   top-secret (5)
> 
> But note that this is slightly different to that proposed in 
> the draft for Top Secret which is given as "topSecret".
> 
> At that point I gave up, if someone could enlighten me on 
> where the list came from and why it is still correct in 2009 
> I would be grateful.
> 
> I am also unsure of the value of a reserved list of text 
> strings when the application of the policyId field makes the 
> actual meaning of all entries in the ClassList policy 
> specific.  There may also be problems where a particular 
> policy uses the values in the ClassList but in a different 
> hierarchical order.
> 
> Regards
>  
> Richard Skedd
> IT Strategy Manager
> T:    +44 117 918 8034 (vnet 7658 8034)
> M:    +44 780 171 8260 (vnet 777118260)
>  
> BAE Systems plc
> Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK 
> Registered in England & Wales No: 1470151 
> 
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Santosh Chokhani
> Sent: 11 August 2009 22:06
> To: Rob Sherwood; ietf-pkix@xxxxxxxx
> Subject: RE: TSCP Comments on
> draft-ietf-pkix-authorityclearanceconstraints-02.txt
> 
> 
>                     *** WARNING ***
> 
>   This message has originated outside your organisation,
>   either from an external partner or the Global Internet. 
>       Keep this in mind if you answer this message.
> 
> 
> 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)
> > 
> > 
> > 
> 
> 
> 
> ********************************************************************
> This email and any attachments are confidential to the 
> intended recipient and may also be privileged. If you are not 
> the intended recipient please delete it from your system and 
> notify the sender.
> You should not copy it or use it for any purpose nor disclose 
> or distribute its contents to any other person.
> ********************************************************************
> 
>