On Tue, Apr 16, 2013 at 04:42:24PM -0700, Paul Hoffman wrote:
> > The TA whose *digest* is in TLSA is "Some issuer 3 (of 2)" whose
> > certificate is not sent in the server chain. How is the client
> > supposed to verify the chain?
>
> As Jim points out, the client might already have it pre-loaded.
> If the client doesn't have it pre-loaded, the TLS handshake fails.
>
> Getting the key or certificate from the TLS server would help,
> but it is not required for the scenario to work.
Yes, some clients *might* have the certificate in hand, and *might*
be able to use it augment to augment the chain, and thus *might*
be able to use the TLSA association, but this is not a basis for
an interoperable protocol.
A client that uses DANE to authenticate servers per their TLSA RRs
or else fail must have some assurance that conformant servers can
be verified.
I am writing a client that needs to know whether certificate usage
"2" TLSA RRs are "usable". Failure to authenticate peer SMTP
servers and delayed email will not do anyone much good. The idea
is to promote DANE and DNSSEC adoption not give both a bad name.
Can I expect server operators to provide the TA certificate in the
TLS handshake server chain? If so on what basis? Their incisive
logical reasoning ability?
If I can't then usage 2 digests are "unusable". Shipping code that
makes mail delivery fail to RFC conformant peers is not particularly
attractive.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
