On Tue, Jan 12, 2016 at 3:05 PM, James Cloos <[email protected]> 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
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
