[ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
Murray S. Kucherawy
msk at cloudmark.com
Fri Oct 22 10:56:30 PDT 2010
> -----Original Message-----
> From: SM [mailto:sm at resistor.net]
> Sent: Thursday, October 21, 2010 9:31 PM
> To: Murray S. Kucherawy
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
> A proper comparison of the two requirea more than one sentence. I'll
> keep it short; ADMD is about administrative authority whereas a DNS
> domain is of a list of labels. The reference to RFC 1034 is a
> pointer for the reader to find out what is meant by "domain
> name". When we talk about domain names, as in DNS, we refer to
> specifications about DNS. If the question comes up in an discussion
> about email (within the IETF), consideration is given to whether it
> is about email delivery or about the domain name space and resource
> records; and the discussion is punted to the appropriate group.
I understand your point, but what I'm saying is that the DNSDIR people, on reviewing RFC5451, were not satisfied with that line of reasoning, resulting in a DISCUSS from the OPS AD until I went back and indicated for every use of "domain" which thing I meant. I'm simply trying to avoid that.
> Maybe I did not explain what I meant correctly. I am not arguing for
> the document to talk only about SHA256. I'll quote the text from
> Section 3.3:
> "DKIM supports multiple digital signature algorithms. Two algorithms
> are defined by this specification at this time: rsa-sha1 and rsa-
> sha256. Signers MUST implement and SHOULD sign using rsa-sha256."
> As you can see, there is a SHOULD for signing using
> rsa-sha256. Signing with rsa-sha1 is not forbidden. I am not in
> favor of alienating half or more of the current install base.
Then I guess I don't understand the basis for the suggested change. The citation you made here doesn't seem to conflict with the "should use sha256 whenever possible" advice, since a normative SHOULD basically means "always, unless you have a very good reason not to do so".
More information about the ietf-dkim