On Mon, Jun 23, 2014 at 11:58:00AM -0400, Paul Wouters wrote:
> >The new draft operates at two layers, on the one hand concretely
> >extending 6698 to support raw public keys, and on the other hand
> >generalizing the approach to arbitrary "key material" (conceptually
> >beyond even raw public keys). My best guess is that were some
> >other kind of "key material" to be used with TLS, that is not in
> >SPKI format,
>
> Please note that this is to support non-TLS scenarios where the public
> key might not be transferred in-band like in the TLS case. That is,
> the draft extends 6698 to support publishing any kind of public key
> in SPKI format for verification. It does not suggest non-SPKI formats.
This was not clear. So the "TLSA" (does not stand for anything)
acronym is not supposed to be understood to apply just to TLS (and
by extension DTLS)?
So for example, would it apply to publishing KDC public keys for
cross-realm pkinit? Does it matter whether the lookup key for the
RRDATA would likely not be "_port._proto.domain", or would that
make the Kerberos cross-realm key use-case fall outside this update
to 6698. In other words does the new draft only apply to some
kind of transport layer security (lower case to distinguish from
TLS) where the end-point identity is necessarily _port._proto,
with with a TLSA-like RRDATA format?
Recall that we've added a charter goal of defining something for
client authentication, which is likely to reuse RFC 6698 RRDATA,
but will probably carry a different lookup key.
So if the scope of RFC 6698 is not TLS, is it just any application
where the 6698 RRDATA format seems to be useful?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
