> It's been a week. Has anyone had time to look the document over, enough
> to have
> any initial reactions?
Here're some comments from on the plane.
Overall, this seems to be shaping up nicely.
Cheers,
Stephen.
not-quite-nits:
#1 PKI - in what sense is DKIM base defining a PKI? Its really
not at all clear to me that it is. Remember that the "I" stands
for infrastructure and in this case DNS is the already existing
infrastructure so on that logic, DKIM is not defining a PKI. I
think maybe a term like a "key centric public key distribution
scheme" would be more accurate if less memorable. Reason to be
careful here is that there's no reason to attract either those
who love, or hate, PKI. Maybe this stuff warrants its own
section, but not necessarily right at the front since its not
really that much of a deal (or oughtn't be;-)
#2 7.1.3 says that an intermediary SHOULD remove signatures
it knows to be broken. Doesn't this conflict with base?
(Same thing in 9.3)
#3 Authentication results are mentioned in 7.1.3 and
subsequently. It would be better if the status of that work
(i.e. not yet on the WG charter) were made clear beforehand.
(This might just be a text ordering issue.)
#4 The transition discussion in 8.3.1 assumes that SSP allows
signers to advertise their chosen algorithms. That is not
yet clearly agreed so a chunk of this text may need to be
reworked. The transition discussion may benefit from a more
concrete use case, e.g. when sha256 is probably replaced in
2010, or for a signer that wants to start using ECC as well
as or instead of RSA.
#5 Section 9.1.3 recommends backing up the old private key.
That seems odd. Suggest deleting it.
#6 Section 9.1.3 last paragraph. Presumably this should have
a mention of at least allowing for the duration for which
messages signed with the old private key are expected to be
first-verified. (I.e. the latency between signer and verifier,
which is short.)
#7 Section 9.2 is v. brief and needs expanding. Its also
unclear how an audit mechanism can alert when a private key
file is copied.
#8 Our charter calls for us to help mail list admins to be
DKIM-friendly. I don't really know what that entails but
I don't see section 9.3 providing it either. What to do?
E.g. I would have thought saying the adding a "[LIST]"
preface to the Subject would be unfriendly to messages
where the Subject field was signed and might recommond
some other list flagging scheme.
#9 Section 10.1 says that 1024 bit rsa is commensurate
with 80 bit asymmetric systems. That surely only relates to
confidentiality (i.e. key transport), so a different
set of comparisons is probably needed.
#10 Section 10.2 implies that RSA is based on the
discrete log problem and not factoring. Maybe my terminology
is out of date, but I think those differ.
nits:
#1 Intro 1st bullet list says 4 efforts, but only has 3 bullets
which reads oddly, suggest splitting 1st bullet
#2 5% of spam being inappropriate marketing - is there a
reference? (I think I believe you but would like a ref.)
#3 Lead in to section 3 includes the "no TTP" statement that
we've refined a few times - I think we ended up with "no
new TTP" as the better phrase.
#4 Section 10 s/tok/took/
#5 Section 10 The "I" in "PKI" already means infrsatructure.
(Also in 10.5)
#6 Section 10.2 The 2nd "C" in "ECC" already means cryprography.
#7 I don't think that there are any normative references needed
here - which may in the end help with process the document.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
