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

From: Stefan Santesson <[email-masked]>
Date: Thu, 21 Feb 2008 16:07:11 +0000

First I want to apologize for a somewhat late response to this issue. I have been away from work due to my mother's passing but I'm now fully back and operational.

I'm somewhat surprised to see such overwhelming support for this draft. Personally I have some big concerns.

Including authorization and clearance information in certificates is both tricky and dangerous. In my opinion certificates is the least suitable place for such information.
Clearance is not just tied to a person, but to systems and I may have a wide range of clearances in different systems. Clearance may change very rapidly while certificates and more static declarations of the relationship between a person and a set of keys. So they do not naturally mix very well.

Further, the extension of this draft affects path validation. This means that supporting this extension involves a HUGE commitment from product development compared to an extension that is only parsed locally in the relying party's application. An extension that is processed in path validation requires not only changes to the path validation algorithm. It will also require API changes to accommodate status and error codes as well as results.

I don't find any motivation for this new standard that makes me believe that it is worth the effort and I therefore object to this being adopted as a PKIX work item.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 12 januari 2008 15:18
> To: [email-masked]
> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
> 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
>
> At 04:00 PM 1/11/2008, Turner, Sean P. wrote:
>
> >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: "Santosh Chokhani" <[email-masked]>
Date: Thu, 21 Feb 2008 12:16:39 -0500

Stefan,

Let us look at the issue of clearance in a certificate first.  The
reason to include the clearance in a certificate is that in many
environments clearance is relatively static.  Also, asserting clearance
in certificates is appropriate since security office who knows or holds
personnel clearances also is involved in issuing certificates.  Finally,
putting them in certificates and vetting them provides a cost-effective
binding.

Now, to your objection regarding path validation.  First of all, the
only time the extra goo is required, is when you want to obtain and
enforce the clearance.  If you do not need to process clearance, you do
not have to.  The only time path processing is impacted is if the CA
asserted clearance constraints as critical.

The processing rules while large to spell out, simply say that do not
delegate something you are not authorized to delegate.  3281
specifically punted on this issue (i.e., AC chain).  So, I do not see
the big problem.  Most access control models, e.g., Role Based Access
Control (RBAC) work that way.  You can not delegate a role unless you
explicitly authorized to delegate the role.

One would think that those implementations that provide chain of
authorizations will need to meet the basic property of not asserting
authorization you are not permitted to delegate.

I also do not see every implementation needing this, unless they want to
provide clearance processing capability.

So, I have the following question for you: Do you have a better
suggestion to meet the needs to communities that need to process
clearances in secure manner?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, February 21, 2008 11:07 AM
To: Russ Housley; [email-masked]
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID

First I want to apologize for a somewhat late response to this issue. I
have been away from work due to my mother's passing but I'm now fully
back and operational.

I'm somewhat surprised to see such overwhelming support for this draft.
Personally I have some big concerns.

Including authorization and clearance information in certificates is
both tricky and dangerous. In my opinion certificates is the least
suitable place for such information.
Clearance is not just tied to a person, but to systems and I may have a
wide range of clearances in different systems. Clearance may change very
rapidly while certificates and more static declarations of the
relationship between a person and a set of keys. So they do not
naturally mix very well.

Further, the extension of this draft affects path validation. This means
that supporting this extension involves a HUGE commitment from product
development compared to an extension that is only parsed locally in the
relying party's application. An extension that is processed in path
validation requires not only changes to the path validation algorithm.
It will also require API changes to accommodate status and error codes
as well as results.

I don't find any motivation for this new standard that makes me believe
that it is worth the effort and I therefore object to this being adopted
as a PKIX work item.

Stefan Santesson
Senior Program Manager

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 21 Feb 2008 13:26:35 -0500

<snip>

[CRW] The sort of operation described in the draft could be performed as
post-processing using the output of a vanilla 3280 path processor.
Direct integration into a 3280 engine is not required but could be
implemented where desired.  Maybe the draft should state something along
those lines.

---

From: Timothy J Miller <[email-masked]>
Date: Thu, 21 Feb 2008 14:11:49 -0600

