Re: Privilege policy (was Re: I-D ACTION:draft-ietf-pkix-acrmf-01.txt)

[Steve Hanna <[e-mail]>]

There seems to be some ongoing confusion about privilege
policy, as defined in X.509. Privilege policy determines
whether the privileges of a privilege holder are sufficient.
An access control list is one example of a privilege policy.

Although ACPROF does not mention privilege policy, I believe
that there's an unstated assumption that after an AC has
been validated it may be used in access control decisions
or for other purposes. It is at this point that privilege
policy enters the picture.

The only place in X.509 AC validation where privilege policy
is involved in is where the acceptable privilege policies
extension is present. In that case, the verifier must
check that the OID for the privilege policy it's planning
to use is included in the list of OIDs in the extension.
However, ACPROF does not support this extension. Therefore,
there is no need for it to worry about privilege policy.

-Steve

Peter Williams wrote:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-09.txt
> 
> describes a set of AC verification rules, when an AC chain
> has one element.
> 
> X.509 16.1 defines the "basic path processing" requirements
> for processing "a single AC". X.509 16 is clear that 16.1
> is REQUIRED for the case of processing a single AC.
> 
> Peter, a question (Q): What is the relationship between
> "privilege policy" (as used in X.509 16.1) and ACPROF section
> 5 "Attribute Certificate validation?"
> 
> I dont believe profiles can remove the X.509 requirement
> to follow X.509 16.1 when validating an AC. As ACPROF makes no
> mention of privilege policy, we have to assume that
> X.509 16.1 controls, and that conforming implementations
> MUST implement the privilege policy enforcement
> requirements.
> 
> A reasonable answer to the question (Q) is that
> "validating right-to-use" a privilege is not the same
> thing as "validating an AC" - even though these two ideas
> are intertwined in the international standard, section 16.1.
> Hence, privilege policy matters fall outside the scope of ACPROF
> and IETF.
> 
> If this latter case is your thinking, then of course
> designers of conforming implementations must
> look to X509 for control when validating actual
> privilege *assertion* at privilege "use" time.
> 
> If we could clearup that ACPROF does not control
> validation of privilege *assertion*, this would
> be valuable. Privlege assertion within a lifetime
> is of course what matters and what makes ACs
> viable. Validating the privilege assertion
> can of course be critically important to
> the application's security policy.
> 
> Peter.
> 
> -----Original Message-----
> From: Yee, Peter [mailto:[e-mail]]
> Sent: Monday, March 11, 2002 2:23 PM
> To: '[e-mail]'
> Cc: '[e-mail]'
> Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt
> 
> >I recognize that [ACPROF], the Internet Attribute Certificate Profile, does
> >not currently recommend the use of delegation and AC chains as specified in
> >the X.509 standard [X.509-2000], however I would hope that your Internet
> >Draft [ACRMF] on Attribute Certificate Request Message Format will not
> >preclude it.
> 
> Yes, I would call that an oversight on my part.  I have to admit that
> sometimes I think of ACs within the limited scope of ACPROF.
>