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

[Peter Williams <[e-mail]>]

I suspect that the only confusion that is relevant is summarized
in the following question and commentary:

(Q) Does one perform the tests laid down by the privilege 
policies(s) *during* AC path processing, or not?

if an AC is "valid" this implies that the relevant
privilege assertions DID INDEED MEET the rules of the relevant privilege 
policy(s). The last implication is another way of asking the 
question (Q), in functional  form. The function is always true 
for a true antededent if path processing for a valid chain itself 
evaluates (validly asserted) privileges against their 
privilege policies and environment values.

(Obviously Roberto's simple example of signing limit enforcement via
PMI is just a case of a privilege assertion  and corresponding
sufficiency determination  where the transacations signing-amount (the 
environment var value) would be judged against the privilege policy 
of the bank/payment-card (which presumably says, the AC-privilege 
assertion is invalid if signing amount > signing limit. Obviously thge
policy could be more complex, and track cumulative limits, with
greater use of env vars.

To PKIX and ACPROF:

This issue of where privilege policy is enforced affects the design of 
a certified AC path processing module, or a DPV server addressing AC 
path evaluation. For this issue, it makes no difference under 
X.509 conformance whether the path has one or more 
elements. Let us assume one element:

(1) If privilege asssertion sufficiency tests are performed *during* 
path validation, then
the privilege policy(s) and enviornment vars must
be passed TO the module/server FROM the client, where
the client normally collected the privilege policies from
the bank's directory; and where environment var values are 
obivously established (obviously)

(2) If the path processing module only performs trivial authentication
of AC chains re PKI, but does not enforce the privilege policies,
then one assumes that the client of the AC path processing
module/server enforces the privilege policys. In this case, a path 
processing RESULT from the module/server of valid DOES NOT satisfy
X.509 16.1; the Path is only "partially evaluated" at
that point.

X.509 16: "The role processing procedure and delegation processing procedure

are done prior to the determination of whether or not the asserted
privileges 
are sufficient for the context of use within the basic procedure." suggests
(to me very clearly, but inevitably not clearly to Denis) along with the 
context that  "AC path processing itself" must determine whether or not 
the asserted privileges are sufificent for the context of us. That is, if a 
DPV server is faced with path processing an AC, it must perform perform the
determination of sufficiency.

Both ACPROF and DPV requirements I-Ds are critically insufficient on
this issue, is  my comment to IETF. The fix is to align both
with X.509 PMI 16.1, basic processing of ACs, as REQUIRED
for X.509 conformance.

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]]
Sent: Tuesday, March 12, 2002 7:10 AM
To: Peter Williams
Cc: 'Yee, Peter'; '[e-mail]'; '[e-mail]'
Subject: Re: Privilege policy (was Re: I-D
ACTION:draft-ietf-pkix-acrmf-01.txt)


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