On Tue, Jan 12, 2016 at 8:31 PM, John Levine <[email protected]> wrote:
> >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. > > Yes, no kidding. > > In the DNS, service names only appear as subnames of transport names. > So one possibility would be to register smtp-client as a service name, > so the DNS label would be _smtp-client._tcp.whatever.example. > I would say "only appear *today* under transport names", but this isn't a hard and fast requirement. We should feel free to construct TLSA owner names in a form that makes sense for the specific application. For the purposes of this draft, including a transport label might make sense if we expected clients to have distinct transport protocol specific authentication credentials for the same application. This seems unlikely to me. On the other hand, these certificates aren't identifying services, > they're identifying clients, and unless I misunderstand, it should be > equally useful to identify clients for POP, IMAP, submission, and > anything else that can do TLS. The list of service names already has > a fair number of client names, with the naming utterly inconsistent, > some with a trailing c, some with trailing "client", trailing > "-client", trailing "-cl", and a few just random acronyms. > Yeah, I noticed the inconsistency too - a bit unfortunate! > To minimize the chaos I'd suggest registering a psedudo-service name > "client", always used with the actual service name as its subname. > So for my SMTP, POP, IMAP, and SUBMIT clients, the names would be > > _smtp._client._tcp.whatever.example > _pop3s._client._tcp.whatever.example > _imaps._client._tcp.whatever.example > _submission._client._tcp.whatever.example > See Viktor's previous note about why we excluded a _client label. I suppose you could use the port number like RFC 6698 does but that > seems wrong since the server picks the port number. If a SRV record > says that the server is, say, running pop3s on port 1234, the client > is still doing pop3s and can't rename its TLSA record on the fly. > Right, we arrived at the same conclusion, and hence excluded the port number from the client record name. -- Shumon Huque
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
