Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt

From: Peter Williams <[email-masked]>
Date: Mon, 11 Mar 2002 15:44:22 -0800

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:[email-masked]]
Sent: Monday, March 11, 2002 2:23 PM
To: [email-masked]'
Cc: [email-masked]'
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.

---

From: Steve Hanna <[email-masked]>
Date: Tue, 12 Mar 2002 10:09:36 -0500

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