On Feb 21, 2008, at 11:16 AM, Santosh Chokhani wrote:

> environments clearance is relatively static.

Only at its lowest and grossest levels.  At higher levels, frex above  
US TS, special program accesses can be very dynamic--particularly  
over the multi-year lifetime of a user certificate.

My particular objection is that by implication you are relying on the  
*revocation* infrastructure to control access to materials based on  
clearance.  This is unwise.  Revocation is neither guaranteed nor  
timely in real-world PKIs--particularly large ones.  Access is better  
controlled by, well, access control systems.

> Also, asserting clearance
> personnel clearances also is involved in issuing certificates.

This is not true everywhere.  DoD certificates are managed by  
personnel offices, not security.

> Finally,

So do attribute certs.  However, you're also overlooking the hidden  
costs caused by additionally burdening the revocation infrastructure-- 
because if you're using a clearance extension I *guarantee* you'll  
end up doing more revocations.

> clearances in secure manner?

Yes, I do.  Invest in an identity management system and an  
*authorization* framework.  You'll be better off.

-- Tim

---

From: Timothy J Miller <[email-masked]>
Date: Thu, 21 Feb 2008 14:12:40 -0600

On Feb 21, 2008, at 10:07 AM, Stefan Santesson wrote:

> Including authorization and clearance information in certificates  
> is both tricky and dangerous. In my opinion certificates is the  
> least suitable place for such information.

Amen brother.  Preach it!

-- Tim

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Feb 2008 15:48:30 -0500

>controlled by, well, access control systems.

Yes, and no.

If people place short-lived authorization information in the public 
key certificate (PKC), then they will have many management 
headaches.  This is only appropriate for very stable authorization 
information. This is related to RFC 3281, which says:

    Authorization information may be placed in a PKC extension or placed
    in a separate attribute certificate (AC).  The placement of
    authorization information in PKCs is usually undesirable for two
    reasons.  First, authorization information often does not have the
    same lifetime as the binding of the identity and the public key.
    When authorization information is placed in a PKC extension, the
    general result is the shortening of the PKC useful lifetime.  Second,
    the PKC issuer is not usually authoritative for the authorization
    information.  This results in additional steps for the PKC issuer to
    obtain authorization information from the authoritative source.

I believe that this is all still correct.  Yet, there are people that 
want to put clearance information into public key certificates.  It 
is important to me that the syntax for representing the clearance in 
a certificate and an attribute certificate are exactly the same.  RFC 
3281 already specifies it for an attribute certificate.  There are 
folks who are going to put clearance information in a 
certificate.  I'd like them all to do it the same way, so that when 
policy permits, they can interoperate.

>>in certificates is appropriate since security office who knows or
>>holds personnel clearances also is involved in issuing certificates.
>

This is covered by the quoted text from RFC 3281.  Yet, some people 
really want to impose the extra step on CAs in support of real 
applications.  Again, I'd like them all to do it the same way, so 
that when policy permits, they can interoperate.

>>Finally,
>>putting them in certificates and vetting them provides a cost- effective
>>binding.
>
>costs caused by additionally burdening the revocation 
>infrastructure-- because if you're using a clearance extension I 
>*guarantee* you'll

No doubt.  This argument has not deterred the folks that want to do it.

>*authorization* framework.  You'll be better off.

As an author of RFC 3281, I've made these same arguments to no 
avail.  So, the reason I want to see PKIX take this on it to allow a 
straight forward migration to attribute certificates (because the 
same syntax is used).   If each organization that wants to do this 
does it their own way, we will be much worse off.

Russ

---

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

Tim,

See responses in-line.

-----Original Message-----
From: Timothy J Miller [mailto:[email-masked]] 
Sent: Thursday, February 21, 2008 3:12 PM
To: Santosh Chokhani
Cc: Stefan Santesson; Russ Housley; [email-masked]
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID

Only at its lowest and grossest levels.  At higher levels, frex above  
US TS, special program accesses can be very dynamic--particularly  
over the multi-year lifetime of a user certificate.
[Santosh] Some of the scenarios we have in mind, the certificates themselves
may be shorter life time than you stipulate.

