Subject: Re: observations on the Clearance and CA Clearance extension discussion

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 25 Feb 2008 15:49:25 +0100

There are one additional issue not mentioned below:

5 - Should we copy and paste the definition of clearance made in RFC 3281 ?

Although many people support that opinion, there has been objections to do it, 
since this definition does not allow to support security sensitivities independently of the security category.

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

In addition, 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).

Another argument is interoperability: the current definition of SecurityCategory is too open 
to allow for interoperability. The draft does not allow to implement interoperable solutions. 

Denis

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-trivi!
 al!
. 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: Russ Housley <[email-masked]>
Date: Mon, 25 Feb 2008 16:59:04 -0500

Denis:

The list of classifications can be augmented by the policy that is
specified.  This is very clear in RFC 3281, which says:

An organization can develop its own security policy that
defines

security classification values and their meanings.
However, the BIT

STRING positions 0 through 5 are reserved for the basic
security

classification hierarchy.

If you have an access control policy that requires something other than
classification and categories, then this data structure is not going to
work for you.  Fine.  Do not try to changes this
structure.  Instead define a different one with a different name and
object identifier.  This one seems to be working for many
organizations.  Please do not mess with it.

Russ

At 09:49 AM 2/25/2008, Denis Pinkas wrote:

There are one additional issue
not mentioned below:

5 - Should we copy and paste the definition of clearance made in RFC 3281
?

Although many people support that opinion, there has been objections to
do it,

since this definition does not allow to support security sensitivities
independently of the security category.

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

In addition, the classList definition is incorrect for the two first bits
and does not even support

(called "security classification values", which is not an
adequate terminology).

Another argument is interoperability: the current definition of
SecurityCategory is too open

to allow for interoperability. The draft does not allow to implement
interoperable solutions.

Denis

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.