Re: Attribute Cert Policies Rationale

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Russ,

> Chris:
>
> Unlike Steve Farrell, I have no major objection to the inclusion of a 
> policy OID.  

Good.

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

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


> 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