To:
Howard Eland <heland@afilias.info>
CC:
Ulrich Wisser <liste@publisher.de>, EPP Provreg <ietf-provreg@cafax.se>
From:
James Gould <jgould@verisign.com>
Date:
Mon, 02 Nov 2009 11:46:00 -0400
In-Reply-To:
<65C7AD75-F057-46B8-B275-54098AD9A4C2@afilias.info>
Sender:
owner-ietf-provreg@cafax.se
Thread-Index:
Acpb03dTS7dtUHyYQeudtT3f6ymPiwACH2uJ
Thread-Topic:
[ietf-provreg] Anyone working on 4310-bis?
User-Agent:
Microsoft-Entourage/12.20.0.090605
Subject:
Re: [ietf-provreg] Anyone working on 4310-bis?
Howard,
So if we ³go to the well once² without backward compatibility support, the
schema would do the following:
1. Remove support for the chg
2. Remove support for rem with just keyTag
3. Support for the combination of add and rem
4. Specify all of the DS information (keyTag, alg, digestType, and digest)
on an add and rem.
As far as supporting a keyData interface and dsData interface to the clients
, I believe that client-side software (SDKıs and utilities) should be
available for the client to generate the DS instead of pushing it to the
server-side. With the dsData interface, the client has maximum flexibility,
the load is distributed to the client-side, and the registries can provide
one consistent interface. It would be good to hear from the Registrars
related to supporting two different models across the DNSSEC registries.
I updated the options for the schema updates below:
Option 1 - Proposal from Klaus that is backward compatible, supports
combined add and rem, and supports rem with the four ds attributes as
elements:
<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>
Option 2 - Combination of Klausıs and Ulrichıs proposals, where the dsData
information is made optional to support the keyData interface:
<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>
Option 3 - Simplified interface that is not backward compatible but is
consistent with the rest of the EPP specs. Updates consist of just add and
rem of dsType data:
<complexType name="updateType">
<sequence>
<element name="add" type="secDNS:dsType" minOccurs="0"/>
<element name="rem" type="secDNS:dsType" minOccurs="0"/>
</sequence>
<attribute name="urgent" type="boolean" default="false"/>
</complexType>
Option 4 - Simplified interface that is not backward compatible but is
consistent with the rest of the EPP specs but with support for a keyData
interface, which makes the daData optional.
<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">
<sequence>
<element name="add" type="secDNS:dsType" minOccurs="0"/>
<element name="rem" type="secDNS:dsType" minOccurs="0"/>
</sequence>
<attribute name="urgent" type="boolean" default="false"/>
</complexType>
I personally like the simplicity of option 3 if we don't have to worry about
backward compatibility. Option 4 would be needed if there is a set of
registries that have a compelling reason to support the keyData interface.
For our registries we should be able to deal with a non-backward compatible
change as long as we move quickly to an agreement. Our registries will most
likely support only the dsData interface. I propose that the version number
of the namespace and schema be changed to reflect the non-backward
compatible change. I would see this as a urn:ietf:params:xml:ns:secDNS-2.0
and secDNS-2.0.xsd.
--
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: Mon, 2 Nov 2009 10:45:03 -0500
To: James Gould <jgould@verisign.com>
Cc: Ulrich Wisser <liste@publisher.de>, EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
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