Subject: Attribute Certificate Policy??

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 5 Mar 2002 17:41:23 -0500

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.
 
X.509 includes an acceptablePrivilegePolicies extension that seems like it might to the job, but it was apparently profiled out by PKIX.
 
Chris Francis

---

From: "Sabett, Randy" <[email-masked]>
Date: Thu, 7 Mar 2002 11:35:34 -0500

All:

I have been following this thread over the past couple of days; many
interesting issues.

I plan to discuss with the full ABA Information Security Committee
leadership during our next call (they are copied on this email as well).
It's not something at which we have been actively looking, but it is
certainly something we could consider.

Regards,

R.
_______________________________ 
Randy V. Sabett, J.D., CISSP 
Cooley Godward LLP 
One Freedom Square, Reston Town Center 
11951 Freedom Drive 
Reston, VA  20190-5601 
Direct:         703.456.8137 
Main:           703.456.8000 
Cell:           703.597.6521 
Fax:            703.456.8100 
E-Mail: [email-masked] 
http://www.cooley.com 
http://www.cooley.com/practice_and_people.ixe?section=Attorney+Biographies&i
d=SABETTRV
Broomfield * Kirkland * Menlo Park * Palo Alto * Reston * San Diego * San
Francisco 

-----Original Message-----
From: Housley, Russ
To: Christopher S. Francis
Cc: [email-masked]; [email-masked]
Sent: 3/7/2002 10:11 AM
Subject: Re: Attribute Certificate Policy??

Chris:

Perhaps we can get some of the American Bar Assoc people to comment on
the 
CP and CPS issues.  I suspect that we will need to go through an 
educational phase before we get any useful feedaback.  Perhaps they have

been looking at it and we are just unaware...

Russ

At 02:53 PM 3/7/2002 +0000, Stephen Farrell wrote:

>Chris,
>
>I'd be against the idea of proposing this as an update to the AC
profile
>for the following reasons:
>
>- The profile is in the rfc editor's queue only awaiting son-of-2359 to
>   be processed and such an update would require a re-set back to WG
last
>   call (a matter of months!)
>- I don't believe that the use of policy OIDs in ACs is at all well
>   understood and therefore I'd argue to omit it from the profile (one
>   of the things we tried to do with the AC profile was to only include
>   suff that we were pretty sure could work)
>- There may be entirely different policy considerations to address,
>   depending on the context for the use of ACs (e.g. supporting roles
for
>   long-term signatures vs roles for access control).
>
>So, while I'd welcome work starting on this - for both process and
>technical reasons I believe the way to handle it is to write things up
in
>a separate I-D. At some point in the future (say if the AC profile were
>being cycled at proposed standard), the two things could be merged if
>appropriate.
>
>Regards,
>Stephen.
>
>
>"Christopher S. Francis" wrote:
> >
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm
not
> > exactly sure what the appropriate process is, but what I have in
mind is to
> > do the following:
> >
> > 1) Get some clarification from ANSI and whoever else has an opinion
on
> > whether X.509 offers an extension that is intended to be used to
carry
> > certificate policy information in attribute certificates.  Perhaps
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps
they had
> > something else in mind.
> > 2) Depending on what I find out, propose an update to the PKIX
attribute
> > certificate profile that includes an extension to ACs to hold policy
> > information about the issuing authority.
> >
> > Based on your earlier responses, I understand that a
certificatePolicies
> > extension could be included in an AC as long as it is marked
non-critical,
> > but it that's only because *anything* can be included as an
extension if
> > it's marked non-critical.  It seems to me there should be something 
> specific
> > in the profile to address the issue of certificate policy.
> >
> > Chris
> > -----Original Message-----
> > From: [email-masked]
[mailto:[email-masked]]On
> > Behalf Of Housley, Russ
> > Sent: Wednesday, March 06, 2002 11:02 AM
> > To: Christopher S. Francis
> > Cc: Ietf-Pkix
> > Subject: Re: Attribute Certificate Policy??
> >
> > Chris:
> >
> > I am not aware of any work in this area.  You can take the lead.
> >
> > Russ
> >
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> >
> > >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.
> > >
> > >
> > >
> > >X.509 includes an acceptablePrivilegePolicies extension that seems
like it
> > >might to the job, but it was apparently profiled out by PKIX.
> > >
> > >
> > >
> > >Chris Francis
> > >
> > >
> > >
> > >
>
>--
>____________________________________________________________
>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

=======================================================
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message

---

From: Peter Williams <[email-masked]>
Date: Thu, 07 Mar 2002 15:15:12 -0800

Im not sure I agree with David Chadwick that
X.509 needs to be involved to address the
needs of AA cert issuing policies.

Why not?

Relying parties ARE REQUIRED by X.509 to obtain
privilege policy, when doing AA path processing.
AA path processing requires handling the privilege
policy-defined constraints.

"The privilege verifier must also determine whether or not the privileges
being asserted are sufficient for the context of
use. The privilege policy establishes the rules for making this
determination and includes specification of any
environmental variables that need to be considered. The privileges asserted,
including those resulting from the role
procedure in 16.2 and the delegation procedure in 16.3 and any relevant
environmental variables (e.g. time of day or
current account balance) are compared against the privilege policy to
determine whether or not they are sufficient for the
context of use."

Relying parties are also required to:
"ensure that the delegator was authorized to delegate the 
privilege they own and" However authorization checking is
not a part of "privilege policy", as far as I can tell
from what the standard actually states.

I see no reason why an SOA-defined privilege, whose verification
of assertion is subject to the X.509 delegation path processing rules ,
cannot be 
defined as the "use of the rights and asumption of the oblitations defined
in 
an AA's CPS" I see no reason why the privilege assertion cannot be: 
cite a set of "AA-policy OIDs", where that set of OID  is just an 
SOA-defined privilege for the delegation path.

