Subject: observations on the Clearance and CA Clearance extension discussion

From: Stephen Kent <[email-masked]>
Date: Thu, 21 Feb 2008 13:36:36 -0500

Folks,

I've been observing this discussion and want to take this opportunity 
to summarize what I see as the major issues that have been raised, 
provide my perspective on them, and suggest ways to resolve them.

1. Should we put authorization data of this sort in a PKC vs. an AC?

ACs were designed to convey authorization data, but PKIX has not 
prohibited carrying such data in PKCs. For example, RFC 3779 does so 
for IP address and AS number ranges. Since there are precedents  in 
Internet standards for carriage of authorization data in PKCs this 
argument need not be revisited.

2. If we carry this data in a PKC, should it be in the SDA extension 
or be a separate extension?

Although this is provision for carrying clearance data in the SDA 
extension, there is an argument for carrying it in a separate 
extension. In some instances (including the ones motivating this I-D) 
the clearance data may be processed by high assurance 
devices/software. In such cases one can argue that having an 
extension that carries only this data makes such high assurance 
processing easier. One might also argue that in such contexts one 
would mark this extension as critical. RFC 3280bis says the SDA 
extension is always non-critical, which also argues for creating a 
separate extension. I assume that most folks agree that the CA 
clearance constraints would be a new extension, a critical one. If 
the two sets of data are to be processed together in the contexts 
alluded to above, it seems to make sense that both be new extensions. 
A newly assigned OID for a new extension seems appropriate to me. I'd 
like to better the motivation to reuse the directory attribute OID 
here,

3. It's not clear that there is a need to put the CA constraints 
extension in a self-signed certificate, but it also is not clearly 
wrong. I can imagine contexts In which it makes sense to require that 
the data from this extension be present in a certificate path for 
certificate processing. That seems to allow three options: have a 
self-signed certificate representing a TA contain the extension, have 
a TA issue a certificate with the extension but not imbed it in the 
TA's self-signed certificate, or note that this is an example of 
"associated data" for a TA and is used to initialize the certificate 
path validation algorithm (as extended to accommodate this data).

RFC 3779 adopted the first option when it discussed the need to bind 
the address space and/or AS number data to a trust anchor. It states 
that a certificate serving as a trust anchor MUST contain the 
extensions that will be used to constrain instances of the extension 
in subsequent certificates in the path. So we have a precedent for 
option #1. However, given our ongoing efforts to more formally 
specify the notion associated data for a TA, it makes sense to 
consider the third option as well. I'd like to hear arguments about 
the merits (and demerits) of all three options, given

4. Stefan raised two concerns about putting clearance info in a 
certificate at all. Although he didn't say it precisely this way, I 
note that it is usually the case that the authorization of an 
individual to access classified data depends not only on the 
individual's clearance, but also on the (accreditation of the) 
machine being used to access the data, and on the location that 
machine (if it is portable). In my experience it is not appropriate 
to say that an individual's clearance changes based on the system he 
is using, but rather that an individual's authorization usually is 
constrained by the system he is using. I raised a similar issue with 
a earlier draft, noting that when a certificate with clearance data 
is issued to a machine, vs. a person, it is not really an expression 
of clearance, but of accreditation. The text I the draft needs to 
accurately reflect this subtle distinction. Stefan also noted that 
the requisite path validation algorithm extensions are non-trivial. 
If the authors want to qualify the intended contexts in which it is 
expected that the newly proposed pair of extensions will be used, 
that might mitigate this concern. The authors need to address these 
issues in the text.

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 22 Feb 2008 08:56:08 +0000

Steve, thank you for the writeup.

Let me clarify on issue 4. What I meant was more in terms of that I may have different clearances within different information systems or resources, or even different parts of an information system. I may for example have high clearance to read certain technical specifications on projects I work on, while a much lower clearance on other specifications. At the same time I may not have any clearance at all to read financial information or marketing strategies. So typically there is not one clearance that can be tied to my identity and a public key unless the usage of that certificate is limited to one local system or resource where I have a common clearance level for all information within it.

If we go this path, I would not be surprised to see demands of more granular clearance information in certificates where multiple clearance level declarations for various different target systems or resources are stated. This would open up for a whole new set of problems, e.g. how to uniformly name and identify a target system or a limited resource for which this clearance is relevant. Further if this is to be supported by a path validation logic, the algorithm may grow to become very complex.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: den 21 februari 2008 19:37
To: [email-masked]
Subject: observations on the Clearance and CA Clearance extension discussion

