Re: [TLS] Verifying X.509 Certificate Chains out of order

[Martin Rex <Martin.Rex at sap.com>]

Peter Gutmann wrote:
> 
> [Replying to two messages at once]
> 
> Axel.Heider at gi-de.com writes:
> 
> >> I'd say modify it, in fact I'm not sure what the rationale for requiring
> >> ordering was in the original spec, "it's tidier that way" doesn't strike me as
> >> a good argument :-).
> >
> >Consider TLS on low-end or embeddede devices with limited ressources. Walking
> >through the chain becomes difficult or even impossible if there is no order.
> 
> Again, how can you create an implementation that can run the entire SSL
> protocol but can't manage a few 32-bit pointers across three or four certs?
> This seems like a total red herring, it's difficult to think of an
> implementation that can perform the necessary cert verification but somehow
> can't manage an extra pointer swap.

It all depends on the PKI software (and the modularization of APIs
and datatypes of that PKI software) how much wasted effort there is.

Since Stefan mentioned it lets take a look at Microsoft SChannel/CryptoAPI
how it might be working there.

I don't know the detail, but Stefan mentioned that "CertGetCertificateChain"
is called used at some point.

Looking at the (relevant) input and output parameters:
  CertGetCertificateChain
       PCCERT_CONTEXT        pCertContext,
       HCERTSTORE            hAdditionalStore,
       PCCERT_CHAIN_CONTEXT* ppChainContext

So in order to pass any additional certs besides the initial
end entity cert from the certificate_list of the SSL/TLS handshake
message, one must first create a "HCERTSTORE" and parse&store
the additional certificates from the certificate_list there.

The output of CertGetCertificateChain() is a CERT_CHAIN_CONTEXT
that contains one (or more) CERT_SIMPLE_CHAIN.  I don't see it in
the documentation (and its not obvious from the function name),
but I assume that the signatures on the output certificate chain has
also been verified.


Lacking experience I don't know how many duplicates of unparsed
certificates are being created in this process.

An optimized approach with a differently modeled PKI Software would
have built a CERT_SIMPLE_CHAIN kind of structure straight from the
SSL/TLS handshake exactly as it falls out of the ASN.1 parser
and use and then called a certificate chain verifier that
looks for a trust anchor matching this chain and checks the
relevant certificate attributes and signatures on the path
from the chosen trust anchor down to the end entity cert.

It may be less generic, but certainly it will be more efficient
in terms of CPU cycles.


While it might not need a lot of pointer-swapping to reorder
certificates in the chain, it will require a significant amount
of non-trivial comparisons to determine what the correct order is.


I haven't benchmarked the MS-CryptoAPI approach, but I assume that
the vast number of features that are offered come at a cost.
 

-Martin
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls