Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

[Viktor Dukhovni <[e-mail]>]

On Mon, Jun 02, 2014 at 02:52:15PM +0000, Viktor Dukhovni wrote:

>     * What is the representation of oob public keys in DANE TLSA
>       records.  Proposed "3 1 X".
> 
>       [FWIW I support this view, with the added observation from
>       James Cloos that "3 0 0" can also match raw public keys via
>       the enclosed SPKI value].

In whatever document ends up publishing the details,  I would say:

    TLS clients that support out of band public keys ([TLS WG
    document reference]) authenticated via DANE TLSA records SHOULD
    NOT employ the "oob public key" TLS extension unless all the
    server's TLSA records are compatible with out of band public
    keys.  The client SHOULD send an SNI extension with the server's
    TLSA base domain even if it is willing or expecting to use out
    of band public keys.

    [ Rationale. ]

    Compatible TLSA records include all records with certificate
    usage DANE-EE(3) and selector SPKI(1) with any matching type.
    Clients MAY also elect to treat records with usage DANE-EE(3),
    selector Cert(0) and matching type Full(0) as compatible,
    provided they are willing and able to extract the public key
    from such a TLSA record for comparison with the server's bare
    out of band public key.

For the server side, I would add:

    Servers that support "oob public key" MAY employ SNI to select
    the correct public key, either by identifying a matching 
    certificate from which to extract the key, or via some other
    mapping from the requested domain to the corresponding key.

-- 
	Viktor.