[cabfpub] General WebPKI requirements

Mon Nov 21 19:18:13 UTC 2016

Kirk asked me to be a little clearer on the rationale for this email and the reasoning we need these broader requirements.

As has come up repeatedly during discussions on SHA-1 deprecation, there is a lack of clarity on when the Baseline Requirements apply to certificates.  From these discussions, it is also very clear that there are CA actions outside of issuing certificate in scope for the BRs that can have negative impacts on BR certificates.  Therefore it is important to have clear expectations of CA behavior for any CA in the WebPKI.

I also know that at least one browser is working on updating their CA policies and another browser has said they are working on their first ever CA contract, so I think it is valuable to have this discussion as a group rather than waiting on them to create a policy without discussion.

Thanks,
Peter

> On Nov 19, 2016, at 3:01 PM, Peter Bowen via Public <public at cabforum.org> wrote:
> 
> 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
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public