Re: [IETF-PKIX] Key Identifiers

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

> From: Denis Pinkas <Denis.Pinkas@bull.net>
>
> The reality is that for discovering a path, you might have to walk up
> and down, but the verification should only be done "walking down". This
> means that no digital signature verification should be done before
> getting one or more candidate paths down.

Part 1 Section 6 states that conforming implementations must perform
path validation in a manner which achieves identical results to the
given procedure, which takes as input a full cert path and works
from top to bottom.

But I don't see how following this procedure saves on signature
computations:  for every point at which there is a choice of issuers,
you need a disambiguator.  That is either a signature verification or
something which gives a shortcut answer without ever giving a false
reject.  Heuristics such as validity checking (against the target date
only, NOT for issuer-subject validity nesting!) might help in a very
few cases.  AuthorityKeyIdentifier will allow you to reject all
inappropriate candidates, but it takes up space in the certs, as you
say.  Another, more radical, approach would be to define new
AlgorithmOIDs which include a one octet checkword in the signature
value, which could be compared against a specific high-entropy octet of
the authority public key.  This would eliminate 255/256 of the
unnecessary signature verifications.  NB: I'm not advocating this
approach, just using it as an illustration of a hack which could
improve pathbuilding efficiency without costing much space.


> > I have one problem with this approach: The verification path is not
> > fixed. Let us assume a CA gets certified by a set of other CAs. Some
> > users trust one of them, others some other CAs (which is why the CA
> > probably got this multiple certificates). When a user certificate
> > contains a reference to a single other CA, a user which does not trust a
> > specific CA will fail to verify the certificate, although there might be
> > a another path which would lead to a successful verification.
>
> I support this comment. This means that placing the key identifier will
> create failures in cases where successful verification could have be
> done applying a different approach.

I don't understand this comment.  If an entity has a certificate signed
by a particular issuer, that certificate will have the identifier of that
issuer's key.  A certificate from a different issuer will have a different
key identifier.  In what case will a key identifier cause a reject where
the signature would otherwise have verified correctly?


> > One question: Do we have an algorithm for a complete verification? There
> > is one that describes how to verify an existing FC path, but do we have
> > an algorithm on how to construct a path?
>
> We currently don't and we probably should define one.

Yes.  Santosh?


Dave Kemp