ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

2005-10-20 09:17:26
Stephen Farrell wrote:
I thought changing the c14n actually was agreed? Changes to
the signature construct would appear to have some support on the
list. Formally of course none of these changes are agreed
since we're not yet a wg.

Sorry -- my decoder ring didn't decode c14n and I thought
it was some actual canonicalization algorithm. Yes, I think
we've agreed to that. I don't know about the digest thing
though, and if I remember the comments correctly I'm skeptical,
but I'm not sure if we're referring to the same thing.

It is true, so I mustn't have been clear. If we fiddle with the
signing process at all, then doing that twice is usually no worse
than doing it once, e.g. if we created a new MUST c14n then it'd
make no difference (wrt imcompatibility) if at the same time we
created a new MUST for the body-hash stuff.

That's not my experience. Any time there are changes,
you leave open the door for unexpected outcomes. If
the magnitude of the change amounts to aesthetics, then,
well, no thank you.

Now its me that's confused. Nothing above refers to preventing
re-use of a key, rather I was asking whether anyone wanted to
mandate use of the same key (i.e. prevent use of different keys)
in that specific context. (Impact of use of different keys would
be that the old DNS content would no longer be sufficient to
check both sigs. OTOH, if you create a 2nd signing key, you'll
probably populate the DNS with its public counterpart, so this
is IMO most likely a don't-care.)

I don't see why we care one way or the other. Even though
I got the polarity of your question backward, it still strikes
me as making proscriptions that are both difficult/impossible
to enforce and of questionable value. I'd just assume we avoid
those.

                Mike
_______________________________________________
ietf-dkim mailing list
http://dkim.org

<Prev in Thread] Current Thread [Next in Thread>