On Fri, Dec 12, 2014 at 05:50:10PM -0500, James Cloos wrote:
> VD> of the protocol.
>
> The only issue with using SRV is that the http GET path would have to be
> standardized, which could be an pain if the advertized MXs already serve
> https for something else.
I was thinking of multiplexing by port, rather than URI. So that
the service in question really could be a light-weight HTTPS server
add-on to an MTA, rather than an HTTP application in a general
purpose HTTPS server.
The key advantage is that MTAs already have code for email address
parsing, table lookups, LDAP, ... and so operating a listener on
some custom port (from an SRV record) might not be a major burden.
The URI would then be "/". The protocol would be some elaboration of:
Client:
GET /?email=<URL-encoded-address> HTTP/1.1
Host: <hostname from srv record>
Content-Length: 0
Server:
200 OK
Content-Type: text/plain; charset=us-ascii
Connection: close
2 0 1 <trust-anchor digest>
3 0 0 <encryption key>
This avoids encoding issues, UDP payload limits, and allows MTAs
to perform the necessary canonicalization to find the keys of
variant address forms.
The disadvantage of a service that's operated as part of the MTA,
is that people would have to deploy updated MTAs to support this.
It does however seem that this may be easier and more flexible than
populating per-user data into the DNS.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
