Re: [ietf-provreg] rfc4310bis 03 AD Feedback

[James Gould <jgould@verisign.com>]

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@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@shinkuro.com>
Date: Sun, 31 Jan 2010 03:59:29 -0500
To: EPP Provreg <ietf-provreg@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@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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