ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Please post issues with draft-dkim-rfc4871-errata-03

2009-02-10 13:23:56


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Tuesday, February 10, 2009 12:23 PM
To: Jeff Macdonald
Cc: dcrocker(_at_)bbiw(_dot_)net; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Please post issues with draft-dkim-rfc4871-
errata-03

Jeff Macdonald wrote:
On Mon, Feb 09, 2009 at 11:56:30AM -0800, Douglas Otis wrote:

The proposed errata use of the word opaque to describe the d=
value,
in addition to the i= value offers _no_ additional clarity.

Given something like this:

d=good.rep.example.net or
d=bad.rep.example.net

do not assume that those identifiers mean "good" and "bad". Good and
bad could be the names of two different companies. A signer could
sign
like this instead:

d=53302.rep.example.net or
d=9999.rep.example.net

and this would enforce to the verifier that no meaning should be
placed
on what d= contains.

d= is just an identfier that is used to look up the public key


Jeff,

It a DNS DOMAIN and a DNS DOMAIN is a well defined entity. And this d=
DNS DOMAIN must match the 2822 (DNS) Domain.  It is well forth,
bloody, scared specific 1st PARTY only signing requirement. It does
not lack clarity. It is not obtuse, it is not "hard to understand or
explain," nor is it unintelligible, and it is certainly not opaque.


Hector,

There is no requirement in RFC4871 (DKIM Base) that the d=domain must
match the 2822 (DNS) domain. There is no requirement that it be 1st
PARTY only signing as you put it. The relevant section of 4871 is as
follows:

d=  The domain of the signing entity (plain-text; REQUIRED).  This is
       the domain that will be queried for the public key.  This domain
       MUST be the same as or a parent domain of the "i=" tag (the
       signing identity, as described below), or it MUST meet the
       requirements for parent domain signing described in Section 3.8.
       When presented with a signature that does not meet these
       requirement, verifiers MUST consider the signature invalid.

I believe you are thinking of the ADSP draft, which is not what the
errata or bis (whichever path is taken) discussion is about.

Mike

Michael Hammer - mhammer(_at_)ag(_dot_)com
Web Operations Security
AG Interactive/americangreetings.com
Tel: 216-889-5304
Cell: 216-849-8397

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