[ietf-dkim] Misc. fairly minor issues

[Michael Thomas]

Paul Hoffman wrote:

>> #2 3.1  Just checking. This part says: "Periods are allowed in 
>> selectors and
>> are component separators.  If keys are stored in DNS, the period defines
>> sub-domain boundaries." Does that mean that the lookup for tcd.ie's 
>> foo.bar
>> selector is in foo.bar_domainkey.tcd.ie? I assume so.
>
>
> Yep.


The confusion here is that somebody might think that there is
a semantic meaning of a "sub-domain" with a DKIM selector
when as far as I can tell there is none. My selector in this mail contains
one of these beasts and as far as I can tell it's only to amuse me and
nothing more.

>> #12 3.4 generally. Could we get someone to volunteer some pseudocode 
>> for these
>> algorithms? I think that that might help cut out some corner cases.
>
>
> That would be nice.


I've tried to do this before and still have the pseudo code around, but
I think I've changed my mind about its utility -- there's such a chance
that there'd be a subtle bug (it's pseudo, after all) in it which we'd
introduce a difference between the normative text. Plus I've seen
disagreements here where it was actually the language of the code
that led to confusion where the normative text didn't have any mention
of the language in question. So I'd just assume we not go here...

>
>> #12 3.4.4 Why not replace this algorithm with the S/MIME c14n alg (of 
>> pgp's).
>> The logic behind that replacement is that there is code and 
>> experience with
>> those body c14n's?
>
>
> Or, better, why not get rid of it, as discussed in a different thread?
>
>
>> #14 3.5, "d=". The relationship between "d=" and "t=s" in the key 
>> record and
>> "i=" is a bit complicated.
>
>
> Agree.


The incremental change here once you work through it really small
though (strcmp vs subdomainof).

>
>> #15 3.5 "d=" says that idns names MUST be punycoded and depending on 
>> stuff,
>> might have to be the same as in "i=". Does the dkim verifier have to 
>> be able to
>> handle only binary comparisons of the punycode or is support for any
>> alternatives needed? (I hope not.)
>
>
> The punycode is straight ASCII, so there is no "binary comparison". It 
> is simple equality.


I assume you mean simple equality of the strcmp variety?

>> #17 3.5 "q=" says that different mechanisms MUST NOT change the 
>> interpretation
>> of the signature. I don't think we can require that since different key
>> services (e.g. xkms, scvp) may have different information about the 
>> public key
>> s.t. one says its a good key and the other says not. Just deleting 
>> the sentence
>> should be ok though.
>
>
> Agree.


I've never been comfortable with that sentence either, but I'm pretty
sure we've been over this before and the consensus was against us.

>
>> #18 3.6.1, "g=". Is "g=*s*t*e*p*h*e*n" allowed or is one "*" the 
>> limit?  I
>> don't care, but it should say.
>
>
> Good catch. Why does the definition for key-g-tag-lpart only allow one 
> "*"?


I'm neutral as to how many we allow, but one thing we might remind people
of is that you shouldn't use off the shelf shell wildcard matching routines
since they allow ? and other stuff too.

>> #22, 5.4 Says "The signer MAY include more header field names than 
>> there are
>> actual corresponding header fields to indicate that additional header 
>> fields of
>> that name SHOULD NOT be added." Is this feature needed? Seems like it 
>> just adds
>> complexity, in particular to the verifier and may be a source of bugs.
>
>
> It prevents a MITM attack that many people think is significant, 
> namely adding headers that mean something to the recipient.


Yep.

>
>> #26, 6.1.1. Section 5 says that "From" MUST be signed. I expected to 
>> see a
>> verifier rule for that here. Suggest adding that.
>
>
> Agree.


I think the section on h= (and the rest of the tags for that matter) is 
phrased in terms
of both signer and verifier. It seems pretty implicit that if a signer 
MUST do something
the verifier MUST make certain that signer did in fact conform. Maybe 
just a
general rule?

       Mike