> -----Original Message-----
> From: SM [mailto:[email protected]]
> Sent: Thursday, October 21, 2010 9:31 PM
> To: Murray S. Kucherawy
> Cc: [email protected]
> 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

Reply via email to