[sidr] Erratum for RFC6486? (manifests)
Tim Bruijnzeels <tim@ripe.net> Tue, 16 July 2013 09:39 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 F1B9E21E81DE for <sidr@ietfa.amsl.com>; Tue, 16 Jul 2013 02:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 SmP-VnYpcrdP for <sidr@ietfa.amsl.com>; Tue, 16 Jul 2013 02:39:48 -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 8AF3B11E8294 for <sidr@ietf.org>; Tue, 16 Jul 2013 02:39:40 -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 1Uz1jN-0004Zy-Rt for sidr@ietf.org; Tue, 16 Jul 2013 11:39:39 +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 1Uz1jN-0002Xr-OQ for sidr@ietf.org; Tue, 16 Jul 2013 11:39:37 +0200
From: Tim Bruijnzeels <tim@ripe.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_769C3106-B707-4CFA-8065-01C87B36EF63"
Message-Id: <A4234F86-EC27-4EB5-B988-D61019E80A7B@ripe.net>
Date: Tue, 16 Jul 2013 11:39:39 +0200
To: "sidr@ietf.org list" <sidr@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130716 clean
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points: -3.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 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] 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071955ec1022733c6040981d63e7137650fe
Subject: [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: Tue, 16 Jul 2013 09:39:53 -0000
Dear WG, RFC6486 has this to say about the validity times of EE certificates in manifests: http://tools.ietf.org/html/rfc6486#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. This causes some issues for our RP software, and I believe it would be better to remove the difference between one-time-use and sequential-use here, and go with something like this instead: The validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate. Reasons: 1) RP can not distinguish between one-time-use and sequential-use RPs don't know which case they are dealing with, and guessing is error-prone. So, in our case we are checking for a condition we don't know how to handle, and in the end we just warn about it.. I am happy to remove this confusing warning, but then what's the point of limiting this in the RFC? 2) Stale vs expired manifests See sections 6.3 and 6.4. If a manifest EE certificate is expired, then the manifest is invalid. However, if the EE certificate is still valid, but it's past the "nextUpdate" time, then it should be considered "stale". The restriction in 5.1 prevents that manifests with one-time-use EE certificates can have this stale state. Yet, this is something a CA may well want to use, e.g.: - issue EE certificate validity time of 1 week - nextUpdate time 1 day The idea being that under normal circumstances a new manifest would be issued within 24 hours (or less), and RPs should use the *latest* manifest available to them, but… in case the RP can't reach the repository, or there is an outage, stale manifests could be used for some time (per local policy of RPs). We currently allow users to accept stale manifest for X days (default = 0 days). To circumvent the issue that one-time-use EE certs would be invalid as soon as they go stale we also accept expired manifest for the same time.. I think this is wrong (e.g. CAs will no longer mention the EE cert on the CRL if it's expired), and again I am more than happy to remove this hack.. In short: I think CAs should have the freedom to choose longer validity times for one-time-use EE certificates. As far as I know *all* implementations use one-time-use anyway, so if this is not permitted, then the difference between 6.3 and 6.4 becomes moot in practice. Cheers 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