criticality conformance

[Peter Williams <[e-mail]>]

Re: criticality conformance (Peter Williams <[e-mail]>, 15:13)
To: Mark S Feldman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]


Mark,

Ive moved the conversation to a non-work list: on the matter of
conformance to v3 extensions in X.509 certificates, and
a bigger picture discussion of how to organize
extensions to reflect the needs of multiple applications,
consider this memo, brought about by your comment:

> Consenting applications should be able to do what they want.  Specific
> applications may restrict the usage of otherwise valid certificates
> based on many criteria, including, but not limited to, extensions.
> The only proprietary, vendor-specific information I've seen pre-loaded
> or hard-coded into applications are vendor-specific "root" keys.


Perhaps you live in a different, safe and secure R&D/defense world to me. 
I see
hard-nosed, commercially-driven proliferation of application-defined 
extensions;
and proprietary key management (PKI) extensions, used to hook users. The 
only
company I have seen which has sought to (a) cater for this inevitable 
market-based
reality (b) create a largely application-independent certificate
platform, is, believe it or not, Microsoft.

Extension contents has become the battleground in the certificate-based
application market. Whose definitions will win is...a platform war
prediction. However there may be a technology solution available. At
this stage in the game, however, too much is being earned by
having the proprietary extensions war; so its unlikely to see light of 
day! Such is
the nature of open standards; they intefere with profit!

A solution is to have a cert contain [a] content schema rule[s], in which
for each supported object class  (where the class notion is applied to 
cert extn
types), the various extensions pertaining to that class are
flagged - madatory/optional/required as appropriate to the application 
which
will use these extensions, for some purpose. The application will choose 
which object
classes it wishes to process from those present in the cert (ignoring 
others
classes, with their critical or otherwise extension values).

This notion replaces the criticality notion; which turns out
to be effectively useless, as we have now seen 3 experts say
in ietf-pkix. (It also makes the cert an effective application
enabling capability versus a mere digital id.)

What we did several months ago in the lab was place a schema rule 
instance
in the policy qualifier, which noted which extensions in
the extn sequence were mandatory, optional etc. Microsoft extended
this simple idea nicely, by allowing certain policy elements
to have an association with just a *subset* of present
extensions, whose particular identitying & governing content rule is 
present - for application
evaluation - in the particular qualifier. You might want to have a look 
at the
Microsoft PKI for software licensing and code signing; very well 
thoughtout
as a basis for a multi-application "certificate-platform".

Obviously one of the objects represented in the ceriifcate
extention set was intended to be the PKIX-like object, covering
application-independent processing, and general-purpose
key distibution support, which has proven itself on the whole to
be largely application-independent for public networks.

see http://www.microsoft.com/intdev/sdk/safe.htm
et al, perhaps for some context, etc.