criticality conformance

Peter Williams <> Thu, 16 May 1996 23:48 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa27916; 16 May 96 19:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa27912; 16 May 96 19:48 EDT
Received: from by CNRI.Reston.VA.US id aa06367; 16 May 96 19:48 EDT
Received: from by neptune.TIS.COM id aa19326; 16 May 96 19:13 EDT
Received: from by neptune.TIS.COM id aa19309; 16 May 96 19:09 EDT
Received: by; id TAA03679; Thu, 16 May 1996 19:10:43 -0400
Received: from by via smap (V3.1) id xma003675; Thu, 16 May 96 19:10:14 -0400
Received: from by (4.1/SUN-5.64) id AA14857; Thu, 16 May 96 19:10:26 EDT
Received: by; id TAA03672; Thu, 16 May 1996 19:10:13 -0400
Received: from by via smap (V3.1) id xma003669; Thu, 16 May 96 19:09:54 -0400
Received: from (Gateway-Outside.Verisign.COM []) by (8.7.4/8.6.12) with ESMTP id QAA23439 for <>; Thu, 16 May 1996 16:12:33 -0700 (PDT)
Received: from peter ( []) by (8.7.4/8.6.12) with SMTP id QAA11459 for <>; Thu, 16 May 1996 16:01:15 -0700 (PDT)
Message-Id: <>
Date: Thu, 16 May 1996 15:16:11 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Williams <>
Organization: VeriSign, Inc
X-Mailer: Mozilla 3.0b3 (Win16; I)
Mime-Version: 1.0
Subject: criticality conformance
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Re: criticality conformance (Peter Williams <>om>, 15:13)
To: Mark S Feldman <>


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 
and proprietary key management (PKI) extensions, used to hook users. The 
company I have seen which has sought to (a) cater for this inevitable 
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 
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 
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 
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 
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.

et al, perhaps for some context, etc.