Folks,

I've been observing this discussion and want to take this opportunity to summarize what I see as the major issues that have been raised, provide my perspective on them, and suggest ways to resolve them.

ACs were designed to convey authorization data, but PKIX has not prohibited carrying such data in PKCs. For example, RFC 3779 does so for IP address and AS number ranges. Since there are precedents  in Internet standards for carriage of authorization data in PKCs this argument need not be revisited.

2. If we carry this data in a PKC, should it be in the SDA extension or be a separate extension?

Although this is provision for carrying clearance data in the SDA extension, there is an argument for carrying it in a separate extension. In some instances (including the ones motivating this I-D) the clearance data may be processed by high assurance devices/software. In such cases one can argue that having an extension that carries only this data makes such high assurance processing easier. One might also argue that in such contexts one would mark this extension as critical. RFC 3280bis says the SDA extension is always non-critical, which also argues for creating a separate extension. I assume that most folks agree that the CA clearance constraints would be a new extension, a critical one. If the two sets of data are to be processed together in the contexts alluded to above, it seems to make sense that both be new extensions. A newly assigned OID for a new extension seems appropriate to me. I'd like to better the motivation to reuse the directory attribute OID here,

3. It's not clear that there is a need to put the CA constraints extension in a self-signed certificate, but it also is not clearly wrong. I can imagine contexts In which it makes sense to require that the data from this extension be present in a certificate path for certificate processing. That seems to allow three options: have a self-signed certificate representing a TA contain the extension, have a TA issue a certificate with the extension but not imbed it in the TA's self-signed certificate, or note that this is an example of "associated data" for a TA and is used to initialize the certificate path validation algorithm (as extended to accommodate this data).

RFC 3779 adopted the first option when it discussed the need to bind the address space and/or AS number data to a trust anchor. It states that a certificate serving as a trust anchor MUST contain the extensions that will be used to constrain instances of the extension in subsequent certificates in the path. So we have a precedent for option #1. However, given our ongoing efforts to more formally specify the notion associated data for a TA, it makes sense to consider the third option as well. I'd like to hear arguments about the merits (and demerits) of all three options, given

4. Stefan raised two concerns about putting clearance info in a certificate at all. Although he didn't say it precisely this way, I note that it is usually the case that the authorization of an individual to access classified data depends not only on the individual's clearance, but also on the (accreditation of the) machine being used to access the data, and on the location that machine (if it is portable). In my experience it is not appropriate to say that an individual's clearance changes based on the system he is using, but rather that an individual's authorization usually is constrained by the system he is using. I raised a similar issue with a earlier draft, noting that when a certificate with clearance data is issued to a machine, vs. a person, it is not really an expression of clearance, but of accreditation. The text I the draft needs to accurately reflect this subtle distinction. Stefan also noted that the requisite path validation algorithm extensions are non-trivial. If the authors want to qualify the intended contexts in which it is expected that the newly proposed pair of extensions will be used, that might mitigate this concern. The authors need to address these issues in the text.

---

From: Timothy J Miller <[email-masked]>
Date: Fri, 22 Feb 2008 10:34:30 -0600

On Feb 21, 2008, at 12:36 PM, Stephen Kent wrote:

> extension. In some instances (including the ones motivating this I- 
> D) the clearance data may be processed by high assurance devices/ 
> software. In such cases one can argue that having an extension that  
> carries only this data makes such high assurance processing easier.  
> One might also argue that in such contexts one would mark this  
> extension as critical. RFC 3280bis says the SDA extension is always  
> non-critical, which also argues for creating a separate extension.

Wouldn't a resolution to this be to allow SDC to be critical?  What  
would be the impact of such a change?  (Apologies if someone covered  
this previously if I missed it.)

> to say that an individual's clearance changes based on the system  
> he is using, but rather that an individual's authorization usually  
> is constrained by the system he is using.

It's most accurate to say:

level asserted = min(level of person, level of data path)

:)

(Of course, in the national security arena, clearance is only part of  
it.  Compartment is arguably more important.)

-- Tim

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Feb 2008 17:37:34 -0500

At 10:34 AM -0600 2/22/08, Timothy J Miller wrote:
>>extension. In some instances (including the ones motivating this 
>>I-D) the clearance data may be processed by high assurance 
>>separate extension.

SDA is never critical. It's a "junk" extension that we don't really 
like anyway :-).  Burying important data in it is a bad idea.

Steve