I think the mapping of SMTP (a protocol, an over-the wire framing and dialogue about exchanging mail) has been crossed (crossing-the-beam crossed) with a ROLE. a client can be an SMTP speaker, and a forwarder/delivery agent can be an SMTP speaker. They aren't performing the sale role.
So does DANE want to identify the ROLE being performed or the protocol being used to do it? How would DANE feel if instead of SMTP it said DECNet-Mail? The sub-domain thing, is that a real zone-cut? Are there detectable zone boundaries? Or is this mapping dot-separated elements but without implying a zone-cut? -G On Wed, Jan 13, 2016 at 3:55 PM, John Levine <jo...@taugh.com> wrote: > I'm having what seems to me a very peculiar argument over in DANE. > > There's a draft called draft-huque-dane-client-cert-02 about > validating SSL certificates for client hosts. The idea, which seems > reasonable, is that if an SMTP or other client presents a TLS > certificate claiming that it's outbound.example.com, the server it's > talking to can look up a TLSA record to see if the certificate is > valid, analogously to the way a client looks up the server's TLSA. > > What's peculiar is the names. The previous proposal was to look up a > TLSA at _smtp.outbound.example.com, then somone noted that _smtp is > for servers, so they want to look up the newly invented name > _smtp-client.outbound.example.com. If you have a client for some > other service, you make up a name. (Read the draft if this seems like > an implausible summary.) > > I suggested they could avoid a lot of future name collision pain by > registering "client" as a pseudo_service name, and then looking up > _smtp._client._tcp.outbound.example.com. If your client is using > another service, you use the service's name from the existing registry > of services instead of _smtp, e.g., _imaps._client.tcp.myhost.example. > > The DANE crowd thinks this is a terrible idea, it's too complicated, > makes the SRV-ID verification harder, name collisions won't happen > and/or are easily solved. Am I missing something, or are they? > > Signed, > Confused > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
