[ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade
pbaker at verisign.com
Tue Feb 27 19:32:08 PST 2007
No, that is not what I am proposing.
The discussion here is about a REQUIREMENT. How the requirement is achieved is not the issue at this point.
Of course since everyone seems to skip straight to the implementation, think up a daft way to do it and then object to the complexity of the scheme I am not proposing we have spent six months discussing what is the most trivial, easy to implement scheme you can imagine that actually works.
The policy record does not directly reference the signing algorithm, all that information remains in the key record. All that you get in the policy record is a statement 'there is always a key record that has a selector that looks like this' or 'there is always one like this and one like that'.
Lets hold off on the implementation though as Steve will no doubt remind us is the basic idea at this point. This means that we only discuss whether it is a valid requirement. The cost of implementation is not the issue at this point.
From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Jim Fenton
Sent: Tuesday, February 27, 2007 6:19 PM
To: John Levine
Cc: ietf-dkim at mipassoc.org; paul.hoffman at domain-assurance.org
Subject: Re: [ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade andDowngrade Attacks
If you mean to just require that and not actually list the algorithms, the verifier would have no way of determining what algorithms the signer uses, without a list of all its selector names.
If you mean to list the algorithms, isn't that what Phill is proposing?
John Levine wrote:
Every protocol with algorithm agility but not a fixed list of "MUST
implement" algorithms has this issue.
Is there any reason that SSP couldn't require that anyone who makes a
statement that he signs messages must sign with all the signature algs
This would be an SSP MUST, not a DKIM MUST.
NOTE WELL: This list operates according to
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ietf-dkim