Subject: Clearance & CA Clearance Constraints Cert Ext ID

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 11 Jan 2008 16:00:45 -0500

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: Russ Housley <[email-masked]>
Date: Sat, 12 Jan 2008 09:18:29 -0500

While this extension is primarily useful to a Government/Military 
environment, it does have some applicability to commercial 
environments too.  This situation is demonstrated in RFC 3114.  I see 
advantages to all of the potential users if this specification is 
published on the IETF standards-track.

I encourage the PKIX WG to accept this document.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jan 2008 11:04:11 -0500

Sean,

I'm in favor of making this a PKIX document, especially given Russ's 
endorsement :-).  However, I see a need to be careful in the wording 
used here. If the cert is issued to a person to define the 
individual's clearance, the words used are not the same as those used 
to describe the classification of data. So, for example, I see the 
term "unclassified" in the ClassList data structure. An individual 
does not hold an "unclassified" clearance, although data may be 
unclassified. Also, a user is not "unmakred."  It looks like these 
terms were taken from a document classification marking context.

Steve

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 14 Jan 2008 09:27:21 -0800

> We're hoping that PKIX would be willing to adopt this as a work item.

I have no objection to the WG taking on work in this area.

With regard to this I-D, I'd like to see it discuss how the proposed  
extension relates (or not) to the X.500 clearance attribute.

-- Kurt

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 14 Jan 2008 17:00:35 -0500

Kurt,

We import the clearance syntax from RFC 3281, which took the syntax from
X.509.

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Kurt Zeilenga
>Sent: Monday, January 14, 2008 12:27 PM
>To: Turner, Sean P.
>Cc: [email-masked]
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
>
>> 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:
>>
>> 
>With regard to this I-D, I'd like to see it discuss how the 
>proposed extension relates (or not) to the X.500 clearance attribute.
>
>-- Kurt
>
>

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 14 Jan 2008 17:14:15 -0500

Steve,

You're right - the "unclassified" and "unmarked" values don't make sense in
terms of a clearance. We could change it to something like: the values
indicate the classification level of data the subject is allowed to access?

spt 

>[mailto:[email-masked]] On Behalf Of Stephen Kent
>Sent: Monday, January 14, 2008 11:04 AM
>To: Turner, Sean P.
>Cc: [email-masked]
>I'm in favor of making this a PKIX document, especially given 
>Russ's endorsement :-).  However, I see a need to be careful 
>in the wording used here. If the cert is issued to a person to 
>define the individual's clearance, the words used are not the 
>same as those used to describe the classification of data. So, 
>for example, I see the term "unclassified" in the ClassList 
>data structure. An individual does not hold an "unclassified" 
>clearance, although data may be unclassified. Also, a user is 
>not "unmakred."  It looks like these terms were taken from a 
>document classification marking context.
>
>Steve
>

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 14 Jan 2008 14:44:55 -0800

> We import the clearance syntax from RFC 3281, which took the syntax  

My concern is that X.501 provided a means for including a clearance in  
an X.509 certificate.  Your I-D proposes another means.  There should  
be some discussion (in the I-D), at a minimum, as to why a second  
means is needed.

-- Kurt

>> http://www.ietf.org/internet-drafts/draft-turner- 
>> caclearanceconstraint
>>> s-00.t
>>> xt
>>>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jan 2008 18:29:27 -0500

>indicate the classification level of data the subject is allowed to access?

That's a good start to addressing my wording complaint, but then 
those two values seem redundant, i.e., every individual is authorized 
to access unclass and unmarked data, so why bother having these?

Note that if these certs were for machines, not people, these might 
make sense, but the text indicated that these are to be issued to 
users, so I am assuming the scope is just that.

Steve

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Jan 2008 09:07:56 -0500

To align with the work in the X.500 series of documents....

At 06:29 PM 1/14/2008, Stephen Kent wrote:

>those two values seem redundant, i.e., every individual is 
>authorized to access unclass and unmarked data, so why bother having these?
>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Jan 2008 12:31:04 -0500

>To align with the work in the X.500 series of documents....

then we need to do a better job of explaining the meaning of the 
class bits, since they represent poor English usage when applied to 
people holding clearances Since device don't hold clearances (they 
are accredited), the terminology needs to be fixed to describe them 
appropriately.

Steve