Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> writes:
Just ones where there's something to say,
Cheers,
Stephen.
Eric Allman wrote:
#1 saying "proof" and "non-repudiation" in the abstract is a
mistake and potentially misleading. Rephase to use less difficult
terms, e.g. talk about signatures being evidence rather than proof.
Given the sensitivity over the exact wording of the abstract, I'm
not willing to make this change without discussion of some proposed
wording.
Ok, I'll back off on this. DKIM isn't the only document that includes
such phrases (but if you could even just not say "non-repudiation"
that'd be great).
I totally agree.
#3 1.1, 2nd set of bullets. dkim *does* require a ttp - the DNS.
Better to say that dkim requires no *new* ttp.
I don't see DNS as a "third party" in the same sense as a CA for
certs. Yes, DNS has to work, but it isn't a third party (unless you
want to count the root servers, I suppose). By this logic, we
should also include the multiple third parties that run the routers
and all the rest of the infrastructure.
In my little PKI-riddled mind, the DNS is a TTP since it supplies the
public keys and if/when DNSSEC were used, it starts to look quite like
a PKI. The routers etc. won't ever really be supplying signed key
records. But if no-one else thinks the same, leaving as-is if of course
right.
Well, I was probably the one who raised this issue originally, and
I don't agree with raising it as-is. The DNS has to be trusted to
give out the right info and, as Stephen observes, if/when DNSSEC
is deployed there will be an isomorphism between a classic PKI
and the DNS.
#5 3.3.1 and 3.3.1, phraseology is still a bit odd. Suggest
changing from: "That hash is then signed by the signer using the
RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]; in
particular see section 5.2) with an exponent of 65537 as the
crypt-alg and the signer's private key. The hash MUST NOT be
truncated or converted into any form other than the native binary
form before being signed." ...to... "The signature is calculated
using the RSA algorithm with a fixed public exponent of 65537 - if
a different public exponent is required, then a new DKIM signing
algorithm must be defined."
Adding the specific reference was specifically requested by another
reviewer --- in fact, I think your proposal changes it back to
almost exactly what was objected to before. I think this requires
some discussion.
Sorry - you're right about the reference, I just forgot to include
it, you could change text suggestion to: "The signature is calculated
using the RSA signature algorithm as specified in PKCS#1 version 1.5
[RFC3447], and with a fixed public exponent of 65537 - if a different
public exponent is required, then a new DKIM signing algorithm tag
value must be defined."
I don't understand the purpose of the fixed exponent of F4. It's
not needed for interoperability because a PKCS#1 RSAPublicKey
(which is what this document implies, though does not say
is stored in the DNS) structure contains the exponent.
#6 3.6.1 "k=" says that the public key is in the "p=" value, but its
actually the modulus.
I guess I'm confused. If this isn't the public key, what is?
Me being pedantic again I guess. The public key is the modulus and
the public exponent (in our case hardcoded to be 65537).
This doesn't look right to me. Here's the relevant text:
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
verifiers MUST support the "rsa" key type. The "rsa" key type
indicates that an RSA public key, as defined in [RFC3447],
sections 3.1 and A.1.1, is being used in the p= tag. (Note: the
p= tag further encodes the value using the base64 algorithm.)
And here's what's in A.1.1:
An RSA public key should be represented with the ASN.1 type
RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
The fields of type RSAPublicKey have the following meanings:
* modulus is the RSA modulus n.
* publicExponent is the RSA public exponent e.
The only ASN.1 definition here is for the full public key.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html