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

Sean Turner <> Thu, 30 August 2018 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43A7A130F11 for <>; Wed, 29 Aug 2018 18:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mKT4Xs4ro5_Y for <>; Wed, 29 Aug 2018 18:34:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2016130EEA for <>; Wed, 29 Aug 2018 18:34:37 -0700 (PDT)
Received: by with SMTP id j7-v6so8107843qtp.2 for <>; Wed, 29 Aug 2018 18:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BkNMRnDEf7kCDwlE93pI34m+uZWhooty8cEInL2MkSQ=; b=K+3qAtPKaZOa3JRdnoZhsnPzwjcWllMeHwJa7wndETlfPq0bITo73s3QkcBd6E7pM5 WN+0TUbZerdz4JhYq8Z1bJtadl2cEPTcXhBduHpysKnzy5GuZtRNzNLJ/MVeDFO6FFpS G5cEv0Kg8u9vUnBEqkOMR026511Bx5f68Lod8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BkNMRnDEf7kCDwlE93pI34m+uZWhooty8cEInL2MkSQ=; b=Mk0C7EyPmi9J9vBWl+M4y6LEM4h6JCoy2fSYkTlqBEMBBTgFJ8d+EJLCAEwBNrd/K1 ybjeL3AtBClervpgSmhnxC3J2CnWA8kpQKRfy8Y9y/ny4ND8uyfP2rjTZv2K/8e+O+X7 kGAwPsXhhWX4ABAPxKSUp7npJtUAWchPKTMy8FPGG9Y3A9tS4IpEZPHVOxRN+gqypiiF RPLVabD7BkHuTbSgvtpyi2G7hdZybuoiK/EHw4rrLKi6T6Gdh0gQph9aaE0T8o2vaVoF SvBowljGUa11z+izWTwd6iQMrYGEyamfIy4oLLAMOvuI3d09n6DymOMTmhKakAMTG5+5 DDNQ==
X-Gm-Message-State: APzg51BULaR4Bw5g770RJp8tE+1QAQHkanpZ8Cyaac3vu6TWdaf3qPzL FvXyNlZjM4rDVgcRyg7MVXO0JA==
X-Google-Smtp-Source: ANB0VdbkyvZHfUTttm6l9SGlNoPg1GUSkgEpXA0HmeBzknQeO9vtw2Zveo++U7wAmK77xUqKx6/ZxA==
X-Received: by 2002:a0c:d7c3:: with SMTP id g3-v6mr9145745qvj.85.1535592876860; Wed, 29 Aug 2018 18:34:36 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id r67-v6sm2977618qkd.10.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 18:34:35 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Sean Turner <>
In-Reply-To: <>
Date: Wed, 29 Aug 2018 21:34:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Toerless Eckert <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [lamps] Renewing (short lived) certs with EST (RFC7030) [was: Re: Sean: Permissibility of expired cert renewal]
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Aug 2018 01:34:53 -0000

> On Jul 23, 2018, at 15:46, Toerless Eckert <> wrote:
> 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 ( ]
> 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:
>  (inline)
> 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 ?

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.