Subject: Re: Attribute Cert Policies Rationale

From: Russ Housley <[email-masked]>
Date: Mon, 16 Dec 2002 09:28:31 -0500

Chris:

Unlike Steve Farrell, I have no major objection to the inclusion of a 
policy OID.  However, I do have a major objection to the use of policy 
qualifiers.  When we were developing RFC 2459, I fought to exclude them 
from the certificate policy.  I wish I had fought harder.  I think that 
they really hurt interoperability and add significant implementation 
complexity.  I do not want to see that repeated here.

Russ

At 12:58 PM 12/9/2002 -0500, Christopher S. Francis wrote:

>A few weeks ago in Atlanta we agreed to take the issue of Why do we need 
>an AC Policies extension?to the list for discussion.  I wanted to wait for 
>the OCSP v2 storm to subside a bit, but Id like to have a productive 
>dialog on this issue before we get into the holidays.
>
>
>
>The reason we need an AC Policies extension is this:  An attribute 
>authority can perform various levels of verification with regard to the 
>attributes asserted in an AC.  The AAs verification procedures and other 
>operational rules it abides by are documented in an AC policy.  There is 
>currently no way to reference this policy in an AC.  The AC Policies 
>extension provides that.  Why do we NEED to reference the AC policy in the 
>certificate?  Its useful because it allows us to cryptographically 
>associate an individual AC with the policy (or policies) that apply to 
>it.  This is better than simply associating an AC with an AC Policy by 
>looking at the issuer DN for the same reasons that it is better to look at 
>the Certificate Policy when evaluating a PKC vs. just looking at the 
>issuer DN.  First, it provides an explicit, cryptographically verifiable 
>association between the certificate and its associated policy.  Second, it 
>allows a single AA to issue attribute certificates under multiple 
>policies.  This is a useful option to have in certain scenarios, 
>particularly when you begin to think about attribute certificates outside 
>the context of access control.
>
>
>
>Heres a hypothetical (non-access control) scenario.  This abstract example 
>is based on WetStones experience in operating a real-world attribute 
>authority.  Consider a calibration and test lab that performs periodic 
>measurement and calibration of pulse rate monitors.  In some cases these 
>monitors are used in life-critical situations and in others the devices 
>are for consumer (home) use.  Clearly different (more stringent) 
>procedures and calibration constraints will be required for the devices 
>used in life-critical situations.  Typically, when devices are calibrated, 
>the lab puts a sticker on the device authorizing it for operation in a 
>specific environment for a specific period of time from the calibration 
>date.  They use Green stickers for devices calibrated to consumer (home 
>use) standards and Red stickers for devices calibrated for use in 
>life-critical environments.  A record of the calibration measurements is 
>also included on the sticker.  Now the lab is going hi-tech and they want 
>to issue an electronic version of their calibration stickers.  They decide 
>to use attribute certificates.  The holder of the attribute certificate is 
>the device being calibrated.  The issuer is the calibration lab.  The 
>attribute being asserted is the devices calibration status based on the 
>devices measured performance.  The end of the certificates validity period 
>represents the expiration date of the calibration sticker.  The 
>calibration measurements are included in the attribute value.  Separate AC 
>Polices are created for life-critical calibrations and consumer (home use) 
>calibrations.  These policies define different levels of verification that 
>the lab performs when calibrating the devices for home vs. life-critical 
>use.  The policies also include things like statements of liability and 
>clearly spell out the obligations of the lab and the owners of the 
>devices.  The AC Policies extension could be used here to explicitly 
>assert the policy under which a particular calibration was performed --- a 
>cryptographically verifiable equivalent of getting a Green sticker vs. a 
>Red sticker.  Right now, theres no standards-based way to make this 
>assertion in an attribute certificate.
>
>
>
>So, just as a Certificate Authority can issue identity certificates under 
>different certificate policies, an attribute authority can issue attribute 
>certificates under different attribute policies, depending on the level of 
>verification applied to the asserted attributes.  It is useful to 
>specifically assert the policies that apply to attribute certificates for 
>the same reasons that is useful to state the certificate policies that 
>apply to public key certificates.  Its not really that big of a 
>jump.  Honestly, I cant figure out why this isnt obvious to everyone 
>:).  The AC Policies extension provides a mechanism to reference an AC 
>Policy in an attribute cert the same way we reference certificate policies 
>in public key certificates.
>
>
>
>Well there it is.  Your comments, questions, and criticisms are 
>welcome.  I hope we can reach a consensus one way or the other on this.
>
>
>
>Chris
>
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 18 Dec 2002 12:42:37 +0100

