On Sat, 2006-07-08 at 12:01 +0100, Stephen Farrell wrote: > > 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 <[EMAIL PROTECTED]> > >> 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.
Rather than specifying specifically "the t=s", as this could also be "t=x:y:z:t:s". Perhaps this could be expressed as "the 's' flag contained within the key record 't=' tag value." -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
