Re: [IETF-PKIX] OCSP: Method of Identifying Certificates

[Jeff Weinstein <jsw@xxxxxxxxxxxx>]

Tim Polk wrote:
> Part 1: Hashing DNs
>
>  There is a major problem with substituting the hash of an issuer's DN for
> the DN itself.  First, the X.501 string matching rules ignore leading and
> trailing white space, and compress consecutive white space characters into
> a single white space character.  In addition, many of the X.501 Name
> subtypes are defined with "caseIgnoreMatch" and "caseIgnoreSubstringsMatch"
> .  The result is, c=us matches c=US matches c=uS.
>
> This means that the hash of two DNs may be different, but the DNs may
> match.  You need to send the DN.

Can't you just canonicalize the DNs before hashing?

> Part 2. DN collisions
>
> >    Some people have argued that if DNs clash, everything in PKIX
> >breaks.
>
> Those people are WRONG. The security of PKIX implementations does *not*
> rely on the name space. The performance will be degraded by DN collisions,
> but implementations will not fail as a result.
>
> Path validation always relies on signatures.  There is no direct security
> implication to having n CAs with the same name (say "X").  Certificates
> bind a name AND KEY.  If the name is right, but the key is wrong, path
> validation will fail.  The impliciations are in the areas of performance,
> procedures, and jurisprudence.

  I do agree that security is not compromised.  However if you are saying
that the result is not "broken", then I strongly disagree.

> The key identifiers do help this situation.  They help the software to find
> useful paths quickly.
>
> A final addendum to your story.  Non-aligned country Z's CA (called "Z")
> issues certificates to East and West X's CAs, which are using the same name
> ("X"), with different constraints.  The path validation routines should
> work, whether or not the keyidentifers are in use.  East and West X use
> different key pairs, so everything works.  (Especially the path validation
> software, which works overtime to sort it all out.)

  Lets say that I am trying to validate an end-entity cert that is issued
by west-"X", but I only have CA cert for east-"X" available locally.  I will
try to validate the end-entity cert and get a signature failure.  At this
point there is no way for me to know that a cert for west-"X" even exists,
much less how to get it.  I don't consider this a degradation in performance,
but rather an avoidable failure.

  In the example you presented the CA "Z" clearly did the wrong thing by
issuing certs to two different entities with the same identifying
information.  In the case of two independent roots using the same
name, things get muddier.

        --Jeff