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


To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
From: Ray.Bellis@nominet.org.uk
Date: Thu, 28 Jan 2010 16:00:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1264694469; x=1296230469; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[ietf -provreg]=20rfc4310bis=2003=20AD=20Feedback|Date:=20Thu, =2028=20Jan=202010=2016:00:52=20+0000|Message-ID:=20<OF29 0E454A.30980263-ON802576B9.00576302-802576B9.0057F86A@nom inet.org.uk>|To:=20James=20Gould=20<jgould@verisign.com> |Cc:=20EPP=20Provreg=20<ietf-provreg@cafax.se> |MIME-Version:=201.0|In-Reply-To:=20<C787106F.3718F%jgoul d@verisign.com>|References:=20<C787106F.3718F%jgould@veri sign.com>; bh=c0XDG8atrhGU8AjxuNpOXp8pGIgu5xC5xeuxlcfUa+s=; b=F26rJPkW6Ucuo2yCHh/Od+9sJ1gAUzJNkLnJ/0ESMzh6yxylZxLz+uIx Uf+cJbnQ/NK2h37ShUYWjVtiJMFlyzMNPv//2Kg6Awgdnb1aQViGnQafs 2Y8eczlS6lj05Qf;
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=kiB2Q7rfiJGonGCNh4lvR4GfX3zbo4o514NKKcelRgV3CwUKpetrv9HN v7AaDETivo4gPFUGzWdNX/RoAzQNfD9VPZXZ8CFV5zd4NC/rlcH0t9sCk 4Cn7G1weCOyqqcv;
In-Reply-To: <C787106F.3718F%jgould@verisign.com>
Sender: owner-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