Michael,
Michael Thomas wrote:
Stephen Farrell wrote:
First, the current s/w will have to change since we're changing
the signature construct (c14n & maybe the digest thing).
>
When did we agree to this?
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.
Since
its signing, a single bit is enough to require new s/w anyway
and there's 99.999% certainty that we'll at least change
one bit in an on-the-wire imcompatible way. Don't you agree?
Maybe. Adding new options to dkim can often be done in a
backward compatible way.
Yes. And should be done that way if possible.
> On the other hand, pre-judging
that there will be incompatible changes leaves the protocol
open to changes great and small, from the technically/security
needed, to the purely aesthetic. The barrier should be first and
foremost "is it broken", not "is it the way I would have designed
it".
The point is that changes to the signing process are always
imcompatible - the best you can do for backwards compatbility
is sign twice or else allow an option to produce a backwards
compatible signature format. But I believe we're likely to end
up with the MUST-implement being the more secure option we have,
which is also not likely to be compatible. I may be wrong there
but we'll see.
Once that happens, many further changes have no additional impact
on incompatability, but of course, all changes do need to be
justified.
That is simply untrue. There is dev, test and interop considerations.
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.
PS: I still didn't hear much about what specific parallel scenarios
we'd like to support btw. e.g. if a single message can have both
new and old signatures from the same domain, do we require that
the same public key be usable to verify both, or should we remain
silent on that, or something else? And which of those signatures
should encapsulate the other, or do we care? ...
I'll bite: how can you stop me from using the same key?? And as a
receiver, why would I be motivated to support such a proscription
which undoubtably lowers my verification rate?
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.)
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org
