Re: [ietf-dkim] editorials and nits

--On July 4, 2006 10:40:38 AM +0100 Stephen Farrell >>> #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).

Personally I have no problem with making a modification, but giventhe sensitivity of this wording I don't feel I can just come up withit myself. Perhaps we should have this as a (hopefully short) agendaitem in Montreal.

...

#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.

I think of TTP as an administrative entity, not as a piece ofsoftware. If I have a key service controlled by the owner of thatkey, then I don't have a third party at all, even if there is anotherpiece of software involved.

As soon as the key data is in the hands of a third party then thesituation changes. I guess that implies that if I outsource my DNSthen there in fact is a TTP. But I can outsource my mail systemtoday and people don't seem to deem that to be a TTP situation evenif it really is once you peek under the hood. But outsourcing isn'ta requirement for DKIM, even if someone might choose to implement itthat way.

Hmm... given the amount of heat this has generated, the best thingis probably to say "does not require any additional TTPs" and leaveit at that.

#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 made the change as you suggest --- but this left me wondering: whenyou use openssl "genrsa", does that produce something that containsthe exponent or not? If it does, then we shouldn't be mentioning65537 at all. If that is implied, then we should. [IIRC I got thiswording from Jon --- perhaps he can add something.]

...

#19, 3.7. This talks about two hashes all the time, which is
correct, but a bit misleading since any sensible API will include
both hashing and private key application inside a "sign()"
function. The end result is that the dkim programmer calls
"hash()" once and either "sign()" or "verify()" once. Suggest
adding a sentence along these lines to clear that up. If someone
ever calculated "sign(hash())" then they'd be wrong and this text
sort of suggests that. Similar comment about the pseudo-code at
the end where I'd rather see something like:

       body-hash = hash( canon_body )
       signature = sign( canon_header || DKIM-SIG )


I disagree.  This section has nothing to do with what an API would
look  like, it's about what algorithms have to be applied and
when. For  example, I can easily see your change being interpreted
to mean that you  don't hash the header at all.


Fair enough. Its hard to get right either way. But can we add an
informative note somewhere like:

    INFORMATIVE NOTE: Many digital signature APIs provide both
hashing
    and application of the RSA private key using a single "sign()"
    primitive. When using such an API the DKIM signature calculation
    pseudo-code might look more like:
          body-hash = hash( canon_body )
          signature = sign( canon_header || DKIM-SIG )
    Were an implementer to mistakenly include a second "hash()"
call,
    i.e.,
          signature = sign( hash (canon_header || DKIM-SIG ) )
    they would sign and verify their own messages with no apparent
    problems, but could not interoperate with correct
implementations.


I added:

       INFORMATIVE NOTE:  Many digital signature APIs provide both
       hashing and application of the RSA private key using a single
       "sign()" primitive.  When using such an API the last two
       steps in the algorithm would probably be combined into a
       single call that would perform both the hash-alg and the
       sign-alg.

#22, 5.2, last para. Change "when the selector containing the
corresponding public key is expected to be removed before the
verifier...", to, "when the public key in the relevant selector is
expected to be revoked before the verifier..." since we're not
recommending removing the selector but rather zeroing out the key.


Is that what we are recommending?  I thought that omitting the key
was a  way of saying "we're sorry, but we had to pull that key
unexpectedly."   In fact, the usual way of dropping a key would be
to drop the record  entirely.  Otherwise you would have
ever-growing name spaces.


I guess I'm confused then. I thought that including a blank key
value was better since it could be cached. I would assume that
you then typically delete the selector record after a while, when
you no longer see many requests for it or whatever.

I guess we're not completely clear on that either way. I changed itto "revoked or removed" to cover all the bases.

#28, 6.2. The reference to ID-AUTH-RES might be better off being
removed for process reasons.


Even as an example?  It's informational, not normative.


I appreciate that, but I bet it'd still slow down base's road
to rfc-dom.


OK, I pulled it.

#32, A.3, the authentication results header should not, IMO be
included here.


I think it is very important to make it clear how one might convey
results to higher levels.  Otherwise all of A.3 doesn't have any
reasonable example.  It doesn't have to be Authentication-Results,
just  something.


An abstract something here is better than a nearly-well-defined
something IMO. (I mean no criticism of ID-AUTH-RES here either, but
it may change in all sorts of ways, including the name of the header
field.)

OK, I used an abstract model. It happens to be the same as theAuth-Res draft using X-Authentication-Results instead ofAuthentication-Results, but honest, it's just something I pulled outof thin air.

Seriously, I think it is good to show the kind of information youshould plan on conveying. I could reorder or shuffle the syntax abit, but that adds nothing and might imply to someone who implementsfrom examples that there is some other formal form they should beusing.

#33, Appendix B. I expected to see a bit here about the type of
setup we have at IETF meetings, where the IETF's MTA signs and the
verifier has to handle the From being nothing like the signer
identity.


Sorry, I don't see any signatures coming from the IETF MTA.  Can
you be  more specific?


If I go to a conference or IETF, then I generally use its smtp
server. If someone was used to mail from me being signed by tcd.ie
and suddenly see mail from me signed by ietf66.org they might react
badly. I don't want that to happen. (I know that the IETF meeting
server doesn't sign now, but I guess it may in future.)

So, my point was that I didn't see an example/use-case that mapped
to the one above.

Well, depending on how you look at it, B.6 (Third-party MessageTransmission) might cover it. Alternatively, we could add a B.7 thatexplicitly discusses the "hotel room" problem. The two are veryclose but not quite identical.


Any thoughts?

#34, Appendix C. I think that this can be deleted. Others may
disagree. In any case, the text says 768 and the command line
1024, no  password handling is shown and the last part could
confuse since that signature is not usable for DKIM. So if this
isn't deleted, then a bunch of changes are needed.


I fixed the discrepancy, but I don't think it should be deleted.
It's  non-normative and will help people understand how to use the
standard,  which I think is A Good Thing.

I'm not sure what you mean about password handling.  I just ran
through  these instructions, and there are no passwords requested.


Sure, you don't have to use passwords with s/w private keys, but you
really should do at least that much.

If we're going to give this kind of help, we don't want it to
encourage people to take less secure options without being clear
that that's what they're doing.

So are you saying that the genrsa step should be using -passin? Ican see that as an optional step that we could discuss, but it's notstrictly required for the algorithm to work.

...

#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).


See my question above about the exponent.

eric
_______________________________________________

NOTE WELL: This list operates according tohttp://mipassoc.org/dkim/ietf-list-rules.html