Subject: Attribute Certificate Policy

From: Denis Pinkas <[email-masked]>
Date: Fri, 14 Jun 2002 09:36:38 +0200

On March 5, the following message was sent to the list by Christopher
Francis:

"Is there a defined mechanism to specify something analogous to a
certificate policy in an attribute certificate ? 

In reviewing the PKIX AC profile, I see that the syntax of the
attributes field is defined by the AttributeType OID, but rather than
syntax per se, I'm looking for a way to specify the particular set of
policies, practices, and procedures that the attribute authority
was operating under when it issued the attribute certificate.  
Seems like this would be important to relying parties."

Several e-mails have then been exchanged on the list. As a result of
these exchanges, Chris and myself have undertaken the writing of a draft 
to define an extension to support an Attribute Certificate Policy.

The document is available from :
http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-00.txt

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 17 Jun 2002 12:19:35 -0400

Denis & Chris:

I really dislike this draft.  Since it is written by two people that I 
respect, I feel obligated to voice my concerns.

If I wrote down everything that causes me concern in this draft, then the 
resulting message would be longer than the draft itself.  For this reason, 
I will stick to the major concerns.

MAJOR CONCERN 1

I see no value in adding a acPolicies extension to a PKC that includes the 
subjectDirectoryAttributes extension.  The current policy extension already 
handles the whole PKC, including the content of the 
subjectDirectoryAttributes extension.  Two policy-related extensions in a 
single PKC provides no value to the replying party.

MAJOR CONCERN 2

Why define a new extension?  Why not simply include the certificatePolicies 
extension in an attribute certificate?  The two extensions have exactly the 
same syntax.  I believe that they have the same semantics too.

MAJOR CONCERN 3

Why do we need more qualifiers?  The draft RECOMMENDS that policy 
information consist of an object identifier, then it defines a pile of 
qualifiers.  Further, the information that is contained in the qualifiers 
is of very little interest to the relying party.  It is useful to the 
issuer.  Why can't the issuer keep this information in a private 
database.  Everything that the issuer knows about the subject/holder need 
not appear in the certificate.

MAJOR CONCERN 4

Can we use the AuthorityInfoAccess extension to point to the issuer's 
repository?  I think it would be straightforward to define an access method 
that meets this objective.  Perhaps this is a matter of taste, but it seems 
to meet the stated requirement of providing a pointer to the issuer's 
repository that otherwise requires the information to be extracted from the 
CP or CPS.

MAJOR CONCERN 5

The PKIX working group does not assign object identifiers in the id-ce 
arc.  This are is owned by the editor of X.509.

    id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }

MAJOR CONCERN 6

The phrases "AA SHALL" and "AA MUST" do not appear anywhere in this 
document.  The closest that I could find is a requirement that the AA "make 
sure that the policy applies to all the attributes."  Without appropriate 
MUST statements, I do not see how a useful service is being provided to the 
replying party.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Jun 2002 18:48:52 +0200

Russ,

First of all, thank you for taking the time to read this draft.

 

> single PKC provides no value to the replying party.

I would agree that this is debatable. Attributes contained in PKCs MUST be
verified at the time of registration, but nothing would prevent a CA to do
more and to revoke a PKC if an attribute is no more correct. This could be
in the CP and the CPS may it is not directly machine readable. Hence why it
might be interresting to say more. An alternative would be for PKCs to keep
the CP extension but to allow to support more qualifiers. 

> same syntax.  I believe that they have the same semantics too.

Not exactly. As indicated above, attributes contained in PKCs MUST be
verified at the time of registration, but nothing would prevent a CA to do
more and to revoke a PKC if an attribute is no more correct. This
information is certainly of some interest for a relying party. The AA should
have a way to indicate this, but since an AC does not contain a CP
extension, this is the reason why a new extension has been created.

> not appear in the certificate.

As indicated above, it is useful for relying parties that may get more
information, e.g. confidence about the freshness of the attributes.  
 
> repository that otherwise requires the information to be extracted from the

RFC 3280 states:

   The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. 

I do not consider an AA to be a CA and I would not like that we introduce
some confusion between a CA and an AA, hence why this extension has not been
created. From RFC 3281: Attribute Authority, the entity that issues the AC,
synonymous in this specification with "AC issuer".

>     id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }

Thanks. Nobody is perfect.
 
> MUST statements, I do not see how a useful service is being provided to the

It is the very first draft, so yet unpolished.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 17 Jun 2002 14:02:41 -0400

