IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 30 August 2018 14:43 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 7D806130E58; Thu, 30 Aug 2018 07:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tekYXvAiLu-Q; Thu, 30 Aug 2018 07:43:11 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA6312F1A6; Thu, 30 Aug 2018 07:43:11 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 599F920491; Thu, 30 Aug 2018 11:01:23 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A36BEB32; Thu, 30 Aug 2018 10:43:09 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A070E2D; Thu, 30 Aug 2018 10:43:09 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Sean Turner <sean@sn3rd.com>
cc: Toerless Eckert <tte@cs.fau.de>, spasm@ietf.org, draft-ietf-anima-bootstrapping-keyinfra@ietf.org
In-Reply-To: <E108AC10-C65A-4D97-B3CD-C4CF638F6297@sn3rd.com>
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>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 30 Aug 2018 10:43:09 -0400
Message-ID: <19312.1535640189@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/yqfLsvxpKfFFqxxRSE26-UwVUfI>
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 14:43:13 -0000

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>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email