Confirm
344
edits
Changes
→CP/CPS Structured According to RFC 3647: Updated language
===== CP/CPS Structured According to RFC 3647 =====
CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements. Further, CP/CPS documents should include every component and subcomponent, and the placement of information should be aligned with the BRs; e.g. domain validation practices should be documented in section 3.2.2.4 of the CA’s CP/CPS.
* The words "''No Stipulation''" mean that "the particular document imposes no requirements related to that section," [https://www. ** Note that the Mozilla root store mozilla.org/en-US/about/governance/policies/security-group/certs/policy defines acceptable usage of "No Stipulation" in CP/CPS documents#33-cps-and-cpses MRSP section 3.3].
* The words "''Not applicable''" are acceptable to indicate that the CA’s policies forbid the practice that is the title of the section. Language similar to “We do not perform <subject of the section>” is preferred.
* Sections must not be left blank. The purpose of "No Stipulation" is to make it clear that the omission of content was intentional.
* If a full description of a section is repeated elsewhere in the document, language similar to “Refer to Section 1.2.3” is preferred. CrossExtensive cross-referencing among multiple CPs and CPSes is discouraged. However, cross-referencing between single CP and CPS documents is acceptable as long as both documents are published on your CA's website, and the CP and CPS documents clearly indicate which root certificates they govern.* If a section in your CP/CPS only applies to a certain type of certificate, then your CP/CPS needs to state that. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#52-forbidden-and-required-practices Mozilla's Root Store Policy] says: "CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage, unless the certificate is being issued to the CA itself." So if your CP/CPS allows for generation and escrow of private keys for personal certificates, then your CP/CPS should clearly indicate that those sections do not apply to TLS server certificates.
Examples:
* If your CA does not allow a particular domain validation method to be used, then the CP or CPS should say that, e.g. "This method of domain validation is not used".
* If a section of your CP delegates the detailing of requirements to one or more CPSsthe CPS, then the CP should state "Refer to <section> of the CPS".* The BRs do not allow certificate suspension, so the CA’s CPS should state that certificate suspension is not allowed for SSL certsTLS certificates, and then the other sections related to suspension should say “Not applicable”.
* If your CA does not issue TLS server certificates containing IP addresses, then section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS should say that such certificate issuance is not allowed, e.g. “No IP address certificates are issued under this CPS.”
* If your CP contains full descriptions of physical security required by section 5 .1 of RFC 3647, then the CPS may say "As stipulated in section 5 .1 of the CP". (This assumes that the CP is also published on your website, and the CP and CPS documents clearly indicate which root certificates they govern.)
===== CP/CPS Documents will be Reviewed! =====
