Re: [ietf-provreg] Anyone working on 4310-bis?

[Klaus Malorny <Klaus.Malorny@knipp.de>]

On 04/11/09 14:31, Ulrich Wisser wrote:
>> So there are registries out there looking to support a keyData
>> interface for
>> DNSSEC, where the client would pass just the keyData on an add/rem/chg?
>> Would the DS data be returned in the info response?
>
> James, I've heard from several registries considering it. But I have no
> input about this from registrars. From a registry standpoint dealing
> with keys instead of ds records makes operations much simpler.
>
> We would not return DS data. .SE would put two DS records for each key
> in the zone file. So returning DS records would mean to return the key
> twice. With the proposed change we would return the key data in the info
> command.
>
> /Ulrich

Hi all,

sorry for flooding the list, but I prefer to keep issues separated.



I'd like to dig a little bit deeper on this dsData/keyData issue:

So we would allow either to

  * [DS]: specify only the DS data

  * [KEY]: specify only the DNSKEY data; the registry would be responsible to
    generate DS record(s) from it

  * [DS/KEY]: specify both DS and DNSKEY data; the registry would either
    silently ignore the DS data and use the key data as in [KEY], or use
    the DNSKEY to verify the correctness of the DS data. I wouldn't
    recommend the first case, though.

in <create> and <update> requests?

It would be upon the registry policy which of the three (including any 
combination of them) would be accepted.

In the <rem> section of an <update>, how can a user remove an existing entry?

* a [DS] entry could remove an existing [DS] or [DS/KEY] entry,
   but it probably should not be able to remove a [KEY] entry
* a [KEY] entry could remove an existing [KEY], [DS/KEY] entry
   or multiple [DS] entries (e.g. with different digest types),
   but the latter is probably not recommended
* a [DS/KEY] entry could remove all three types

Again, it would probably be the best to define the acceptable ways as a registry 
policy, wouldn't it?

For the <info> request, I would like propose that the answer returns exactly the 
data that has been specified in the <create>/<update> requests.

However, different answers could be imaginable:

* a [KEY] could be returned either as the respective [DS] entries
   (maybe even in addition).
* [DS/KEY] could be returned as [DS] only.


One final thing:

I believe that the <maxSigLife> element should be removed from the group 
definition and put directly into the sequence, so that it may be also specified 
in a key data only solution. Or shall it not be applicable in this case? I.e.:

<complexType name="dsDataType">
   <sequence>
     <group minOccurs="0">
       <sequence>
         <element name="keyTag"     type="unsignedShort"/>
         <element name="alg"        type="unsignedByte"/>
         <element name="digestType" type="unsignedByte"/>
         <element name="digest"     type="hexBinary"/>
       </sequence>
     </group>
     <element name="maxSigLife" type="secDNS:maxSigLifeType"
       minOccurs="0"/>
     <element name="keyData" type="secDNS:keyDataType"
       minOccurs="0"/>
   </sequence>
</complexType>


Regards,

Klaus



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se