Subject: Attribute Cert Policies Rationale

From: "Christopher S. Francis" <[email-masked]>
Date: Mon, 9 Dec 2002 12:58:22 -0500

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 Farrell <[email-masked]>
Date: Tue, 10 Dec 2002 12:27:51 +0000

IMO this is neither needed nor desirable. ("Neither use nor 
ornament" as me granny used say.)

It clearly isn't needed since there are IMO already sufficient 
degrees of freedom in the AC profile, i.e. whatever their problems, 
DNs are cheap (certainly relative to paying all those policy-gank 
consultants and lawyers!).

The reason it isn't desirable is that AC usage is still almost
non-existent, and adding yet more complexity is a very good way
to ensure that things stay as they are.

Stephen.

PS: I could try start a separate disussion about PKIX feature-creep,
but I won't. (Oops, maybe I just did:-)

-- 
____________________________________________________________
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: Tue, 10 Dec 2002 08:33:32 -0500

Thank you for your comments Stephen.

... snip

... end snip

I can't believe you feel adding an extension w/ an OID is complex compared
to the other topics that regularly get discussed here :)).

While I agree that AC usage is not widespread, as someone who is actually
operating a commercial attribute authority, I must respectfully disagree.
It is precisely because my company is trying to use attribute certificates
for something real that this issue has come up.  Not making changes to
accommodate real-world experiences is a sure fire way to ensure that usage
of ACs remains extremely limited.

Chris

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Dec 2002 10:31:41 -0500

Chris:

I can not speak to the issue of utility of this extension since I have
not worked much with attribute certificates.

Assuming, we include this extensions, you need to think about what role,
if any it will play in attribute certification path validation.  Without
a role in path validation, it just becomes an advisory field, and that
may be useful too.  I simply do not know.

If you do decide to define a path validation engine for handling this,
here are some suggestions based on what I think is bad about certificate
policy processing in X.509 (and hence RFC 3280) and hence should not be
used for attribute certificates.

1.  Rather than initializing an application with acceptable policies,
let the path validation engine return the policies the path is good for.

2.  Do not have equivalent of require explicit policy field.  I do not
find this field particularly useful from practical viewpoint.

3.  I do not know if you foresee a need for policy mapping.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Christopher S. Francis
Sent: Tuesday, December 10, 2002 8:34 AM
To: [email-masked]
Cc: Ietf-Pkix
Subject: RE: Attribute Cert Policies Rationale

... snip

The reason it isn't desirable is that AC usage is still almost
non-existent, and adding yet more complexity is a very good way to
ensure that things stay as they are.

... end snip

I can't believe you feel adding an extension w/ an OID is complex
compared to the other topics that regularly get discussed here :)).

While I agree that AC usage is not widespread, as someone who is
actually operating a commercial attribute authority, I must respectfully
disagree. It is precisely because my company is trying to use attribute
certificates for something real that this issue has come up.  Not making
changes to accommodate real-world experiences is a sure fire way to
ensure that usage of ACs remains extremely limited.

Chris

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2002 15:41:55 +0000

Chris,

The complexity of PKI policy is not commensurate with the
number of arcs in a policy OID, but I guess we all know
that already.

And I take it that since you only disagree about the
desirability aspects, you acknowledge that this is not
necessary. 

I could be somewhat rude and tell you where to stick 
your policy OID...Into your RDN:-) But seriously, what's
the difference? That only needs another PKC per AA, 
instead of new s/w per relying party and AA. Seems like
a no-brainer to me until your policies are such that 
this doesn't work, something that I don't believe you've
shown so far.

Cheers,
Stephen.

---

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 10 Dec 2002 11:39:34 -0500

Santosh,

Thanks for the feedback.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 10:32 AM
To: 'Christopher S. Francis'
Cc: 'Ietf-Pkix'
Subject: RE: Attribute Cert Policies Rationale

Chris:

[Chris Francis - WetStone Technologies] Hmm.  Interesting thought.  I can
see where that would be useful.  I'm hesitant to deviate from X.509 and
RFC-3280 in this area though.  I think the draft is more likely to be
accepted by maintaining consistency with existing standards.

[Chris Francis - WetStone Technologies] Concur.  The draft does not include
processing of this field for AC Policies.

[Chris Francis - WetStone Technologies] I do not see a need for it.  Use of
policy mapping was a bad idea for PKC policies - it's a bad idea here too.

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

... snip

... end snip

Chris

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Dec 2002 11:41:45 -0500

Santosh:

RFC 3281 does not allow attribute certificate chains.  The AA is 
authoritative for a set of attributes.  The replying party either trusts 
the AA or it doe not.  The end.

Russ

---

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 10 Dec 2002 11:57:57 -0500

Steve,

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 10:42 AM
To: Christopher S. Francis
Cc: Ietf-Pkix
Subject: Re: Attribute Cert Policies Rationale

Chris,

[Chris Francis - WetStone Technologies] I never said that it was.  My
previous comment was simply that I find it incredible that you view the
addition of this extension as complex given the complexity of some of the
other things that are discussed here.  Relatively speaking, this is probably
one of the simplest most straightforward things to hit this list in quite a
while.