>the CP extension but to allow to support more qualifiers.

There seem to be three cases to discuss:
         a)  the attribute is long-lived and unlikely to change,
         b)  the attribute is long-lived and likely to change, and
         c)  the attribute is short-lived.

I think that your reply only addresses the first case (a).  I assume that 
short validity periods will be used when the attribute fits into one of the 
other two cases (b and c).

So, in the first case, you are using a policy qualifier (yuck) to tell the 
relying party that the issuer does not expect the attribute to change but 
that periodic checks will be made just to make sure that everything is as 
expected.  If an unexpected condition is discovered, then the certificate 
will be revoked.  I find it hard to believe that the same frequency will be 
needed for each attribute that might appear in the 
subjectDirectoryAttributes extension.

>extension, this is the reason why a new extension has been created.

I see nothing in X.509 that prohibits the use of the certificatePolicies 
extension in an attribute certificate. (There is one place where it says 
"CA", but if that were replaced with "issuer".)  Maybe I missed something ...

>information, e.g. confidence about the freshness of the attributes.

I do not see it.  You are saying that the relying party will reject an 
attribute certificate in the following situation:

         1)  the AA has a valid PKC
         2)  the subject has a valid PKC
         3)  the subject has a valid AC
         4)  the AC was issued under an acceptable policy
         5)  the AC policy qualifier indicates periodic checks that
                 are weekly, but the relying party would like more
                 frequent checks

X.509 says:

         The optional qualifiers are not used in the certification path 
processing
         procedure, but relevant qualifiers are provided as an output of 
that process
         to the certificate using application to assist in determining 
whether a valid
         path is appropriate for the particular transaction.

RFC 3280 says:

         Optional qualifiers, which MAY be present, are not expected to change
         the definition of the policy.

Your use of qualifier does meet the limits imposed by these documents; 
however, I think that there is a mismatch between the single value in the 
policy qualifier and the potential for more than one attribute in the 
subjectDirectoryAttributes extension or the AC.

Using separate ACs for each attribute would solve this problem, but that 
seems to impose way too much overhead and complexity.

>synonymous in this specification with "AC issuer".

An AA is not a CA.  In fact, RFC 3281 says that they are not allowed to 
have the same distinguished name.

Perhaps I am misunderstanding this whole section of the document, by I 
thought that you want a URI that points to the issuer's repository.  The 
justification provided is that you want to be able to pass a pointer to the 
certificate (either PKC or AC) rather than pass the certificate 
itself.  Clearly, the certificate is already available to the to extract 
the URI in the first place.

>Thanks. Nobody is perfect.

I certainly make mistakes too.  That is why I value peer review.

>It is the very first draft, so yet unpolished.

Apparently sharing my first four major concerns has not altered your 
thinking. So, we can expect a second draft with little change?

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 17 Jun 2002 14:14:42 -0400

All:

Sharon pointed me to the part of X.509 that prohibits the use of the 
certificatePolicies extension in attribute certificates.  I would rather 
work with the X.509 community to remove this restriction than define a new 
extension with the same syntax and semantics.

Russ

>short validity periods will be used when the attribute fits into one of 
>the other two cases (b and c).
>
>will be revoked.  I find it hard to believe that the same frequency will 
>be needed for each attribute that might appear in the 
>justification provided is that you want to be able to pass a pointer to 
>the certificate (either PKC or AC) rather than pass the certificate

---

From: "Christopher S. Francis" <[email-masked]>
Date: Mon, 17 Jun 2002 14:25:44 -0400

Russ,

Thanks for your comments.

I have one more thing to add to Denis' original reply.

Chris
...  snip

[Chris Francis - WetStone Technologies] My first inclination was to simply
use the certificatePolicies extension in an attribute certificate.  A new
extension is useful though because it allows the extension to have the more
targeted purpose of capturing policy items related to binding of attributes
to identity (vs. binding of a public key to an identity).  It seemed that it
would be easier to get agreement on adding a new extension to cover
attributes rather than broadening the scope of the certificatePolicies
extension to allow for its use in attribute certificates.

---

From: "Christopher S. Francis" <[email-masked]>
Date: Mon, 17 Jun 2002 15:00:48 -0400

Russ,

My primary motivation for starting down this path is that I strongly believe
that a standardized mechanism is required to convey policy information in
attribute certificates.  If the restriction on the use of
certificatePolicies in attribute certificates could be removed, I would be
in favor of that, but the last time I raised that issue, I didn't get very
far.

