Re: 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
[email protected]
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 <[email protected]>
Date: Wed, 4 Nov 2009 15:06:57 -0500
Cc: EPP Provreg <[email protected]>
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 [email protected]