Re: rfc4310bis 03 AD Feedback

James Gould <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <C78865B1.371EC%[email protected]>
Is there anyone out there supporting or planning on supporting the client
specified maxSigLife.  In looking into this in more detail if this attribute
were supported, doesn¹t it make more sense for it to be an attribute outside
the dsData or keyData, since it applies to the domain¹s RRSIG and not to an
individual DS?  This means that it¹s an attribute of the domain and not of
the DS.  Since we¹re not worried about backward compatibility any longer
with the change in the URI we¹re open to remove or move this element.  Any
thoughts to this?  

-- 


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: Thu, 28 Jan 2010 11:00:52 -0500
To: James Gould <[email protected]>
Cc: EPP Provreg <[email protected]>
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback


>   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

Please forgive my ignorance, as I wasn't around when 4310 was written.

What's the rationale for giving the child _any_ say in the DS record
signature lifetimes as presented in the parent zone?

kind regards, 

Ray 

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email protected], t: +44 1865 332211
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.