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

From: James Gould <[email-masked]>
Date: Wed, 28 Oct 2009 18:19:53 -0400

Howard,

I don¹t believe that there is a desire to allow wildcard deletion of DS
records.  That is the existing issue, where the client requests to delete
keyTag 12345 and if there are multiple DS records with the same keyTag 1234
for the domain, all of the DS records will be deleted.  I believe it is
preferable to make the deletions as explicit as possible, where the option
of using the dsDataType will address it by requiring all four elements to be
passed (keyTag, alg, digestType, and digest) for uniquely identifying the DS
record to delete.  None of the attributes alone uniquely identify a DS
record, so the natural primary key is the combination of all four of them.
If clients desire to be able to uniquely identify a DS record by using a
subset of the four elements, than a change could be made to make one or more
of the elements of dsData optional by defining a new complexType like
dsDataType with minOccurs=²0².  The selectType meets the need, but it best
not to introduce a new element like ³select² under the rem element.

My recommendation is for the registry to return an error if the client
specifies a DS that does not result in a single DS record being deleted.  If
we want to make the input elements for the rem flexible to allow the client
to decide what uniquely identifies the DS to remove than the schema could
look like below (the remType dsData element could be renamed to something
like "select" if needed).  Specifying no elements for the dsData should
result in an error since it won't match anything.

    <complexType name="updateType">

        <choice>
  
            <element name="chg" type="secDNS:dsType"/>

            <sequence>

                <element name="add" type="secDNS:dsType" minOccurs="0"/>

                <element name="rem" type="secDNS:remType" minOccurs="0"/>

            </sequence>

        </choice>
 
        <attribute name="urgent" type="boolean" default="false"/>

    </complexType>

     <complexType name="selectType">
       <sequence>
         <element name="keyTag" type="unsignedShort"
                  minOccurs="0"/>
         <element name="alg" type="unsignedByte"
                  minOccurs="0"/>
         <element name="digestType" type="unsignedByte"
                  minOccurs="0"/>
         <element name="digest" type="hexBinary"
                  minOccurs="0"/>
       </sequence>
     </complexType>

    <complexType name="remType">

        <choice maxOccurs="unbounded">

            <element name="keyTag" type="unsignedShort"/>

            <element name="dsData" type="secDNS:selectType"/>

        </choice>
 
    </complexType>

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
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: Howard Eland <[email-masked]>
Date: Wed, 28 Oct 2009 17:19:32 -0400
To: James Gould <[email-masked]>
Cc: Klaus Malorny <[email-masked]>, EPP Provreg
<[email-masked]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

So, thinking about this, plus Ed's comments about being able to use the
digest itself led me to add a couple more things.

First, I'd think it'd be good to be able to specify which DS records to
operate on with as little information as possible, and make it flexible
(without having to specify the entire DS record).

Second, I could see people wanting to do things like "remove all algorithm
ID 5 records".

So, I came up with a selectType, that let's you pick from keyTag, alg ID,
digest type, or digest itself.  For a rem, that's all that is needed.
However, to make this consistent, I added it to chg as well (creating
"chgType" in the process, so you could specify changing only one of many DS
records without repeating the entire set.  I made these changes to your last
post of "updateType" below, so the simultaneous add/rem is in there as well.

I believe we're _mostly_ backwards compatible here (see Caveat 3).
A couple of caveats:
1) Both with this and the post below, it looks like the XML would allow for
a no-op on updateType (since the second choice contains all elements with
minOccurs=0).
2) I did not validate this XML yet - I wanted to explain the concepts before
going any further.
3) As written, this allows for selecting _no_ attributes, which, in theory,
would allow one to remove all DS records for a domain object.  Currently RFC
4310 does not allow this, because the keyTag is required.  This adds
functionality, but at the expense of a foot-shotgun.

(non-validated) XML code below.

-Howard

    <complexType name="updateType">
        <choice>
          <element name="chg" type="secDNS:chgType"/>
          <sequence>
            <element name="add" type="secDNS:dsType" minOccurs="0"/>
            <element name="rem" type="secDNS:remType" minOccurs="0"/>
          </sequence>
        </choice>
        <attribute name="urgent" type="boolean" default="false"/>
    </complexType>

     <complexType name="selectType">
       <sequence>
         <element name="keyTag" type="unsignedShort"
                  minOccurs="0" maxOccurs="1"/>
         <element name="alg" type="unsignedByte"
                  minOccurs="0" maxOccurs="1"/>
         <element name="digestType" type="unsignedByte"
                  minOccurs="0" maxOccurs="1"/>
         <element name="digest" type="hexBinary"
                  minOccurs="0" maxOccurs="1"/>
       </sequence>
     </complexType>

     <complexType name="remType">
         <element name="select" type="secDNS:selectType"
          maxOccurs="unbounded"/>
     </complexType>

     <complexType name="chgType">
       <sequence maxOccurs="unbounded">
         <element name="select" type="secDNS:selectType"/>
         <element name="selectChg" type="secDNS:dsType"/>
       </sequence>
     </complexType>

On Oct 28, 2009, at 9:32 AM, James Gould wrote:

