Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 16 Jan 2008 09:51:46 +0100

Sean,

1 - You say: "we allow multiple securityCategories with one policyId". 
The problem is that the same classList would apply. This would not allow 
to grant to the same individual both TOP SECRET COMMERCIAL and 
CONFIDENTIAL TECHNICAL.

2 - I do not see the value of duplicating text from RFC 3281.
The attribute      id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 
       ds(5) module(1) selected-attribute-types(5) clearance(55) } 
defined in the ID is the same as the attribute
       name      { id-at-clearance }
       OID       { joint-iso-ccitt(2) ds(5) module(1)
                   selected-attribute-types(5) clearance (55) }
defined in RFC 3281.

The differences are as follows:
  a) RFC 3281 does not say that the extension can be placed in a PKC.
  b) RFC 3281 does not say how many instances can be placed in an AC.

3 - Supporting such an attribute in ACs, has nothing to do with supporting an AA hiearchy.
But this is a non issue. RFC 3281 supports this attribute for ACs.

4 - With the proposed definition of the constraints, no standard code would be available, 
since the details of the securityCategory field would be left undefined. One main goal of RFCs
is to allow for interoperability testing.

5 - There is no RFC 3281 vs. X.501 battle, since the ASN.1 definition is the same.
The question is whether the RFC 3281 / X.501 definition is adequate in practice.
IMO, it would work, if two changes are made to the ID :

a)  multiples instances of this attribute should be allowed. On the contrary, it would be possible  
to grant to the same individual both TOP SECRET COMMERCIAL and CONFIDENTIAL TECHNICAL 
(see argument 1).

b) some standard OIDs for securityCategories should mandated to support 
in order to allow for interoperability (see argument 4).

Denis

=======================================================================

>Denis,

>Thanks for taking the time to read the ID.  Responses to your comments
>inline.

>spt

>>Sean and Santosh,
>>
>>I browsed through the draft.
>>
>>While I believe that it might be useful to work on this topic, 
>>I do not agree with the content of the draft on several aspects.
>>
>>First of all, a clearance is much better placed in an 
>>attribute certificate (AC) rather than a PKC :
>>Different AAs (Attribute Authorities) may grant different 
>>security clearances, while a given CA will in practice only 
>>grant clearances under the same policyID.
>
>I really, really, really want to agree, but supporting an AA hiearchy to
>issue clearances that are actually in some instances good for longer than
>many a certificate's validity periods - makes me think the AA implementation
>headache isn't worth it. This is my opinion though - you may disagree.
>
>>The document should be applicable as well to extensions placed in ACs.
>
>We don't prohibit these extensions from being included in attribute
>certificates, but I am also not sure we have to explicitly say they can be
>included in attribute certificates.
>
>>RFC 3281 which is a copy and paste of X.501 with some 
>>adaptations is not a practical solution.
>
>I'll let the RFC 3281 vs. X.501 battle be waged somewhere else ;)
>
>>The draft allows only one clearance certificate extension. 
>>This does not reflect real world situations where, given one 
>>policyId, there will be different securityCategories, each one 
>>with a different sensitivity (which is a much better word than 
>>"class").
>>This restriction should be removed.
>
>There's no restriction to remove - we allow multiple securityCategories with
>one policyId.
>
>>As already mentioned on the list, the classList definition is 
>>incorrect for the two first bits and does not even support the 
>>example from section 1: HIGHLY CONFIDENTIAL and GENERAL 
>>(called "security classification values", which is not an 
>>adequate terminology).
>
>The bits are reserved, as per RFC 3281, so we can't change them.
>
>>In addition, the text says:
>>
>>      policyId identifies the security policy to which the clearance 
>>      relates.  The policyId indicates the semantics of the classList 
>>      and securityCategory fields.
>>
>>If this is the case, rather than an OID and ANY DEFINED by the 
>>OID, it would be better to use UTF8String.
>
>Again we imported the ASN.1 because I think reuse is better than making
>something new because we'd like to just match the clearance policyId OID to
>the security-policy-identifier OID from the ESS Security Label. I think not
>using an OID is a really bad idea.
>
>>Another argument is interoperability: the current definition 
>>of SecurityCategory is too open to allow for interoperability. 
>>The RFC should allow, from the beginning, to implement 
>>interoperable solutions. 
>
>Because we can't agree to a common security policy for the Internet - I'd
>suggest we not try to explore this rathole. We didn't do it in S/MIME and I
>don't think we should do it here.
>
>>The text also says:
>> 
>>      classlist identifies the security classifications. Six basic 
>>      values are defined in bit positions 0 through 5 and more may be 
>>      defined by an organizational security policy. 
>>
>>This is untrue. The additional bits cannot be defined by an 
>>organizational security policy, but only by an addition to the 
>>RFC (make a parrallel with the keyUsage bits)
>
>I disagree completely. You register an OID in a registration document. In
>that document you can list your syntax and what the bits mean - if you
>expand the syntax you put it there. To get interop, you need to publish the
>syntax - you might do it in an RFC or you might not.
>
>>This raises the question of compatibility with X.501 section 19.5.
>>In my opinion, we should not stick to the X.501 definition, if 
>>there are good reasons not to do so.
>
>I agree, but I haven't heard a good reason to change yet.
>
>>There is no discussion at all about the criticality of this 
>>extension, even in the security considerations section.
>
>We do discuss criticality. Section 2 and 3, where the extensions are
>defined, indicate that the clearance extension is never critial and that the
>CA clearance extension may be critical.
>
>>The security considerations section contains the following sentence:
>>
>>   Certificate issuers must recognize that absence of the 
>>   CAClearanceConstraints in a CA certificate means that in 
>>terms of the 
>>   clearance, the subject CA is not constrained. 
>>
>>This sentence is incorrect for two reasons:
>>
>>1) it seems to apply to Relying parties (RPs), not CAs,
>>2) this is inconsistent with all the rules which are 
>>established about the criticality of extensions.
>>
>>A RP (or a CA) does not have to recognize the absence of an 
>>extension, whatever the extension may be.
>
>What we're saying is if you don't include the CAClearanceConstraints in a
>CAs certificate it is unconstrained. I could tweak the wording to say that.
>I did not intend to imply the two reasons you cite.
>
>>Finally, the CA clearance constraints extension only makes 
>>sense in a close community of CAs, where all CAs are 
>>constrained one way or another by a TA. This should be clearly 
>>advertised upfront in the introduction.
>
>I disagree with this. In a cross-certified environment where the domains
>understand each others policies this could work.
>
>>Denis
>>
>>>Santosh Chokhani and I have produced an ID that defines an extension 
>>>that holds a subject's clearance. The ID also defines an extension 
>>>called clearance constraints to limit the clearance values a 
>>CA should 
>>>place in subordinate certificates. Finally, it defines the 
>>>certification path processing rules to determine the 
>>clearances for the 
>>>subject of the certificate based on the clearance and clearance 
>>>constraints asserted in the certification path. The ID can be 
>>found at:
>>>
>>>http://www.ietf.org/internet-drafts/draft-turner-caclearanceco
>>nstraints
>>>-00.t
>>>xt
>>>
>>>We're hoping that PKIX would be willing to adopt this as a work item. 
>>>
>>>spt