On Sun, 26 Feb 2017, Dale Worley wrote: I'm not an author but I am the author of the similar OPENPGPKEY RFC-7929 which actually went through all the discussion on the same matters you raise. The smime draft waited for that discussion to finish and for 7929 to be published so it could re-use the same text and methods.
1. I assume that in parallel with RFC 6698, DNAME records must be followed during SMIMEA resolution. It's not clear to me whether CNAME records must also be followed or how, given that SNAMEA records are not for host names, but their grandparent node is a host name.
Regular processing rules for CNAME and DNAME apply - I don't think it requires additional text.
2. Presumably it was deliberate not to have the first label for an SNAMEA record be the canonical UTF-8 string for the local-part, even though the DNS architecture (RFC 1035) seems to admit binary labels.
Yes, you can find 100+ messages in the archive or you can listen to a few hours of heated debate at some of the previous DANE IETF meetings. (So heated in fact, that I'm not even comfortable giving you a 1 line summary)
3. Presumably it was deliberate to hash using SHA2-256 truncated to 224 bits rather than use SHA-224.
Yes, the Microsoft crypto api lacks support for SHA-224. We did want the shorter length so SHA256 truncated was chosen.
4. Is it worth suggesting that some mechanism might be devised for annotating an e-mail message with the canonical form of the sender's local-part that is intended to be used to authenticate the message?
The SMTP people raised strong objections about interpreting anything as this is forbidden by the SMTP specifications. You will also find dozens of messags and recordings of meetings in the archive that lead to the current compromise text (which was also used in OPENPGPKEY, RFC-7929)
The last sentence of the 1st paragraph of section 1 suggests that this is deliberately out of scope for this document, but it might be worth suggesting experimentation regarding this in section 4, which seems to be entirely about further experimentation.
I don't think you will find anyone willing to restart that battle.
* Editorial/Nits Should there be an explicit statement that the resolver must follow CNAME and DNAME records? That seems to be required by RFC 6698 section A.2.1, but that requirement is buried rather deeply. Also, is CNAME following required? My vague understanding is that CNAME can only be used to alias host names, and SMIMEA records are not for host names (contrasting with the DANE records for TLS) -- though the grandparent node of any SNAMEA is a host name.
CNAMEs can be used for most RRTYPEs (excluding NS, SOA, CNAMEs) and it might be that people will have multiple email addresses where they want to prevent duplicating long blobs of certificates in a zonefile. So CNAMEs are very useful.
Also, some adjustments of the resolution process of RFC 6698 re CNAME records were made in RFC 7671, but this draft only mentions 7671 in passing, in the introduction. It seems that it should be noted that 7671 contains a lot of operational information about DANE.
The bulk of that relates to the TLSA record, which doesn't apply here. Paul _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