My particular objection is that by implication you are relying on the  
*revocation* infrastructure to control access to materials based on  
clearance.  This is unwise.  Revocation is neither guaranteed nor  
timely in real-world PKIs--particularly large ones.  Access is better  
controlled by, well, access control systems.
[Santosh] If multiple relying parties rely on an attribute, in a distributed
framework, it is better to have the bestowing authority revoke the
attribute.  If a particular relying party is concerned about an attribute,
it can have its additional checks.  It is equally unwise to assume that
revocation of an attribute will be carried out by multiple relying parties
properly.

[Santosh] A better solution may be SAML authorization assertions.  However,
in that scenario the SAML Authorization Server is the one that implements
what this I-D says.

> holds

This is not true everywhere.  DoD certificates are managed by  
personnel offices, not security.
[Santosh] In many environments, badging and security go hand in hand and
that is where credentials are issued.

[Santosh] That is simply a cost trade off.  BTW, AC do not mitigate the
revocation problem.

Yes, I do.  Invest in an identity management system and an  
*authorization* framework.  You'll be better off.
[Santosh] We have several tools such as local access control, attribute
certificates, SDA in PKC, SAML Authorization Servers (which can work from
AC, PKC or local knowledge).  Saying one shoe fits all is wrong.

[Santosh]Besides, this I-D provides processing rules for hierarchical,
distributed environments.  Authorization determination engine implementation
location will determine where this logic goes.  So, if you had SAML Servers
or local decision makers (based on objects created by distributed
authorities), that the processing rules will be implemented there.

-- Tim

---

From: Timothy J Miller <[email-masked]>
Date: Thu, 21 Feb 2008 15:07:53 -0600

On Feb 21, 2008, at 2:48 PM, Russ Housley wrote:

> I believe that this is all still correct.  Yet, there are people  
> that want to put clearance information into public key  
> certificates.  It is important to me that the syntax for  
> representing the clearance in a certificate and an attribute  
> certificate are exactly the same.  RFC 3281 already specifies it  
> for an attribute certificate.  There are folks who are going to put  
> clearance information in a certificate.  I'd like them all to do it  
> the same way, so that when policy permits, they can interoperate.

[...]

> avail.  So, the reason I want to see PKIX take this on it to allow  
> a straight forward migration to attribute certificates (because the  

Then we agree.  :)

I should have been clearer; I wasn't questioning the method, I was  
questioning the motive.  I'm dead-set against contaminating my  
authentication instrument with authorization data.  But if that's  
something someone wants to do--misguided though it may be--then any  
method that provides a clear path from authN-cum-authZ cert to  
attribute cert is the best way to go.

-- Tim

---

From: Timothy J Miller <[email-masked]>
Date: Thu, 21 Feb 2008 15:13:13 -0600

On Feb 21, 2008, at 2:48 PM, Turner, Sean P. wrote:

> The access control system is still in control of access.  The  
> output of the
> path processing is the subject's clearances not an access control  
> decision.
> The output of the path processing can be passed to the access  
> control system
> to make it's decision.

Through this binding you're tying the validity assurance of clearance  
data to the validity assurance of the certificate.  I'd assert that  
generally speaking you want/need *higher* validity assurance of  
clearance.  Yes, this can vary by environment, but I'm willing to bet  
that this would be generally true.

However, as Russ so gently pointed out, discussing the "why" of this  
is off-topic.

-- Tim

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 21 Feb 2008 17:37:51 -0500

Russ Housley wrote:
> It is important to me that the syntax for representing the clearance 
> in a certificate and an attribute certificate are exactly the same.  
> RFC 3281 already specifies it for an attribute certificate.  There are 
> folks who are going to put clearance information in a certificate.  
> I'd like them all to do it the same way, so that when policy permits, 
> they can interoperate.

Unfortunately, the current draft is working against this goal.  There is 
already a mechanism defined in X.501 including clearance information in 
a public key certificate.  X.501 defines the clearance attribute, which 
(as X.501 notes) would be placed in the subjectDirectoryAttributes 
extension when included in a public key certificate.  This draft defines 
a new certificate extension that uses the syntax and OID of the X.501 
clearance attribute.  Thus, there will be two ways defined for CAs to 
include clearance information in public key certificates, even though 
both use the same syntax.  If the goal is for everyone to encode this 
information in public key certificates in the same way, then we 
shouldn't base achieving that goal on the assumption that everyone will 
ignore X.501 when determining how to encode an X.501 defined attribute.

