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

[James Gould <jgould@verisign.com>]

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

Klaus,

Sorry for the late reply to your post, since you raise some good questions.  I believe that the clients should specify the dsData with the keyData for optional validation for maximum flexibility to the client, but if there is the need to support a keyData interface then the specification can support it.   

“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.
“

The [DS] and [DS/KEY] models make sense, and the ladder interpretation of [DS/KEY] seems like the better one, where it is really [DS] with the optional use of the key data for validation.  The server should support either the [DS] / [DS/KEY] model or the [KEY] model and not both.  

“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
“

The [DS] entry should remove a single DS data record.  If there are multiple DS data records with the same [KEY] the <rem> SHOULD not more then one DS data records as a side effect.  This is the wildcard scenario.  I would imagine with the [KEY] interface that the server is responsible for the generation of the associated DS records, so a removal of a [KEY] entry should remove all DS records for that [KEY] entry.  [DS/KEY] doesn’t make much sense on a <rem> since I view [DS/KEY] as [DS] with optional keyData validation, which is not needed on a remove.  It would be good if the server returned an error if both the dsData and the keyData is passed on a <rem> to reduce confusion.  

“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.:
“

I’m not sure if the client specified maxSigLife makes much sense for the [KEY] interface since the DS data becomes the responsibility of the server.  Do any of the registries looking to support the [KEY] interface have an opinion on this one?   



-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.

---

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Wed, 4 Nov 2009 15:06:57 -0500
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

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