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

Toerless Eckert <tte@cs.fau.de> Mon, 23 July 2018 19:46 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DD044130F0A; Mon, 23 Jul 2018 12:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FH5QrItoOSJT; Mon, 23 Jul 2018 12:46:27 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754E3130EE2; Mon, 23 Jul 2018 12:46:27 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 46C0D58C4AF; Mon, 23 Jul 2018 21:46:23 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 33F6E4402CB; Mon, 23 Jul 2018 21:46:23 +0200 (CEST)
Date: Mon, 23 Jul 2018 21:46:23 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Sean Turner <sean@sn3rd.com>, spasm@ietf.org
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org
Message-ID: <20180723194623.7niwhsz4tnigwern@faui48f.informatik.uni-erlangen.de>
References: <20180719212936.mroidiansyiurjra@faui48f.informatik.uni-erlangen.de> <FE5CF951-6501-4751-8C3B-AB414A14A930@sn3rd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FE5CF951-6501-4751-8C3B-AB414A14A930@sn3rd.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/jD6pUsijtMxWQLWxzMRJbMmHIL4>
Subject: [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: Mon, 23 Jul 2018 19:46:30 -0000

Thanks, Sean

Let me add the LAMPS working group mailing list so we have more eyes on this.
[Bcc anima WG mailing list so WG members interested in this disus can subscribe to LAMPS
 WG mailing list (spasm@ietf.org) ]
Inline replies/Q's to your analysis at the end of this mail.

To repeat and expand the goal of this discussion from what i was saying that
the LAMPS mike in IETF102:

- In ANIMA draft-ietf-anima-autonomic-control-plane (ACP), we use EST (RFC7030)
  to renew certificates. We would like to make installations with short-lived
  certificates work reliable, but devices may be disconnected longer than
  the short-lived time, so renewal may only happen after the cert is expired.

- In the ANIMA WG, we seem to not be clear on the rules for renewing expired certs.
  RFC7030 section 3.3.2 sounds as if it mandatory for the EST server to
  validate the client certificate according to RFC5280, so we where concluding
  that an expired client certificate might not be something that the client
  could use if he wanted to comply to all IETF PKIX regulations.
  [ technically it would of course be fine to us the expired client certificate,
  and it might be necessary to use it because for renewals, the certificate
  to be renewed must be carried in the TLS authentication (if i understand it
  correctly, it would not be re-signaled inside the EST connection because
  the EST server wants to have prof of posession of the cert by the client,
  and thats done by TLS and does not need to be duplicate). ]

- Yaron reminded me that in draft-ietf-acme-star certificates renewed certificates
  are not handled as an entity that requires authentication of the recipient
  but instead something that can be pre-created and cached in various places
  to overcome problems with nomadic connectivity. This to me looks like
  quite different from the approach by EST.

- My thinking is somewhat in the middle between what i think EST says and what
  draft-ietf-acme-star says:

  - In EST, you do want identification with the pre-existing (expired) certificate.
  - The proof of posession of the expired certificate can help the registrar
    to determine aliveness of the client and reset any policy that could exist
    to determine whether the client is dead (after a long enough period of time)
    and stop reneweing certificates.
  - The proof of posession is also necessary IMHO when rekeying is required.

- Which brings us back to Seans analysis of existing PKIX texts:

On Mon, Jul 23, 2018 at 08:08:10AM -0400, Sean Turner wrote:
> Toreless,
> I do not believe there is any prohibition against the use of expired or even revoked certificates for renew/rekey in the PKIX suite of RFCs.

That wold be great.

> The path validation algorithm in 5280 does consider whether the certificate is revoked/expired, but does hard fail on that status.

But that would contradict your above statement, would it not ? With RFC7030
3.3.2 requiring RFC5280, it would have to fail for expired certificates. No ?

> There???s nothing in the management protocols 2986 (PKCS#10), 5272 (CMC), and 4210 (CMP) about it either.

Ok, so we can ignore those docs ;-)

> But, the real reason it might be allowed is based on the CP (Certificate Policy) and that follows 3647; this RFC does have sections on "Identification and authentication for re-key after revocation???; I say ???might??? here because it is a policy decision (some CPs I???ve written allow it some do not).

Ok, so RFC3647 does seem to not describe the case of a purely 
expired certificate, but just the re-keying of a certificate that
was revoked, and even in that case it would be permitted based
on a policy, so it would be ok.

Seems to leave 5280 as the existing doc standing in the way ?
If so, how to most easily fix this ?


> spt
> > On Jul 19, 2018, at 17:29, Toerless Eckert <tte@cs.fau.de> wrote:
> > 
> > Sean,
> > 
> > wrt to the reply you gave me in Lamps wrt to:
> > "Do existing authoritative IETF PKIX documents permit to use expired
> > certificates as authentication for certificate renewal"
> > 
> > Could you please point us to the reference that you mentioned whether
> > or not this is allowed by current PKI standards ?
> > 
> > Note that specifically in the case of BRSKI, we are talking about
> > using an expired client cert in a TLS connection to an RA, so that
> > TLS connection would only be used for renewal.
> > 
> > Aka: I am not even sure if the expired cert would need to be "permitted"
> > for this operartion by a PKIX document and/or by TLS.
> > 
> > To me this is key missing piece to make ANIMA enrollment/renewal
> > rock-solid in the face of non-contiguous full reachability of RA/CA.
> > 
> > If we know and can point to how this is permissible it should
> > be simple for us to have short informative text explaining this
> > crucial option.
> > 
> > Thanks!
> >    Toerless