Re: [dane] DANE Client Authentication draft updated

[Shumon Huque <[e-mail]>]

On Tue, Jan 12, 2016 at 3:05 PM, James Cloos <[e-mail]> wrote:

> For draft-huque-dane-client-cert I'd still prefer RR names like:
>
>  _smtp._client.example
>
> for the cert provided by an smtp client which HELO/EHLOs as example.
> And similarly for other protocols.  Rather than things like _smtp-client.
>
> Putting all of the client TLSAs under a single label allows (but
> obviously does not require) them to be in their own zone.
>

Thanks for the feedback. I had the _service._client form in an earlier
version of this draft but Viktor talked me out of it, on the grounds of
insufficient usefulness and unneeded complexity. I'd be interested in
hearing other opinions on this point also.

On the "_smtp-client" label choice, I had originally used just "_smtp", but
a colleague more plugged into IANA service name registration procedures
advised me that I should choose a different client specific label. The
"_smtp" label is a server side label with an associated server side port,
and that reusing that label for a client identifier would elicit objections.

Than can be useful.
>
> And in the case where the proposed tls extension is not used, it should
> be OK for the name to be in CN, too.  So something like 'MUST be in
> either dnsName or CN, but SHOULD be in the dnsName'.
>

Current IETF specs strongly discourage putting domain name identifiers
in the subject CN (see RFC6125 for example), which I agree with, and
whose lead I followed. I suspect that DANE client certificates is enough
of a green field application, that there aren't backwards compatibility
concerns that would prove to be impediment here. Even if you were using
public CAs, practically all of them today can issue domain names in
dNSName. SRVName unfortunately is a real world impediment for some
parties, which is why that one isn't a MUST.

What specific concerns did you have in mind with disallowing CN?

-- 
Shumon Huque