[ietf-dkim] Core algorithm support/use, draft text v2

[Mark Delany]

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.