On Wed, Mar 01, 2006 at 11:05:33AM -0800, Jim Fenton allegedly wrote:
Mark Delany wrote:
On Tue, Feb 28, 2006 at 11:06:35AM -0800, Jim Fenton allegedly wrote:
I don't recall anyone suggesting that we require signers to do multiple
signatures (at least, I wasn't suggesting that). In any case, I agree
with your statement.
But surely at some point, if not at the beginning, they will have to,
won't they?
I guess I wasn't clear. What I meant was that the specification
shouldn't require senders to apply two signatures (i.e., doesn't say
"MUST sign using both SHA-256 and SHA-1 hashes"). It needs to require
one, permit two, and I expect the desire for verification to succeed
will dictate when two signatures are required.
Ok. Sounds good.
Say, eg, SHA-4096 comes along and is ordained as the preferred hash in
some future DKIM. A signer adopting SHA-4096, will need to continue to
additionally sign with the older hashes as long as they believe some
recipients may not have upgraded to verify SHA-4096.
That comes back to the point that Ned et al made perhaps a week ago,
if we know that transition will occur at some point in the future,
leaving that code unexercised until then is surely a recipe for
disaster.
I think we're currently in a situation where two signatures might be
required in some contexts. I don't have a problem with saying that
signers MUST be capable of generating multiple signatures, but I'm not
convinced that saying so will cause code to actually get exercised.
I think your first words were better. Signers may, verifiers MUST be
able to choose amongst multiple signatures consistent with local
policy (pick strongest, pick weakest, ignore unrecognized, whatever).
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html