Although we're required to maintain "a continuous 24x7 ability to
accept... revocation requests", we are not required to do so via any
particular interface. Our cert-prob-reports alias satisfies this
requirement, so we should not tie our own hands with regards to ACME
Revocation API availability.
5.1.8 & 6.2.1: Replace FIPS language with excerpt of BRs 6.2.7, allowing
Common Criteria EAL 4+ as an alternative to FIPS.
6.1.6: Remove mention of FIPS 186-4, which is not specifically required
by the BRs and was withdrawn on Feb. 3, 2024 in favour of FIPS 186-5.
6.2.10: Replace FIPS mention with more general language, borrowing a
phrase from 5.1.7.
---------
Co-authored-by: Josh Aas <jaas@kflag.net>
Co-authored-by: Aaron Gable <aaron@letsencrypt.org>
Rearrange information in Sections 4.9.2 and 4.9.3, to make it easier to
talk about differences between requesting revocation versus that request
being accepted. State that revocation requests for short-lived certs may
be ignored, regardless of how the request was received. In the two
places where we say we will revoke "all" certificates under certain
circumstances, update that to only include long-lived certs.
Fixes https://github.com/letsencrypt/cp-cps/issues/257
Remove all instances of "of this document"; bare section references
always point to this document. Wrap all internal section references in
hyperlinks, to make document navigation easier. Settle of saying
"Section X of the Baseline Requirements", rather than putting the
section number after the document name.
Fixes https://github.com/letsencrypt/cp-cps/issues/187
Minor formatting change from a tab to a space to make format consistent
with other headings.
Co-authored-by: Kristin Berdan <kberdan@abetterinternet.org>
To make it easier to collectively refer to both domain names and IP
addresses.
Fixes https://github.com/letsencrypt/cp-cps/issues/276
---------
Co-authored-by: Aaron Gable <aaron@letsencrypt.org>
The TLS Client Auth EKU will be omitted from Subscriber Certificates
issued under the "tlsserver" profile, and likely omitted from
Subordinate CA Certificates issued later this year to comply with
Chrome's "single purpose hierarchy" requirement.
Fixes https://github.com/letsencrypt/cp-cps/issues/260
RFC 3647 says that the key changeover section "describes the procedures
to provide a new public key to a CA's users following a re-key by the
CA. These procedures may be the same as the procedure for providing the
current key."
Since section 6.1 describes the procedures for generating and providing
the current CA keys to relying parties, it is a better reference than
section 2.2.
- Remove OCSP Delegated Responder profile, as we no longer issue such
certificates
- Remove restrictions on the Common Names we set
- Remove restriction on ECDSA P-521
- Improve descriptions of key sizes and checking routines
- Improve descriptions of algorithm identifiers
- Miscellaneous formatting and phrasing improvements
Fixes#185Fixes#196Fixes#212Fixes#213Fixes#217Fixes#218
- Move references to both the policy/legal repository and the
certificate repository into Section 2.2, matching the BRs
- Replace description of revocation advertisement with cross-reference
Fixes https://github.com/letsencrypt/cp-cps/issues/239
- Simplify 3.2.2 to more directly reflect the language used in that
section of the BRs
- Replace sections 3.2.3, 3.2.4, and 3.2.5 with "No applicable", because
Let's Encrypt does not need to perform authentication of individual
identity or validation of authority, and does not include non-verified
subscriber information in certificates
Note that this is the first use of "Not applicable." as full section
contents in this document. This feels more appropriate than "No
stipulation", as we are affirmatively stating that these sections do not
concern our operations, rather than saying simply that we choose not to
describe our operations in these sections.
Update Section 4.3.1 to mention our pre-issuance linting, which is now
required by the BRs. Also rephrase Section 8.7 to mention our
post-issuance (rather than pre-issuance) linting, in line with what that
section of the BRs cares about.
Fixes https://github.com/letsencrypt/cp-cps/issues/223
It is not the role of the CP/CPS to place restrictions on Subscriber
behavior, and we already have very similar language in the Subscriber
Agreement.
Fixes#205
RFC 3647 says that the key changeover section "describes the procedures
to provide a new public key to a CA's users following a re-key by the
CA. These procedures may be the same as the procedure for providing the
current key." As such, it's best to replace this section with a
reference to Section 2.2, which already describes how we publish our CA
public keys.
Fixes https://github.com/letsencrypt/cp-cps/issues/225
Section 3.1.2 is described by RFC 3647 as simply "Whether names have to
be meaningful or not", with a footnote defining "meaningful" as "the
name form has commonly understood semantics to determine the identity of
a person and/or organization."
By this definition our certificates -- neither CA certs nor end-entity
certs -- have "meaningful" names. We should accurately reflect this by
simply stating "no stipulation" and not placing any additional
requirements on ourselves.
Fixes https://github.com/letsencrypt/cp-cps/issues/224
Change the phrasing and capitalization of a few CP/CPS section headings
to exactly match those suggested by RFC 3647, Section 6. These section
titles will be mandatory as of 2024-09-15, per CA/BF Ballot SC-074.
Also add a new linting tool which enforces some of the requirements
imposed by Ballot SC-074. And fix the old "Test Tools" job, which was
broken because it only ran for PRs targeting "master".
* Remove CPS OID and URL from Subscriber Certificate profile
As of BRs version 2.0.0, the inclusion of policy identifiers beyond the BRs DV OID is optional, and the inclusion of CPS URL policy qualifiers for those identifiers is NOT RECOMMENDED. Remove these from our certificate profile, as we intend to remove them from our Subscriber certificates on June 15th.
* Make it optional, unify Subscriber and Subordinate CA language
* Trailing space
Co-authored-by: Andrew Gabbitas <agabbitas@letsencrypt.org>
* Update publication date
---------
Co-authored-by: Andrew Gabbitas <agabbitas@letsencrypt.org>
Create new combined CP/CPS based on existing CPS. The date will
be added in a future commit.
Leave the existing CP.md and CPS.md documents, and their supporting
infrastructure, in place. They will be removed or moved aside in a future
change.
* Section 1.1: Eliminate passive voice. Correct HTTP links to HTTPS.
* Section 1.2: Change "Certification Practices Statement" to use "Practice" singular, for consistency. Add revision information for these changes.
* Section 1.4.2: Add punctuation and "or" to alphabetical lists, for clarity.
* Section 1.5.1: Eliminate passive voice.
* Sections 1.6.1 & 1.6.2: Reformat to match the CP's formatting style.
* Section 1.6.4: Add an Oxford comma to the document list (as used throughout). Remove the incorrect comma before "of the CA". Correct "these Requirements" to "this CPS".
* Section 3.4: Partially eliminate passive voice (some does reduce ambiguity).
* Section 4.2.1: Eliminate passive voice.
* Section 4.9.2: Eliminate passive voice.
* Section 4.9.3: Eliminate passive voice.
* Section 4.9.8: Eliminate passive voice. Add a comma after "Relying Party", for clarity.
* Section 5.3.4: Rephrase that training is "repeated annually" not "on an annual basis", for brevity.
* Section 5.7.3: Eliminate passive voice.
* Section 5.8: Eliminate passive voice (which makes "review"'s tense correct).
* Section 6.1.6: Change NIST SP link to break out the URL, for consistency.
* Section 6.4.1: Add a second "the" before "place it will be stored", for clarity.
* Section 6.4.2: Replace "a combination of" with "both", for brevity.
* Section 6.6.1: Replace "reception" with "receipt", per common usage.
This updates our CP to match BRs v1.8.3, which pulls in ballots:
- SC50: Remove the requirements of 4.1.1
- SC53: Sunset for SHA-1 OCSP Signing
- SC51: Reduce and Clarify Log and Records Archival Retention Requirements
Fixes#166Fixes#167
* Add pre-issuance linting to CPS 8.7
Fixes#48
* Clarify key compromise in CPS 4.9.12 and 4.9.3
Fixes#49
* Update CP/CPS 7.1.4 to be DV-specific
Fixes#50
* Remove specific reference to zlint
Remove "RFC 2253 and RFC 2616 provide more information." These aren't exhaustive references for Distinguished Names and are more likely to be confusing than helpful.
* no-stipulations: Adding first version
- Add `tools/no_stipulations/no_stipulations.py` with unit tests
- Add github actions to `flake8` and `unittest`
* no-stipulations: Bug fix (#5)
- Fix insertion of extra newlines
- Add output flag
>> [note] odd letsencrypt is pointing to inscure urls
>> Best practices is to use secure urls https://
Fix: CP.md
Signed off by -- I-Cat <the_kat690@hotmail.com>
The wording reads like "all other" excludes keyCompromise which
preceded that paragraph. This clarifies that we still accept
all revocation requests via our email address.
Specify in Section 4.9.3 that revocations for key compromise will result in blocking of the public key for future issuance and revocation of other outstanding certificates with the key.
# This document contains some guidelines for editing ISRG CP and CPS documents.
## CP
Our CP is a copy of the Baseline Requirements (BRs) with the following changes:
1. Change anything that is obviously necessary, including much of the content in Sections 1.1 and 1.2.
2. Stucture should follow the structure suggested in RFC 3647 Section 6. Casing of section labels should match RFC 3647 casing. Where there is a difference between the BR structure and RFC 3647 suggested structures, use RFC 3647.
Note that any RFC 3647 section is allowed to contain sub-sections that are not defined in RFC 3647, so additional sub-sections in the BRs should be copied.
An example of a conflict between RFC 3647 and the BR structure is the title of Section 3.2.2. The BRs call it "Authentication of Organization and Domain Identity" but RFC 3647 calls it "Authentication of organization identity". We must use the RFC 3647 section name.
3. Section names for any validation methods we don't use under Sections 3.2.2.4 and 3.2.2.5 should be [Reserved] with "No stipulation." as the content. We do not include information for validation methods we don't use so as to not introduce confusion.
4. No sections can be left blank. If there is a blank section in the BRs say "No stipulation." to indicate that our CP will not impose additional requirements.
5. Section 9, legal, is designed and reviewed by ISRG attorneys.
## CPS
The CPS should have the same structure at the CP, but contain more detailed information.
Section 9, legal, is designed and reviewed by ISRG attorneys.