[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: <Ray.Bellis@nominet.org.uk>
CC: EPP Provreg <ietf-provreg@cafax.se>
From: James Gould <jgould@verisign.com>
Date: Fri, 29 Jan 2010 10:15:13 -0500
In-Reply-To: <OF290E454A.30980263-ON802576B9.00576302-802576B9.0057F86A@nominet.org.uk>
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcqgMxyUZt5wcbEwS8urg3QSuo1DmgAwr4ci
Thread-Topic: [ietf-provreg] rfc4310bis 03 AD Feedback
User-Agent: Microsoft-Entourage/12.23.0.091001
Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback

Title: Re: [ietf-provreg] rfc4310bis 03 AD Feedback
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
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: <Ray.Bellis@nominet.org.uk>
Date: Thu, 28 Jan 2010 11:00:52 -0500
To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
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: ray@nominet.org.uk, t: +44 1865 332211




Home | Date list | Subject list