Subject: Re: Fwd: Re: RSA/SHA256

From: Jelte Jansen <[email-masked]>
Date: Thu, 01 Nov 2007 15:47:35 +0100

Michael StJohns wrote:

>>> Doesn't it actually make this worse if you split them? We'd either have
>>> to make it mandatory to support every combination that is possible,
>>> which I think can't be done, since it still seems hard to predict the
>>> future, or we'd have to require every combination that is allowed to
>>> have its own specification somewhere in a published document. I don't
>>> really see the difference in the location of the actual bits within the
>>> algorithm field in that case.
>>
>> Read this again.  We're currently using the same *registry* to indicate both key type and signature algorithms.  
>>
>> Split the "key type" *registry* from the "Signature type" *registry*. 
>>
>> The former applies to the DNSKEY record.  The latter applies to the RRSIG record and never the twain shall meet.
>>

Ah, like that, ok, so no problem for the every-or-selected then.

Still I don't really see the benefit when we go back so sending packets.

Wouldn't you still need to specify it in the DNSKEY record too (if only
to get it into the DS RR, so that a validator knows whether it should be
able to verify it)?

Jelte

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Michael StJohns <[email-masked]>
Date: Thu, 01 Nov 2007 11:51:04 -0400

At 10:47 11/1/2007, Jelte Jansen wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Michael StJohns wrote:
>

The DNSKEY record algorithm type field specifies a type of key - its mis-named.  An RSA key can be used with any signature algorithm that's RSA based - e.g. RSA/MD5, RSA/SHA1, RSA/SHA256.   If you continue to use the same registry for both DNSKEY and RRSIG algorithm fields, you run into the problem of which algorithm type to use in the DNSKEY record. 

For example - current implementations generally understand RSA/MD5 and RSA/SHA1.  Let's say you're running (on the server side) a new implementation which also understands RSA/SHA256. You make the legal, but probably bad choice to tag all of your keys as RSA/SHA256 (and the reason you did that was that guidance suggested that RSA/SHA1 was deprecated), but for compatibility with old implementations you do a signature as RSA/SHA1   The old implementations will probably choke on this, even though its a legitimate combination because they don't understand that RSA/SHA256 in a DNSKEY really is the same key type as RSA/SHA1 or RSA/MD5.  Far better if the key type just said "RSA" and left it at that.

It was a bad design choice to conflate these registries in the first place. Let's fix them in this go around.