Re: criticality conformance

[Peter Williams <[e-mail]>]

> 
> I see two uses of certificates evolving:
> 
> 1) Application-specific certificates.  They may be perfectly valid
> X.509v3, but they are linked back to a special, limited purpose root
> or they have special extensions, perhaps carrying information not
> available elsewhere.  These certificates are proprietary black boxes.
> They could just as well be something other than X.509 certificates,
> but the application authors chose X.509 as an expedient, marketing
> ploy, what have you.
> 
> 2) Identity certificates that are of general use.  More or less the
> original PEM model.  The problem here is the lack of infrastructure.
> This has largely been bypassed in the rush for (1) above.  Separate
> mechanisms will map identity to authority, privilege, etc.


The rush is the fact that certificates now solve
an important problem to users - key distribution
supporting a modicum of end-end privacy.

Steve Crocker trained you well in constantly saying (so that
people might eventually believe you) X.509 cannot occur
as there is no infrastructure.

Turns out (now there is money flowing the certs business)
the infrastructure was there all along. D&B have
huge organizational dbs, suitable for auth managament,
and Equifax have huge residential dbs suitable for...

The directory problem has been solved by the Web;
see several directory services now available at
URLs, and cert distribution within those only
required a mime-type...

With refienement, LDAP may well be integrated into
the Web as a locator protocol for more refined
service access, but its immaterial functionally.

  
> In the end, isn't the application granting a privilege the sole
> arbiter of the validity of a certificate?  Maybe, as I said
> previously, "validity" is the wrong word.  A certificate may be
> perfectly valid in the X.509 sense, but it may not be "valid for a
> particular purpose."

Of course. certs only perform key distirbution. That key
may be obtained over such a channel which allows the
applciation to assume the properties are suitable
for a given use. In practice such properties
come down to a policy oid, which the app can select on,
and know represent an authenicated channel of authoitative
keying. Subscriber agreement during certiifcate management then
allows consumers to decide whether the policies are suitable
for use in support of purpose A or B, or none. The cert
is itself immaterial; what matters is its background
management procedures embodied in the policy id.

 
> A specific extensions can easily be critical or non-critical in all
> cases.  Being able to say otherwise in the certificate with the
> criticality flag creates confusion (I think this is similar to your
> original question).  It is a shame that the OID space for extensions
> can't be divided into critical and non-critical (say, even and odd),
> creating an atomic bond between the extension and its criticality -- no
> need for external, possibly ambiguous, rules identifying extensions as
> critical or not.

We can do this. IETF PKIX creates a pkix oid in the internet space,
and has two subtrees. Into one or the other it reassigns the numbers
of the ISO oids, and all IETF people use the IANA versions. Its
only a number, but with pkix-profiled criticality specialization
suggested by TIS. This is exactly how IETF needs to add
value to the raw ISO work, to make it practicable.