Re: Attribute Certificates and Privilege Policy

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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

> 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