Subject: QC Interoperability Was: Rename Qualified Certificates?

From: Anders Rundgren <[email-masked]>
Date: Mon, 17 May 1999 15:43:07 +0200

Stefan,
I have a rather serious comment to a paragraph in your last posting:

>Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
>It's purpose is NOT to state any functional or other requirements. It's
>purpose is only to provide technical interoperability between "Qualified
>Certificates". E.g. so that the information put into an Italian "Qualified
>Certificate", can be displayed and understood by a German, English or
>American software.

The QC draft MAY support legal interoperability (whatever that mean) but
for TECHNICAL interoperability you have a long uncertain way to go.

You CAN  (for example) create a Java class that READS a QC-compatible certificate
but what is the enormous value of that if the INTERPRETATION of a variant set of attributes is
somewhere outside of the draft?  The reader is < 1% of the QC problem.

And the optional biometric part is not even possible to read using a generic class
as the mechanisms to access biometric template data is not specified in any detail.

And if you put an already variant file-format like a QC in another flexible container
like PKCS #15 you can be sure of ZERO interoperability.  I.e. you MAY be able to READ
QC data but you won't be able to ACT (using generic code) because you don't know the
semantics given a set of different QC manufacturers.

##############################################################
I.e. to achieve Interoperability (in the sense that end-users would know it) requires a
very strict profile with a FIXED set of attributes and interpretation.
##############################################################

Sorry for being pessimistic but 20++ year of SW development has taught me that
universal flexible formats (like EDI) requires a great deal of "adjustments" for every
actual implementation before the s.c. interoperability shows up :-). 

The solution? Either there is none or a MSFT-like thing will happen.  I.e. a market-leader
sets a de facto standard which may or may not adhere to the QC-draft.

Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 May 1999 14:59:33 -0400

Anders,

The profile being discussed here addresses syntax for a specicial class of
certificates in the same way that RFC 2459 addresses syntax for a broader
class of X.509 certs.  None of the documents specifies how an application
will employ the raneg of data that can be represented in certs, especially
in light of the large number of optional extensions that are available.
Each application defines how certs are to be employed in the context of the
application.  S/MIME is doing this, as is IPsec.  The details of such
processing are the responsibility of the cognizant application WGs, not of
PKIX.

A valid question here is whether qualified certs need a single IETF WG to
represent them in this respect, or whether they will be used by several
different applications that the model described above for other
applications is still appropriate. My guess would be the latter.

Steve