I could be somewhat rude and tell you where to stick
your policy OID...Into your RDN:-)

[Chris Francis - WetStone Technologies] :)
But seriously, what's
the difference? That only needs another PKC per AA,
instead of new s/w per relying party and AA. Seems like
a no-brainer to me until your policies are such that
this doesn't work, something that I don't believe you've
shown so far.
[Chris Francis - WetStone Technologies] Standing up two physically different
AAs to do the same job is expensive.  Having a single AA issue certificates
using multiple identities adds complexity that doesn't need to be there.
Plus, having an explicit reference to the policies that apply to the
certificate IN the certificate is better than an implied reference based on
the issuer DN.

Cheers,
Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2002 17:12:38 +0000

Chris,

I think we're pretty much there in terms of understanding one another,
so there's probably no need to prolong this thread - between us at least.

> Standing up two physically different

That depends entirely on your AA implementation, something about which
the rfc is properly silent, but I'd expect that any sensible AA or CA
could handle >1 identity smoothly, so I disagree that this really adds
unnecessary complexity to the AA (e.g. its almost the same as handling
key &/or cert rollover for the AA and if you don't handle that you're
broken).

In contrast your proposal adds complexity to the relying party, which is
IMO clearly less desirable when its not needed.

> certificate IN the certificate is better than an implied reference based on

We disagree there. Which is fine, since the sentence contains the word
"better", but I still fail to see how embedding an OID in the extensions
field SEQUENCE OF is "better" than embedding it in the RDN field 
SEQUENCE OF. The code looks just the same anyway, but maybe you assume 
there's a one true DIT for AA's?

Stephen.

---

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 10 Dec 2002 13:44:30 -0500

Steve,

I can't resist a response since you ended your previous message with a
question:)

My objection to the using the RDN isn't related to the complexities of
supporting multiple identities as much as it is to the complexity of
seamlessly switching back and forth between those identities without
interruption to the operation of the AA.  If the AA supports responding to
requests for attribute certificates through an online protocol, security
controls pertaining to the activation of the AA's private key material would
likely make it problematic to switch back and forth between identities
without human intervention.

Besides that, embedding information about policy (or anything else other
than the name of the AA) in the DN just seems ..... inelegant.  Yuk:(

Chris
-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 12:13 PM
To: Christopher S. Francis
Cc: Ietf-Pkix
Subject: Re: Attribute Cert Policies Rationale

Chris,

Stephen.

> > I can't believe you feel adding an extension w/ an OID is complex
compared
> > While I agree that AC usage is not widespread, as someone who is
actually

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Dec 2002 14:00:37 -0500

Russ:

In that case, we do not need to do much since RP can get the attribute
certificate policy from the certificate and make its own decision.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2002 11:42 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Attribute Cert Policies Rationale

Santosh:

Russ

At 10:31 AM 12/10/2002 -0500, Santosh Chokhani wrote:

>Assuming, we include this extensions, you need to think about what 
>role, if any it will play in attribute certification path validation.  
>Without a role in path validation, it just becomes an advisory field, 
>and that may be useful too.  I simply do not know.
>
>here are some suggestions based on what I think is bad about 
>certificate policy processing in X.509 (and hence RFC 3280) and hence 
>should not be used for attribute certificates.
>
>actually operating a commercial attribute authority, I must 
>respectfully disagree. It is precisely because my company is trying to 
>use attribute certificates for something real that this issue has come 
>up.  Not making changes to accommodate real-world experiences is a sure

>fire way to ensure that usage of ACs remains extremely limited.
>
>Chris

---

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 10 Dec 2002 15:24:42 -0500

Santosh,
...snip
Russ:

[Chris Francis - WetStone Technologies] And there's the rub.  Currently
there's no place to put the attribute certificate policy in the certificate.
Do you support the idea of adding an extension for this purpose?
Chris

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Dec 2002 15:45:49 -0500

Chris:

I think having a policy OID does not hurt anything.  But, my opinion in
this matter is not useful since I have not had much practical or
theoretical experience in dealing with attribute certificates.

-----Original Message-----
From: Christopher S. Francis [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2002 3:25 PM
To: Santosh Chokhani; 'Russ Housley'
Cc: [email-masked]
Subject: RE: Attribute Cert Policies Rationale

Santosh,
...snip
Russ:

[Chris Francis - WetStone Technologies] And there's the rub.  Currently
there's no place to put the attribute certificate policy in the
certificate. Do you support the idea of adding an extension for this
purpose? Chris

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 11 Dec 2002 11:04:35 +0100

Steve,

> consultants and lawyers!).

Having a different AA name to identify a policy is not a clean solution.

> to ensure that things stay as they are.

Maybe one of the reasons why AC usage is still almost non-existent, is 
because it is lacking many features, including this feature.

We need to be positive and identify the obstacles for the use of ACs.

FYI, I have proposed a talk at the next RSA 2003 Conference in San Francisco 
on the following topic:

" Why are Attribute Certificates not yet in use today ? "

That talk has been accepted. So I welcome you to attend that presentation.

:-)

Denis

PS. Thanks for giving me the opportunity to advertise that presentation.

:-)