[Dnssec-deployment] Validating algorithm types (was Re: DS digest types 1 vs 2)

[Paul Hoffman]

At 10:33 AM -0400 8/2/10, Matt Larson wrote:
>We are doing a sanity check on the algorithm field, however, and only
>allowing DS records for legitimate algorithms, i.e., we are tracking
>http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1.
>
>Here's a question for everyone: of the assigned algorithm types on the
>page referenced above, are there any that don't make sense to allow a
>DS record for?  I'm thinking particularly of indirect (252) and the
>two private codes (253 and 254).  Is there any legitimate reason for a
>DS record for keys with those algorithms to appear in the "public"
>name space?

252 is right out: it is not defined anywhere. I can see you using an algorithm number for an indirect signature mechanism that is defined, but not until then.

Once draft-ietf-dnsext-dnssec-alg-allocation is published (any day/week/month now), I see no reason to accept 253 or 254. "Private" means "not public", and you are signing a public zone.

>My inclination is that they should be allowed unless proven harmful.

My, you seem to like slippery slopes. How harmful to do want them to be? How will you measure that?

>Can anyone think of a reason to classify any assigned algorithm as
>actually harmful?

Nope. But I can see a reason not to have things defined as private, or things that are undefined, not be part of a public zone.

--Paul Hoffman, Director
--VPN Consortium