Re: Example of stupid inconsistencies between registries

Hi Patrik,

FWIW, we (Nominet / .uk) chose the DS interface for 2 reasons:
- compatibility; DS data can be generated from key data but not vice-versa
- simplicity & clarity of responsibility (we just publish what we're given)

On the other hand, we chose to be cautious about the set of algorithms/digest types/digests to allow for the DS record, because 3rd party components might allow nonstandard values on input, but then fail.  That said, no-one's yet asked for GOST support.

I haven't read the RFC recently, but I recall the choice of interface was an either/or - so a MUST implies the loss of the key interface (not that I'd cry for it).

Anthony


________________________________________
From: [email protected] [[email protected]] on behalf of Patrik Fältström [[email protected]]
Sent: 05 March 2012 10:43
To: [email protected]
Subject: [provreg] Example of stupid inconsistencies between registries

According to RFC 5910, section 4, there are two alternative interfaces for managing DNSSEC key data when interfacing with a registry. The RFC does not explicitly say whether a registry must implement one or the other.

I have successfully implemented in a web interface, an API for registrants etc, the DS interface as the client do believe passing DS data is the easiest. After all that is what is to be signed by the parent.

I just encountered a registry that "want to set a limit on what digest algorithms to use" and to do that, they have decided to not implement the DS interface and only support the KEY interface.

I can accept limitations on what digest algorithms they accept, but not limitations by not supporting DS.

Reactions?

  Patrik

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg