>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. 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. 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 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. Registering the service name is easy, just a few paragraphs in the IANA considerations section. R's, John _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
