Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs

Sean Turner <sean@sn3rd.com> Fri, 13 January 2017 01:16 UTC

Return-Path: <sean@sn3rd.com>
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 3D6B1129620 for <sidr@ietfa.amsl.com>; Thu, 12 Jan 2017 17:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 RDmbNIsGLU3E for <sidr@ietfa.amsl.com>; Thu, 12 Jan 2017 17:16:26 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6749129613 for <sidr@ietf.org>; Thu, 12 Jan 2017 17:16:25 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id s140so40025025qke.0 for <sidr@ietf.org>; Thu, 12 Jan 2017 17:16:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/lIs2gVJyn+d5/l2v2Fu2VFbsxAtm55ksIJrjBhKY1M=; b=AMGr0/haCbx9i06vjKd7Is6CCS+fkYqITpOjzoUlYPBo9nTLrlM8zo5LdkLZJQRIr0 gdtY4HTQU3oN8DegW+hHu1ojJnAv+nhSyr1Nf6/+5o51Vd4okBZH1cgHn2WyWFXLrzDe f037BJenyTJjuzZdew+PHG8mcQMtGKhbqqllk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/lIs2gVJyn+d5/l2v2Fu2VFbsxAtm55ksIJrjBhKY1M=; b=XC1m+UBb65UeQFNhQgaZ2n+AZZvSylKDr51/pGUb6ZqEzzk7Aryj+HXHBCRPLmt+VJ /fwQIri3bEZLpaR0nmCvpAGaoANaEbJpgzeekKTbfJw4i96jXyNZxj66kGOh7YNJoiax 2z6/CLCNYZauBjMBXzwR5BIptA5JuCBSDAOrDidK17GR3SP7yW9s5KkQdd7X6ON8V+Q/ v8JiNk5DczX3YR2HuU/vaerZ5TQH4CToyX5pKems3Zca75Zatowp0dLp9a8gr9oKMacL md+F7/pB6YTZZ0/csW/JiYxLASwkRjg3K9oqGllokrlxNIzaU2lOM/eF7peYLqiYNxHC Ro+Q==
X-Gm-Message-State: AIkVDXK5sVjBP+LzhLwkopTLcGnr3wxNwZEeWjTzWR7ROb5/PF9bu41tGo0ixGz0FfrBxQ==
X-Received: by 10.55.100.88 with SMTP id y85mr15295835qkb.194.1484270185018; Thu, 12 Jan 2017 17:16:25 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id i41sm8024122qtc.18.2017.01.12.17.16.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 17:16:24 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <m24m13j4d8.wl-randy@psg.com>
Date: Thu, 12 Jan 2017 20:16:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD41EC7C-67B8-4CB0-A113-6D0FC408B994@sn3rd.com>
References: <2459DA8D-593F-4B75-9C74-619DDBA907E4@nist.gov> <m27f60ie53.wl-randy@psg.com> <DCCE4A71-87F8-4A8A-A561-202F6331DC93@nist.gov> <m24m13j4d8.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/IUqgqHHiLWMCwAWEqoa8gzGW0bw>
Cc: sidr list <sidr@ietf.org>
Subject: Re: [sidr] IPv4 examples for draft-ietf-sidr-bgpsec-pki-algs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Jan 2017 01:16:27 -0000

> On Jan 12, 2017, at 17:33, Randy Bush <randy@psg.com> wrote:
> 
> mornin' oliver,
> 
>> This most likely would set a bad example for others that might start
>> issuing certificates with “infinite” life spans.
> 
> 'zactly
> 
>> In this regards what about a Validity of 365 days within the
>> example. This seems feasible to me.
> 
>>> of course that leaves open what lifetime to recommend.  we're not
>>> gonna do oscp, but rather withdraw from the rpki.  so to keep from
>>> making too much bgp noise, let me toss out O(year) to start the
>>> discussion.
> 
> i can live with a year.  i will be interested if others comment.
> 
> i have a vague memory of talking about this before.  one needs to deploy
> the replacement key in advance, as it can take some time to propagate to
> the far corners of the internet.  and one probably does not want to
> reannounce all one's routes at once.
> 
> a small i-d may be in order.

The CPS really dictates the validity period.  Can you check what your RIPE issued RPKI certificates have as a validity date?

You’re right that you need to get the replacement cert early to make sure you don’t end up being without a certificate.  RFC 6484 recommends 1 week prior to the expiration of the old cert.  I think the CPS also allows some addition time to account for this problem.

spt