As with any privilege, under the privilege policy,
such an SOA_defined privilege would require handling under 
environment-specific processing rules, as defined by the SOA. These 
can be defined as: also evaluate a delgation path under the cert 
policy and cert policy mapping constraints rules used
in evaluating certification paths. 

I dont thinkg either X.509 or IETF needs to be involved (i.e.
we have to wait another 2 years) to do  this. It would be nice if IETF 
defined such a privilege type, but  nothing stops any SOA doing so. It 
doesnt seem to require an AA cert extension; a privilege definition
is sufficient.  

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 12:53 PM
To: [email-masked]
Subject: RE: Attribute Certificate Policy??

I just want to point out that X.509 states that the certificatePolicies
extension is only to be used in public-key certificates.

The first sentences in section 8 of X.509 state: "The certificate extensions
defined in this clause are for use with public-key certificates, unless
otherwise stated. Extensions for use with attribute certificates are defined
in clause 15." There is nothing in section 8.2.2.6 on the
certificatePolicies extension stating that the extension may be used in an
attribute certificate, so its use is limited to public-key certificates.

I don't know what mechanisms, if any, are defined in X.509 to provide policy
information about attribute certificates, but perhaps someone who is more
familiar with that standard can provide some insight.

Dave

At 01:15 PM 3/7/02 -0500, Christopher S. Francis wrote:

>Yuriy,
>
>Hmm.... You certainly have more experience in this area than I do.  In
>actual practice what you say may indeed be the case.  I based my comments
on
>what I read in X.509.
>
> >From X.509 section 8.2.2.6 on the certificate policies extension:
>
>"If the extension is flagged critical, it indicates that the certificate
>shall only be used for the purpose, and in accordance with the rules
implied
>by one of the indicated certificate policies.  The rules of a particular
>policy may require the certificate-using system to process the qualifier
>value in a particular way.
>
>If the extension is flagged non-critical, use of this extension does not
>necessarily constrain use of the certificate to the policies listed.
>However, a certificate user may require a particular policy to be present
in
>order to use the certificate (see 10).  Policy qualifiers may, at the
option
>of the certificate user, be processed or ignored."
>
>Chris
>
>From: Yuriy Dzambasow [mailto:[email-masked]]
>Sent: Thursday, March 07, 2002 12:29 PM
>To: Christopher S. Francis; Housley, Russ
>Cc: Ietf-Pkix
>Subject: RE: Attribute Certificate Policy??
>
>
>Chris:
>
>...snip...
>
> >
> > In some environments, I believe that an AA might in fact want to make
the
> > certificatePolicies extension critical, especially if there is legal
> > liability involved.  By making the extension critical it says that
relying
> > parties are required to accept the terms documented in the AA's CPS
before
> > relying on the authorizations granted in the certificate.
> >
> > Chris
>
>Marking an extension critical has nothing to do with accepting terms in CPs
>and CPSs.  Things like relying party agreements address this issue.
>
>Yuriy
>
>...snip...

---

From: Peter Williams <[email-masked]>
Date: Thu, 07 Mar 2002 16:26:24 -0800

Summary:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-02.txt
7.1 seems seems insufficient to address PMI elements of remote
validation.

Note:

The topic of AA-cert policies and delegation path validation caused
me to review DPV requirements, for X.509 cert paths that contain
AA-issued privileges.(see X.509 13.2)

Though the PKIX profile of X.509 may not really address privileges that 
are represented in a public-key cert's subjectDirectoryAttribute extension,
the X.509-quality requirements for handling such a case of privlege 
management seem clear.

As described in X.509: "Privilege policy" rule execution is  required, when 
an  assertion of the privilege is made via subjectDirectoryAttribute, for
a cert issued by a combined CA/AA. The verifier (e.g. DPV server) MUST check
the delegation/certification path using each privilege-specific 
determination process, during (public-key) certificate path processing.
(X.509 16.3)

Ok, this means that a DPV server must also be able to handle this case,
and therefore "validation policy" must be defined to be include all 
"privilege policies" relevant to an evaluated cert chain. Hence
the definition in the IETF DPV/DPD requirements document
is somewhat insufficient, as it does not address this
X.509-imposed requirement.

---

From: Peter Williams <[email-masked]>
Date: Wed, 13 Mar 2002 12:41:14 -0800

Sharon,
 
I find your writing the clearest of any architect in PKIX, by far,
and always consistent with simple readings of the international
standards actually say. You always attempt to
adopt the model being specified, rather than contort language 
via profiling to perhaps enable the international standards to addresses 
something else. Whilst a standard is insufficient
if you have to ask an author/editor what it means, I seek
a clear opinion on one issue raised in your mail to PKIX
on the topic of attribute certificate policy and privilege
policies.
 
The opinion issue concerns the "acceptablePrivilegePolicies extension" which
must be absent in a conforming PKIX AC.
 
Question:
 
Does the X.509 standard mean that one should/may evaluate privilege
assertions as valid (against
some privilege policys) in the ABSENCE of acceptablePrivilelge Policies?
 
-------------

Now I have a point of confusion (being a pretty ignorant soul who
has learned alot in the last week and is very
excited now with PMI given privilege policies) if a verfier 
does indeed evaluate privilege policies:
 
Given your commentary on the authority model of SOA/AAs, and the absence
by design of an AA issuer's certification policy/practice, how does
one determine which privilege policies to apply?
 
Of is the ambiguity of privilege policy requirement there by design,
in the absence of acceptablePrivilegePolicy Extension: that is, its
a relying party matter to select the policies to be applied?