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

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
Thread-Index: AQJs0N/D/l5NoTpYLg93tf6KU6JktQGtF0yUAqwrFxwB3DikzQGoMb9Ao2h8upA=
Content-Language: en-us
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]
Precedence: list

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

[lamps] Renewing (short lived) certs with EST (RF… Toerless Eckert
Re: [lamps] Renewing (short lived) certs with EST… Sean Turner
Re: [lamps] Renewing (short lived) certs with EST… Sean Turner
Re: [lamps] Renewing (short lived) certs with EST… Michael Richardson
Re: [lamps] Renewing (short lived) certs with EST… Jim Schaad
Re: [lamps] Renewing (short lived) certs with EST… Sean Turner
Re: [lamps] Renewing (short lived) certs with EST… Michael Richardson