RE: Cert comparison needs AI?

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Paul Koning <pkoning@xedia.com>
> 
> >>>>> "Anders" == Anders Rundgren <anders.rundgren@jaybis.com> writes:
> 
>  Anders> Stefan,
>  >> It means that when you form an application, you have to handle
>  >> this with care and make sure that the application don't produce
>  >> missleading results.
> 
>  Anders> Noop. In the absence of defined semantics, this property or
>  Anders> quality MUST be a part of a valid QC CPS.  The German (QC
>  Anders> sample?) CPS must state that you can't compare German QCs (or
>  Anders> do it on your own risk) while the Swedish and Finnish ID-card
>  Anders> programs guarantee that you can trust the static unique ID as
>  Anders> being the sole attribute to compare (after you have detected
>  Anders> that the cert really is belonging to these domains).
> 
> Maybe I'm reading too much into this.  Or my expectations are too
> high.  But it surely strikes me as very odd to have a "data type"
> whose semantics -- if any -- depend on the value of some unrelated
> other data object.  I suppose you could argue that it's like a tagged
> union type, but that seems a bit of a stretch.
> 
> To put it differently, on what principles is a person supposed to
> judge the merits of a proposed standard that contains components whose 
> meanings, if any, are undefined?



"Undefined" is overstating the case.  QC-03 says:

   "The serialNumber attribute type SHALL, when present, be used
   to differentiate between names where the subject field would
   otherwise be identical.  This attribute has no defined semantics
   beyond ensuring uniqueness of subject names."

"ensuring uniqueness" is a defined semantic, even if the process by
which uniqueness is ensured is relegated to the CPS (or CP) for a
particular domain.  Although I have one quarrel with the definition, I
basically agree with Stefan that using the serialNumber attribute to
contain a true serial number (a static identifier which refers to the
same entity even when the Common Name changes) fits within an amended
definition:

Stefan, could you change "would otherwise be identical" to
"might otherwise be identical" in the definition of serialNumber?
The former implies that serialNumber SHALL be used only in the case
of a known collision, whereas the latter accommodates the prophylactic
use of serialNumber in all certificates (within a given domain) to
eliminate the potential for collision.



I agree with Anders that the penultimate paragraph under "Security
Considerations" is not particularly helpful as it stands:

  "Comparing two qualified certificates to determine if they
  represent the same physical entity may provide misleading results
  and should be performed with care."

It is obvious that just because a QC contains an "unmistakeable
identity" does not imply that there is only one possible unmistaken
identity for a given physical entity. It's hard to see how this
result would be "misleading" to anyone.

On the other hand, if two certs contain the identical unmistakeable
identities yet refer to two different physical entities, then the
identities must not have been so unmistakeable in the first place,
and the QC has failed to satisfy the requirements of section 2.

Stefan, could you either delete that paragraph from "Security
Considerations", or replace it with something like:

  "A given physical entity may have multiple forms of unmistakeable
  identity.  It is not necessarily possible to determine by examination
  that two qualified certificates refer to the same physical entity."