Re: rfc4310bis 03 AD Feedback
Howard Eland <heland <at> afilias.info>
2010-02-01 21:05:47 GMT
Hi James,
We bantered this about internally for a bit now, but came to the conclusion that in order to use maxSigLife at
all we would have to limit the range of accepted values for maxSigLife to be very small, and (more
importantly) change registrar behavior whenever signing policy was modified. For registrars, they
must be in synch with our signing policy, which made this another invitation for pedal removal via firearm.
Our current implementation supports maxSigLife, but an upcoming build of ours will indeed ignore it.
I agree that multiple maxSigLife elements should return an error. Not specifying maxSigLife should
default to server policy. As stated, we are moving towards having any MaxSigLife also default to default
server policy.
But, not everyone will agree with our choice here, so let me evaluate the options you suggest:
(1) I'm not sure that either error code you suggest provides a good indication of the problem back to the
client. 2004 is really misleading, and not indicative of the problem. Perhaps 2308 "Data management
Policy Violation" may be closer (although if this is required via this specification, then it's hardly
server policy)?
I like the use of the word MUST (be see my option (4) below) for multiple maxSigLife elements in a single
domain object, since one RRSIG will be used across the DS RRset anyway.
(2) I'm not crazy about this at all. maxSigLife is "metadata" for a DS record, so it belongs there. If you do
(1) or (4), then it's much cleaner.
(3) No. This reduces functionality, and although I'm not going to use it, others may. (I'm sure others on the
list will do better than I at recalling the rationale for maxSigLife, but it escapes me for now).
Option 4: If multiple maxSigLife values are requested, the server MAY use the smallest maxSigLife value
received. This could, of course, be setup as server policy, leaving it open in this specification, but at
least this gives guidance for server implementors.
-Howard
On Jan 31, 2010, at 9:23 AM, James Gould wrote:
> Michael & Howard,
>
> Do either you have thoughts related to the maxSigLife attribute in RFC 4310?
> In review, the AD had the following comment to the draft:
>
>>> An OPTIONAL <secDNS:maxSigLife> element that indicates a child's
>>> preference for the number of seconds after signature generation
>>> when the parent's signature on the DS information provided by the
>>> child will expire. A client SHOULD specify the same <secDNS:
>>> maxSigLife> value for all <secDNS:dsData> elements associated with
>>> a domain. If the <secDNS:maxSigLife> is not present, or if
>>> multiple <secDNS:maxSigLife> values are requested, the default
>>> signature expiration policy of the server operator (as determined
>>> using an out-of-band mechanism) applies.
>>
>> I am slightly surprised that the latter is not an error condition.
>> But if this what people have implemented, then Ok.
>
>
> I agree that at a minimum the server should return an error instead of
> applying the server default when multiple maxSigLife values are requested.
> To address this I have the following options. I would like to hear from
> anyone using the maxSigLife attribute or planning on using the maxSigLife
> attribute.
>
> 1. Keep the maxSigLife as an element of secDNS:dsData or secDNS:keyData.
> Update the text to require the server to return an 2305 “Object association
> prohibits operation” or 2004 “Parameter value range error” error when
> multiple maxSigLife values are requested. I’m leaning towards the 2004
> error. I would also recommend that we change “A client SHOULD specify the
> same <secDNS:maxSigLife> value” to “A client MUST specify the same
> <secDNS:maxSigLife> value”, since I don’t know the use case where the value
> could be different per DS.
> 2. Move the maxSigLife element out of the secDNS:dsData and secDNS:keyData,
> so that it can be set as a single value for a domain. The maxSigLife
> applies to the RRSIG, so it doesn’t make much sense to set it at the DS
> level. This would mean that maxSigLife would be an optional element
> directly under secDNS:create, secDNS:update, and secDNS:infData. This
> breaks backward compatibility, but backward compatibility is already broken
> by changing the URI.
> 3. Remove the maxSigLife element all together. This doesn’t sound like much
> of an option if there are servers using it. This breaks backward
> compatibility, but backward compatibility is already broken by changing the
> URI.
> 4. Update the text to allow for different maxSigLife values without the
> server applying the default. If we allow for multiple maxSigLife values I
> don’t believe it is correct for the server to return a successful response
> and then pretty much ignore the requested values.
>
> If there are any other options for this or if there are preferences to the
> options I proposed above, please respond to the list or to me privately.
>
> Thanks,
>
> --
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> jgould <at> 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: Andrew Sullivan <ajs <at> shinkuro.com>
> Date: Sun, 31 Jan 2010 03:59:29 -0500
> To: EPP Provreg <ietf-provreg <at> cafax.se>
> Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
>
> On Fri, Jan 29, 2010 at 10:15:13AM -0500, James Gould wrote:
>> Is there anyone out there supporting or planning on supporting the client
>> specified maxSigLife. In looking into this in more detail if this attribute
>
> Afilias supports it now, IIRC.
>
> A
>
> --
> Andrew Sullivan
> ajs <at> shinkuro.com
> Shinkuro, Inc.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to ietf-provreg-request <at> cafax.se
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to ietf-provreg-request <at> cafax.se
RSS Feed