ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Misc. fairly minor issues

2006-07-08 04:05:51


Jim Fenton wrote:
Eric Allman wrote:
I've deleted the points where I have nothing to add to Paul's comments.

--On July 1, 2006 9:46:19 PM -0400 Paul Hoffman <phoffman(_at_)proper(_dot_)com>
wrote:


And "l=" is not mentioned when saying how to calculate
"bh=". I guess the right thing to do might be to add some mention
of "l=" when talking about calculating "bh=",
Agree.
I changed the first line of the bh= description to read "The hash of
the body part of the message as limited by the "l=" tag (base64;
REQUIRED)."
I think we need to say "canonicalized" somewhere there, as in "hash of
the canonicalized body".
#14 3.5, "d=". The relationship between "d=" and "t=s" in the key
record and "i=" is a bit complicated.
Agree.
Could someone please propose simpler wording?
I'm doing a good job at coming up with more complex wording, but that's
not really helpful.  The relationship between i=, d=, and the t=s flag
of the key record is subtle enough that perhaps it should be a separate
section, e.g., 3.8.  Then we might have:

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 the 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.

=====

3.8 Signing by parent domains

In some circumstances, it is desirable for a domain to apply a signature
on behalf of any of its subdomains without the need to maintain separate
selectors (key records) in each subdomain.

By default, private keys corresponding to key records can be used to
sign messages for any subdomain of the domain in which they reside,
e.g., a key record for the domain example.com can be used to verify
messages where the signing identity (i= tag of the signature) is
sub.example.com, or even sub1.sub2.example.com.  In order to limit the
capability of such keys when this is not intended, the t=s flag of the
key record can be used to constrain the validity of the record to
exactly the domain of the signing identity.

If the referenced key record contains the t=s flag, the domain of the
signing identity (i= flag) MUST be the same as that of the d= domain. If this flag is absent, the domain of the signing identity MUST be the
same as, or a subdomain of, the d= domain.

Key records which are not intended for use with subdomains SHOULD
specify the "t=s" flag.

Looks good to me.
S.

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