Certificate renew / rekey / update in CP and CPS


#1

I thought I should read some more documentation and so I opened the CPS document to find out what was LE audited against.

I got quickly confused though. CPS defines:

  1. “renew” as a procedure when a new certificate is issued for existing key, i.e., the key is not changed. Section 3.3.2.
  2. “update” (Section 3.3.3) when the identity must be re-established.
  3. Rekey is mentioned is unsupported.

When I open the CP document, it reads that “Update” is not supported. This leaves me with “renew” as the only operation.

What did I miss?


#2

Can you give me a hint as to what you are referring to with CP / CPS ? or a link to the document


#3

Well, each PKI system should have a set of documents, which describe how it operates. I believe these are also main documents for audit and they are also included in all CA certificates. The two I mentioned were:

  • Certificate Policy (CP); and
  • Certification Practice Statement (CPS) - this normally describes how the PKI operates procedurally.

I believe, not quite sure (got here from the X3 CA certificate, the main address is:
https://letsencrypt.org/repository/


#4

I agree that the CP and CPS are not consistent in their treatment of this scenario. I believe the reality is that Let’s Encrypt doesn’t do any of these things under section 3.3 (rekey, renew, update) for end entity (DV SSL) certificates going out to users, it basically just always ends up under section 3.2 identity to issue a certificate via ACME even though we talk here about “renewing” certificates, as far as these policy documents are concerned those are still new issuances.

However, the CA also issues a far smaller number of certificates, not via ACME, for administrative purposes. While there are few of them, the rules for them end up much more complicated and take up a lot of these documents. The auditors must inspect these too of course. So renewal in the CP / CPS sense might happen for those. Maybe @jsha can explain all the stuff I inevitably got wrong above.


#5

As part of our partnership with IdenTrust for our cross-sign, we adapted their CP and CPS to our use case, with permission. We modified them a lot in the process, to make them describe our model better, but in some places they are confusing, for instance in the renewal sections. As a practical matter, to renew a certificate with ACME / Let’s Encrypt, you simply request a new certificate. This does match with the description in the CPS, even though the CPS makes renewal sound like a special case. In a future revision of the CPS we’re hoping to clarify this and make it clearer that renewal is the same as issuing a new certificate.

There is provision for administrative certificates in the CPS, but Let’s Encrypt does not currently use them.


#6

thanks @jsha . If I understand correctly, you say that CPS doesn’t quite reflect the reality at the moment. The issue may however be a bit deeper as (assuming the CPS is the more accurate document) if you really implement the “update” only, you seem to violate the CPS definition here. I believe that Boulder doesn’t re-establish identity with each request but caches proofs for days. I assume this is where Authz validity comes to play.

I don’t say the implementation is wrong or insecure, but I struggle to match it with the CPS definitions. I hope the gap here is purely an administrative issue, although it can potentially have security implications.

Vaguely related. Are there any public documents that would describe cryptographic implementations, risk/threat analysis, or security reviews of protocol implementation?


#7

I think what all the language is trying to say (IANAL, so I’m not sure if it is successful at doing that :smile:) is that the CA doesn’t support updating, rekeying or renewal operations as such, but rather that all those operations trigger what’s described in section 3.2 (which essentially boils down to “We’ll do what the BRs say” - and those allow reusing authorizations for up to 39 months). In that sense, the CP and CPS reflect the reality (as boulder doesn’t have a dedicated “renew” endpoint either).

There’s tons of discussion on the ACME WG mailing list. For example, someone created a formal model of ACME, see mailing list discussion and relevant code.


#8

Ok, that makes sense. I didn’t find the word “reuse” or plural of “certificate” in the BRs but just like you, IANAL.

Excellent. Thanks, wasn’t aware of that! I’ll try to get in touch with authors to find out what is a potential impact of this authorization caching on their models. I’m sorry but it still bothers me as a user.


#9

If it’s for your accounts - you can always deactivate authorizations ( which clears any authorization caching ) - I automatically do that on obtaining a certificate on many of my accounts.


#10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.