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

Sean Turner <sean@sn3rd.com> Thu, 30 August 2018 01:34 UTC

Return-Path: <sean@sn3rd.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 43A7A130F11 for <spasm@ietfa.amsl.com>; Wed, 29 Aug 2018 18:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 mKT4Xs4ro5_Y for <spasm@ietfa.amsl.com>; Wed, 29 Aug 2018 18:34:38 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2016130EEA for <spasm@ietf.org>; Wed, 29 Aug 2018 18:34:37 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id j7-v6so8107843qtp.2 for <spasm@ietf.org>; Wed, 29 Aug 2018 18:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; 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; d=1e100.net; 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 [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id r67-v6sm2977618qkd.10.2018.08.29.18.34.35 (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 <sean@sn3rd.com>
In-Reply-To: <20180723194623.7niwhsz4tnigwern@faui48f.informatik.uni-erlangen.de>
Date: Wed, 29 Aug 2018 21:34:34 -0400
Cc: spasm@ietf.org, draft-ietf-anima-bootstrapping-keyinfra@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/VXCh7_MTdNouq0ezH1zmUd9OIBw>
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 01:34:53 -0000


> On Jul 23, 2018, at 15:46, Toerless Eckert <tte@cs.fau.de> 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 (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:
>  (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.

spt