To:
EPP Provreg <ietf-provreg@cafax.se>
From:
Howard Eland <heland@afilias.info>
Date:
Tue, 27 Oct 2009 18:27:10 -0500
In-Reply-To:
<C70CDEE0.3572B%jgould@verisign.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] Anyone working on 4310-bis?
There's a lot of ways to skin this cat. All of them that I can see involve an RFC update (even if it's just for clarification). So, I seem to be hearing "yes, fix this, but hurry up about it". If this is the case, then is there anything else that folks would like to see in 4310-bis? (who has the worm-can opener?) Other comments below. On Oct 27, 2009, at 4:31 PM, James Gould wrote: > 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. I'd rather not include the digest itself here, since the <keyTag, algID, digestType> tuple uniquely identify the DS record. I'm not sure we have to maintain backwards compatibility, but, assuming we do, an error could be returned anytime multiple DS records are matched, as you suggest, or we could also affect the remove against all records that match those attributes sent in (in other words, the default is to match all for any given attribute). > The following is > what I would propose for the XML schema change: [...] > > 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? > To make <secDNS:chg> the most versatile, I'd still like to have the ability to specify the other attributes. That way, it can be used to change one or more DS records, as opposed to having to replicate all DS records to change one. This would make syntax similar to <secDNS:rem>, and would still be backwards compatible: if you don't specify the keyTag or any other attributes, then they all change. -Howard > > -- > > > 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