[cabfpub] General WebPKI requirements

[Peter Bowen]

We have had a number of discussions about how to determine when the BRs are applicable and how they apply to things other than End-Entity certificates.  I posted a draft to mozilla.dev.security.policy about a week ago which attempts to address this along with expectations for CAs in the WebPKI.  I’ve updated the draft based on feedback.  A new version is below.  While it does reference non-CA/Browser Forum documents, I think that this is a reasonable candidate for something to discuss in the Forum, as it overlaps with other discussions we have been having.

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](https://tools.ietf.org/html/rfc5280). 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.  The
attributes included in distinguished names are properties of a subject and may
vary based what the CA has verified.  It should not be assumed that it is
possible to build a tree based on the properties; there may be completely
disjoint sets of properties in the subjects of certificates sharing a common
issuer.

The WebPKI is a collection of independent PKIs.  Each PKI is consists of one or
more Certificate Authorities, one or more End Entities, and a set of
certificates that link them.

There are several key entity types in the WebPKI.  These include logical
entities that exist in bit and bytes and real world entities that have legal
status.  Some of these are outlined below.

Distinguished Name: A set of attribute types and attribute values.

Key Pair: a set cryptographic keys, usable with an asymmetric key cryptographic
algorithm, consisting of a Private Key, a Public Key, and associated parameters.
For any given Private Key and parameter set, there exists exactly one associated
Public Key.

Certification Authority (CA): a logical entity which uses its private key to
sign certificates.  Each CA has a single Key Pair and a single Distinguished
Name.  A CA is uniquely identified by the combination of the Distinguished Name
and 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.

Certificate Policy: a named set of rules that indicates the applicability of a
certificate to a particular community or class of application with common
security requirement and rules for the CA must follow when issuing the
certificate.

Certification Practice Statement (CPS): A document which describes the rules and
procedures used in operating a Certificate Authority. The CPS describes how the
applicable Certificate Policies are interpreted in the context of the system
architecture and operating procedures of the Certification Authority Operator.

Compliant Certificate: a Certificate as described in [RFC
5280](https://tools.ietf.org/html/rfc5280) as updated by [RFC
6818](https://tools.ietf.org/html/rfc681) 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

CA Certificate: a Compliant Certificate with a Basic Constraints extension with
a value of true in the cA component

Self-signed CA 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

Transitive CA Certificate: a CA Certificate where the Issuer and Subject
Distinguished Names are not the same.  RFC 5280 and X.509 refer to this as a
"cross-certificate."

End-entity Certificate: a Compliant Certificate either with no Basic Constraints
extension or with a value of false in the CA component

Trust Anchor List: a curated set of Certification Authorities that the list
maintainer recommends Relying Parties recognized as trusted for a specific
purpose or set of purposes. A single Trust Anchor List may contain CAs from
multiple independent PKIs and may also contain multiple CAs from the same PKI.

In order to provide assurance to parties relying upon these certificates, there
are minimal interoperability requirements for CAs in the WebPKI.

Each CA in a WebPKI Trust Anchor List must:

1. have exactly one Private Key
2. have a unique key identifier (across all known CAs)
3. have a distinguished name that consists of relative distinguished names each
   containing a single attribute
4. have a distinguished name with unique set of attributes (across all known
   CAs)
5. have a single defined CAO at any given time.
6. have a single CPS at any given time.

Each CA Operator may have multiple CAs, multiple CPSes, and multiple CA Key
Pairs. Not all CAs operated by a CAO may be subject to these requirements.

Each CPS must have a single CAO.

Each CA Private Key must have a single defined CAO at any given time and must only ever be used with one set of parameters.

Private Keys which are CA private keys must only be used to generate signatures
that meet the following requirements:

1. The signature must be over a SHA-256, SHA-384, or SHA-512 hash
2. The data being signed must be one of the following:
  * Self-signed CA Certificate
  * Transitive CA Certificate
  * End-entity Certificate
  * Certificate Revocation Lists (as defined in [RFC
  5280](https://tools.ietf.org/html/rfc5280))
  * OCSP response (as defined in [RFC
  6960](https://tools.ietf.org/html/rfc6960))
  * Precertificate (as defined in draft-ietf-trans-rfc6962-bis)
3. Data that does not meet the above requirements must not be signed

CA private keys must meet one of the following requirements:

1. RSA keys with p and q each being at least 1024 bits long and an odd value
   for the exponent e
2. DSA keys with p being at least 2048 bits long and q being at least 224 bits
   long
3. EC keys on the NIST P-256, P-384, or P-521 curves

Two or more CAs may have the same Private Key as long as they have the same CAO
and the same CPS.

CAs must not sign certificates that:

* Have any extension with an Object Identifier (OID) in the 2.16.840.1.113730.1 arc
* Have any extension with an OID 2.5.29.0 to 2.5.29.8, 2.5.29.10 to 2.5.29.13, 2.5.29.22, 2.5.29.25, or 2.5.29.26 or OIDs in those arcs
* Have a Extended Key Usage extension with 2.16.840.1.113730.4.1 or 1.3.6.1.4.1.311.10.3.3 key purposes

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

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

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

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:

1. Ensure the End-Entity certificates follows the S/MIME Certificate Profile:
   Minimum
2. 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

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

The CAO must ensure that any CA that is the subject of a Transitive CA
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 the id-kp-serverAuth, id-kp-codeSigning,
  or id-kp-emailProtection key purpose ids nor the special KeyPurposeId
  anyExtendedKeyUsage

_TBD: Add language to exclude CAs from appropriate requirements if EKU restricted_

If the CAO designates the CA as a "Root CA", then additional requirements apply:

* 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.
* the CA key pair for any Root CA must be used only for Root CAs