Dave

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Feb 2008 15:14:52 -0800

At 3:48 PM -0500 2/21/08, Russ Housley wrote:
>that want to put clearance information into public key certificates. 
>RFC 3281 already specifies it for an attribute certificate.  There 
>are folks who are going to put clearance information in a 

Sure. But shouldn't the specification also give the reader sharp 
warnings about both the problems associated with doing so, and 
pointers to ways that we think are better? I see nothing about this 
in the intro of the draft; it is also absent from the Security 
Considerations.

>does it their own way, we will be much worse off.

But if other organizations read this document and think it is a good 
idea, *they* will be worse off. It seems short-sighted for all of us 
on this list to know that attributes certs are better suited for 
this, but the document be silent about that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 21 Feb 2008 23:45:28 +0000

> *authorization* framework.  You'll be better off.

I really support this view. About everything I have seen and experienced in this space indicates that this is true.
What I think we need is not a more complex and harder to manage PKI, but rather to consolidate PKI to its core function to assert a relationship between an entity and a key.

Stefan Santesson
Senior Program Manager

> Sent: den 21 februari 2008 21:12
> To: Santosh Chokhani

---

From: Stephen Kent <[email-masked]>
Date: Thu, 21 Feb 2008 23:09:28 -0500

Tim,

The cert for my secure phone has always contained clearance info, for 
20+ years. It represents both clearance level info and category info. 
The motivation for this is that the key in the cert is tightly 
managed, and that is a very expensive management task. To put the 
clearance info elsewhere would require a separate, expensive 
management system. As a result, the two are combined.

I agree that fine grained clearance info may not be appropriate for 
certs, but one cannot make a flat statement that such use will not 
work or will be dangerous. The viability of such use depends on 
context, and there are lots of different contexts.  You cite 
multi-year cert lifetimes, but the cert for my phone must be renewed 
yearly, so that example is not consistent with your cited experience.

My experience is that many folks are granted access to major 
categories for very long intervals, so even above the collateral 
level info there is value in being able to express this clearance 
info in certs.

Your comment about who issues certs/badge vs. clearance management is 
simply not uniformly true. Maybe you're comments are based on 
experience with the CAC and software certs issued by DISA; you didn't 
say.  The CAC is a poster boy for a badly designed PKI, in numerous 
ways, so I would not use it as good model (for almost anything).

I am familiar with examples of certs issued in DoD under other 
paradigms, which are not consistent with many of your observations. 
SO I think it's fair to say that while it may not always be a good 
idea to put clearance info into PKCs, it is not true that it is never 
a god idea.

Steve

---

From: Stephen Wilson <[email-masked]>
Date: Fri, 22 Feb 2008 17:09:15 +1100

Stephen Kent wrote:

> The motivation for this is that the key in the cert is tightly managed, 
> and that is a very expensive management task. To put the clearance info 
> elsewhere would require a separate, expensive management system. As a 
> result, the two are combined.

I agree.  And to generalise, this is why I think Attribute Certificates 
don't often make much sense.  They imply two separate management systems 
when just one would suffice if we relaxed the taboo on "authorisation" 
being blended with "authentication".

Obviously short term clearances and short term 'attributes' in general 
are not such a good fit for X.509 certificates but obviously lots of 
clearances last for years.

> certs, but one cannot make a flat statement that such use will not work 
> or will be dangerous. The viability of such use depends on context, and 
> there are lots of different contexts.  You cite multi-year cert 
> lifetimes, but the cert for my phone must be renewed yearly, so that 
> example is not consistent with your cited experience.

Roger that!

Cheers,

Steve Wilson.

Chair, OASIS PKI Adoption TC
Managing Director, Lockstep Group

Phone +61 (0)414 488 851

