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 ([email protected]) ]
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 ?
Cheers
Toerless
> spt
>
> > On Jul 19, 2018, at 17:29, Toerless Eckert <[email protected]> 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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
