Re: off-list was Re: Revision of 4310

Hello,

Well I think you know here I stand here. For me the hypothesis number 3 
will be the best option. But I think number 2 will also be a good 
approximation where I can make some adjustments to work with it. But the 
number 1, for me, will be a bad choice. :(
So depending on what the list chose I will follow it.

Best regards,

Eduardo Duarte


James Gould wrote, On 03-02-2010 23:18:
> Pre-publishing the DS is a valid use case, but I guess it boils down 
> to how the servers are going to handle the pre-published DS.  I know 
> for our registries that we'll publish what is given to us or do the 
> validation inline with the EPP transaction.  Validation could be done 
> inline with the EPP transaction so that DS is not stored in the 
> database unless it has the corresponding DNSKEY in the child zone or 
> in the case of .PT it could be done asynchronously which leads to 
> accepting DS that might not be published based on server policy.  So 
> the real question is whether the rfc4310-bis needs to add an 
> additional flag element to support the ladder?  I personally don't 
> like the term "active" for this, since "active" does not effectively 
> reflect the purpose.  I believe that published is more accurate, since 
> the server is making a decision related to what is published and what 
> is not published.  This should be an optional attribute to support 
> servers that publish everything, where the default is true.  I would 
> like to pose the following options to the list for consideration in 
> rfc4310-bis:
>
>    1. Don't include any additional elements.  This means that the
>       server would either validate the passed DS inline with the EPP
>       transaction or would publish all DS that is passed.
>    2. Add a new optional element in the secDNS:dsData (DS Interface)
>       and secDNS:keyData (Key Interface) elements of secDNS:infData.
>        I propose the use of the secDNS:published element.
>    3. Add a new optional secDNS:childKeyPublished element in the
>       secDNS:dsData (DS Interface) and secDNS:keyData (Key Interface)
>       elements of secDNS:create, secDNS:update, and secDNS:infData.
>        This element would be specified by the client to inform the
>       server which DS has a corresponding DNSKEY published in the
>       child zone.  It would be up to the server to decide the
>       validation and publishing scheme based on this flag.  Option #2
>       might have to go along with this as well in the event that the
>       server will publish a different set of DS based on offline /
>       asynchronous processing.
>
>
> I would like to hear from those interested in this topic either from 
> messages to the list or to me privately.
>
> Thanks,
>
> -- 
>
>
> JG
>
> -------------------------------------------------------
> *James F. Gould
> **Principal Software Engineer
> *VeriSign Naming Services
> [email protected]
> *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: *<[email protected]>
> *Date: *Mon, 1 Feb 2010 11:51:55 -0500
> *To: *<[email protected]>
> *Cc: *EPP Provreg <[email protected]>
> *Subject: *Re: off-list was Re: [ietf-provreg] Revision of 4310
>
> Eduardo Duarte <[email protected]> wrote:
>
> > ... we are thinking of adding a
> > DS validator in order to publish only the correct DS's. Also we 
> always have
> > our data in the database and there we keep the multiple keys 
> associated with
> > the domain some in publish state and other in a unpublished state. So 
> when a
> > user adds a DS to our system he is adding it to the database and not 
> to the
> > zone itself and after, when generating the zone the script, will only 
> pick-up
> > and add to the zone the "actives" DS's.
>
> As has been pointed out elsewhere, there are valid reasons for 
> publishing a DS record in the parent without a corresponding DNSKEY in 
> the child (e.g. key rollover). If you are going to validate the 
> DS/DNSKEY correspondences, then a better check would be that at least 
> one of the DS records being published in the parent corresponds to a 
> DNSKEY currently in the child.
>
> Stephen