On Mon, Jun 23, 2014 at 11:05:42PM +0200, Martin Rex wrote:
> The Selector Type 1 "SubjectPublicKeyInfo" is already defined (Section 7.3)
> and explained (Appendic A.1.2.2) in rfc6698:
>
> https://tools.ietf.org/html/rfc6698#section-7.3
> https://tools.ietf.org/html/rfc6698#appendix-A.1.2.2
>
> Existing TLSA/DANE-aware TLS clients will (silently) assume, that this
> selector refers to a public key that is embedded in a more-or-less regular
> X.509 certificate,
Hence the 6698 update. If the service is in fact a TLS service,
clients using X.509 handshakes will not see anything new, because
they won't use the new extension to negotiate use of raw public
keys.
> and that this certificate will appear in the
> (PKIX) certification path that the TLS client came up with for
> certificate path verification.
DANE-EE(3) is not PKIX and has no PKIX path.
> The newly envisoned usage scenario seems to be for use by TLS peers
> with bare public keys (i.e. that do not exchange any certificates at
> all and do not, or not necessarily manage such keys with an X.509 cert
> wrapper/container.
Many clients will support both, and servers even more so may be
willing to use the same public either adorned in X.509v3 finery,
or bare (with or without the emperor's new clothes).
> In theory, this looks like TLSA/DANE aware clients might get confused,
The underlying meaning of "DANE-EE(3) SPKI(1) ?" is unchanged, it
matches a leaf SPKI object in either form. There is no confusion.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
