Re: Attribute Cert Policies Rationale

[Russ Housley <housley@xxxxxxxxxxxx>]

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