Subject: RE: Rationales for CA clearance constraints

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Oct 2008 08:05:38 -0400

Stefan,

here are some observations re your message from Tuesday.

>Let me recap:
>
>1) Practical use of PKI, primary in defense/military applications 
>has resulted in a need to include clearance information in 
>certificates.

yes

>2) These applications require clearance constraints processing

yes

3) Clearance is defined within a context. An infinite combination of 
context and clearance levels may exist.

the operative term here is may. in practice I don't think there will 
be that many combinations of contexts and clearance levels.

>
>4) The constraints mechanism calculates the effective clearance of 
>an End Entity (EE). The effective clearance for the EE is the 
>intersection of all clearances of the path.

yes.

>5) Calculation of effective clearance is dependent on the definition 
>of clearance levels (classList) and context (securityCategories and 
>policyId), and has no default deterministic logic.

yes.

>This differs IMO from anything else we have defined in the past in 
>one important way. No prior path validation mechanism that we have 
>defined previously (that I can think of) requires you to calculate 
>an intersection of values without providing you with the logic for 
>calculating that intersection.

fair criticism.

>- For policy constraints, I can calculate intersection of valid 
>policies without knowing the meaning of each policy.

because the intersection is computed just on the OID values, right?

>- Name constraints are only valid for hierarchical name forms and 
>each name form defines the "intersection" logic for matching 
>constraints

yes, and the same is true for the address space and AS # extensions 
defined in RFC 3779. BTW, 3779 is a good example of a standard that 
extends the path processing logic, but does not claim to change the 
underlying base spec (3280.5280).

>This may seem like a small thing, but I'm not sure it is. If we 
>define standards that require us to calculate a certain value X 
>without defining the logic for calculating X, then I fear that we 
>may create serious interoperability problems and set precedence for 
>bad protocol design. Or am I just seeing ghosts?

I think you have done a good job of concisely characterizing the 
issues we have been discussing, and have clearly articulated your 
concerns.

We could chose to simply the situation, a bit, by requiring that the 
same clearance policy id be present in all of the certs in a path. 
Sean & Santosh, do we think there are circumstances where that 
constraint would pose problems? If not, then this simplifies the 
problem, a bit, because it means that the same intersection logic 
will apply down the path.

We do have to face the fact that a relying party processing either 
extension will have to have a way to plug in software that knows how 
to do this processing, on a per-policy basis. This is analogous to 
supporting different signature and hash algorithms, but admittedly 
more complex because of the need
to use this code during path processing. Nonetheless, the bottom line 
is similar:

         - not all RPs will need to know how to process these extensions.

         - RPs that do know how to process these extensions do not need
           to know  how to process all policy IDs.

         - an RP that does deal with these extensions probably will need to
           deal with one or a very few policy IDs. If this is true, then only
           a few plug-in modules will be needed by an RP. this is similar to
           the typical RP need for crypto algorithm support.

I think you have identified two primary concerns:

         - a vendor who serves a very wide range of users needs to have
           a way for its RP software to load plug-ins for various policy IDs,
           to enable clearance and clearance constraint processing,

         - that vendor, or others, need to write the plug-ins for the user
           community.

I'm not convinced that this a bigger challenge than dealing crypto 
algorithms specified by OIDs. Crypto algorithms also have to be 
invoked at each tier in cert path validation process. Yes, the 
interface to the plug-ins is a bit more complex, but the parameters 
that need to be passed to a clearance plug-in are well-defined. There 
is a similar need to be able to manage the loading of clearance (and 
algorithm) plug-ins in a secure fashion.

Stefan, I just saw your message of a few minutes ago. I'm glad you 
agree that PKIX can take o this new work item. The straw poll yielded 
a majority of votes in favor of the work, although there was far from 
unanimous agreement on this topic.

Sean & Santosh, please post an updated version of the document as a 
00 PKIX I-D as soon as possible.

Thanks,

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 29 Oct 2008 09:03:02 -0400

Steve,

At a minimum, binary comparison of constraints in the intermediate
certificates and the clearance in the end certificates is possible even
if the syntax and semantics of value for the various security categories
TYPE are unknown.  Given all these are SET, the binary comparison can be
efficiently implemented.