Russ,

> policy OID.  

Good.

 > However, I do have a major objection to the use of policy

Do you really think this is the case for the CPS Pointer and User Notice 
qualifiers ?

    "The CPS Pointer qualifier contains a pointer to a Certification
    Practice Statement (CPS) published by the CA."

    "User notice is intended for display to a relying party when a
    certificate is used."

RFC 3280 states: "Optional qualifiers, which MAY be present, are not 
expected to change the definition of the policy."

I do not understand why these two qualifiers "really hurt interoperability" 
and for that reason should be banned. Would you explain ?

Denis

>> A few weeks ago in Atlanta we agreed to take the issue of Why do we 
>> need an AC Policies extension?to the list for discussion.  I wanted to 
>> wait for the OCSP v2 storm to subside a bit, but Id like to have a 
>> productive dialog on this issue before we get into the holidays.
>>
>>
>>
>> authority can perform various levels of verification with regard to 
>> the attributes asserted in an AC.  The AAs verification procedures and 
>> other operational rules it abides by are documented in an AC policy.  
>> There is currently no way to reference this policy in an AC.  The AC 
>> Policies extension provides that.  Why do we NEED to reference the AC 
>> policy in the certificate?  Its useful because it allows us to 
>> cryptographically associate an individual AC with the policy (or 
>> policies) that apply to it.  This is better than simply associating an 
>> AC with an AC Policy by looking at the issuer DN for the same reasons 
>> that it is better to look at the Certificate Policy when evaluating a 
>> PKC vs. just looking at the issuer DN.  First, it provides an 
>> explicit, cryptographically verifiable association between the 
>> certificate and its associated policy.  Second, it allows a single AA 
>> to issue attribute certificates under multiple policies.  This is a 
>> useful option to have in certain scenarios, particularly when you 
>> begin to think about attribute certificates outside the context of 
>> access control.
>>
>>
>>
>> Heres a hypothetical (non-access control) scenario.  This abstract 
>> example is based on WetStones experience in operating a real-world 
>> attribute authority.  Consider a calibration and test lab that 
>> performs periodic measurement and calibration of pulse rate monitors.  
>> In some cases these monitors are used in life-critical situations and 
>> in others the devices are for consumer (home) use.  Clearly different 
>> (more stringent) procedures and calibration constraints will be 
>> required for the devices used in life-critical situations.  Typically, 
>> when devices are calibrated, the lab puts a sticker on the device 
>> authorizing it for operation in a specific environment for a specific 
>> period of time from the calibration date.  They use Green stickers for 
>> devices calibrated to consumer (home use) standards and Red stickers 
>> for devices calibrated for use in life-critical environments.  A 
>> record of the calibration measurements is also included on the 
>> sticker.  Now the lab is going hi-tech and they want to issue an 
>> electronic version of their calibration stickers.  They decide to use 
>> attribute certificates.  The holder of the attribute certificate is 
>> attribute being asserted is the devices calibration status based on 
>> the devices measured performance.  The end of the certificates 
>> validity period represents the expiration date of the calibration 
>> sticker.  The calibration measurements are included in the attribute 
>> value.  Separate AC Polices are created for life-critical calibrations 
>> and consumer (home use) calibrations.  These policies define different 
>> levels of verification that the lab performs when calibrating the 
>> devices for home vs. life-critical use.  The policies also include 
>> things like statements of liability and clearly spell out the 
>> obligations of the lab and the owners of the devices.  The AC Policies 
>> extension could be used here to explicitly assert the policy under 
>> which a particular calibration was performed --- a cryptographically 
>> verifiable equivalent of getting a Green sticker vs. a Red sticker.  
>> Right now, theres no standards-based way to make this assertion in an 
>> attribute certificate.
>>
>>
>>
>> So, just as a Certificate Authority can issue identity certificates 
>> under different certificate policies, an attribute authority can issue 
>> attribute certificates under different attribute policies, depending 
>> on the level of verification applied to the asserted attributes.  It 
>> is useful to specifically assert the policies that apply to attribute 
>> certificates for the same reasons that is useful to state the 
>> certificate policies that apply to public key certificates.  Its not 
>> really that big of a jump.  Honestly, I cant figure out why this isnt 
>> obvious to everyone :).  The AC Policies extension provides a 
>> mechanism to reference an AC Policy in an attribute cert the same way 
>> we reference certificate policies in public key certificates.
>>
>>
>>

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Dec 2002 09:37:56 -0500

