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

[pgut001 at cs.auckland.ac.nz (Peter Gutmann)]

Martin Rex <Martin.Rex at sap.com> writes:

>But I really dislike the idea of expecting an empty DName (i.e. one that
>contains no RDName elements in the ASN.1 SEQUENCE) should have the same
>meaning as _NO_ DName at all!  Are you sure that this notion is interoperable
>with other implementations?

Because TLS client certs are so rarely used it's hard to say, the best I can
say is "I haven't run into problems so far", but that doesn't mean much given
the very small sample size.  A side-reason for leaving things this way is that
if anyone ever does run into this then it'll break in an obvious way, they'll
get back to me, and I can then get some hard data on what they're trying to do
with it and what sort of behaviour they expect from it.

As a generalisation, you'd be amazed at the total garbage you can put into
fields in security protocols and no-one notices.  Look at the (rather out of
date) shopping-list of certificate bugs in
http://www.cypherpunks.to/~peter/T2a_X509_Certs.pdf, there have even been
cases where major CAs have put random garbage (in some cases not even valid
ASN.1) into cert fields and no-one noticed.  So it could well be that
implementations are oblivious to whatever's in the CA-DN fields.  For example
since my code can't do anything useful with them it just skips them on read,
so there could be anything in there.  It's like TLS-Ext extensions (or X.509
extensions, or CMS attributes, or ...), if you can't figure out what to do
with something optional like this and it doesn't affect the protocol operation
then you can ignore it and continue.

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