Given that there is a lack of clarity on when the CABF BRs apply, and that applicability of the BRs is outside the scope of the BRs, I propose the following text to clarify and help CAs understand the expectations of operating a publicly trusted CA.
Thanks, Peter Requirements for a CA in the WebPKI The WebPKI is a loosely defined group of Certification Authorities which are trusted to issue certificates asserting control of identifiers bound to and scoped by the ICANN/PTI operated DNS root. The WebPKI may also provide identity certificates asserting that the holder can act on behalf of natural persons and legal entities. The WebPKI is based on certificate as described in RFC 5280. It is inspired by ITU-T X.500 series standards but does not always comply with the X.500 standards. In particular, WebPKI acknowledges and accepts that the Directory Information Tree does not exist and therefore focused on properties of subjects rather than their relationships. Therefore Distinguished Names, while being Sequences of Relative Distinguished Names (RDNs), are treated as an unordered Set of RDNs and different natural persons or legal entities may have the same Distinguished Name if the described properties of the persons or entities are the same. In order to provide assurance to parties relying upon these certificates, there are minimal interoperability requirements for CAs in the WebPKI. Definitions: Certification Authority (CA) - a logical entity which uses its private key to sign certificates. Certificate Authority Key Pair - a set cryptographic keys, usable with an asymmetric key cryptographic algorithm, consisting of a CA private key and a CA public key. Certification Authority Operator (CAO) - a natural person or legal entity which has control of and is responsible for the use of the CA private key. CA-Certificate - a Compliant Certificate with a Basic Constraints extension with a value of true in the cA component Self-signed Certificate - a CA Certificate where the Issuer and Subject Distinguished Names are identical and where the signature can be verified by the Subject Public Key Info in the certificate Cross-Certificate - a CA Certificate where the Issuer and Subject Distinguished Names are not the same End-entity Certificate - a Compliant Certificate either with no Basic Constraints extension or with a value of false in the CA component Compliant Certificate - a Certificate as described in RFC 5280 as updated by RFC 6818 with the following exceptions: dNSName type GeneralNames included in a Subject Alternative Name extension may contain ‘*’ and ‘?’ The critical attribute of extensions of type Name Constraints may be set to false Requirements: 1) The CA must have exactly one CA private key. 2) The CA must have a unique key identifier (across all known CAs). 3) The CA must have a unique distinguished name (across all known CAs). 4) The CA must have a single defined CAO at any given time. 5) Private keys which are CA private keys must only be used to generate signatures that meet the following requirements: a) The signature must be over a SHA-256, SHA-384, or SHA-512 hash b) The data being signed must be one of the following: - Self-signed Certificate - Cross-Certificate - End-entity Certificate - Certificate Revocation Lists (as defined in RFC 5280) - OCSP response (as defined in RFC 6960) - Precertificate (as defined in draft-ietf-trans-rfc6962-bis) c) Data that does not meet the above requirements must not be signed 6) CA private keys must meet one of the following requirements: a) RSA keys with p and q each being at least 1024 bits long and an odd value for the exponent e b) DSA keys with p being at least 2048 bits long and q being at least 224 bits long c) EC keys on the NIST P-256, P-384, or P-521 curves 7) End-entity Certificates must include an Extended Key Usage extension if one of the following is true: - The Certificate does not include a Key Usage extension - The Key Usage Extension includes Digital Signature - The subject public key info contains a RSA key and the the key usage extension includes Key Encipherment - The subject public key info contains a EC key and the key usage extension includes Key Agreement 8) If the Extended Key Usage extension in an End-Entity certificate contains either the id-kp-serverAuth key purpose id or the special KeyPurposeId anyExtendedKeyUsage, or both, then the CA must follow the Baseline Requirements for publicly trusted certificates when issuing the certificate 9) If the Extended Key Usage extension in an End-Entity certificate contains either the id-kp-codeSigning key purpose id or the special KeyPurposeId anyExtendedKeyUsage, or both, then the CA must follow the Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates when issuing the certificate 10) If the Extended Key Usage extension in an End-Entity certificate contains either the id-kp-emailProtection key purpose id or the special KeyPurposeId anyExtendedKeyUsage, or both, then the CA must: a) Ensure the End-Entity certificates follows the S/MIME Certificate Profile: Minimum b) take reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf 11) If the Subject Distinguished Name of an End-Entity certificate contains any attributes of with the type jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3), then the CAO must validate the details of the subject according to the Extended Validation Guidelines 12) The CAO must ensure that any CA that is the subject of a Cross-Certificate issued by the CA follows these requirements unless the Cross-Certificate meets the below requirements: - The Cross-Certificate contains an Extended Key Usage extension - The EKU extension does not contain either the id-kp-serverAuth key purpose id or the special KeyPurposeId anyExtendedKeyUsage 13) If the CAO designates the CA as a "Root CA", then the CA private key may only be used to sign End-Entity certificates when the End-Entity certificate contains a Key Usage Extension which has id-kp-OCSPSigning as the only key purpose. 14) The CA key pair for any Root CA must be used only for Root CAs _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
