[ietf-dkim] agenda item on upgrading hash algorithms?

[Jon Callas]

On 22 Feb 2006, at 1:03 PM, Douglas Otis wrote:

>
> On Feb 22, 2006, at 11:11 AM, Jon Callas wrote:
>
>> The only question facing us is whether we jump straight to SHA-256  
>> now, or allow both. Jumping is cryptographically wiser as it gets  
>> us off the weak hash. Allowing both is engineeringly wiser as it  
>> forces us to be agile now. Neither is a bad choice, sadly. If one  
>> were a bad choice, then it would be easy. As things sit, we have a  
>> hard choice, and no matter what we do, people will look back with  
>> the wisdom of hindsight and cluck their tongues sadly about how  
>> stupid we were and how *clearly* it would have been better to do  
>> the other thing.
>
> There is an equally important question related to this question.   
> Adopting an IANA index of the signature/hash algorithms as found  
> with RFC2538 rather than expressing this as a textual  
> representation, suggests one area not well covered.  This does not  
> require hindsight as OpenPGP has already has made an appropriate  
> choice for a binary resource record and binary representation of  
> algorithms.  Following their example, it is already apparent what  
> should be done.  When considering the servers and clients must be  
> modified anyway, switching to this resource record type to afford a  
> binary format puts DKIM in step with the rest of the industry.

Yes, but.

The binary formats we have in OpenPGP have their own set of issues.  
It's easy to plop in an new algorithm identifier, but when it comes  
to signatures, we also have to play, "Buddy, can you spare an OID?"  
Furthermore, we end up needing to have things in text, too, because  
people want to have that because the binary objects almost never  
wander around naked; they're almost always armored or in clearsigned  
form. RFC2538 pretty much has the same issues. There are other  
virtues than saving a byte here and there. If you don't believe me,  
look at how OpenPGP handles lengths. There is more complexity in  
saving bytes there than anyone needs.

	Jon