>  Klaus,
>  
>  Your proposal will work with one small fix of replacing </sequence> in
> remType to </choice>.    This will be backward compatible, will address the
> issue of  identifying the DS record to remove, and will support adding and
> removing more than one DS record in the same command.  I like that the chg
> still behaves like a replace, which again is backward compatible.  The only
> difference is that all four elements need to be provided (keyTag, alg,
> digestType, digest) with a rem, which I don¹t believe should be a big issue.
> Does anyone see an issue with having to specify either the keyTag or all four
> elements on a rem?  The following is the schema elements with the small fix
> that I tested through with various use cases successfully.
>  
>      <complexType name="updateType">        <choice>          <element
> name="chg" type="secDNS:dsType"/>          <sequence>            <element
> name="add" type="secDNS:dsType" minOccurs="0"/>            <element name="rem"
> type="secDNS:remType" minOccurs="0"/>          </sequence>        </choice>
> <attribute name="urgent" type="boolean" default="false"/>    </complexType>
> <complexType name="remType">        <choice maxOccurs="unbounded">
> <element name="keyTag" type="unsignedShort"/>          <element name="dsData"
> type="secDNS:dsDataType"/>        </choice>    </complexType>
>  
>  The following tests worked and passed schema validation:
>  
>  
> * Passing a single add, chg, or rem with the rem containing just the keyTag.
> This is the backward compatible tests.
> * Passing multiple dsData elements for both the  add and rem elements
> * Passing multiple keyTag or dsData elements with the rem element
> *  
> 
>  
>  
>  -- 
>  
>  
>  JG 
>  
>  -------------------------------------------------------
>  James F. Gould
>  Principal Software Engineer
>  VeriSign Naming Services
>  [email-masked]
>  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-masked]>
>  Date: Tue, 27 Oct 2009 19:38:02 -0400
>  To: James Gould <[email-masked]>
>  Cc: Howard Eland <[email-masked]>, EPP Provreg <[email-masked]>
>  Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>  
>  On 2009-10-27 22:31, James Gould wrote:
>> [...]
>> 
>> Updated XML schema:
>>      <complexType name="remKeyType">
>>          <simpleContent>
>>              <extension base="unsignedShort">
>>                  <attribute name="alg" type="unsignedByte"/>
>>                  <attribute name="digestType" type="unsignedByte"/>
>>                  <attribute name="digest" type="hexBinary"/>
>>              </extension>
>>          </simpleContent>
>>      </complexType>
>> 
>>      <complexType name="remType">
>>          <sequence>
>>              <element name="keyTag" type="secDNS:remKeyType"
>> maxOccurs="unbounded"/>
>>          </sequence>
>>      </complexType>
>> 
>> [...]
>  
>  Hi James,
>  
>  instead of adding attributes, one could declare the content of the <rem>
> element
>  to be a choice between the <keyTag> element and the <dsData> element, with
>  unbounded repetition, e.g.
>  
>        <complexType name="remType">
>          <choice maxOccurs="unbounded">
>            <element name="keyTag" type="unsignedShort"/>
>            <element name="dsData" type="secDNS:dsDataType"/>
>          </sequence>
>        </complexType>
>  
>  Also, I propose a change to allow both <add> and <rem> to occur in the same
>  request, i.e. something like this (may be formally incorrect, haven't checked
>  the syntax):
>  
>        <complexType name="updateType">
>          <choice>
>            <element name="chg" type="secDNS:dsType"/>
>            <sequence>
>              <element name="add" type="secDNS:dsType" minOccurs="0"/>
>              <element name="rem" type="secDNS:remType" minOccurs="0"/>
>            </sequence>
>          </choice>
>          <attribute name="urgent" type="boolean" default="false"/>
>        </complexType>
>  
>  
>  Regards,
>  
>  Klaus
>  
>   
>   

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Howard Eland <[email-masked]>
Date: Wed, 28 Oct 2009 17:46:33 -0500

On Oct 28, 2009, at 5:19 PM, James Gould wrote:

> Howard,
>
> I don’t believe that there is a desire to allow wildcard deletion of  
> DS
> for the domain, all of the DS records will be deleted.

Not quite.  The current standard ensures _all_ DS records under a  
specific keytag are transformed.  I'm suggesting a way to allow  
anywhere from 1 to all DS records that match the keytag.

Also, I'm attempting to make the functionality between these two  
commands consistent, and the spirit of the chg element in the current  
RFC seems to suggest that the change can occur for multiple DS  
records.  See below for more on chg.

>  I believe it is

If we're shying away from selecting multiple DS records for  
transformation, then I agree with Ed - just use the hash.

I'm still thinking that it would be good to be able to delete all alg  
ID 5 records, or all digest type 1 records, but maybe I'm in the  
minority here.

> dsDataType with minOccurs=”0”.  The selectType meets the need, but  
> it best
> not to introduce a new element like “select” under the rem element.
>

This still does not address the issue of the chg element.  Maybe an  
example is in order:

If I have two DS records each with keytag 12345, alg ID 5.  One has  
digest type 1, the other, digest type 2, and each with their own  
digest.  Under the current (and this) mechanism, how would one change  
_one_ of these to a new digest?  There is no way to specify under chg  
which DS to affect.  Currently, the only way I can see to do this  
would be to rem then add.  That may be OK, but then why have chg at all?

Another example would be "how does one change the keytag of one of  
these DS records, but not the other?"  A rem/add is probably not  
called for here, as we could potentially break validation, albeit  
temporarily.

I don't want to add complexity that isn't needed.  However, I'd like  
to make sure that if we're going to the well to fix problems, we fix  
as many as we can see.  I can certainly live without the multiple DS  
operations, but I think the selection bit needs to be addressed.

-Howard

>> digestType, digest) with a rem, which I don’t believe should be a  
>> big issue.
>> Cc: Howard Eland <[email-masked]>, EPP Provreg <[email-masked] 
>> >