I agree with Doug that if additional information is to be offered it should be in the key records. In fact the whole point of my proposal is that almost all the policy information lives in the key records.
The policy record essentially contains one bit of information 'everything is/is not DKIM'. The only parameter that is needed is to allow for specification of the key record prefix so the correct key records can be found. I disagree that there is a need to state that an algorithm is deprecated in signer generated records though. If there was such a need it should be done through a separate mechanism for distributing the status of cryptographic algorithms and should proceed from an authoritative source like CFRG. > -----Original Message----- > From: Douglas Otis [mailto:[EMAIL PROTECTED] > Sent: Monday, October 23, 2006 2:20 PM > To: Hallam-Baker, Phillip > Cc: [email protected] > Subject: Re: [ietf-dkim] Comments on > draft-ietf-dkim-ssp-requirements-02.txt > > > On Oct 23, 2006, at 10:52 AM, Hallam-Baker, Phillip wrote: > > > The deployment scenarios do not capture the downgrade > attack problem > > correctly. > > > > As has been repeatedly pointed out on the list and never > rebutted the > > only way you can have a successful transition from a state > where the > > whole world uses algorithm A to one where the whole world uses > > algorithm B without having a period where one group or the other is > > unable to achieve their security goals is to: > > > > * Sign messages with both algorithms > > * Have a policy statement that specifies that messages are > signed with > > both algorithms. > > When more than one algorithm is offered, where the signer is > also responding to an attack vector, the following is also desired - > > * Indicate which of algorithms are deprecated. > > However, this strategy is not to be handled in the initial > specifications. > > An optimal location for this information to minimize overhead > is within the key records. There is also a desire to > eliminate policy references in various scenarios not > compatible with preventing this downgrade concern. > > -Doug > > > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
