Re: [sidr] Erratum for RFC6486? (manifests)
Tim Bruijnzeels <tim@ripe.net> Fri, 19 July 2013 12:34 UTC
Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6FE11E8124 for <sidr@ietfa.amsl.com>; Fri, 19 Jul 2013 05:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3Cz7RgD0srH for <sidr@ietfa.amsl.com>; Fri, 19 Jul 2013 05:34:32 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id D861111E8123 for <sidr@ietf.org>; Fri, 19 Jul 2013 05:34:31 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1V09tB-0007wg-Qi; Fri, 19 Jul 2013 14:34:28 +0200
Received: from puppy.ripe.net ([193.0.1.230] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1V09tB-0001eG-Ob; Fri, 19 Jul 2013 14:34:25 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <51E6D5FF.6030802@bbn.com>
Date: Fri, 19 Jul 2013 14:34:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <23E19953-DFC2-4331-B497-60BC0FFDEB37@ripe.net>
References: <A4234F86-EC27-4EB5-B988-D61019E80A7B@ripe.net> <51E6D5FF.6030802@bbn.com>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1508)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130719 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719f56fbf8f1b4b74f91777f83b4ba8f909
Cc: Sandra Murphy <Sandra.Murphy@sparta.com>, "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] Erratum for RFC6486? (manifests)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 19 Jul 2013 12:34:38 -0000
Hi Steve, I think we agree for the most part on the idea to remove the restriction for single use EE certificate. To quote and answer to the end of your mail first: Sandy, I am not sure, but this may be short topic for one of the sessions. Especially if we want to say anything about best practices for CAs. > So, while I believe that there is no need to change the 5.1 text based on the > RP concern you cited, I support a change to that text to allow CAs more > flexibility in managing the EE cert validity in manifests, and to remove the > single-use vs. sequential-use EE cert distinction. > > Would you like to propose and share text for the suggested change? We may have to > issue a new RFC, updating 6486, since this does represent a technical change to > how we say a CA should behave. I proposed to change this text in section 5.1: In the case of a "one-time-use" EE certificate, the validity times of the EE certificate MUST exactly match the thisUpdate and nextUpdate times of the manifest. In the case of a "sequential-use" EE certificate, the validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate. To: The validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate. That said I think there are quite a few details left that are worth discussing. > Section 5.1 of RFC 6486 is titled "Manifest Generation Procedure." This it is a set of directions to the CA creating the manifest, not directions to an RP verifying a > manifest. Section 6 is the discussion of what a relying party is supposed to do with a manifest. My quick re-read of Section 6 does not call for an RP to check that the validity time is consistent with the single-use vs. sequential-use EE cert criteria in 5.1. So, the primary concern you cited, i.e., that an RP cannot know which test to apply, is not a valid > reason to change this text. Although I agree in general with the approach to "be strict in what you send, and liberal in what you accept" I just found this instance confusing. It was not 100% clear to me if I should care as an RP. In any case, I am happy to remove this check, and only care about valid, stale, invalid.. > I agree that the invalid vs. stale disparity that arises because of the directions to > CAs on manifest EE cert generation is an awkward one. > Your example of a manifest with > a planned daily update, but a cert that is valid for a week, is an reasonable operational > model. If RPs continue to fetch data based on what has changed, then a manifest that is > slated to change, but doesn't, doesn't impose an addition sync load. If an RP were to > fetch data based on when it says it will expire, then this might be less desirable. So > we might take that into consideration when suggesting this model. As I understand there are three cases with regards to stale and invalid based on time (ignoring other cases): -1 Manifest is current = now is after thisUpdate and before nextUpdate && = now is within EE Certificate validity time -2 Manifest is stale = now is after nextUpdate = now is within EE Certificate validity time -3 Manifest is invalid = now is outside of (after) EE Certificate validity time The current text allows for all three states to exist for multi-use EE certificates, but only 1 and 3 can exist for single use. I want remove this restriction, because RP treatment of "stale" is different from "invalid", and as a CA I want to be able influence this. > If we had guidelines for best practices for pub point management, with suggested > rates of change, we might better understand the possible impact of this operational > model. For example, if the recommended frequency of CRL issuance is daily, then the > manifest ought to change daily as well, the there's a decent chance that the CRL and > the manifest are either both stale or current. I agree that best practices would be good, both for CA and RP. Is this something to discuss shortly? As a start… W.r.t. RP: - I would advise against fetching new manifests based on the expiry of the EE cert if that date is after the nextUpdate. - I would advice that RPs fetch new data at least in advance of the - I think RPs are free to poll more frequently …. W.r.t. CAs: - I would advise to limit the nextUpdate time to a window that forms the 'optimal compromise' between: - being overrun by RPs trying to get new data - workload of generating new certificates - too slow propagation times for new products - to -router - The RIR implementations all use 24 hours I think, this seems reasonable. - I would advise that longer EE certificate time should be used to prevent that manifests are immediately invalid if RPs only fetch close to the nextUpdate time, and are unsuccessful for whatever reason Al that is best current practice for the current implementation. I think that a faster notification mechanisms and propagation times are a real need expressed by operators and should be addressed in future work. Tim
- [sidr] Erratum for RFC6486? (manifests) Tim Bruijnzeels
- Re: [sidr] Erratum for RFC6486? (manifests) Rob Austein
- Re: [sidr] Erratum for RFC6486? (manifests) Stephen Kent
- Re: [sidr] Erratum for RFC6486? (manifests) Tim Bruijnzeels
- Re: [sidr] Erratum for RFC6486? (manifests) Murphy, Sandra
- Re: [sidr] Erratum for RFC6486? (manifests) Stephen Kent