Subject: [ietf-dkim] Base-04 //deprecated cryptographic algorithms

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Jul 2006 16:53:12 -0700

,---
|4.  Semantics of Multiple Signatures
|...
| When evaluating a message with multiple signatures, a verifier should
| evaluate signatures independently and on their own merits.  For
| example, a verifier that by policy chooses not to accept signatures
| with deprecated cryptographic algorithms should consider such
| signatures invalid.
'___

The terms "deprecated" and "obsolete" have been defined for HTTP that  
are fairly typical of other computer related definitions.

http://www.w3.org/TR/REC-html40/conform.html

An element has a status of "deprecated" when it will not be supported  
some time in the future.
An element has a status of "obsolete" when support is currently being  
withdrawn.

In this paragraph, the term "deprecated" should be changed to  
"obsolete" to be consistent.

Currently DKIM lacks a defined mechanism to differentiate  
"deprecated" algorithms.  While one could insist distinctions of  
supported/deprecated/obsolete are better done within a separate  
policy transaction, such additional information should be conveyed in  
conjunction with the key/signature information when possible to avoid  
unnecessary overhead.  DKIM already adds to the overhead, where  
opportunities of reduction should not be ignored.  When an algorithm  
is considered "deprecated" (per the w3.org definition), there will  
not be any advanced warning based upon the current DKIM draft.  A  
signer unhappy with protections afforded by what they consider a  
"deprecated" algorithm can not clearly signal this.  It may become  
common for alternative services to be used for various recipients  
where multiple signatures might become ordinary.  A transition of  
deprecated to obsolete by the signing domain may occur when the  
verifier had not been warned and thus remained unprepared.

Although best done now, this signaling could be added sometime in the  
future.  Using consistent terminology at this time would be helpful  
for these future definitions.

-Doug 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Jul 2006 18:12:44 -0700

On Jul 20, 2006, at 5:02 PM, [email-masked] wrote:

> This was dealt with (ignoring the editorial nit).
>
> Eliot - plese do not open a new issue for this.

This concern _has_ been rephrased into _only_ being an editorial nit  
on the use of the term.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Jul 2006 06:46:50 +0100

To be clear:

Tony Hansen wrote:
>> In this paragraph, the term "deprecated" should be changed to "obsolete"
>> to be consistent.
> 
> +1

I've no problem with that editorial nit being raised, accepted or
rejected. I do have a problem Doug's saying yet again:

 >> "deprecated" algorithms. [...etc...]

That has been dealt with ad nauseum.

S.