Subject: Attribute Certificates and Privilege Policy

From: Sharon Boeyen <[email-masked]>
Date: Thu, 14 Mar 2002 14:09:49 -0500

I'll try to address all the questions I've seen re the 509 aspects of this
discussion. (Sorry this is rather long, but I found this 
easier than trying to respond to each message).

I think Peter has identified at least one part of 509 that could benefit
from some editorial clarification. 

Clause 16 "Privilege path processing procedure" may be more appropriate
titled "Privilege assertion processing procedure".
Each paragraph in 16.1 could probably use subtitles to clarify what's really
going on. The paragraphs in this section are basically 
a list of each of the checks that need to be done before an asserted
privilege can be granted to a claimant. 
- Para 1 is doing a "validation" on each of the attribute certificates in
the path. This is just checking the signatures, using the 
PKI path validation steps as if you were checking the signature on a signed
form - the details are in clause 10 of the PKI section. 
- Para 2 is a check to ensure the claimant's willingness to use that
attribute cert for the context - no standard steps for this 
check are defined.
- Para 3 is the revocation status check - no details req'd
- Para 4 is the check for whether the asserted privilege is valid for the
time of interest - no details req'd
- Para 5 is checking any constraints imposed by the issuer of the AC on the
set of permitted targets - no details req'd
- Para 6 is the checks for roles and of delegation. Note that 16.2 is merely
the details associated with the role check and 
16.3 is merely the details assoiated with the delegation check.
- Para 7 is the privilege policy check against the asserted privilege
together with the other inputs (target sensitivity, 
environmental variables) and checking any constraints on privilege policy
imposed by the issuer.

So this complete set of steps comprise the processing that needs to be done
to assess a privilege assertion. Some of these
relate to paths (Para 1 is processing of a public-key certification path to
verify the signature on the attribute cert and 
Para 6 along with 16.3 is processing of a delegation path of attribute
certificates to determine whether or not the delegation 
itself is authorized and valid. As part of the processing of a delegation
path, note that the signature on EACH attribute 
certificate in the path needs to be verified, so again the public-key path
validation is used for that purpose). I wanted to 
try to clarify this because asking if something is part of "path validation"
is not as easy to answer as it would be if 
we were talking about PKI instead of PMI.  

The privilege policy is the basis for determining the acceptance of an
attribute certificate (at least from a policy perspective).
It is processed by a verifier as one of the steps in assessing a privilege
assertion, but it is not strictly part of either 
public-key certification path processing done for signature verification or
part of delegation path processing for verifying 
delegation. 

Many aspects of privlege policy were not standardized in 509, including its
syntax, who can write them etc, how does 
a verifier know which one to use etc. Some of these were deferred, e.g.
syntax. Note however, that in OASIS, the XACML 
working group is now defining a standard XML syntax for access control
policy. Some material from the sample syntaxes 
in the X.509 informative annex were input to the XACML work so folks
interested in privilege policy may find that work 
interesting as well. As for how the verifier knows which privilege policy to
use - that is left to the implementation. In 
some cases a target may always work with a single privilege policy and it
may be created by the local SOA . There 
are hooks to tie privilege policies to attributes for which an SOA assigns
privileges (the attributeDescriptor in 15.3.2.2 and 
there is also directory syntax to store them, but no standardized way for a
verifier to determine which to use. However a local
trusted SOA would obviously be one possible source of privilege policies. 

Regarding the acceptablePrivilegePolicies extension, a verifier is always
assessing a privilege assertion with respect to 
a specific privilege policy as per para 7 in 14.1. In the absence of the
acceptablePrivilegePolicies extension, the verifier 
merely assess the assertion with respect to the privilege policy it is
working with (out of band / local means for determining
which privilege policy the verifier operates with - likely greatly
determined by the target). If the acceptablePrivilegePolicies 
extension is present, then the verifier needs to check whether the privilege
policy it is operating under is one of the ones 
listed as acceptable in that extension. If it is, then the verifier proceeds
normally. If it is not, the verifier stops and the privilege
asserter is not given access. 

The privilege policy is the set of rules that determine acceptability of an
asserted privilege. A primary difference between 
that and certificate policy is that certificate policy is tied to a
certificate and defines acceptable uses for that certificate, 
while privilege policy is associated with a verifier and the target that is
in question and determines which privilege assertions
are appropriate. So, things like usage constraints, dollar limits, time
constraints, name constraints - all those things would 
be appropriate for inclusion in a privilege policy. I'm not convinced about
liability limits though, because privilegePolicy must
be machine processable as it is processed dynamically at assertion
assessment time. Liability limits don't seem like they 
would easily lend themselves to this. 

In terms of 'why no certificate policy' - there was no need identified for
an equivalent. A verifier trusts an SOA as the 
ultimate source of authority for assignment of a set of privileges. That's
the authorization issue I mentioned earlier. 
If delegation is done, then the checks for ensuring that is authorized are
part of the delegation path processing 
procedure. If an AA (SOA or delegated AA) wishes to constrain the policy
under which an AC is used, it can do 
so through the acceptablePrivilegePolicies extension. As for certificate
policies, they are used when verifying the 
signature on the attribute certificates as well as when verifying the
signature on any transaction associated with 
the specific assertion of privilege being made by the claimant. So
certificate policies do factor into the overall 
validation for any given transaction, but are not part of the privilege
assertion assessment.

I hope this addresses the questions that were raised by Denis, Chris and
Peter - if not I'm sure you'll let me know :-). 

