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

[James Gould <jgould@verisign.com>]

I'm glad that this thread has come up, since I too was going to propose
something similar to option 1 but with making the specification change
backward compatible.  We are implementing to 4310 for .com, .net, and .edu
with no additional extensions.  We see the issue with use of just the
keyTag, since it is derived and is not unique.  There are use cases where
for the same key, which means the same keyTag, there could be multiple
digest types and algorithms.  My proposal is to add optional attributes
(alg, digestType, and digest) to the <secDNS:keyTag> element of <secDNS:rem>
and to add verbiage for the registries to match the DS record for the delete
based on all of the passed information.  If there is more than one matching
DS record for the input, than an error must be returned.  The following is
what I would propose for the XML schema change:

Original XML schema:

    <complexType name="remType">
        <sequence> 
            <element name="keyTag" type=" unsignedShort"
maxOccurs="unbounded"/>
        </sequence>
    </complexType> 

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>



An example of the resulting secDNS:rem for deleting two DS records with the
same keyTag value but with a different algorithm, digestType, and digest is
below:

      <secDNS:rem>
        <secDNS:keyTag alg="1" digestType="5"
digest="48EC35D5B3A34B45C399">12345</secDNS:keyTag>
        <secDNS:keyTag alg="2" digestType="3"
digest="38EC35D5B3A34B44C39B">12345</secDNS:keyTag>
      </secDNS:rem>


One additional proposed change is to clarify the use of the <secDNS:chg> to
state something like ³is used to replace all existing DS information with
new DS information².  The information associated with the specified keyTag¹s
is not the only information changed, since the interpretation is that the
<secDNS:dsData> elements provided with the <secDNS:chg> is a wholesale
replacement of the all of the existing dsData information.  Have any of the
registries interpreted the <secDNS:chg> in a different way?


-- 


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: Tue, 27 Oct 2009 15:56:18 -0500
> To: EPP Provreg <ietf-provreg@cafax.se>
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
> 
> The issue I brought up to Andrew involves the transform commands.
> These only require the key tag to perform tasks such as remove, but,
> as mentioned in 4034, the key tag by itself may not be unique.  We are
> seeing much interest in multiple DS records that have the same key tag
> with different digest types from registrants.  If multiple DS records
> are added to the registry with the same key tag, and a subsequent
> transform command is sent with only the key tag, as specified in 4310,
> the result is left to interpretation.
> 
> Possible solutions for this are:
> 1) Force the specification of <key tag, alg ID, digest type> for all
> transform commands (this requires the protocol change to 4310, and is
> where I'm headed).
> 2) Proceed to transform all DS records with this key tag in the same
> manner (but here too are dragons, as a change or update could result
> in either duplicate DS records, or would force the registry to remove
> the dups, causing a discrepancy between the registrar and the registry).
> 3) Do not allow multiple DS records with the same key tag (forcing key
> tags to be unique on the domain object - this seems like a non-starter
> to me).
> 4) Do not allow multiple DS records (also a non-starter).
> 
> Thoughts?
> 
> -Howard
> 
> 
> On Oct 27, 2009, at 3:31 PM, Patrik Fältström wrote:
> 
>> 
>> On 27 okt 2009, at 21.16, Patrick Mevzek wrote:
>> 
>>> Andrew Sullivan <ajs@shinkuro.com> 2009-10-27 21:05
>>>> I have of late observed a couple possibly pointy corners in RFC
>>>> 4310,
>>>> and Howard Eland just pointed out to me a pretty big operational
>>>> problem in it, so I am wondering whether anyone is working on
>>>> updates
>>>> to it.
>>> 
>>> I'm not specifically working on it, but I would advise anyone dealing
>>> with DNSSEC and EPP to have a look at what .CZ did and what .EU will
>>> do soon, as they both created other extensions to handle DNSSEC with
>>> EPP. Maybe other registries too. Sorry if you did that already.
>>> 
>>> I'm not judging pro or in favor of any other extension,
>>> but I believe that having a look at the currently deployed EPP
>>> dealings with DNSSEC would be a good idea in light of future work on
>>> 4310.
>> 
>> We use epp and DNSSEC in .SE since a while back. What are the issues
>> you think?
>> 
>>   Patrik
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> =-=-=-
>> List run by majordomo software.  For (Un-)subscription and similar
>> details
>> send "help" to ietf-provreg-request@cafax.se
>> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software.  For (Un-)subscription and similar details
> send "help" to ietf-provreg-request@cafax.se
> 


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