...
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: +1 301 854 6889 3060 Washington Road Direct: +1 301 854 5704 Glenwood, Maryland 21738 FAX: +1 301 854 5363
binAbymo8523k.bin
Description: application/moss-signature