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

Peter Williams <peterw@valicert.com> Tue, 12 March 2002 00:30 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00692 for <pkix-archive@lists.ietf.org>; Mon, 11 Mar 2002 19:30:11 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id g2BNiY002140 for ietf-pkix-bks; Mon, 11 Mar 2002 15:44:34 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2BNiW802135 for <ietf-pkix@imc.org>; Mon, 11 Mar 2002 15:44:32 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0GSU005011WRZM@ext-mail.valicert.com> for ietf-pkix@imc.org; Mon, 11 Mar 2002 15:43:39 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0GSU005GG1WQA7@ext-mail.valicert.com>; Mon, 11 Mar 2002 15:43:39 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <GK1PP7VF>; Mon, 11 Mar 2002 15:44:29 -0800
Content-return: allowed
Date: Mon, 11 Mar 2002 15:44:22 -0800
From: Peter Williams <peterw@valicert.com>
Subject: RE: I-D ACTION:draft-ietf-pkix-acrmf-01.txt
To: "'Yee, Peter'" <pyee@rsasecurity.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Francois.Rousseau@CSE-CST.GC.CA'" <Francois.Rousseau@CSE-CST.GC.CA>
Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E01F4A524@polaris.valicert.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

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:pyee@rsasecurity.com]
Sent: Monday, March 11, 2002 2:23 PM
To: 'Francois.Rousseau@CSE-CST.GC.CA'
Cc: 'ietf-pkix@imc.org'
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.