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

[Howard Eland <heland@afilias.info>]

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

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


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

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

>
>    <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
> 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: Howard Eland <heland@afilias.info>
> Date: Wed, 28 Oct 2009 17:19:32 -0400
> To: James Gould <jgould@verisign.com>
> Cc: Klaus Malorny <Klaus.Malorny@knipp.de>, EPP Provreg
> <ietf-provreg@cafax.se>
> 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
>> 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: Tue, 27 Oct 2009 19:38:02 -0400
>> To: James Gould <jgould@verisign.com>
>> Cc: Howard Eland <heland@afilias.info>, EPP Provreg <ietf-provreg@cafax.se 
>> >
>> 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 ietf-provreg-request@cafax.se