I agree, we have already agreed to introduce a new cannonicalization: the
slippery slope argument is not operative.
The slippery slope argument is difficult to distinguish from 'I don't have a
real case to make against this change so I will make an unanswerable
objection based on the possibility of unforseen consequences'. The more
relevant question is whether this commits us to a change that breaks
backwards compatibility, it does not as we have already made this
concession.
We have a good deployed base and I don't want to see that trodden on without
cause. But the consequences of minor treading are not serious. Verifiers are
part of anti-spam infrastructure that is aggressively upgraded at this point
in time. I think that we can manage a transition without creating a long
term maintenance issue. We are not talking about a major impact on already
written code, it is a detail change that does not require major
re-architecting.
I would have serious issues if we had a major deployed base of verifiers.
I very much prefer the separate hash approach for several reasons:
* It is easier to debug deployments.
Unintended modificaiton of the head and body can be distinguished.
If there are multiple signatures it is possible to see who probably
screwed up
* In a reporting environment the sender can adapt the canonicalization
strategy
If mail sent to vmail with cannonicalization A is repeatedly
reporting
body validation failures try canonicalization B
* It allows for a more flexible software architecture
Message digests frequently calculated for other purposes can be
reused
Mailing list signers only need to digest the body once.
* The costs are marginal, at most an extra digest cycle.
With this particular change DKIM would be exactly isomorphic to
Authenticater Sender, the VeriSign domain keyed signed email proposal
(leaving aside the ability to link to certs which is an option/extension
issue). I believe that with this change DKIM has reached a local minima, I
am not aware of other likely slippage.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html