Hi Charles, and welcome. I can't answer many of your questions, but I
can certainly take a whack at a few.
3.3.3 Other algorithms
Presumably there is nothing to prevent allowing PGP as the signing
algorithm in the future, if someone makes out a good case for it.
PGP, to the best of my knowledge, is neither a hash nor a cryptographic
algorithm, but makes use of both. We should anticipate new algorithms
for each in the future, but this is not something we want to have a
plethora of, lest we fragment the installed base.
3.4 Canonicalization
In what circumstances is the 'simple' canonicalization inappropriate, and
why is it the default?
Is it not the case that the "meaning" of a message is, according to RFC
2822 etc., unaffected by changes of folding, or of case of header-names,
or of CTE, or of encodings or re-encodings using RFC 2047 or RFC 2231?
And
hence any canonicalization that preserves "meaning" cannot do any harm?
Anyway, I shall return to this when I come to section 5.3.
3.4.2 The "relaxed" Header Field Canonicalization Algorithm
Is it possible that re-folding a structured header en route will
introduce
a WSP that was not there beforehand, and thus break the signature? I
avoided this in my own draft by ignoring all WSP in headers, except when
inside comments and quoted-strings and in structured headers such as
Subject.
3.5 The DKIM-Signature header field
Although your charter forbids you from discussing non-repudiation,
authorization, and other matters not strictly relevant for DKIM, it is to
be envisaged that other applications will arise from time to time
requiring signatures over headers, and it would be unfortunate if each
such application had to invent Yet-Another-Signing-Protocol when a simple
adaptation of what you have written would have sufficed. There are
already
too many only-slightly-different-wheels in existence for us to be
inventing any more. Surely, a facility for signing headers should be
described as a tool which can then be used for various applications in
future, of which DKIM would be just the first? So why was this approach
not taken?
In fact it is. The DNS record contains s= for this purpose, and the
purpose of the signature contained within the message can be inferred by
the application invoking it ;-)
In fact, you almost made it. The only features which might make it hard
for future applications that I can see are the appearance of "DKIM" in
your newly invented "DKIM-Signature" header (it rather needs an
'application' tag in the signature to indicate why the signature was
made), and the insistence that the d= and s= tags, which together
identify
the owner of the key, should be syntactically of the form of domain-names
(which might be totally inappropriate for those other applications,
though
it should clearly be required when the application is DKIM).
Can the various tags appear in this header in any order? OTOH, why is
there not an insistence that the b= tag should come last (since it has to
be easily joined to and separated from the rest)?
I can't speak to anyone's implementation, but general SMTP folding rules
apply, no?
v= Version (MUST be included).
Does the version relate to the version of the algorithm identified by the
a= tag, or to the version of dkim-base as a whole? IOW, if someone
invents
a new tag, or a new tag-value, that can be safely ignored by existing
implementations, is it necessary to invent a new version?
Version of DKIM, but I think this is a valid point.
bh= The hash of the canonicalized body part of the message
Yes, I like this, since it enables some useful information to be
recovered
if the header hash succeeds but the body hash fails.
d= The domain of the signing entity
Is this case-insensitive?
h= Signed header fields
Why MUST NOT this list be empty? Suppose you want to sign the body, but
not any headers? Unusual, but perhaps sensible for some application. No
interoperability arises.
I don't understand the remark about "message/rfc822 content types". How
can this problem arise?
i= Identity of the user or agent
Is this case-insensitive (I might expect a different answer there for the
<local-part> and the <domain-name>)?
Why MUST the <domain-name> be a subdomain of the d= tag (and why not of
the s= tag, and what interoperability arises anyway)?
Must this tag, if a <local-part> is present, be a valid working email
address?
l= Body length count
INFORMATIVE IMPLEMENTATION WARNING:
I am very suspicious of the propriety of suggesting, in any IETF
standard,
that it is legitimate to remove text from a message being conveyed
(certainly without the consent of the recipient). Surely marking it with
blood-red ink, or warnings in 32pt characters is as far as one should go?
What if it's executable code inserted by an attacker?
q= A colon-separated list of query methods used to retrieve the
public key
Clearly, the use of DNS or some similar global database is the only
sensible PKI that is workable for DKIM. But am I right in saying that
this
tag does not preclude the use of other PKIs for other applications (e.g.
attached certificates, web-of-trust, private agreements between the
communicating parties, etc.)?
Why MUST signers support "dns/ext" (clearly, verifiers MUST)? Surely a
signer who, as a matter of policy, always chooses to use some other query
method, is not obliged to implement something he is never going to use.
You can do what you want between two parties with pre-arrangement, but
that's not the interesting case DKIM is attempting to solve. In fact, a
primary purpose of DKIM is to enable trusted introducers. And so a
single common method is needed for interoperability.
s= The Selector subdividing the namespace
Case-insensitive?
t= Signature Timestamp
... The format is the number of seconds
since 00:00:00 on January 1, 1970 in the UTC time zone. ...
Strictly speaking not true, since the usual UNIX algorithm for
calculating
this quantity takes no account of leap seconds. I presume this is all
laid
down in POSIX somewhere.
And expecting this to work up to AD 200,000 seems an overkill (though
beyond 2038 would be helpful).
I believe for purposes of this discussion this is not a big deal.
z= Copied header fields
Verifiers MUST NOT use the header field names or copied values
for checking the signature in any way. Copied header field
values are for diagnostic use only.
Why ever not? I can think of examples where a verifier might find it
exceedingly useful to be aware of the original state of some header which
might have been changed somewhere en route. And what potential
interoperability arises if a verifier makes some use of this information?
Because z= field does NOT get rendered to the user, but rather the real
header fields will. It makes no sense that the z= field should be
verified and the others are not. Allowing otherwise would provide for a
malicious opportunity.
3.6 Key Management and Representation
public_key = dkim_find_key(q_val, d_val, s_val)
I do not find the operation 'dkim_find_key' defined or used anywhere else
in the draft.
3.6.1 Textual Representation
h= Acceptable hash algorithms
... Signers and Verifiers MUST
support the "sha256" hash algorithm. Verifiers MUST also support
the "sha1" hash algorithm.
Why MUST signers support the "sha256" hash algorithm (clearly, verifiers
MUST)? Surely a signer who, as a matter of policy, always chooses to use
sha-1 is not obliged to implement something he is never going to use?
Again, for interoperability. We picked one. That was the one.
I'm sorry, but I've run out of time and must be on a plane shortly.
Perhaps others will pick up the ones I did not answer.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html