[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Skedd, Richard (UK) wrote:

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


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


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


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