Re: criticality conformance

[Mark S Feldman <[e-mail]>]

...
> Perhaps you live in a different, safe and secure R&D/defense world to me.  

No, I think we all pretty much live in the same world:-)

...
> 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!

I see no problem with application-specific extensions, even
proprietary ones, as long as they do not make the certificates
unusable for other purposes.  In the end, and it may take some time,
if vendors make incompatible changes to what they advertised as X.509
certificates to "hook" users, the users will revolt.  Making a profit
with open standards is a different game, but it is still winnable.

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.

> 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).

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."  

I may use VeriSign as my root and I may be able to validate your
certificate back to VeriSign, but that does not mean that you may log
into my computer.  The certificate-based challenge-response login in
my computer is basing its decision on the validity of the certificate
in the X.509 sense and the distinguished name, issuername/serial
number, or some such.  Such a decision could also be made based on
non-critical extensions.  Should there be a "valid for login to TIS
systems" extension and should I believe it if I find it in your
otherwise valid certificate?  My responses is "No and no."

> 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.)

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.

  Mark

====
Trusted Information Systems, Inc.                Phone: [phone]
3060 Washington Road                            Direct: [phone]
Glenwood, Maryland 21738                           FAX: [phone]