|
I agree that we need an AC Policies
extension. An AA could issue multiple types of ACs and just having the DN on
the Cert will not provide sufficient information to identify the type of AC. An
AC policy extension will allow identification. Principal Consultant NetWorks Group O. 810.225.4800 ex. 2245 M. 810.599.0879 E. www.networksgroup.com -----Original Message----- A few
weeks ago in Atlanta we agreed to take the issue of "Why do we need an AC
Policies extension?" to the list for discussion. I wanted to wait for the OCSP v2 storm to
subside a bit, but I'd like to have a productive dialog on this issue
before we get into the holidays. The
reason we need an AC Policies extension is this: An attribute authority can perform various
levels of verification with regard to the attributes asserted in an AC. The AA's verification procedures and
other operational rules it abides by are documented in an AC policy. There is currently no way to reference this
policy in an AC. The AC Policies
extension provides that. Why do we NEED
to reference the AC policy in the certificate?
It's useful because it allows us to cryptographically associate an
individual AC with the policy (or policies) that apply to it. This is better than simply associating an AC
with an AC Policy by looking at the issuer DN for the same reasons that it is
better to look at the Certificate Policy when evaluating a PKC vs. just looking
at the issuer DN. First, it provides an
explicit, cryptographically verifiable association between the certificate and
its associated policy. Second, it allows
a single AA to issue attribute certificates under multiple policies. This is a useful option to have in certain
scenarios, particularly when you begin to think about attribute certificates
outside the context of access control. Here's
a hypothetical (non-access control) scenario.
This abstract example is based on WetStone's experience in
operating a real-world attribute authority.
Consider a calibration and test lab that performs periodic measurement
and calibration of pulse rate monitors.
In some cases these monitors are used in life-critical situations and in
others the devices are for consumer (home) use.
Clearly different (more stringent) procedures and calibration
constraints will be required for the devices used in life-critical
situations. Typically, when devices are
calibrated, the lab puts a sticker on the device authorizing it for operation
in a specific environment for a specific period of time from the calibration
date. They use Green stickers for devices
calibrated to consumer (home use) standards and Red stickers for devices
calibrated for use in life-critical environments. A record of the calibration measurements is
also included on the sticker. Now the
lab is going hi-tech and they want to issue an electronic version of their
calibration stickers. They decide to use
attribute certificates. The holder of
the attribute certificate is the device being calibrated. The issuer is the calibration lab. The attribute being asserted is the
device's calibration status based on the device's measured
performance. The end of the
certificate's validity period represents the expiration date of the
calibration sticker. The calibration
measurements are included in the attribute value. Separate AC Polices are created for
life-critical calibrations and consumer (home use) calibrations. These policies define different levels of
verification that the lab performs when calibrating the devices for home vs.
life-critical use. The policies also
include things like statements of liability and clearly spell out the
obligations of the lab and the owners of the devices. The AC Policies extension could be used here
to explicitly assert the policy under which a particular calibration was
performed --- a cryptographically verifiable equivalent of getting a Green
sticker vs. a Red sticker. Right now,
there's no standards-based way to make this assertion in an attribute
certificate. So, just
as a Certificate Authority can issue identity certificates under different
certificate policies, an attribute authority can issue attribute certificates
under different "attribute policies", depending on the level of
verification applied to the asserted attributes. It is useful to specifically assert the
policies that apply to attribute certificates for the same reasons that is
useful to state the certificate policies that apply to public key
certificates. It's not really that
big of a jump. Honestly, I can't
figure out why this isn't obvious to everyone :). The AC Policies extension provides a
mechanism to reference an AC Policy in an attribute cert the same way we
reference certificate policies in public key certificates. Well
there it is. Your comments, questions,
and criticisms are welcome. I hope we
can reach a consensus one way or the other on this. Chris |