cp-cps
cp-cps copied to clipboard
letsencrypt
ISRG / Let's Encrypt CP and CPS Documents
The key types and key sizes seem in [section 6.1.5](https://letsencrypt.org/documents/isrg-cp-cps-v5.2/#6.1.5-key-sizes) seem, to me, to be better suited in [section 7.1](https://letsencrypt.org/documents/isrg-cp-cps-v5.2/#7.1-certificate-profile) certificate profile in the subject public key field.
Section 7.1: - Subordinate: remove "Let's Encrypt Authority X", as those intermediates have expired - DV-SSL: specify that we only accept 3 specific RSA key sizes - OCSP: remove this...
The BRs, Section 9.9, says "Thus, except in the case where the CA is a government entity, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for...
There is a foreseeable future where our long-lived certs have revocation information provided only via CRL, and our short-lived certs have no revocation information at all. To prepare for this...
In Section 6.1.4 we say "Public Keys are provided to Relying Parties as part of browser, operating system, or other software trusted root certificate lists". This is true for our...
Sections 3.1.3, 3.2.2, and 4.9.2 all use the term "FQDN" to encompass all possible identifiers that can be in a certificate's Subject and SAN extension. These will need to be...
See https://community.letsencrypt.org/t/inconsistency-between-subscriber-agreement-and-the-cp-cps/215079 for an example of how the language in the Subscriber Agreement and the language in the CP/CPS differ here. We have other sections which reference the SA with...
The current text is: > Applicants are required to prove possession of the Private Key corresponding to the Public Key in a Certificate request by signing the CSR provided to...
The Mozilla CA self assessment 6.1.7 Key usage purposes (as per X.509 v3 key usage field) states the following. When looking at our [CPS](https://letsencrypt.org/documents/isrg-cp-cps-v5.1/#7.1-certificate-profile), it's not explicitly clear which certificate...
We are required to update each of these documents at least once every 365 days. We should have a github action which runs periodically (monthly?), checks the last time the...