In terms of 509 clarifications, if people think some defect work is needed
there, please let me know. 

FYI, I'm going to try to get all my editing tasks from the recent X.509
meeting completed and provide a brief summary 
of the meeting to this list prior to the PKIX meeting. There are a couple of
current issues we're working on with respect 
to SOAs that PMI folks might be interested in.

Again, apologies for the length of the message.
Sharon 

Sharon Boeyen
Principal, Advanced Security
Tel: 613 270 3181 
www.entrust.com

Entrust, Inc.
Securing the Internet

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Mar 2002 18:50:19 +0100

Sharon,

Yes, this is indeed a very long e-mail. Mine will be shorter.

Shortly speaking, the "privilege policy" is the equivalent of a 
"validation policy" (see the DPV requ. draft availmable from 
http://www.imc.org/draft-ietf-pkix-dpv-dpd-req), but it is NOT 
the equivalent of a certification policy.

You said: "In terms of 'why no certificate policy' - there was no need
identified for an equivalent".

For CAs there are different levels of verification of the identity presented
at the time of registration. This level is "visible" through the certificate
policy.

I do not see why we should not draw a parallel with attributes, where for
AAs there would be different levels of verification of the attributes
presented at the time of registration. This level would be "visible" through
the "attribute policy".

A validation policy (i.e. privilege policy using the ISO terminology) may
consider that some attribute policies are adequate and that some others are
not.

Otherwise, the single way to trust is to use the name of the AA. 

If an AA supports different "attribute policies", it would have to change
its
name, each time. :-(

Thus I see a good reason to have an equivalent.

Regards,

Denis

> Each paragraph in 16.1 could probably use subtitles to clarify what's
> really going on. The paragraphs in this section are basically
> 
> PKI path validation steps as if you were checking the signature on a
> signed form - the details are in clause 10 of the PKI section.
> 
> - Para 5 is checking any constraints imposed by the issuer of the AC on
> the set of permitted targets - no details req'd
> - Para 6 is the checks for roles and of delegation. Note that 16.2 is
> merely the details associated with the role check and
> 
> So this complete set of steps comprise the processing that needs to be
> done to assess a privilege assertion. Some of these
> relate to paths (Para 1 is processing of a public-key certification path
> to verify the signature on the attribute cert and
> try to clarify this because asking if something is part of "path
> validation" is not as easy to answer as it would be if
> public-key certification path processing done for signature verification
> or part of delegation path processing for verifying
> delegation.
> 
> Many aspects of privlege policy were not standardized in 509, including
> its syntax, who can write them etc, how does
> interesting as well. As for how the verifier knows which privilege policy
> to use - that is left to the implementation. In
> there is also directory syntax to store them, but no standardized way for
> a verifier to determine which to use. However a local
> extension is present, then the verifier needs to check whether the
> privilege policy it is operating under is one of the ones
> listed as acceptable in that extension. If it is, then the verifier
> proceeds normally. If it is not, the verifier stops and the privilege
> The privilege policy is the set of rules that determine acceptability of
> an asserted privilege. A primary difference between
> while privilege policy is associated with a verifier and the target that
> is in question and determines which privilege assertions
> be appropriate for inclusion in a privilege policy. I'm not convinced
> about liability limits though, because privilegePolicy must
> of the meeting to this list prior to the PKIX meeting. There are a couple
> of current issues we're working on with respect

---

From: "Christopher S. Francis" <[email-masked]>
Date: Fri, 15 Mar 2002 14:58:13 -0500

I concur with Denis.  It seems entirely reasonable that an AA may want to
apply different levels of verification of the attributes presented in the
ACs that it issues.

Just as commercial CAs issue PK certificates under various policies,
charging higher prices for higher levels of assurance, an Attribute
Authority may want to issue ACs under various policies, with different
levels of assurance based on the level of verification of the asserted
attributes.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Denis Pinkas
Sent: Friday, March 15, 2002 12:50 PM
To: Sharon Boeyen
Cc: [email-masked]'
Subject: Re: Attribute Certificates and Privilege Policy

Sharon,

Regards,

Denis