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

[Sean Turner <[e-mail]>]

> On Jul 23, 2018, at 15:46, Toerless Eckert <[e-mail]> 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 ([e-mail]) ]
> 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