(Note: part5 of the reply - last part)
On Wed, 13 Jul 2005, Jim Fenton wrote:
8. TXT record data
In section 3.7.1 it specifies separate tag "k" to specify key type
and tag "h" for hash algorithm where as in DKIM-Signature there is
one tag "a" that specifies "rsa-sha1". These differences to not make
sense - either in both cases it should be specified as "rsa-sha1" in
one tag or in both cases it should be specified with separate tag
for key type and for hash algorithm.
I agree that it's a little inconsistent now.
Since you proposed new header field, it should have been consistent in
there. I would recommend separate tags in the DKIM-Signature field,
possibly with default values (i.e. tags do not have to be present to
save space if its RSA crypto and SHA1 hash).
10. References
In 10.1 under Normative references you list
[OPENSSL] Team, C&D, .., WEB http://www.openssl.org/docs/, June 2005
For of all listing URL (and without even pointing to specific document)
instead of document in normative section is considered something like
strongly not recommended. Second why is it in normative in the first
place when the only reference to openssl I can find is in examples and
examples are not part of normative text of the specification. Similarly
I would recomend checking all other normative reference to make sure
they are used in parts of the text that is normative as opposed to
additional information note or example.
I'm not even sure why the [OPENSSL] reference is there; I don't see it
referenced.
Its indirectly referenced in "Appendix C -- Creating a public key
(INFORMATIVE)". If that section is retained that it should have
direct reference, i.e. [OPENSSL].
Also I do not see full draft names for ID-DK-RR ad ID-DKPOLICY, what
you have there is totally not appropriate for reference.
True; ID-DK-RR hasn't been written yet and ID-DKPOLICY is
draft-allman-dkim-ssp-00.txt which was just published.
Referencing documents that are not available and are not expected to be
published together with the draft is probably not appropriate. You can
simply reference a small subsection of the draft and say that in the
future this subsection will be replaced with new draft there.
11. IANA Considerations
a. IANA Considerations are missing registration of DKIM-Signature header
field.
b. "Use of the _domainkey prefix in DNS records will require registration
by IANA."
Where exactly did you expect to register dns prefix? This is NOT SRV!!!
Right, and SRV only allows the use of protocol names, so we need something
new (i.e., a new IANA registry, not just a new value).
I disagree about need for such registry, I suspect you'll see even stronger
(over my dead body type of responses) from core dns people in namedroppers
and probably from IAB as well (see there dns-considerations draft).
In any case the need new IANA registry MUST be specified in the draft.
c. "The DKK and DKP RR types must be registered by IANA."
RR Types are not registered in normal sense - IANA assigns new RR
number per requests. Also isn't it my understanding that both DKK
and DKP are going to be covered by separate drafts, why is this
IANA registration about them is here then?
Sure; this can probably move to that other draft when it is written.
12. Examples
From section B3 -
"Authentication-Status: XXX"
Where exactly is "Authentication-Status" defined?
[ID-AUTH-RES]
That document defines "Authentication-Results" not "Authentication-Status".
From section B2 -
Received: from dsl-10.2.3.4.football.example.com [10.2.3.4]
by submitserver.example.com with SUBMISSION;
Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
I don't see "SUBMISSION" as valid value for "with" at the
http://www.iana.org/assignments/mail-parameters
and "from dsl-10.2.3.4.football.example.com [10.2.3.4]" is
also invalid syntax for Received, see RFC2821
OK; this isn't normative, but no reason it shouldn't be right.
From section 3.5 -
DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane <---- Missing ";"
c=simple; q=dns; i=(_at_)eng(_dot_)example(_dot_)net; t=1117574938;
x=1118006938;
h=from:to:subject:date;
z=From:foo(_at_)eng(_dot_)example(_dot_)net|To:joe(_at_)example(_dot_)com|
Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700
And I think another missing ";" at the end of "z" value as well.
Correct.
-Jim
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net