RE: Attribute Certificates and Privilege Policy

[Peter Williams <peterw@xxxxxxxxxxxx>]

IETF has a simple choice to make
in my view, in its profiling of X.509 
PMI.

It either contiues to bastardize the PMI into
an "attribute-cert framework", for
sending DoD and NATO clearances
around with those S/MIME implementations
doing MAC, 

Or,


It use PMI for real **privilege** management, not 
conveying  "attributes" about PKI subjects
under some ambiguous control model,
neeing ambiguous CPSs to establish meaning.

Currently, there is no evidence of any real
use of "Privilege" in IETF's profiling of 
the PMI. Its just using the AC as a syntax for 
expressing attributes about subjects. ACPROF
doesnt even call an AA an AA, it calls
it an AC issuer, presumably so folks are not
bound to the ISO semantics of AAs and SOAs.

Whilst DOD in DMS S/MIME does have real privileges
to be managed, which are not mere authorization
attributes representing clearnaces, they dont seem
to surface much in ACPROF's implied control and
issuing model.

Peter.
-----Original Message-----
From: Christopher S. Francis [mailto:chris.francis@xxxxxxxxxxxxxxxx]
Sent: Friday, March 15, 2002 11:58 AM
To: Denis Pinkas; Sharon Boeyen
Cc: ietf-pkix@xxxxxxx
Subject: RE: Attribute Certificates and Privilege Policy



I concur with Denis.  It seems entirely reasonable that an AA may want to
apply different levels of verification of the attributes presented in the
ACs that it issues.

Just as commercial CAs issue PK certificates under various policies,
charging higher prices for higher levels of assurance, an Attribute
Authority may want to issue ACs under various policies, with different
levels of assurance based on the level of verification of the asserted
attributes.

Chris

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On
Behalf Of Denis Pinkas
Sent: Friday, March 15, 2002 12:50 PM
To: Sharon Boeyen
Cc: 'ietf-pkix@xxxxxxx'
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