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