Subject: RE: Attribute Cert Policies Rationale

From: Roger Younglove <[email-masked]>
Date: Mon, 9 Dec 2002 16:37:19 -0500

I agree that we need an AC Policies extension. An AA could issue multiple
types of ACs and just having the DN on the Cert will not provide sufficient
information to identify the type of AC. An AC policy extension will allow
identification.
 
Roger Younglove, CISSP
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [email-masked]
www.networksgroup.com
 
-----Original Message-----
From: Christopher S. Francis [mailto:[email-masked]] 
Sent: Monday, December 09, 2002 12:58 PM
To: Ietf-Pkix
Subject: Attribute Cert Policies Rationale
 
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 I'd 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 AA's 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?  It's
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.
 
Here's a hypothetical (non-access control) scenario.  This abstract example
is based on WetStone's 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 device's calibration status based on the device's
measured performance.  The end of the certificate's 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, there's
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.  It's not really that big of a jump.  Honestly,
I can't figure out why this isn't 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: Stephen Kent <[email-masked]>
Date: Fri, 20 Dec 2002 11:57:42 -0500

At 4:37 PM -0500 12/9/02, Roger Younglove wrote:
>I agree that we need an AC Policies extension. An AA could issue 
>multiple types of ACs and just having the DN on the Cert will not 
>provide sufficient information to identify the type of AC. An AC 
>policy extension will allow identification.
>
   We seem to be overlooking another, perhaps simpler solution, namely 
to assign different attribute OIDs to represent the same attributes 
associated with different policies.  In the example Chris provided, 
the lab could issue green vs. red attributes, distinguished by OID, 
rather than adding a policy extension to the AC.

Steve

---

From: "Chris @ work" <[email-masked]>
Date: Mon, 23 Dec 2002 15:11:37 -0500

RE: Attribute Cert Policies RationaleSteve,

I considered that approach initially, but rejected it becuase it inhibits interoperability.  If issuers have to define a unique OID for an attribute type to reflect their particular policy, then this makes it difficult for AC processing software to be developed to support a common set of attribute types (such as those defined in RFC-3281 for instance).

Chris
  ----- Original Message ----- 
  From: Stephen Kent 
  To: Roger Younglove 
  Cc: 'Christopher S. Francis' ; Ietf-Pkix 
  Sent: Friday, December 20, 2002 11:57 AM
  Subject: RE: Attribute Cert Policies Rationale

    We seem to be overlooking another, perhaps simpler solution, namely to assign different attribute OIDs to represent the same attributes associated with different policies.  In the example Chris provided, the lab could issue green vs. red attributes, distinguished by OID, rather than adding a policy extension to the AC.

  Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Dec 2002 15:42:36 -0500

At 3:11 PM -0500 12/23/02, Chris @ work wrote:
>Steve,
>
>I considered that approach initially, but rejected it becuase it 
>inhibits interoperability.  If issuers have to define a unique OID 
>for an attribute type to reflect their particular policy, then this 
>makes it difficult for AC processing software to be developed to 
>support a common set of attribute types (such as those defined in 
>RFC-3281 for instance).
>
>Chris

Chris,

I would have expected software that makes use of ACs to have the OIDs 
for acceptable policies (and meaningful attributes) specified as 
parameters to the software, so I'm not sure why using different OIDs 
to represent attributes asserted under different policies would be 
problematic.  can you explain in more detail?

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 23 Dec 2002 17:39:25 -0500

Steve:
 
Let us assume that there are n attributes and m policies.
 
Chris's approach will require you to register n + m OIDs and an application
will have to know about no more than n + m OIDs.
 
The other approach will require you to register n * m OIDs and an
application may have to know about up to n * m OIDs
 
Thus, the second approach makes the OIDS proliferation faster.  How fast,
depends on n and m.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Monday, December 23, 2002 3:43 PM
To: Chris @ work
Cc: Ietf-Pkix
Subject: Re: Attribute Cert Policies Rationale

Steve,

I considered that approach initially, but rejected it becuase it inhibits
interoperability.  If issuers have to define a unique OID for an attribute
type to reflect their particular policy, then this makes it difficult for AC
processing software to be developed to support a common set of attribute
types (such as those defined in RFC-3281 for instance).

Chris

Chris,

I would have expected software that makes use of ACs to have the OIDs for
acceptable policies (and meaningful attributes) specified as parameters to
the software, so I'm not sure why using different OIDs to represent
attributes asserted under different policies would be problematic.  can you
explain in more detail?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Dec 2002 17:57:51 -0500

>Chris's approach will require you to register n + m OIDs and an 
>application will have to know about no more than n + m OIDs.
>
>Thus, the second approach makes the OIDS proliferation faster.  How 
>fast, depends on n and m.

Santosh,

One starts with the assumption that there are N attributes to begin 
with, and Chris is suggesting creating a facility to represent M 
policies.  So, the new registration burden under Chris's scheme is M 
policy OIDs, and under my suggestion, it is up to N*M. So the added 
registration burden is (N-1)*M IF every attribute is issued under 
every policy, which may or may not be the case.

While in the worst case an app might have to be configured with N*M 
OIDs, I suspect that in practice any app will deal with a subset of 
attributes and policies and thus the config burden is likely to be 
considerably less than the max.

