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

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 15 Jan 2008 14:40:08 +0100

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.

The document should be applicable as well to extensions placed in ACs.
RFC 3281 which is a copy and paste of X.501 with some adaptations is not a practical solution.

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.

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

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.

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. 

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)

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.

There is no discussion at all about the criticality of this extension, 
even in the security considerations section.

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.

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.

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-caclearanceconstraints-00.t
>xt 
>
>We're hoping that PKIX would be willing to adopt this as a work item. 
>
>spt

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 15 Jan 2008 11:13:06 -0500

Denis,

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

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Tuesday, January 15, 2008 8:40 AM
>To: [email-masked]
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
>Sean and Santosh,
>
>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.

>adaptations is not a practical solution.

I'll let the RFC 3281 vs. X.501 battle be waged somewhere else ;)

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

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 

The bits are reserved, as per RFC 3281, so we can't change them.

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

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

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

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