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

[Howard Eland <heland@afilias.info>]

All,

I am in favor of "going to the well once".  I know there's been  
reluctance to change some things because of backwards compatibility  
and current implementation issues.  However, I feel that if the  
current document is broken enough to effect these changes, then we  
should do everything we can to make it right.  It is in exactly this  
spirit that I conceded to requiring the entire dsData set on remove,  
rather than just the digest.

On the two different DNS models: I am in favor of this, on one  
condition: the text has got to make sure that we preserve the  
authority of the data elements.  By this I mean that while it's  
permissible to send in the DNSKEY data, the registry itself MUST NOT  
publish and / or sign this record in the DNS, if they are not  
authoritative for it.

Interestingly enough, this is one reason why I like this option -  
because the parent _is_ authoritative for the DS record.  The same  
comment should be made to the owner of the child zone as well (that  
they are not authoritative for the DS record) - although I don't think  
it can be as strong.

Another reason I like this option is that it gives the registry the  
ability to maintain some consistency in not only the DS record RDATA,  
but also the DS record TTL.

-Howard


On Nov 2, 2009, at 8:03 AM, James Gould wrote:

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


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