Re: Attribute Certificates and Privilege Policy

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Sharon,

> Just a couple of points to add:
> 
> The 509 PMI framework does not have any equivalent to
> cross-certification defined (it was included in early drafts
> but dropped from the spec prior to approval). The model is
> really addressing environments where the SOA and the verifier
> are in the same "security domain" and does not really address
> any cross-domain issues. 

You got one point: the issue is to allow for more than trust anchor.
The other point is to allow different levels of verification of the
attributes for the same AA.

> Verifiers are expected to be configured
> with a trusted copy of their SOA public key as they are today for
> trust anchors in PMI. The verifier trusts the SOA as the ultimate
> source of authority for a set of privileges.

This is too restrictive. Verifiers are expected to be configured 
with a validation policy, that includes more than one trust anchor.

Verifiers may also be configured for a single domain to only consider
attributes that are highly verified.

> If there are requirements to enhance the 509 model, those
> requirements can certainly be submitted to the 509 work by PKIX.

So be it.

> From a process standpoint there is no problem, the liaisons
> already exist and we've worked successfully on other topics
> through this channel, regardless of who agrees or disagrees with the
> specific topic.
 
> From my own personal standpoint, I'm not yet convinced of the requirement.

Please, take a look at http://www.imc.org/draft-ietf-pkix-dpv-dpd-req even
if it does not address Attribute Certificates, but the concepts for
validating an Attribute Certificate would be similar. We are not including
them in this document yet, as there is a need to clarify the use of
Attribute Certificates in the general case (more than one root trusted).
 
> the arguments seem to be that we need it for PMI because we use it for PKI
> or we need it to cover liability issues. The liability issue seems much less
> convincing when you recognize that the 509 PMI model does NOT include any
> inter-domain cross-certification equivalent. Documenting your own
> liability for internal applications isn't very interesting.

This has first a relationship with trust, which thenafter includes a
relationship with liability.

Denis

> Sharon
> 
> 
> -----Original Message-----
> From: Peter Williams [mailto:peterw@xxxxxxxxxxxx]
> Sent: Friday, March 15, 2002 6:49 PM
> To: 'Denis Pinkas'
> Cc: 'ietf-pkix@xxxxxxx'
> Subject: RE: Attribute Certificates and Privilege Policy
> 
> I dont see how privilege policy, as defined by ISO,
> has any equivalency relation to validation policy - as
> an architect speaking from a company that was
> conceived to deploy and has deployed over a hundred
> operational validation servers and associated validation
> policies in the world - for probably every major PKI
> vendors' system, and probably 50% of all operational
> commercial-grade PKIs!
> 
> Validation policies are the expression in some rule form
> of the risk management controls a RP uses to *Accept*
> a cert path, beyond the rules built into the simplistic path
> processing algorithm specified by ISO for
> trust chains *validation*; acceptance and validation
> are very different processes, especially in well written
> CPSs mapping technology onto law principles. ValiCert
> must have built now 10 quite-different validation policys, for
> various military projects and banking groups.
> 
> Whilst ISO rules for PKI trust chain processing
> properly arrange for inteoperability and navigation of trust
> domains (a valid ISO issue), validation policies address the
> risks applications face when PKI fails, PKI signals need to be
> ignored/overridden, redundacy of PKI chains, or PKI is used t
> o assist privilege-based control systems - whose purposes fall outside
> the scope of ISO PKI/PMI frameworks, or IETF profiles
> thereof.
> 
> In practice, privilege policy is already deployed worldwide, in
> two forms. Java 2 enables
> relying parties to sign and use an executable-form "AC", that limits
> privilege acceptance for privileges asserted by loading-code,
> using privilege-policy rule expressions that are
> expressed as executable code, selected and downloaded by the
> target system. Microsoft  Win32 OS's TCB does something similar
> since 5  years ago, using other signalling
> and enforcement techniques, that leverages a little of the
> Authenticode standardization in 2459, and other
> PKI-based techniques properly not addressed by PKIX.
> 
> Validation policies are, in contrast, all about validation of
> certificate chains, PKI and PMI varieties. AS we learned
> from the authoritative editor of X.509, the ISO intended
> that privilege policy enforcement has little or nothing
> to do with AC delegation path processing, and nothing
> whatsoever to do with PKI path processing. Validation
> policies are exclusively associated with the PKI
> and/or PMI chain processing.
> 
> I asked the question, is privilege policy enforcement
> PART OF path processing. Sharon indicated that it
> is not, though ISO wording and titling of X.509 sections
> 16.x.y could be improved. Hence validation policies
> are not equivalent in basis to privilege policies.
> 
> AS privilege policy and validation policy do take
> the perspective of relying parties, there
> is some limited consistency in that shared
> perspective, to be fair to Denis.
> 
> If ISO decide that, contrary to current intepretation
> by the editor of the ISO position, that privilege
> policy enforcement IS A PART OF path processing,
> then we could possibly agree on there being
> some equivalency basis.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: Friday, March 15, 2002 9:50 AM
> To: Sharon Boeyen
> Cc: 'ietf-pkix@xxxxxxx'
> Subject: Re: Attribute Certificates and Privilege Policy
> 
> 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