Re: Key identifiers

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

> > = Denis Pinkas 
>   = David P. Kemp

> > 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.

In most cases you will have the saving. The only case where you will not
have the saving is when two CAs will have the same name (whether that
name is a DN or an alternate name). This case should be very seldom but
might exist. For that very seldom case, I do not think that we need
additional mandatory parameters that every CA shall support and that
takes some space in the certificate.  

>           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?

The problem is that the link is pointing *back* to a particular cert of
a CA. A CA may have its signing public key signed by more than one CA.
In that case the end-entity will point to only one of these certs which
may end up to an intrusted point for the receiver. Using a different
cert for the key of the CA could end up to a trusted point for the
receiver. This is why you may end up with a reject.

> > > 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

Denis



-- 
      Denis Pinkas     Bull S.A.          mailto:Denis.Pinkas@bull.net
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21