Subject: RE: Attribute Certificates and Privilege Policy

From: Sharon Boeyen <[email-masked]>
Date: Wed, 20 Mar 2002 09:32:23 -0500

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. 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.  

If there are requirements to enhance the 509 model, those
requirements can certainly be submitted to the 509 work by PKIX.
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.
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. 
 
Sharon  

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Friday, March 15, 2002 6:49 PM
To: 'Denis Pinkas'
Cc: [email-masked]'
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:[email-masked]]
Sent: Friday, March 15, 2002 9:50 AM
To: Sharon Boeyen
Cc: [email-masked]'
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

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 21 Mar 2002 11:32:23 -0500

Sharon,
 
I’m confused about why you are tying the need for an attribute authority to issue certificates under more than one ‘attribute certificate policy’ to cross certification.
 
It’s simple matter of allowing a single AA to issue certificates under more than one policy, depending on the level of verification they perform with respect to the asserted attributes.  It may not make a whole lot of sense to operate that way if the attributes being asserted are for clearance authorizations, but as I understand it, attribute certificates as supposed to be more generic than that.  If I’m wrong about that, please tell me.
 
Consider the following hypothetical:
A laboratory that calibrates test equipment decides to embrace PKI/PMI technology and become an attribute authority.  Instead of putting a sticker on the side of the devices they calibrate, they issue an attribute certificate.  The “authorization” being granted by the attribute certificate is the authorization for the device to operate during the period specified by the AC’s validity period.  
 
In this scenario, it seems reasonable that the calibration lab may want to offer a few different levels of calibration services, depending on the level of testing they perform to calibrate the device.  They might, for example, require that devices used for medical/life support applications go through a more rigorous calibration procedure.  Maybe they want to have different liability levels associated with the different types of calibration.
 
It seems reasonable that the calibration lab (the AA) may want to issue different kinds of calibration stickers (the ACs) based on the type of calibration that was performed so it can only be held accountable for meeting the applicable calibration standards.
 
In this context, it seems reasonable that the AA may want to issue ACs under different policies and provide something in the AC that indicates the specific policy under which it was issued.
 
There’s no cross certification involved here.
 
Chris
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sharon Boeyen
Sent: Wednesday, March 20, 2002 9:32 AM
To: 'Peter Williams'; 'Denis Pinkas'
Cc: [email-masked]'
Subject: RE: Attribute Certificates and Privilege Policy
 
the arguments seem to be that we need it for PMI because we use it for PKI or 
  
Sharon

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 26 Mar 2002 15:16:14 +0100

Sharon,

> 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

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.

> requirements can certainly be submitted to the 509 work by PKIX.

So be it.

> 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).
 
> or we need it to cover liability issues. The liability issue seems much less
> 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