Defining a separate extension within the PKIX group seemed a reasonable
first step.

Chris

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Monday, June 17, 2002 2:15 PM
To: [email-masked]; [email-masked]
Cc: pkix
Subject: Re: Attribute Certificate Policy

All:

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 17 Jun 2002 15:19:23 -0400

>in favor of that, but the last time I raised that issue, I didn't get very

I see no reason for two extensions with the same syntax and the same 
semantics.  I think others will agree.

>Defining a separate extension within the PKIX group seemed a reasonable

Hopefully the discussion will determine if others agree with me.  If so, 
then we can make a request to the X.509 community.  So far, only three 
people have voiced an opinion either way.

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 17 Jun 2002 18:04:07 -0400

Russ:

Also, the CP and CPS Framework does not address the issues surrounding
validating and revoking the attributes.  It is very much identity
oriented.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Housley, Russ
Sent: Monday, June 17, 2002 2:15 PM
To: [email-masked]; [email-masked]
Cc: pkix
Subject: Re: Attribute Certificate Policy

All:

work with the X.509 community to remove this restriction than define a
new 
extension with the same syntax and semantics.

Russ

>> > I really dislike this draft.  Since it is written by two people 
>> > that I respect, I feel obligated to voice my concerns.
>>
>> > If I wrote down everything that causes me concern in this draft, 
>> > then the resulting message would be longer than the draft itself.  
>> > For this reason, I will stick to the major concerns.
>>
>> > MAJOR CONCERN 1
>>
>> > I see no value in adding a acPolicies extension to a PKC that 
>> > includes the subjectDirectoryAttributes extension.  The current 
>> > policy extension
>> already
>> > subjectDirectoryAttributes extension.  Two policy-related 
>> > extensions in a single PKC provides no value to the replying party.
>>
>>I would agree that this is debatable. Attributes contained in PKCs 
>>MUST be verified at the time of registration, but nothing would 
>>prevent a CA to do more and to revoke a PKC if an attribute is no more

>>correct. This could be in the CP and the CPS may it is not directly 
>>machine readable. Hence why it might be interresting to say more. An 
>>alternative would be for PKCs to keep the CP extension but to allow to

>>support more qualifiers.

>>verified at the time of registration, but nothing would prevent a CA 
>>to do more and to revoke a PKC if an attribute is no more correct. 
>>This information is certainly of some interest for a relying party. 
>>The AA should have a way to indicate this, but since an AC does not 
>>contain a CP extension, this is the reason why a new extension has 
>>been created.
>
>> > information consist of an object identifier, then it defines a pile

>> > of qualifiers.  Further, the information that is contained in the 
>> > qualifiers is of very little interest to the relying party.  It is 
>> > useful to the issuer.  Why can't the issuer keep this information 
>> > in a private database.  Everything that the issuer knows about the 
>> > subject/holder need not appear in the certificate.
>>

>> > Can we use the AuthorityInfoAccess extension to point to the 
>> > issuer's repository?  I think it would be straightforward to define

>> > an access
>> method
>> > that meets this objective.  Perhaps this is a matter of taste, but 
>> > it
>> seems
>> > to meet the stated requirement of providing a pointer to the 
>> > issuer's repository that otherwise requires the information to be 
>> > extracted
>> from the
>> > CP or CPS.
>>
>>RFC 3280 states:
>>
>>I do not consider an AA to be a CA and I would not like that we 
>>introduce some confusion between a CA and an AA, hence why this 
>>extension has not been created. From RFC 3281: Attribute Authority, 
>>the entity that issues the AC, synonymous in this specification with 
>>"AC issuer".
>

>> > The PKIX working group does not assign object identifiers in the 
>> > id-ce arc.  This are is owned by the editor of X.509.
>> >

>> > document.  The closest that I could find is a requirement that the 
>> > AA
>> "make
>> > sure that the policy applies to all the attributes."  Without 
>> > appropriate MUST statements, I do not see how a useful service is 
>> > being provided
>> to the
>> > replying party.
>>

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 18 Jun 2002 12:22:05 +0200

Russ,

 
 
> other two cases (b and c).

Correct.
 
> will be revoked.  

Correct.

> I find it hard to believe that the same frequency will be

Ideally one policy per attribute would be needed. For attributes included in
the subjectDirectoryAttributes extension from a PKC a common denominator
will have to be used.

For attributes included in an AC, the same applies but in that case an AC
may only include one or two atributes and thus the policy can be defined at
a finer level of granularity.

 
> "CA", but if that were replaced with "issuer".)  Maybe I missed something ...