That could be the minimum processing for all TYPE OID.  If the RP knows
the syntax and semantics of values for a given TYPE, it can do finer
processing.

In the default processing, lack of match for a category will result in
its deprecation and not the rejection of certificate.  This is safe and
secure.

If you like, we can enhance the I-D along these lines and let the group
review it.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Wednesday, October 29, 2008 8:06 AM
To: Stefan Santesson
Cc: [email-masked]
Subject: RE: Rationales for CA clearance constraints

Stefan,

		Let me recap:

		1) Practical use of PKI, primary in defense/military
applications has resulted in a need to include clearance information in
certificates.

yes

		2) These applications require clearance constraints
processing

yes

	3) Clearance is defined within a context. An infinite
combination of context and clearance levels may exist.

the operative term here is may. in practice I don't think there will be
that many combinations of contexts and clearance levels.

		4) The constraints mechanism calculates the effective
clearance of an End Entity (EE). The effective clearance for the EE is
the intersection of all clearances of the path.

yes.

		5) Calculation of effective clearance is dependent on
the definition of clearance levels (classList) and context
(securityCategories and policyId), and has no default deterministic
logic.

yes.

		This differs IMO from anything else we have defined in
the past in one important way. No prior path validation mechanism that
we have defined previously (that I can think of) requires you to
calculate an intersection of values without providing you with the logic
for calculating that intersection.

fair criticism.

		- For policy constraints, I can calculate intersection
of valid policies without knowing the meaning of each policy.

		- Name constraints are only valid for hierarchical name
forms and each name form defines the "intersection" logic for matching
constraints

		This may seem like a small thing, but I'm not sure it
is. If we define standards that require us to calculate a certain value
X without defining the logic for calculating X, then I fear that we may
create serious interoperability problems and set precedence for bad
protocol design. Or am I just seeing ghosts?

I think you have done a good job of concisely characterizing the issues
we have been discussing, and have clearly articulated your concerns.

We could chose to simply the situation, a bit, by requiring that the
same clearance policy id be present in all of the certs in a path. Sean
& Santosh, do we think there are circumstances where that constraint
would pose problems? If not, then this simplifies the problem, a bit,
because it means that the same intersection logic will apply down the
path.

We do have to face the fact that a relying party processing either
extension will have to have a way to plug in software that knows how to
do this processing, on a per-policy basis. This is analogous to
supporting different signature and hash algorithms, but admittedly more
complex because of the need

to use this code during path processing. Nonetheless, the bottom line is
similar:

        - an RP that does deal with these extensions probably will need
to

          deal with one or a very few policy IDs. If this is true, then
only

          a few plug-in modules will be needed by an RP. this is similar
to

          a way for its RP software to load plug-ins for various policy
IDs,

        - that vendor, or others, need to write the plug-ins for the
user

          community.

I'm not convinced that this a bigger challenge than dealing crypto
algorithms specified by OIDs. Crypto algorithms also have to be invoked
at each tier in cert path validation process. Yes, the interface to the
plug-ins is a bit more complex, but the parameters that need to be
passed to a clearance plug-in are well-defined. There is a similar need
to be able to manage the loading of clearance (and algorithm) plug-ins
in a secure fashion.

Stefan, I just saw your message of a few minutes ago. I'm glad you agree
that PKIX can take o this new work item. The straw poll yielded a
majority of votes in favor of the work, although there was far from
unanimous agreement on this topic.

Sean & Santosh, please post an updated version of the document as a 00
PKIX I-D as soon as possible.

Thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 30 Oct 2008 00:46:13 -0400

At 9:03 AM -0400 10/29/08, Santosh Chokhani wrote:
>certificates and the clearance in the end certificates is possible 
>even if the syntax and semantics of value for the various security 
>categories TYPE are unknown.  Given all these are SET, the binary 
>comparison can be efficiently implemented.
>
>That could be the minimum processing for all TYPE OID.  If the RP 
>knows the syntax and semantics of values for a given TYPE, it can do 
>finer processing.
>
>In the default processing, lack of match for a category will result 
>in its deprecation and not the rejection of certificate.  This is 
>safe and secure.
>
>If you like, we can enhance the I-D along these lines and let the 
>group review it.
>

yes, please do.

Thanks,

Steve