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

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 20 Feb 2008 12:34:01 -0500

Denis,

Comments inline.. 

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Wednesday, January 16, 2008 3:52 AM
>To: [email-masked]
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
>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.

You register a policy company XYZ - it gets an OID. In that policy you say
what classList bits you support. You can add new ones say bits 7 and 8 and
call them TOP SECRET COMMERCIAL and CONFIDENTIAL TECHNICAL. If you're
getting at that the first set of numbers is reserved essentially, I don't
think we should reopen that because we already had that argument in S/MIME
(and maybe also in PKIX).

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

We followed in Stefan's footsteps [RFC 4262] where an attribute
(SMIMECapabilities) got turned in to an extension. The precedent has been
set we just followed it. I don't think we need to look at RFC 3281 to say
where the information can or can't go. X.501 and other places where sytnax
is defined doesn't say where all the info can go. 

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

I think relying on RFC 3281 means you need an AA (AC issuer) to issue you an
AC. There's not a lot of those around.

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

So there are other standards that have essentially ANYs in them where
interoperability was achieved I believe we can do the same thing here. There
is an ISO standard (ISO 15816) that defines categories, but honestly I'd
like to decouple that discussion from this discussion. 

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

See answer to 1 above.

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

See response to #4

spt

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

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 20 Feb 2008 16:46:10 -0500

> is defined doesn't say where all the info can go.

When I scanned this document some time ago, I was unsure how one was 
expected to include clearance information in a certificate.  Section 2 
of the draft begins:

   The Clearance certificate extension in a certificate indicates the
   clearances held by the subject.  It uses the clearance attribute
   syntax from Section 4.4.6 of [RFC3281] in the Subject Directory
   Attributes extension.  The Clearance certificate extension MUST never
   be marked critical.

The statement about criticality implied that this was an extension, but 
the second sentence suggested that it should appear in the 
subjectDirectoryAttributes extension.

I do not understand why this draft specifies that this attribute should 
be encoded as an extension.  The clearance attribute is defined as an 
Attribute.  The subjectDirectoryAttributes extension was defined for the 
specific purpose of allowing attributes to be included in certificates.  
X.501, which defines the clearance attribute, states that if a clearance 
attribute is to be included in a public key certificate, it should be 
placed in the subjectDirectoryAttributes extension.

Why do people feel that there is a compelling reason to avoid using the 
subjectDirectoryAttributes extension when encoding an attribute in an 
extension?

> like to decouple that discussion from this discussion. 

The processing rules for the CAClearanceConstraints extension includes 
the following rule:

       -- Calculate securityCategories intersection in accordance with
          guidelines associated with the security policy represented by
          the policyID.

Why do you believe that it is reasonable to publish this draft with such 
an incomplete processing rule included?  How do you expect people to 
implement this CAClearanceConstraints extension?

Is there an assumption that inclusion of securityCategories in 
CAClearanceConstraints extensions will be rare and so it is acceptable 
for a generic implementation to simply reject certification paths that 
include a CAClearanceConstraints extension with securityCategories?  
Alternatively, do you expect that there will be a limited number of 
security policies and there is a plan to publish a second document that 
lists these security policies along with the rules for performing the 
above calculation for each of the security policies?

You say that other standards do something similar.  Can you point to 
specific examples where a standard has been approved despite leaving 
things as open ended as this?

Dave

P.S. I also do not understand the reason for including the 
CAClearanceConstraints extensions in a trust anchor certificate.  If a 
CA wants to effectively impose such constraints, shouldn't it include 
the constraint information in all (non-self-issued) CA certificates that 
it issues.  As for end entity certificates, the CA can constrain itself 
by simply not issuing any certificates that violate the constraint.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 20 Feb 2008 18:27:01 -0500

Dave,

The answer to your question regarding "Clearance" is that it is a
separate extension.  Do you think that the I-D needs to be clarified.

In terms of using SDA instead, I am ok with it being in SDA or a
separate extension.

In terms of security categories, we have exposure to some "security
policies" where some categories are restrictive and hence intersection
is appropriate and some are permissive and hence union is appropriate.
That is why we did not write the rules.

In terms of CA clearance constraint, some implementations need to limit
the TA and that is why the constraint appears in the TA.  As to the end
entity, we explicitly state that CA clearance constraint will not appear
in end entity.  In terms of a Signing CA, the flexibility of CA
clearance constraint in lowest layer CA is useful depending on which
parent issues it a certificate since these constraints are imposed
during path validation.  Depending on what path is chosen clearances
asserted in an end entity certificate may be valid or not. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Wednesday, February 20, 2008 4:46 PM
To: Turner, Sean P.
Cc: pkix
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID

Dave

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 20 Feb 2008 20:47:14 -0500

Dave,

Comments in line...

spt

>> (SMIMECapabilities) got turned in to an extension. The precedent has 
>> been set we just followed it. I don't think we need to look at RFC 
>> 3281 to say where the information can or can't go. X.501 and other 
>> places where sytnax is defined doesn't say where all the info can go.
>>   
>
>When I scanned this document some time ago, I was unsure how 
>one was expected to include clearance information in a 
>certificate.  Section 2 of the draft begins:
>
>The statement about criticality implied that this was an 
>extension, but the second sentence suggested that it should 
>appear in the subjectDirectoryAttributes extension.

Sorry about the confusion. In the next version we'll delete the "in the
Subject Directory Attributes extension." We were proposing it as a
standalone extension.

>I do not understand why this draft specifies that this 
>attribute should be encoded as an extension.  The clearance 
>attribute is defined as an Attribute.  The 
>subjectDirectoryAttributes extension was defined for the 
>X.501, which defines the clearance attribute, states that if a 
>clearance attribute is to be included in a public key 
>certificate, it should be placed in the 
>Why do people feel that there is a compelling reason to avoid 
>using the subjectDirectoryAttributes extension when encoding 
>an attribute in an extension?

X.501 says "The clearance can be bound to the Distinguished Name of the
requestor through a certificate extension field (subject Directory
attribute) or through an attribute certificate." This might be picky but
that's not a MUST/SHALL or even a SHOULD for either. (some or many may
disagree with the following) I think people don't like SDA because it's
optional in RFC3280 - which basically means unsupported. Now you can argue
that adding a new attribute or a new extension still means it's all
unsupported but at least if you define your own extension you can pick
whether you want criticality (note we always want clearance to be
non-critical) and you don't have to carry the extra OID and SEQUENCE
wrappers.

>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.
>>>     
>>
>> interoperability was achieved I believe we can do the same 
>thing here. 
>> There is an ISO standard (ISO 15816) that defines categories, but 
>> honestly I'd like to decouple that discussion from this discussion.
>>   
>
>The processing rules for the CAClearanceConstraints extension 
>includes the following rule:
>
>Why do you believe that it is reasonable to publish this draft 
>with such an incomplete processing rule included?  How do you 
>expect people to implement this CAClearanceConstraints extension?
>
>CAClearanceConstraints extensions will be rare and so it is 
>acceptable for a generic implementation to simply reject 
>certification paths that include a CAClearanceConstraints 
>extension with securityCategories?  

I think it's reasonable because there are many RFC that publish without
complete policy definitions or requirements (and I agree with why it's done
... but we're just another one of them).

I'd say the number of CAs that will issue clearances or include
CAClearanceConstraints will small compared to those that don't. I suspect
that most policies probably won't need categories, they could do it with the
classList.

>Alternatively, do you expect that there will be a limited 
>number of security policies and there is a plan to publish a 
>second document that lists these security policies along with 
>the rules for performing the above calculation for each of the 
>security policies?

The answer may well depend on whether this ID gets published ;) but I'd not
expect a huge amount of policies - based on the fact that not a lot of
people implmement security labels/clearances. Maybe NIST will do one?

>You say that other standards do something similar.  Can you 
>point to specific examples where a standard has been approved 
>despite leaving things as open ended as this?

This is where we get in to the you say interop and I say interop. I'm not
sure what you mean by "as open ended as this" but if I look for ANYs or any
where there's an undefined policy (I'm not trying to start a flame war or
open old wounds here):

PKIX:

RFC 3161 - TSAPolicyId - Is required but there's no required OID or the
defaults it says that must be defined.

RFC 3280 - Certificate Policies - CAs and applications are required to
support, but there's no required policy OID to include.

RFC 3281 - No attributes are required to be conveyed.
         - Clearance - uses the same syntax as our ID.

RFC 5055 - ValidationPolicy - Required as part of Querry with no MUST policy
OID and not requirements for the mandatory defaults.

S/MIME:

RFC 2634 - ESS Security Label - uses syntax similar to our ID.

I'm sure there are more.

Maybe this RFC motivates implementors to start supporting these two
extensions in their products because they see there's a market. Maybe all
the fields get supported - maybe not. The next step in the standardization
process determines what fields get culled.

spt

>CAClearanceConstraints extensions in a trust anchor 
>certificate.  If a CA wants to effectively impose such 
>constraints, shouldn't it include the constraint information 
>in all (non-self-issued) CA certificates that it issues.  As 
>for end entity certificates, the CA can constrain itself by 
>simply not issuing any certificates that violate the constraint.
>

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 21 Feb 2008 08:28:14 -0500

