Hi Murray,
At 13:48 21-10-10, Murray S. Kucherawy wrote:
That sounds right to me.
It does not sound right to me.
I forget; does the email architecture document talk about the
difference between a DNS domain and an ADMD? This was an issue
during the IESG evaluation of Authentication-Results and I seem to
recall it being a place to which readers could be referred to learn
the difference. Maybe changing "domain" to "DNS domain" would be
appropriate, and also changing the RFC1034 reference to point at RFC5598?
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.
Changing the reference to RFC 5598 may cause problems in other parts
of the draft.
The OpenDKIM stats shows that SHA1 is still in very widespread use,
both by domain counts and by aggregate message counts. Trying to
force DS to talk only about SHA256 would mean alienating half or
more of the current install base, and we felt that was probably a bad idea.
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.
Seems reasonable to me, though I don't think it needs to be
normative since that text is discussion rather than protocol specification.
That text is not normative. Having the reference as normative means
"please read the following document to understand what is written in
this document".
I can't remember the disposition of this, but I think the problem is
that we want to use ToASCII while no current (i.e. not obsolete)
document contains a definition of it. I seem to recall one of the
other co-authors looking into it and finding this was acceptable,
but I don't recall. Dave, can you comment?
It would be highly unusual to use such a reference. I will most
likely nit about that.
I don't recall it being tested specifically. And I don't have a
good sense about whether the addition of this normative requirement
would require a recycle or not. I defer to those more experienced than me.
The addition of the normative requirement would complicate
matters. I mentioned the recycle as it would keep matters
simple. It would be premature to determine which status is the most
appropriate.
No, I think it's simply an informative back-reference to another
specified requirement. Maybe changing "must always" to "always has
to" would clear that up.
That's fine.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html