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 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.
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.
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?
I think what all the language is trying to say (IANAL, so I'm not sure if it is successful at doing that ) 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).
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.
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.
) 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).