ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02

2010-10-22 12:59:10
-----Original Message-----
From: SM [mailto:sm(_at_)resistor(_dot_)net]
Sent: Thursday, October 21, 2010 9:31 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)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".

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html