You mentioned that Sharon noticed that the current ISO text precludes to use
the CP extension for ACs. The current RFC 3280, also precludes it.
 
Changing one word by another is an important change. I do not say that it
cannot be done, but I was not assuming such a change. 

The real issue is:

Should the notion of policy be supported at all in an AC ?
I believe that the answer is YES.

If so, then the next question is how. There were two alternatives:

  1) by changing both X.509 and RFC 3280, or
  2) by defining a new extension.

You would prefer the former choice. Since the ISO process is quite long,
I would prefer the IETF process.  

Chris and myself made the later choice.

Thenafter as soon as we say that regular checks can be made on the
attributes under a policy, a parameter is useful to indicate that frequency.
Hence the reason of at least a new qualifier, that is specific to attributes
included either in a PKC or an AC.

If we change X.509 this makes an addition that may take quite long. If the
IETF goes first, then ISO could add the PKIX addition later on and we would
not have to wait for the next ISO publication round. Of course, this does
not prevent discussions and co-ordination between the ISO SC6 and the PKIX
WGs.

 
 
>                  are weekly, but the relying party would like more

Yes, the last condition could lead to a reject.
 
> processing procedure, but relevant qualifiers are provided as 
> an output of that process to the certificate using application 
> to assist in determining whether a valid path is appropriate 
> for the particular transaction.

> subjectDirectoryAttributes extension or the AC.

This may prevent some attribute grouping, either in the
subjectDirectoryAttributes extension from a PKC or in an AC.
 
> seems to impose way too much overhead and complexity.

This is one way to solve the problem.

 
 
> thought that you want a URI that points to the issuer's repository.  

Yes.

> The justification provided is that you want to be able to pass a pointer 
> to the certificate (either PKC or AC) rather than pass the certificate

No. You can get the AC from the protocol. If there is a thin client, the
thin client will not verify the AC and build the certificate chain to verify
the AC. If a fat client was doing it, then he could get the uri, if the
meaning of authority information access extension was extended to cover AAs
(which is not the case today). So the proposal is to include the location in
the AC itself.

 

 
> thinking. So, we can expect a second draft with little change?

At this time, the only changes I see would be to change some shall and must
into SHALL and MUST.

I do not think it is necessary to make these changes now. The purpose of
sending this draft was to trigger a discussion before the Yokohama meeting
and at the Yokohama meeting.

I will certainly be interested to have a discussion on that topic before the
PKIX WG meeting in Yokohama. I will be there from the Monday. Unfortunately,
Chris will not be there.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 18 Jun 2002 08:49:51 -0400

Santosh:

This is a good point, but it would be a very straightforward addition.  In 
fact, given the current existence of subjectDirectoryAttributes, it should 
probably be included now.

Russ

At 06:04 PM 6/17/2002 -0400, Santosh Chokhani wrote:
>The

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 18 Jun 2002 09:13:22 -0400

Denis:

In this message, I address only one of my concerns.

> it seems

I think that I understand your goal better, but I do not see what this has 
to do with AC policy.

I would prefer to specify a mechanism that works equally well for PKCs and 
ACs.  Using the same mechanism for both certificate types is a win for thin 
clients.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 18 Jun 2002 16:37:28 +0200

Russ,

> In this message, I address only one of my concerns.

(text deleted)

> >You can get the AC from the protocol. If there is a thin client, the
 
> I think that I understand your goal better, but I do not see what this has

The document was targeted to support ACs, but in order to have a short
title, the title and the abstract did not reflected this. So looking at 
the title, you are quite right. We could change the title, but ...  
 
> ACs.  Using the same mechanism for both certificate types is a win for thin

 ... I have nothing against your suggestion. This kind of extension would
work quite nice for both PKCs and ACs.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 18 Jun 2002 10:44:14 -0400

Denis:

Given this agreement, perhaps the best course of action is to separate the 
two mechanisms into separate documents.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 18 Jun 2002 17:08:54 +0200

Russ,

At this time the agreement would be to have an extension valid for both 
PKCs and ACs to indicate possible repository references for the certificate.

If we call that document "Useful extensions for PKCs and ACs" then it may
still be in the same document. I would prefer to limit the number of RFCs,
if possible.

So let us first agree on the technical concepts and decide later on how 
to present/package them.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 18 Jun 2002 13:22:37 -0400

Russ:

I agree that the addition will be straightforward.  I think it will be
more than few sentences though depending on the guidance we want to give
in the areas of validating the privileges (attributes) and conditions
under which they should be revoked.  The good news is that it does not
impact most of the technical and non-technical security controls.  But,
it may also impact the Legal Sections also.

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]] 
Sent: Tuesday, June 18, 2002 8:50 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Attribute Certificate Policy

Santosh:

This is a good point, but it would be a very straightforward addition.
In 
fact, given the current existence of subjectDirectoryAttributes, it
should 
probably be included now.

Russ

At 06:04 PM 6/17/2002 -0400, Santosh Chokhani wrote:
>new extension with the same syntax and semantics.
>
>Russ
>
>

> >I think that your reply only addresses the first case (a).  I assume
> >that short validity periods will be used when the attribute fits into

> >one of
> >So, in the first case, you are using a policy qualifier (yuck) to
> >tell the relying party that the issuer does not expect the attribute 
> >to change
>but
> >that periodic checks will be made just to make sure that everything
> >is
>as
> >>Not exactly. As indicated above, attributes contained in PKCs MUST
> >>be verified at the time of registration, but nothing would prevent a

> >>CA to do more and to revoke a PKC if an attribute is no more 
> >>correct. This information is certainly of some interest for a 
> >>relying party. The AA should have a way to indicate this, but since 
> >>an AC does not contain a CP extension, this is the reason why a new 
> >>extension has been created.
> >
> >I see nothing in X.509 that prohibits the use of the
> >certificatePolicies extension in an attribute certificate. (There is 
> >one place where it
>says
> >> > qualifiers is of very little interest to the relying party.  It 
> >> > is useful to the issuer.  Why can't the issuer keep this 
> >> > information in a private database.  Everything that the issuer 
> >> > knows about the subject/holder need not appear in the 
> >> > certificate.
> >>
> >I do not see it.  You are saying that the relying party will reject
> >an attribute certificate in the following situation:
> >
> >         The optional qualifiers are not used in the certification
> > path processing
> >         to the certificate using application to assist in
> > determining whether a valid
> >         Optional qualifiers, which MAY be present, are not expected
> > to
>change
> >Your use of qualifier does meet the limits imposed by these
> >documents; however, I think that there is a mismatch between the 
> >single value in
>the
> >Using separate ACs for each attribute would solve this problem, but
> >that seems to impose way too much overhead and complexity.
> >
> >>  > MAJOR CONCERN 4
> >> >
> >> > that meets this objective.  Perhaps this is a matter of taste,
> >> > but it
> >> seems

> >> > extracted
> >> from the
> >> > CP or CPS.
> >>
> >>RFC 3280 states:
> >>
> >>    The authority information access extension indicates how to
> >> access
>CA

> >>"AC issuer".
> >
> >An AA is not a CA.  In fact, RFC 3281 says that they are not allowed
> >to have the same distinguished name.
> >
> >Perhaps I am misunderstanding this whole section of the document, by
> >I thought that you want a URI that points to the issuer's repository.
>The
> >> > document.  The closest that I could find is a requirement that
> >> > the AA
> >> "make

---

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 18 Jun 2002 15:48:39 -0400

Can someone please point me to the location of the "CP and CPS
Framework"?  

Is this part of X.509 or is it in a separate document.  I'm looking at
X.509 now and I'm not finding it.  I've seen ANSI X9.79-1 (PKI Practices
and Policy Framework).  Is that what you're talking about?

Chris
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Santosh Chokhani
Sent: Tuesday, June 18, 2002 1:23 PM
To: 'Housley, Russ'
Cc: [email-masked]
Subject: RE: Attribute Certificate Policy

Russ:

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 8:50 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Attribute Certificate Policy

Santosh:

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 18 Jun 2002 16:00:35 -0400

The old RFC is 2527.  The new one is about to get an RFC number (may
already have one), but is on PKIX web page as ID

-----Original Message-----
From: Christopher S. Francis [mailto:[email-masked]] 
Sent: Tuesday, June 18, 2002 3:49 PM
To: Santosh Chokhani; 'Housley, Russ'
Cc: [email-masked]
Subject: RE: Attribute Certificate Policy

Chris
-----Original Message-----

Russ:

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 8:50 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Attribute Certificate Policy

Santosh:

This is a good point, but it would be a very straightforward addition.
In fact, given the current existence of subjectDirectoryAttributes, it
should probably be included now.

Russ

At 06:04 PM 6/17/2002 -0400, Santosh Chokhani wrote:
>[mailto:[email-masked]]