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

[Stefan Santesson <stefans at microsoft.com>]

On the original question:

> It is claimed that OpenSSL, IE and Firefox does not enforce the second
> MUST in the paragraph above, and succeeds in verifying an
> out-of-sequence chain.  I haven't verified the claim.

A Microsoft based SSL server will insert the certificates in order. A Microsoft based SSL client doesn't require the certificates to be in order. The client simply passes these certificates to the CertGetCertificateChain API in the hAdditionalStore parameter. This will validate the subject certificate regardless of order.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On Behalf Of
> Simon Josefsson
> Sent: den 6 oktober 2008 10:51
> To: tls at ietf.org
> Subject: [TLS] Verifying X.509 Certificate Chains out of order
>
> All,
>
> We've received a request to verify X.509 certificate chains out of
> order
> in GnuTLS.  Doing that would violate the following in RFC 5246 (earlier
> versions had similar language), §7.4.2:
>
>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the
> root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order
> to
>       validate it in any case.
>
> It is claimed that OpenSSL, IE and Firefox does not enforce the second
> MUST in the paragraph above, and succeeds in verifying an
> out-of-sequence chain.  I haven't verified the claim.  It appears as if
> the OpenSSL developers don't consider their behaviour as a bug (see
> reply below).
>
> For more details, including the particular certificate chain in this
> example, see:
>
> http://thread.gmane.org/gmane.network.gnutls.general/1383/focus=1384
>
> I can see several reasons to enforce the MUST recommendation here, e.g.,
> covert channels, DoS-considerations, unneeded complexity.
>
> What are others opinion on this?  I'm looking for some guidance on
> whether we should modify our current behaviour.
>
> /Simon
>
> Peter Volkov <pva at gentoo.org> writes:
>
> > Is it possible to do something similar in gnutls? It looks like there
> > are reasons to validate certificate with wrong order...
> >
> > -------- Forwarded message --------
> > From: Tim Hudson <tjh AT cryptsoft  com>
> > Reply-TO: openssl-dev at openssl.org
> > TO: openssl-dev at openssl.org
> >
> > Peter Volkov wrote:
> >> CC'ing openssl developers for their opinions, since I think this
> >> behavior better to have consistent or configurable. Description of
> the
> >> problem is here:
> >
> > Placing this in context - connect with internet explorer or firefox
> to
> > https://metasploit.com/ and you will see that both of those
> independent
> > implementations see nothing wrong with the certificate chain and
> handle the
> > redirect to http://metasploit.com/ without and errors or warnings.
> >
> > Implementations typically take the list of certificates as untrusted
> > certificates to add into the process of walking the certificate chain
> to a
> > trusted root certificate. There are pragmatic reasons for doing it
> this way.
> >
> >  From an interoperability point of view remember the adage - "Be
> strict in what
> > you generate, be liberal in what you accept"
> >
> > Tim.
> >
> ______________________________________________________________________
> >
> >
> > --
> > Peter.
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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