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

From: "Rob Sherwood" <[email-masked]>
Date: Tue, 11 Aug 2009 12:35:25 -0400

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. 

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.

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.

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.

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.

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)

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 11 Aug 2009 17:06:02 -0400

Rob,

See responses in-line below. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rob Sherwood
> Sent: Tuesday, August 11, 2009 12:35 PM
> To: [email-masked]
> 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,
[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
> 13530 Dulles Technology Dr, Ste 200, Herndon, VA 20171 PH 
> +1.703.793.7705 (W) +1.703.362.2329 (M)
> 
> 
>

---

From: "Skedd, Richard (UK)" <[email-masked]>
Date: Wed, 12 Aug 2009 12:25:16 +0100

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: 11 August 2009 22:06
To: Rob Sherwood; [email-masked]
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,

> 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.

> 
> 4. Clearance level declarations are incomplete. Declaration of 
> clearance without investigation level (NACI, Poly, etc) and issuer 
> (DoD, Treasury,

> 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.

> 
> 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

********************************************************************
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.
********************************************************************

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 12 Aug 2009 10:37:57 -0400

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.

> From: Skedd, Richard (UK) [mailto:[email-masked]] 
> Sent: Wednesday, August 12, 2009 7:25 AM
> To: Santosh Chokhani
> Cc: Rob Sherwood; [email-masked]
> 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.
> 
> 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
> [mailto:[email-masked]]
> (http://www.tscp.org),
> [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.
>  
> > 
> fact that 
> Please note that the I-D is not proposing that clearance or 
> clearance constraint will be a mandatory requirement for certificates.
> 
> > 
> appears to be a
> [Santosh] The classification list is from an existing vetted 
> clearance attribute defined in RFC 3281.
> 
> > 
> [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.  
> 
> > 
> [Santosh] The I-D deals with "subject".  Subject can be human 
> or non-human entity.
> 
> > 
> 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.

---

From: Sean Turner <[email-masked]>
Date: Wed, 12 Aug 2009 10:36:50 -0400

> use case for the inclusion of clearance attributes in PKCs.  Perhaps you

The use case for clearance in a public key certificate is pretty 
straightforward: a) follow certificate policy that requires clearance be 
included in public key certificate b) include clearance information in a 
subscriber's public key certificate c) relying party uses clearance to 
make an authorization decision.  If we throw in authority clearance 
constraints, then the relying party also checks that issuer was allowed 
to issue clearance in subscriber's certificate between b) and c). 
There's many examples including clearance in public key certificates, as 
noted by Steve Kent on 2/21/08 his "secure phone has always contained 
clearance info, for 20+ years."

I'd rather not reopen the "clearances are too dynamic to put in public 
key certificate" discussion.  This document isn't requiring that they be 
included in every certificate (a CP would do that).  We're just 
providing an interoperable way to do it.  If somebody really wanted to 
associate more dynamic clearances with a subject, they should put them 
in attribute certificates and we have sections to address that.

> came from and why it is still correct in 2009 I would be grateful.

The clearance attribute is based on the X.411-1988 security-label 
attribute.  Clearance is different in a couple of ways a) policy-Id 
required b) privacy-mark removed c) classList is a bit string vice 
integer d) topSecret vice top-secret.   All of the differences were 
purposeful except maybe for the last one.

I'd say the list is still correct in 2009 because it contains the basic 
classification used by many.  I wasn't there in 1988, but I suspect that 
to navigate the international standards gauntlet that they had to pick 
something to call the fields and they went with what they knew, which 
might have been based on some national input or knowledge of James Bond 
books (betting on the former).  X.411/X.501/RFC 3281 are all extensible 
so it met the international standards bar of providing basic 
interoperability while allowing those that want something more exotic to 
specify it.

I also don't want to throw these structures out because there is 
implementation experience with both clearance/security-label attributes.

> different hierarchical order.

The reserved text field isn't transfered so an implementation that chose 
to display a value for the bits could show secret, SECRET, or 
COUNTRY-NAME SECRET.  Note that display is not addressed by this document.

As you pointed out the ClassList is extensible so if a policy needs to 
add more it can.  The access control decision point is going to need 
more information than just the clearance values. It's going to need to 
know which one dominates the others.

spt