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

[James Gould <jgould@verisign.com>]

Ulrich,

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?  Was providing a keyData
interface for DNSSEC requested by the Registrars to ease in the
implementation?  Iım not sure if having the registries supporting two
different models like the hostAttr and hostObj models of the domain
specification adds value or causes more complexity for the Registrars.  I'm
assuming that the Registry should support one model or the other and not
both.  If there is a compelling reason for supporting two different models,
then I believe that a combination of Klausıs and Ulrichıs schema changes
makes sense, but I would like to hear from others related to the advantage
of supporting two DNSSEC models (dsData and keyData).

In summary, below is the XML schema snippet from Klaus:

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


Below is the XML schema snippet that includes both Klausıs and Ulrichıs
proposals:

      <complexType name="dsDataType">
        <sequence>
            <group minOccurs="0">
                <element name="keyTag"     type="unsignedShort"/>
                <element name="alg"        type="unsignedByte"/>
                <element name="digestType" type="unsignedByte"/>
                <element name="digest"     type="hexBinary"/>
                <element name="maxSigLife" type="secDNS:maxSigLifeType"
minOccurs="0"/>
            </group>
            <element name="keyData" type="secDNS:keyDataType"
minOccurs="0"/>
        </sequence>
      </complexType>


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



I agree that if we're not concerned about backward compatibility that the
chg can be removed since supporting add and rem of multiple DS records is
consistent with the other EPP specifications and removes the need for chg.
I'm on the fence about this since I like backward compatibility but I also
like removing confusion around the use of chg if add and rem can be used in
its place.  

-- 


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: Ulrich Wisser <liste@publisher.de>
Date: Mon, 2 Nov 2009 05:08:03 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Andrew Sullivan wrote:
> On Wed, Oct 28, 2009 at 12:45:54PM +0100, Ulrich Wisser wrote:
>
>> The add command (as well as update) uses the secDNS:dsDataType. Which
>> makes keytag, alg, digestType and digest mandatory. I know that .SE and
>> other registries considered to become a "fat" registry and take in the
>> public keys instead of the ds records. The DS records would be computed
>> from the public keys according to registry policies.
>> This case is not covered by 4310.
>
> While this is true, 4310 does provide an OPTIONAL <secDNS:keyData>
> element.  Registry policy could require this.  Then you could get the
> DS and the DNSKEY at the same time, and you could even check to be
> sure the DS they're providing actually matches the DNSKEY they're
> providing (and use that as a first-line test to make sure their plan
> is sane.  If they can't generate the right DS, they are as likely to
> have other problems as not, and it could well be that you want to stop
> doing anything until it's sorted).  No?

I agree and this is not a big issue. I just thought that while we are
changing the XML schema anyway, this change wouldn't be to troublesome
either. I believe

      <complexType name="dsDataType">
        <sequence>
<group minOccurs="0">
          <element name="keyTag"     type="unsignedShort"/>
          <element name="alg"        type="unsignedByte"/>
          <element name="digestType" type="unsignedByte"/>
          <element name="digest"     type="hexBinary"/>
          <element name="maxSigLife" type="secDNS:maxSigLifeType"
           minOccurs="0"/>
</group>
          <element name="keyData" type="secDNS:keyDataType"
           minOccurs="0"/>
        </sequence>
      </complexType>

would do the trick and still be backward compatible, wouldn't it?

/Ulrich

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