[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
********************************************************************