Re: [lamps] Renewing (short lived) certs with EST (RFC7030) [was: Re: Sean: Permissibility of expired cert renewal]

Jim Schaad <ietf@augustcellars.com> Thu, 30 August 2018 17:25 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8567C130DE8; Thu, 30 Aug 2018 10:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 mSaiLRwDooqo; Thu, 30 Aug 2018 10:25:31 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1946130DE6; Thu, 30 Aug 2018 10:25:30 -0700 (PDT)
Received: from Jude (192.168.1.157) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Aug 2018 10:21:12 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Michael Richardson' <mcr+ietf@sandelman.ca>, 'Sean Turner' <sean@sn3rd.com>
CC: <spasm@ietf.org>, <draft-ietf-anima-bootstrapping-keyinfra@ietf.org>, 'Toerless Eckert' <tte@cs.fau.de>
References: <20180719212936.mroidiansyiurjra@faui48f.informatik.uni-erlangen.de> <FE5CF951-6501-4751-8C3B-AB414A14A930@sn3rd.com> <20180723194623.7niwhsz4tnigwern@faui48f.informatik.uni-erlangen.de> <E108AC10-C65A-4D97-B3CD-C4CF638F6297@sn3rd.com> <19312.1535640189@localhost>
In-Reply-To: <19312.1535640189@localhost>
Date: Thu, 30 Aug 2018 10:25:00 -0700
Message-ID: <051f01d44086$639dac60$2ad90520$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJs0N/D/l5NoTpYLg93tf6KU6JktQGtF0yUAqwrFxwB3DikzQGoMb9Ao2h8upA=
Content-Language: en-us
X-Originating-IP: [192.168.1.157]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/EjOYvWuf_4-HyEWjarQdprFObXU>
Subject: Re: [lamps] Renewing (short lived) certs with EST (RFC7030) [was: Re: Sean: Permissibility of expired cert renewal]
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 17:25:34 -0000

One of the issues that you need to make sure to include is that revocation information must be kept by the EST server until the point in time that the expired certificate would not be permitted to be used for authentication.  There is currently on a requirement that this information be kept by the server until "the first CRL after the certificate expired as been issued."  

Jim


> -----Original Message-----
> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Thursday, August 30, 2018 7:43 AM
> To: Sean Turner <sean@sn3rd.com>
> Cc: spasm@ietf.org; draft-ietf-anima-bootstrapping-keyinfra@ietf.org; Toerless
> Eckert <tte@cs.fau.de>
> Subject: Re: [lamps] Renewing (short lived) certs with EST (RFC7030) [was: Re:
> Sean: Permissibility of expired cert renewal]
> 
> 
> Sean Turner <sean@sn3rd.com> wrote:
>     >> Seems to leave 5280 as the existing doc standing in the way ?
>     >> If so, how to most easily fix this ?
> 
>     > I think what you’re after is an explicit statement that says you’re
>     > free to use an expired certificate to request a new certificate? If
>     > you’re looking for that to be added to RFC 5280 I’d say good luck
>     > because it’s policy specific thing.
> 
> I think that what we want to do is write a Security Considerations for renewing
> certificates using EST with an expired certificate as
> authentication.    We need to outline what kinds of policy might be required,
> and when it would be approrpriate not to accept specific certificates, or when it
> might be appropriate to accept no expired certificates (perhaps for an interval
> of time).  Or just how old (as a percentage of cert life) is too old.
> 
> I think that the threat case here is that devices are inappropriately disposed of
> (vulnerable to dumpster diving or ebay acquisition), with the assumption that
> the credentials are old and do not need to be wiped.
> Probably there are other threat cases that I have not thought of, and I think that
> the goal would be to write the threats down... ideally to give them names.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>