www.lockstep.com.au
-------------------
Lockstep Consulting provides independent specialist advice and analysis 
on identity management, PKI and smartcards.  Lockstep Technologies 
develops unique new smartcard technologies to address transaction 
privacy and web fraud.

---

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

Russ,

> does it their own way, we will be much worse off.

I'm not so sure.

I spent many years of my life as a consultant in government projects of various kinds in Europe and I've seen the kind of impact an RFC like this one can have. A typical scenario is that government agency X in country Y hires an "expert" on PKI that heard of this new standard for how to deal with clearance information, indicating the direction of the industry. This now becomes a fundamental requirement for delivering solutions to this government project which impacts the whole system design. The story ends like a huge number of these projects, that 5-10 years later the users of the targeted information system still uses password based authentication because the high profiled government PKI project crashed under its own weight.

I think I'd much rather see such extension defined within the limited community that think they need it over an international standard with a IETF/PKIX rubber stamp on it. Then of course, if it gets widely deployed, nothing prevents us from endorsing it as an RFC.

Stefan Santesson
Senior Program Manager

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 22 Feb 2008 07:09:10 -0500

Stefan,

Major parts of this I-D (i.e., chain of authorization processing) are
not divergent from whatever authorization means you choose.  Choice of
location will dictate where the logic resides.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, February 21, 2008 6:45 PM
To: Timothy J Miller; Santosh Chokhani
Cc: Russ Housley; [email-masked]
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID

> *authorization* framework.  You'll be better off.

I really support this view. About everything I have seen and experienced
in this space indicates that this is true.
What I think we need is not a more complex and harder to manage PKI, but
rather to consolidate PKI to its core function to assert a relationship
between an entity and a key.

Stefan Santesson
Senior Program Manager

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 22 Feb 2008 09:58:57 -0500

This forces at least CA clearance Constraints processing into the path
processing algorithm if the extension is critical, and also suggest
that, if recognized, it should be processed here.

[CRW] True, you'd need to at least indicate ability to process the
critical extension to the path processing implementation.

---

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

[CRW] The sort of operation described in the draft could be performed
> as

That can be argued.

RFC 3280bis section  6.1.4  "Preparation for Certificate i+1" states:

      (o)  Recognize and process any other critical extension present in
      the certificate.  Process any other recognized non-critical
      extension present in the certificate that is relevant to path
      processing.

draft-turner-caclearanceconstraints-00.txt states in section 3 that:

   The CA Clearance Constraints certificate extension MAY be critical
   or non-critical.

This forces at least CA clearance Constraints processing into the path processing algorithm if the extension is critical, and also suggest that, if recognized, it should be processed here.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Carl Wallace
> Sent: den 21 februari 2008 19:27
> To: [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Feb 2008 14:23:34 -0500

David:

Experience trying to deploy clearance with SubjectDirectoryAttribute 
has proven to be quite difficult.  One issue is that CA clearance 
constraints impose limits on clearance values, which if carried in 
SubjectDirectoryAttributes impose limits on a single 
attribute.  Another concern is that one dos not want to make the 
SubjectDirectoryAttributes critical to ensure proper processing of 
the CA clearance constraints.

Russ

  At 05:37 PM 2/21/2008, David A. Cooper wrote:
>Russ Housley wrote:
>>It is important to me that the syntax for representing the 
>>clearance in a certificate and an attribute certificate are exactly the same.
>>are folks who are going to put clearance information in a certificate.
>>I'd like them all to do it the same way, so that when policy 
>>permits, they can interoperate.
>
>Unfortunately, the current draft is working against this 
>goal.  There is already a mechanism defined in X.501 including 
>clearance information in a public key certificate.  X.501 defines 
>the clearance attribute, which (as X.501 notes) would be placed in 
>the subjectDirectoryAttributes extension when included in a public 
>key certificate.  This draft defines a new certificate extension 
>that uses the syntax and OID of the X.501 clearance 
>attribute.  Thus, there will be two ways defined for CAs to include 
>clearance information in public key certificates, even though both 
>use the same syntax.  If the goal is for everyone to encode this 
>shouldn't base achieving that goal on the assumption that everyone 
>will ignore X.501 when determining how to encode an X.501 defined attribute.
>
>Dave
>