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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html