Document:  draft-delany-domainkeys-base-05.txt
Reviewer: Black_David@emc.com
Review Date:  Wednesday 7/19/2006 7:37 AM CST
IESG Telechat Date:  Thursday, 20 July 2006

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

The draft is generally well written, and contains good
explanations of the design rationale, which is important
to describe for this sort of document. 

I found two important issues that really need IESG attention,
and a number of less important issues.

(1) The IESG should replace the "Purpose of Submission" paragraph on
p.2 with a "Purpose of Publication" paragraph explaining:
- Why this draft is being published
- Why it is being published as Historic
- Where implementers should look for specifications that the
	IESG/IETF recommend for implementation.

(2) Some of the public key lengths used are surprisingly short by
comparison to current practice in other areas , e.g., 512-bit RSA
keys are allowed.  The only explanation I see for this is in
section 3.2.4, which lists a couple of reasons why larger keys
are harder to implement (space and time costs), and then says:

    o Keys can be replaced on a regular basis, thus their lifetime can
      be relatively short

    o The security goals of this specification are modest compared to
      typical goals of public key systems

Both bullets need more explanation that should at least answer:
	- How and why are the security goals modest?
	- What are typical goals of public key systems?
	- Given these, what are reasonable key lifetimes for
		some of the shorter key lengths.
The IESG may want to add a cautionary note specifically warning
designers away from the key lengths used in this draft in the absence
of careful analysis of level of threat, and the resulting key lifetimes.

-- Less important issues

Section 3.4.1 should recommend or reference a maximum line length that
will avoid issues with long lines.

Section 3.4.2.2 - Are "folding white space characters" removed from
anywhere in a line, or only at its beginning?

The use of "lifetime" in section 3.7 is potentially ambiguous, as there
are two factors involved here:
- How long a signer continues to use a key.
- How long a key record needs to remain in the DNS after the last time
	it has been used to sign an email.
This ought to be clarified - the primary concern in Section 3.7 appears
to be the latter.

Section 3.7.3 specifies a static policy of always preferring the earliest
signature.  I can envision mailing list examples, where the signature
of the mailing list MTA verifying that this was indeed sent to the
mailing list in question is more important than the signature of the
sender.  This could use some discussion.

Section 3.8 - the disconnect between the verifier and the MUA is
unfortunate.  Removal of the "good" status is a double-edged sword -
one thing that could be done here is to have the verifier sign the
combination of the verified signature, the good status, and verifier
information.  The MUA can then validate the verification.  This sort
of possibility might be useful to discuss as a future opportunity
to improve on this disconnect.

Section 5.1 on the X.509 header should say something about what
(if anything) was implemented.