[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Attribute Certificates and Privilege Policy



Title: RE: Attribute Certificates and Privilege Policy

Sharon,

 

I’m confused about why you are tying the need for an attribute authority to issue certificates under more than one ‘attribute certificate policy’ to cross certification.

 

It’s simple matter of allowing a single AA to issue certificates under more than one policy, depending on the level of verification they perform with respect to the asserted attributes.  It may not make a whole lot of sense to operate that way if the attributes being asserted are for clearance authorizations, but as I understand it, attribute certificates as supposed to be more generic than that.  If I’m wrong about that, please tell me.

 

Consider the following hypothetical:

A laboratory that calibrates test equipment decides to embrace PKI/PMI technology and become an attribute authority.  Instead of putting a sticker on the side of the devices they calibrate, they issue an attribute certificate.  The “authorization” being granted by the attribute certificate is the authorization for the device to operate during the period specified by the AC’s validity period. 

 

In this scenario, it seems reasonable that the calibration lab may want to offer a few different levels of calibration services, depending on the level of testing they perform to calibrate the device.  They might, for example, require that devices used for medical/life support applications go through a more rigorous calibration procedure.  Maybe they want to have different liability levels associated with the different types of calibration.

 

It seems reasonable that the calibration lab (the AA) may want to issue different kinds of calibration stickers (the ACs) based on the type of calibration that was performed so it can only be held accountable for meeting the applicable calibration standards.

 

In this context, it seems reasonable that the AA may want to issue ACs under different policies and provide something in the AC that indicates the specific policy under which it was issued.

 

There’s no cross certification involved here.

 

Chris

 

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Sharon Boeyen
Sent: Wednesday, March 20, 2002 9:32 AM
To: 'Peter Williams'; 'Denis Pinkas'
Cc: 'ietf-pkix@xxxxxxx'
Subject: RE: Attribute Certificates and Privilege Policy

 

Just a couple of points to add:

The 509 PMI framework does not have any equivalent to
cross-certification defined (it was included in early drafts
but dropped from the spec prior to approval). The model is
really addressing environments where the SOA and the verifier
are in the same "security domain" and does not really address
any cross-domain issues. Verifiers are expected to be configured
with a trusted copy of their SOA public key as they are today for
trust anchors in PMI. The verifier trusts the SOA as the ultimate
source of authority for a set of privileges. 

If there are requirements to enhance the 509 model, those
requirements can certainly be submitted to the 509 work by PKIX.
From a process standpoint there is no problem, the liaisons
already exist and we've worked successfully on other topics
through this channel, regardless of who agrees or disagrees with the
specific topic.

From my own personal standpoint, I'm not yet convinced of the requirement.
the arguments seem to be that we need it for PMI because we use it for PKI or
we need it to cover liability issues. The liability issue seems much less
convincing when you recognize that the 509 PMI model does NOT include any
inter-domain cross-certification equivalent. Documenting your own liability
for internal applications isn't very interesting.
 
Sharon