On Fri, Mar 22, 2013 at 12:07:25AM +0000, Viktor Dukhovni wrote:
Any comments at all on the below? It is tempting to simply treat
"IN TLSA x 0 0" as "unusable", for all "x", and thereby discourage
the notion that it is a good practice to deliver full certificates
via DNS, instead of the TLS handshake...
> Are servers that publish their trust anchor details via DNS in full:
>
> _25._tcp.mail.example.com. IN TLSA 2 0 0 <DER cert in hex>
>
> exempt from being obligated to provide the same certificate somewhere
> in their trust chain? It is far easier to treat the "2 0 0" case
> as a more specific bulky match blob, than to also arrange for it
> to be an input into the client's trust chain construction algorithm.
>
> The latter is largely impractical with OpenSSL. I thought I saw
> some text in the RFC about "2 x y" trust-anchors needing to be
> explicitly provided in the server's trust chain, since clients
> cannot be expected to already have these on hand. Can't seem
> to find it any more.
FWIW, I have a practical solution for OpenSSL, but I'd rather not
have to field it.
> I am hoping that the above includes the "2 0 0" case, for though
> the cert is available in DNS it is not in the trust chain or trust
> store, and moving it from the DNS into the trust chain or trust
> store is non-trivial.
>
> I am also hoping that almost nobody will use match type 0 certs,
> and that in practice all TLSA records will be sha2 digests.
>
> If verifiers are obligated to attempt to use the certificate in
> "2 0 0" as part of the trust chain if missing, then I may need
> to treat "2 0 0" as "unusable" until OpenSSL makes it possible
> to configure each connection with a private list of additional
> trust anchors before starting the handshake (without polluting
> the trust store for future connections that use the same
> persistent SSL_CTX).
So no new OpenSSL library code is required to support this, if one
stares at the (lightly documented) OpenSSL API hard enough, but
still "IN TLSA x 0 0" looks unwieldy.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
