Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS)
Sandra Murphy <sandy@tislabs.com> Fri, 11 December 2015 17:42 UTC
Return-Path: <sandy@tislabs.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC41A904F; Fri, 11 Dec 2015 09:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgYbUjK-orgj; Fri, 11 Dec 2015 09:42:09 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD2A1B2DA9; Fri, 11 Dec 2015 09:42:09 -0800 (PST)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id CA57928B003D; Fri, 11 Dec 2015 12:42:08 -0500 (EST)
Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 90C9A1F8051; Fri, 11 Dec 2015 12:42:08 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9C2C0F1F-A5E4-413E-8E2F-7036C0D55EA9"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <34A163BE-44D1-4994-AEFA-9F09CD0C28AE@tislabs.com>
Date: Fri, 11 Dec 2015 12:41:42 -0500
Message-Id: <B611CB8E-1601-48DF-80B2-4550521891CD@tislabs.com>
References: <20151118020907.790.34242.idtracker@ietfa.amsl.com> <938892D5-919F-4C61-B518-7145CB40A05B@tislabs.com> <D274CFE7.7267B%terry.manderson@icann.org> <34A163BE-44D1-4994-AEFA-9F09CD0C28AE@tislabs.com>
To: sidr <sidr@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/iGvKYRpgFvzorBGuDQSaYvs1rmI>
Cc: "draft-ietf-sidr-rfc6485bis@ietf.org" <draft-ietf-sidr-rfc6485bis@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, Sandra Murphy <sandy@tislabs.com>
Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rfc6485bis-04: (with DISCUSS)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2015 17:42:11 -0000
On Dec 5, 2015, at 12:29 AM, Sandra Murphy <sandy@tislabs.com> wrote: > The AD, the chairs and the authors have discussed the draft change suggested below. > > To summarize: The language Terry’s DISCUSS objects to is SHOULD recommendations of how to handle algorithm transitions, and being SHOULD only, leads to potential differences in implementation and operation choice. RFC6916 made much more stringent descriptions of algorithm transition and mandates certain actions. RFC6916 was published a year after RFC6485 and rfc6485bis attempts to meld the two by pointing to it, but leaves the SHOULD language in place. > > The decision of AD, chairs and authors is that the wg consensus for rfc6485bis was focussed on the OID problem, so it could not be said that this section was carefully considered by the wg. > > So the draft draft-ietf-sidr-rfc6485bis-04 is being returned to the wg to address this problem and then to do a wglc (and IETF Last Call) before it is returned to the IESG. > > > —Sandy, speaking as one of the co-chairs speaking as document shepherd. This message is intended to spark discussion. Terry agreed that his preference is to remove the SHOULD language. He did not insist that this was the only way to go. >>> >>> >>> >>> Would you prefer that RFC6485bis remove the inherited ³SHOULD² language >>> and point only to RFC6916? >> >> Yes, That is certainly one way to address this. And I would be OK with >> that. >> > If we did do that, it could look like: OLD It is anticipated that the RPKI will require the adoption of updated key sizes and a different set of signature and hash algorithms over time, in order to maintain an acceptable level of cryptographic security to protect the integrity of signed products in the RPKI. This profile should be replaced to specify such future requirements, as and when appropriate. Certification Authorities (CAs) and RPs SHOULD be capable of supporting a transition to allow for the phased introduction of additional encryption algorithms and key specifications, and also accommodate the orderly deprecation of previously specified algorithms and keys. Accordingly, CAs and RPs SHOULD be capable of supporting multiple RPKI algorithm and key profiles simultaneously within the scope of such anticipated transitions. The recommended procedures to implement such a transition of key sizes and algorithms is specified in [RFC6916] NEW It is anticipated that the RPKI will require the adoption of updated key sizes and a different set of signature and hash algorithms over time, in order to maintain an acceptable level of cryptographic security to protect the integrity of signed products in the RPKI. This profile should be replaced to specify such future requirements, as and when appropriate. The mandated procedures to implement a transition of key sizes and algorithms are specified in [RFC6916]. Comments? —Sandy, speaking as document shepherd and regular ol’ member
- [sidr] Terry Manderson's Discuss on draft-ietf-si… Terry Manderson
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Sandra Murphy
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Terry Manderson
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Sandra Murphy
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Sandra Murphy
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Sandra Murphy