Confirmed users
593
edits
CA/CP-CPS Guidance: Difference between revisions
→Frequently Asked Questions: Added FAQ on certificate profiles
m (→Relevant MRSP Text: Added hyperlink) |
(→Frequently Asked Questions: Added FAQ on certificate profiles) |
||
| Line 799: | Line 799: | ||
Certificate, CRL, and OCSP profiles may be maintained in separately versioned appendices, repositories, companion documents, or similar supporting materials, provided they are publicly accessible, clearly in scope, versioned, and sufficiently identified. | Certificate, CRL, and OCSP profiles may be maintained in separately versioned appendices, repositories, companion documents, or similar supporting materials, provided they are publicly accessible, clearly in scope, versioned, and sufficiently identified. | ||
=== What level of detail is expected for certificate profiles in CP/CPS Documentation? === | |||
Mozilla does not prescribe a specific format for certificate profiles. Certificate profile information may be presented using field-by-field profile tables, structured profile specifications, references to externally maintained profile documentation, or other formats that clearly describe the certificates issued by the CA. | |||
The objective is not to standardize documentation style, but to ensure that certificate profile information is sufficiently clear, complete, and accurate to allow a technically competent reviewer to understand the certificates issued by the CA and evaluate conformance with applicable requirements. | |||
Certificate profiles should be maintained as authoritative descriptions of the certificates the CA intends to issue. Profile documentation should accurately reflect the certificates currently issued by the CA and should be updated when certificate content changes. A reviewer should be able to compare an issued certificate against the documented profile and determine whether the certificate conforms to the CA's documented practices. | |||
Mozilla encourages CA operators to view certificate profiles not only as compliance documentation, but also as an important preventive control. Many certificate misissuance incidents have involved unexpected or incorrectly configured certificate fields, extensions, constraints, policy identifiers, or other certificate content. Accurate and sufficiently detailed certificate profiles help reduce the risk of such incidents by providing a clear specification against which issuance systems, linting tools, auditors, and compliance personnel can validate certificate content. | |||
Certificate profiles should therefore contain sufficient detail to support implementation review, auditor testing, compliance assessment, and operational validation. In general, profiles should identify the certificate type to which they apply and describe the fields, extensions, constraints, policy identifiers, and other certificate content relevant to demonstrating conformance with applicable requirements. Any optional, conditional, or profile-specific variations should be clearly identified. | |||
Mozilla does not require every profile to be documented at the same level of granularity. However, profile documentation should be sufficiently detailed that it can serve as a reliable reference for understanding the certificate content the CA intends to issue and for identifying unintended deviations between documented practices and actual certificates. | |||
In short, the profile should match the certificate, and the certificate should match the profile. | |||
=== Can a CA operator use multiple CP/CPS documents? === | === Can a CA operator use multiple CP/CPS documents? === | ||