Your actual configuration burden may vary :-)

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 24 Dec 2002 08:21:01 -0500

Steve:
 
I think you are probably right about the clients.  I do think that to reduce
the explosion of OIDs and not overloading the meaning of privileges makes it
more attractive to keep the privilege and policy apart.
 
IMHO, given all the various atomic fields and extensions in both public key
and attribute certificates, the better approach is to keep the two apart.
It offers us the best long term flexibility.
 
-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, December 23, 2002 5:58 PM
To: Santosh Chokhani
Cc: 'Ietf-Pkix'
Subject: RE: Attribute Cert Policies Rationale

Steve:

Santosh,

One starts with the assumption that there are N attributes to begin with,
and Chris is suggesting creating a facility to represent M policies.  So,
the new registration burden under Chris's scheme is M policy OIDs, and under
my suggestion, it is up to N*M. So the added registration burden is (N-1)*M
IF every attribute is issued under every policy, which may or may not be the
case.

While in the worst case an app might have to be configured with N*M OIDs, I
suspect that in practice any app will deal with a subset of attributes and
policies and thus the config burden is likely to be considerably less than
the max.

Steve

---

From: "Christopher S. Francis" <[email-masked]>
Date: Fri, 27 Dec 2002 09:46:43 -0500

Steve,
 
What Santosh said.  Overloading the attribute value OID with policy information seems like a messy solution to me that will not scale well.  
 
Furthermore, it is conceivable that applications may want to take different actions when they don't understand the syntax of a particular attribute vs. when they don't find the policy under which it was issued acceptable.  Using the attribute value OID to convey policy information makes it impossible to make this distinction. 
 
Chris
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Santosh Chokhani
Sent: Monday, December 23, 2002 5:39 PM
To: 'Stephen Kent'; 'Chris @ work'
Cc: 'Ietf-Pkix'
Subject: RE: Attribute Cert Policies Rationale
 
Steve:

Chris's approach will require you to register n + m OIDs and an application will have to know about no more than n + m OIDs.
 
The other approach will require you to register n * m OIDs and an application may have to know about up to n * m OIDs
 
Thus, the second approach makes the OIDS proliferation faster.  How fast, depends on n and m.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Monday, December 23, 2002 3:43 PM
To: Chris @ work
Cc: Ietf-Pkix
Subject: Re: Attribute Cert Policies Rationale

Chris
 
Chris,
 
I would have expected software that makes use of ACs to have the OIDs for acceptable policies (and meaningful attributes) specified as parameters to the software, so I'm not sure why using different OIDs to represent attributes asserted under different policies would be problematic.  can you explain in more detail?
 
Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Dec 2002 10:52:04 -0500

At 9:46 AM -0500 12/27/02, Christopher S. Francis wrote:
>Steve,
>
>
>
>What Santosh said.  Overloading the attribute value OID with policy 
>information seems like a messy solution to me that will not scale 
>well. 
>
>
>
>Furthermore, it is conceivable that applications may want to take 
>different actions when they don't understand the syntax of a 
>particular attribute vs. when they don't find the policy under which 
>it was issued acceptable.  Using the attribute value OID to convey 
>policy information makes it impossible to make this distinction.
>
>
>
>Chris

Chris,

I agree that encoding both the attribute type and policy in the OID 
is less elegant than having a separate, explicit policy extension in 
an AC.  But from my reading of the discussion, there has not been 
strong support for adding an explicit policy facility to ACs, so I 
was just suggesting an alternative that would meet your perceived 
requirement in case the WG does not add the facility you want.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 27 Dec 2002 11:41:00 -0500

Chris and Steve:
 
There is another advantage to keeping the policy and attribute separate.
One can envision a common set of attributes understood by a variety of
applications.  With the approach of keeping the policy separate, not only do
you not have exponential growth in OID, the applications that do not
understand or care about the policies can process the attributes
certificates by ignoring the policy extension and those that care can
process and enforce the policy.
 
The only objection I envision to having policy is adding a field to be
processed.  If the extension is non-critical, applications that understand
the policy can ignore it and still use the certificate.
 
The advantages seem to be numerous.  Having the flexibility is better.
-----Original Message-----
From: Christopher S. Francis [mailto:[email-masked]] 
Sent: Friday, December 27, 2002 9:47 AM
To: Santosh Chokhani; 'Stephen Kent'
Cc: 'Ietf-Pkix'
Subject: RE: Attribute Cert Policies Rationale

Steve,
 
What Santosh said.  Overloading the attribute value OID with policy
information seems like a messy solution to me that will not scale well.  
 
Furthermore, it is conceivable that applications may want to take different
actions when they don't understand the syntax of a particular attribute vs.
when they don't find the policy under which it was issued acceptable.  Using
the attribute value OID to convey policy information makes it impossible to
make this distinction. 
 
Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Santosh Chokhani
Sent: Monday, December 23, 2002 5:39 PM
To: 'Stephen Kent'; 'Chris @ work'
Cc: 'Ietf-Pkix'
Subject: RE: Attribute Cert Policies Rationale
 
Steve:

 
 
-----Original Message-----

Chris
 
Chris,

Steve