<snip>

[CRW] This could be categorized as associated data for a TA.  Similar to
certificate policies or name constraints, a TA may act more broadly than
a relying party wishes to accept when using that TA to validate
something.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 21 Feb 2008 10:31:54 -0500

Carl,

I agree with you that a relying party may wish to impose certain 
constraints.  However, this draft talks about including the 
CAClearanceConstraints extension in trust anchor certificates and then 
using the contents of that extension to initialize a path processing 
state variable.  This is a CA placing a constraints extension in a 
self-signed certificate to constrain itself.

Section 4.1.1 of the draft says that the processing is presented as 
additions to the path processing algorithm in RFC 3280.  If the intent 
is as you suggest, then the draft should specify 
initial-clearance-constraints as a new input to the path processing 
algorithm, which are used to initialize clearance related state 
variables.  This would be consistent with RFC 3280 and would make it 
clear that the relying party may impose initial constraints.

Dave

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 21 Feb 2008 10:41:53 -0500

[CRW] This sounds right to me, with the inclusion of the value as an
extension or "associated data" simply being a mechanism to populate the
input to the path validation engine.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 21 Feb 2008 10:57:40 -0500

> non-critical) and you don't have to carry the extra OID and SEQUENCE

I think it is pretty clear from both the language of X.501 and the 
syntax of the clearance attribute (compare the syntax for the clearance 
attribute with the syntax used for extensions):
                clearance ATTRIBUTE ::= {

                keyUsage EXTENSION ::= {

What you are doing is effectively creating a new certificate extension 
and assigning it an OID that has already been assigned to an existing 
attribute.  If you wish to use the existing OID, then you should profile 
the attribute assigned to that OID not define something new.  At the 
moment, there doesn't seem to be a need to define a new extension whose 
syntax is nearly identical to that of an existing attribute when the 
draft could just profile the use of the attribute.  Arguing that a new 
extension is needed since support for the subjectDirectoryAttributes 
extension is option is hardly compelling.  Anyone that wants to support 
the clearance attribute will need to support the 
subjectDirectoryAttributes extension, just as they would if they wanted 
to support the attributes in RFC 3739.  The subjectDirectoryAttributes 
extension is not a very complex extension to process.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 21 Feb 2008 11:07:08 -0500

David,

We require the constraint to be imposed.

What the I-D has and what you propose will result in the same answer
assuming constraint is imposed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Thursday, February 21, 2008 10:32 AM
To: Carl Wallace
Cc: pkix
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID

Carl,

Dave

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 21 Feb 2008 11:18:27 -0500

Dave,

We followed the example set by Stefan in the S/MIME Capabilities certificate
extension that uses an attribute's syntax as an extension's syntax. The
outcome of the discussion was that you didn't need to define a new structure
and that you could reuse the syntax because (to loosely paraphrase the
outcome of the discussions) you'll know it's an extension from context.

spt

>From: David A. Cooper [mailto:[email-masked]] 
>Sent: Thursday, February 21, 2008 10:58 AM
>To: Turner, Sean P.
>Cc: pkix
>>> I do not understand why this draft specifies that this attribute 
>>> should be encoded as an extension.  The clearance attribute is 
>>> defined as an Attribute.  The subjectDirectoryAttributes extension 
>>> was defined for the specific purpose of allowing attributes to be 
>>> included in certificates.
>certificate, it 
>>> should be placed in the subjectDirectoryAttributes extension.
>>>
>>> Why do people feel that there is a compelling reason to avoid using 
>>> the subjectDirectoryAttributes extension when encoding an attribute 
>>> in an extension?
>>>     
>>
>> X.501 says "The clearance can be bound to the Distinguished Name of 
>> the requestor through a certificate extension field (subject 
>Directory
>> attribute) or through an attribute certificate." This might be picky 
>> but that's not a MUST/SHALL or even a SHOULD for either. 
>(some or many 
>> may disagree with the following) I think people don't like 
>SDA because 
>> it's optional in RFC3280 - which basically means 
>unsupported. Now you 
>> can argue that adding a new attribute or a new extension still means 
>> it's all unsupported but at least if you define your own 
>extension you 
>> can pick whether you want criticality (note we always want clearance 
>> to be
>I think it is pretty clear from both the language of X.501 and 
>the syntax of the clearance attribute (compare the syntax for 
>the clearance attribute with the syntax used for extensions):
>What you are doing is effectively creating a new certificate 
>extension and assigning it an OID that has already been 
>assigned to an existing attribute.  If you wish to use the 
>existing OID, then you should profile the attribute assigned 
>to that OID not define something new.  At the moment, there 
>doesn't seem to be a need to define a new extension whose 
>syntax is nearly identical to that of an existing attribute 
>when the draft could just profile the use of the attribute.  
>Arguing that a new extension is needed since support for the 
>subjectDirectoryAttributes extension is option is hardly 
>compelling.  Anyone that wants to support the clearance 
>attribute will need to support the subjectDirectoryAttributes 
>extension, just as they would if they wanted to support the 
>attributes in RFC 3739.  The subjectDirectoryAttributes

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 21 Feb 2008 11:34:40 -0500

I can't comment on all of the drafts that you mention, but I am familiar 
with RFC 3280 and RFC 5055.

In the case of the certificatePolicies extension in RFC 3280, the path 
validation algorithm completely specifies how to process the extension.  
Code can be developed for CAs to include the extension in certificates 
and in relying parties to process the extension without any pre-existing 
knowledge about what policy OIDs may be included in the extension. While 
the syntax of policy qualifiers is open ended and each qualifier could 
have its own processing rules, RFC 3280 clearly discourages the use of 
policy qualifiers and further recommends that if they are included that 
only the two qualifiers defined in the document (along with processing 
rules) be used.

Similarly, while new name forms could be defined for inclusion in the 
otherName field of GeneralName and new processing rules could be defined 
for these name forms when they appear in a nameConstraints extension, 
RFC 3280 defines the processing rules for several of the name forms in 
GeneralName.  This makes it possible to use the nameConstraints 
extension in a way that permits interoperability even though the 
extension leaves room for future extensibility.

ValidationPolicy in RFC 5055 is similar.  ValidationPolicy simply allows 
a set of values to be associated with a single OID.  That means that in 
order to use a ValidationPolicy, both the client and server need to 
configured with the OID and the associated parameter values.  But, this 
is a configuration issue not an implementation issue.  Someone 
implementing the SCVP protocol does need to know about all of the 
ValidationPolicy OIDs that might be used since validation policies only 
specify input values not unique processing rules.  The person 
implementing SCVP simply needs to allow for the ability to read in 
information about validation policies from a configuration file.  While 
one part of the validation policy is the validation algorithm, and that 
certainly does include processing rules, SCVP defines two validation 
algorithms and in most cases it should be sufficient for the implementor 
to only write code to support these two validation algorithms.

Perhaps there is a middle ground in terms of the CAClearanceConstraints 
> That is why we did not write the rules.

If this means that there will only be two possible processing rules for 
calculating securityCategories intersections, then the draft could 
specify those two processing rules.  At least then, adding support for 
new security policies could be accomplished by adding information about 
a security policy to a configuration file to indicate which of the two 
processing rules should be used when processing the 
CAClearanceConstraints extension.  Currently the draft implies that 
there may be as many processing rules as there are security policies, 
which would mean new coding would be needed to add support for each 
additional policy.

At the moment, there is simply a big whole in the draft that makes it 
unimplementable by those who are reading the draft since there is a step 
in the processing algorithm that is left unspecified.  While the authors 
may have exposure to some security policies and may know 
securityCategories intersections should be processed for those security 
policies, what about everyone else reading the draft?

Dave

Turner, Sean P. wrote:
>>> So there are other standards that have essentially ANYs in 
>>>       
>> them where 
>>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 21 Feb 2008 11:48:41 -0500

Santosh,

I do not understand what you are trying to say.  There is a big 
difference between a CA using the contents of a self-signed certificate 
to impose constraints on itself and a relying party using an input to 
the path validation algorithm to impose constraints.

Are these constraints imposed by the relying party or by the CA that is 
being used by the relying party as a trust anchor? 

Santosh Chokhani wrote:
>> the constraint information in all (non-self-issued) CA certificates
>>     
> that
>   
>> it issues.  As for end entity certificates, the CA can constrain
>>     
> itself
>   
>> [CRW] This could be categorized as associated data for a TA.  Similar
>>     
> to
>   
>> certificate policies or name constraints, a TA may act more broadly
>>     
> than
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 21 Feb 2008 11:53:26 -0500

David,

The I-D is written with the intent that all these processing is done by
the relying party during path validation.

None of this is required (per this I-D) during certificate minting,
albeit that will be a good idea.

If you agree, we will be happy to make the crystal clear although I
recall going through significant pain to just do that prior to the
publication of the I-D.  If you point out what parts of the I-D lead to
this confusion, I will be happy to modify it accordingly.

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Thursday, February 21, 2008 11:49 AM
To: Santosh Chokhani
Cc: Carl Wallace; pkix
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID

Santosh,

> From: [email-masked]
[mailto:[email-masked]]