[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DKIM - Other Inconsistancies



(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=@xxxxxxxxxxxxxxx; t=1117574938; x=1118006938;
    h=from:to:subject:date;
    z=From:foo@xxxxxxxxxxxxxxx|To:joe@xxxxxxxxxxx|
     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@xxxxxxxx