Denis:

>I do not understand why these two qualifiers "really hurt 
>interoperability" and for that reason should be banned. Would you explain ?

There have been implementation bugs.  I am aware of an implementation that 
displayed the Verisign CPS notice regardless of the content of the 
qualifier.  Imagine a certificate issued by Certs-R-Us and the user sees a 
message that says Verisign is not liable for the certificate contents.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Dec 2002 15:25:19 +0000

> >>Unlike Steve Farrell, I have no major objection to the inclusion of a

Funnily enough, I do (still) have an objection: Its unnecessary additional
crud and the same effect can be achieved now with no new specification and
no new code. I already showed one way, here's another: put your policy
garbage in the issuer's PKC which is fine with both 3280 and 3281 unless 
you're under the mistaken impression that PKCs are somehow expensive.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 19 Dec 2002 12:34:10 -0500

Steve, 

Both of the alternatives you have suggested are broken.  I've already
stated my opinions on why using a separate DN for each AA policy is
cumbersome, so I wont repeat them.  

Your latest suggestion of where to put my "policy garbage" is also
flawed.  The CA that issues the PKC to the AA may not be able (and
probably does not want) to make claims regarding the policies enforced
by the AA in validating asserted attributes.  If a commercial
certificate authority (say VeriSign) issues the PKC to the AA, it's not
likely that VeriSign is going to want to make assertions regarding the
policies that apply to the AA's operations.  The CA issuing the PKCs has
no insight into that.

Chris

> >>Unlike Steve Farrell, I have no major objection to the inclusion of
a

Funnily enough, I do (still) have an objection: Its unnecessary
additional
crud and the same effect can be achieved now with no new specification
and
no new code. I already showed one way, here's another: put your policy
garbage in the issuer's PKC which is fine with both 3280 and 3281 unless
you're under the mistaken impression that PKCs are somehow expensive.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Dec 2002 18:07:31 +0000

Hi Chris,

> Both of the alternatives you have suggested are broken.  

Truth by blatent assertion. You're starting to sound like me:-)

> flawed.  The CA that issues the PKC to the AA may not be able (and
                                                ^^^
The "may" is the give-away. Its technically quite possible to setup an 
environment where the CA is so aware and where no policy extensions
are needed in ACs, but where all policy rules are followed, to the
extent that the 3280 implementation follows them that is, so the 3281 
code doesn't need to know and no new rfc is needed.

> policies that apply to the AA's operations.  The CA issuing the PKCs has

So don't use such an AC-ignorant PKC service if you want this stuff. 
Build/buy a CA, or use a service that can put policy OIDs into PKCs 
more flexibly that those guys you mentioned:-). It can, and has, all 
been done already.

Unless there's a use case where it really isn't *possible* for the AA's 
PKCs to use a closely bound CA then this AC extension is not needed.
Most of the cases I can imagine would inherently call for the CA/AA
to know of one another or else wouldn't require any policy stuff. 
(Remember with ACs, all relying parties have to specifically "know" 
the AA is an AA, so they already have to have AA-specific configuration 
for this to work, which means that adding another PKC root CA isn't the
problem it usually is - i.e. the normal reasons why client-ssl is hard
don't apply.) 

But feel free to propose a use case that does justify this, its just
that I haven't seen one that convinced me so far.

Cheers,
Stephen.

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 19 Dec 2002 14:23:15 -0500

Steve,
A CA's job is about binding identities to public keys.  Coupling that to AA
policies and procedures is outside the scope of what a CA is supposed to
care about.  That aside, of course it's *possible* to set up an environment
where the CA is aware of the AA's policies and practices and is willing to
assert AA policy information in the PKC, it's just not always practical or
cost-effective.  This would almost certainly require that the AA and the CA
be operated by the same organization.  Why should we engineer the technology
so that this is the only option available?  If an organization wants to
operate an AA, why should we force them to also operate a CA that is tightly
coupled to the AA's operations?

Consider the calibration lab scenario I described initially.  The lab is in
the business of calibrating stuff.  They want to issue an electronic version
of their calibration stickers in the form of attribute certificates, but
they have no interest in also running a CA.  Running their own CA increases
their costs and distracts them from their core business, which is
calibration (e.g. validating the attributes asserted in their ACs).  Running
a CA, which again is about validating identities, is a job best outsourced
to someone who wants to be in that business.

Chris
Hi Chris,

                                                ^^^

Cheers,
Stephen.