Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review

Howard,

Thanks for the feedback.  Below is my reply to your feedback:

> Section 3.3.  Maximum Signature LIfetime
> Nit: for clarity, you may want to add "in the parent zone" to the end of the 
> sentence "The maxSigLife value applies to the RRSIG resource record (RR) over 
> the DS RRset.".

No problem I can add this to the –06 draft.

> Section 5.1.2. EPP <info> Command, Example <info> Response for a Secure 
> Delegation using the Key Data Interface:
> I believe the server should also return the server generated <secDNS:dsData> 
> when the client only sends in the Key Data interface.

What is the purpose for doing this, since with the Key Data Interface the client is managing the keys and the server is managing the DS associated with the keys?  What would the client really do with the DS returned since they don’t explicitly set it or manage it.  We don’t return the RRSIG resource records with the DS Data Interface, so why would another generated set of resource records be returned back?    

> Section 5.2.1. EPP <create> Command, second bullet set plus examples
> It is not clear in this section of the document that <secDNS:dsData> and 
> <secDNS:keyData> elements, when used to create DS records on the server, 
> cannot be intermixed.  The text seems to imply that under a single 
> <secDNS:create>, one could specify multiple <secDNS:dsData> elements, multiple 
> <secDNS:keyData> elements, or a mixture of both, as a method for creating 
> multiple DS records in the server.  Using this interpretation, the example is 
> actually ambiguous, as it is not sure if the <secDNS:keyData> is part of the 
> optional "validation" element for the previous <secDNS:dsData>, or if it is 
> implying the creation of another DS record by using only the <secDNS:keyData> 
> for the second DS.  I understand it's specified in the XML explicitly as 
> "dsOrKeyType", but the text under create should reflect this as well.

This text is used throughout the draft, since section 4 “DS Data Interface and Key Data Interface” is meant to more fully define the two supported interfaces of using either <secDNS:dsData> elements or <secDNS:keyData>, where only one is used.  It is hard for me to believe that it can be interpreted to use the optional “validation” element of the <secDNS:dsData> in the sentence “Zero or more <secDNS:dsData> elements or <secDNS:keyData> elements”.  Based on your proposal 0, would it be clearer to say “Zero or more <secDNS:dsData> elements or <secDNS:keyData> elements, but not both as defined in section 4”?  I view this as being redundant, but maybe because I wrote it.  Please let me know if this sentence is really ambiguous and whether the extra verbiage for the one sentence helps.  

> 9. Security Considerations, 2nd to last paragraph
> After "Data validity checking", add "and Delegation Signer record creation".

No problem I can add this to the –06 draft.



-- 


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, 23 Feb 2010 16:17:01 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review

In addition to that already posted to the list, I have the following comments:

Section 3.3.  Maximum Signature LIfetime
Nit: for clarity, you may want to add "in the parent zone" to the end of the sentence "The maxSigLife value applies to the RRSIG resource record (RR) over the DS RRset.".

Section 5.1.2. EPP <info> Command, Example <info> Response for a Secure Delegation using the Key Data Interface:
I believe the server should also return the server generated <secDNS:dsData> when the client only sends in the Key Data interface.

Section 5.2.1. EPP <create> Command, second bullet set plus examples
It is not clear in this section of the document that <secDNS:dsData> and <secDNS:keyData> elements, when used to create DS records on the server, cannot be intermixed.  The text seems to imply that under a single <secDNS:create>, one could specify multiple <secDNS:dsData> elements, multiple <secDNS:keyData> elements, or a mixture of both, as a method for creating multiple DS records in the server.  Using this interpretation, the example is actually ambiguous, as it is not sure if the <secDNS:keyData> is part of the optional "validation" element for the previous <secDNS:dsData>, or if it is implying the creation of another DS record by using only the <secDNS:keyData> for the second DS.  I understand it's specified in the XML explicitly as "dsOrKeyType", but the text under create should reflect this as well.

The text could do one of the following:
0) Add text that explicitly states that only one of <secDNSdsData> or <secDNS:keyData> can be specified.
1) Change the "Zero or more" statement to "Zero or one", forcing a <secDNS:create> for each DS record desired (although this hoses up maxSigLife, so there's a bit more to this than just that).
2) Add something akin to a <secDNS:dsKeyData> element that would be used as a wrapper for the <secDNS:keyData> when it is used as the optional element under <secDNS:dsData>.  This would avoid confusion as to when the client was specifying <secDNS:keyData> for validation purposes, or when it's used to specify another DS.  In fact, couldn't doing this eliminate the need for <secDNS:dsData> and <secDNS:keyData> to be mutually exclusive?

9. Security Considerations, 2nd to last paragraph
After "Data validity checking", add "and Delegation Signer record creation".

-Howard


 
On Feb 17, 2010, at 4:06 PM, James Gould wrote:

> All,
>
> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which includes the feedback that I received so far.  I included an open question on the inclusion of the ttl element to the AD for guidance.  Please let me know if you have any feedback to the latest draft. 
>
> Thanks,  
>
> -- 
>
>
> JG 
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> jgould@verisign.com <x-msg://170/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.