Proposal to define applicability of BRs and expectations of CAs

[Peter Bowen]

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

[Jakob Bohm]

On 11/11/2016 02:42, Peter Bowen wrote:
> 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
>

As phrased, I assume this is intended as something that might become a
CA/B forum document rather than a Mozilla specific document.

Could some of this be shortened by reference to existing BR documents,
thus avoiding needless redundancy and risk of inconsistency?

> 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.
>

A single organization will usually operate more than one logical CA
entity, such as one or more root CAs and one or more intermediary CAs.

>
> 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
>

Change to "Self-signed CA Certificate" (to distinguish from self-signed
end entity certificate, which need not be mentioned in the text, but
which do exist outside the scope of this document).

>
> Cross-Certificate - a CA Certificate where the Issuer and Subject
> Distinguished Names are not the same
>
>

Change to "Intermediary CA Certificate" for consistency with common
usage of the terminology. Also add

"Cross-Certificate - an Intermediary CA Certificate whose Subject and
public key is the same as that of some Self-signed CA Certificate
in the WebPKI, regardless if that Self-signed CA Certificate has the
same CAO or not."

> 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

Should this be reworded to allow future stronger hash algorithms, such
as SHA-3 or non-US algorithms if and when those are otherwise accepted
by the BRs?

Should there be an exception for issuing updated OCSP certificates
and/or CRLs with historic hash algorithms previously used by the same CA
in order to support revocation checking of existing/older
certificates issued using those algorithms and checked by relying
parties incapable of checking certificate chains involving the
currently acceptable algorithms.

For example, when a relying party checks the validity of a time stamped
e-mail or code signature made in 2014 using an SHA-1 certificate
chaining to the CA in question, such a relying party may make OCSP
and/or CRL queries to the CA expecting the OCSP replies and/or CRL to
be signed using SHA-1 using a chain of SHA-1 certificates leading to
the original issuing CA. Such a requirement might be met with
reasonable protection of the modern PKI by:

- Signing SHA-1 CRLs with reasonably long lifetimes (e.g. 1 month) and
randomized values (timestamps, revocations of non-existing serial
numbers) at both ends of the CRL.

- Issuing very few SHA-1 OCSP signing certificates with 1 year or
longer validity, then using those to sign both CRL-derived canned
SHA-1 OCSP responses and negative OCSP responses for queries about
never issued certificates and/or multiple actual certificates.
Securing the SHA-1 OCSP responders (at URLs listed in the previously
issued SHA-1 certificates) against SHA-1 attacks is left as an
exercise for the CA.

>
> 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

Again, should future algorithm options be automatically accepted, if
and when those are added to other parts of the BRs?

>
>
> 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
>

Maybe this should not be conditional on the algorithm, only the Key
Usage extension. That way the text becomes applicable to any future
accepted algorithms too.

>
> 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

This number 9 obviously does not apply to Mozilla after they stopped
caring about code signing. But it still applies to other CA/B forum
members.

>
>
> 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
>

"id-kp-serverAuth, id-kp-codeSigning and/or id-kp-emailProtection" (for
consistency with numbers 9 and 10 above).

>
> 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.
>

"13 and a half) Any issued intermediary CA certificates (including
cross certificates) must include a path length basic constraint which
is as low as the intended use of its subject CA allows, and always
strictly less than any path length basic constraint on the issuing CAs
own valid certificates."

>
> 14) The CA key pair for any Root CA must be used only for Root CAs
>

This number 14 seems to prohibit the issuing of true cross certificates
between WebPKI root CAs, as is otherwise recommended when standing up a
new root CA. (Example 1: Let's Encrypt is cross signed by a CA already
in existing root stores) (Example 2: When existing CAs set up new SHA-2
only roots as part of the transition away from SHA-1, those roots were
usually cross signed by their already trusted SHA-1 roots).

Perhaps a better text would be

"1 and a half) The CA private key must not be used for any other CA or
entity, but a CA may have more than one CA Certificate for that private
key".



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Nick Lamb]

On Friday, 11 November 2016 04:47:21 UTC, Jakob Bohm wrote:
> (Example 1: Let's Encrypt is cross signed by a CA already
> in existing root stores)

In fact ISRG Root X1, the new Let's Encrypt root being trusted by Mozilla (but so far not by any other major root trust store) is _not_ cross signed by anybody important.

The Let's Encrypt intermediates are cross signed by Identrust's DST Root CA X3, but the root isn't. I presume this was a deliberate choice.

[Gervase Markham]

Hi Peter,

On 11/11/16 01:42, Peter Bowen wrote:
> 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.

This is helpful, thank you. Is it your proposal that this, or something
like it, would be incorporated into Mozilla's root store policy as a
"Scope" section or similar name?

The following issues with our current policy may be relevant:
https://github.com/mozilla/pkipolicy/issues/27
https://github.com/mozilla/pkipolicy/issues/5

> 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.

I sort of think I know what you mean here, but could you expand this
last part?

> 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.

This is true, but is it important enough to be put here? What practical
affect does it have to acknowledge this truth?

> Definitions:

Is this also your take on how best to resolve the issue currently before
the CAB Forum about how to use consistent definitions of things like
"CA" in the BRs?

> Certification Authority (CA) - a logical entity which uses its private
> key to sign certificates.

Is this too broad? An intermediate certificate might meet this
definition. Why do we need this definition if we have CAO and CAKP?

> Cross-Certificate - a CA Certificate where the Issuer and Subject
> Distinguished Names are not the same

I would call this an Intermediate Certificate. A cross certificate is an
informal term for a certificate which ties two previously-separated
trees of certificates together.

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

I thought you weren't supposed to do "CA: false" explicitly?

> 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 ‘?’

Is "?" for CT?

> Requirements:
>
> 1) The CA must have exactly one CA private key.

One might add for clarity "A CAO operates one or more CAs."

> 7) End-entity Certificates must include an Extended Key Usage
> extension if one of the following is true:

Why is this not required all the time?

> 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

I would leave out anyExtendedKeyUsage - Firefox, at least, doesn't
recognise it.

> 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

Again, if this were a Mozilla document, this would not be necessary.

> 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

What is that?

> 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

Why define EV this way, and not any other?

Gerv

[Dimitris Zacharopoulos]

On 11/11/2016 3:42 πμ, Peter Bowen wrote:
> 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

Hi Peter,

Although this is very helpful so that people can better understand the
CA/B Forum's expectations and BR scope by introducing fresh language and
definitions (and make some definitions clearer), I believe that
proposing new definitions is a very radical move that would ultimately
cause even more confusion to CAs, auditors and relying parties. The best
place to discuss these definitions would be the CA/B Forum.

In order to define the "BR scope" for the Mozilla policy, perhaps it
would help to list the current proposals (maybe on the wiki?) by trying
to use as much of the current BRs definitions for "CA", "Certificate",
"Root Certificate", "Root CA", etc. Someone will have to go back and
check the archive for these proposals and post them on the wiki. Or, we
would have a new "call for proposals" and start from there :)


Best regards,
Dimitris.

>
> 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
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Gervase Markham]

On 11/11/16 13:26, Dimitris Zacharopoulos wrote:
> Although this is very helpful so that people can better understand the
> CA/B Forum's expectations and BR scope by introducing fresh language and
> definitions (and make some definitions clearer), I believe that
> proposing new definitions is a very radical move that would ultimately
> cause even more confusion to CAs, auditors and relying parties. The best
> place to discuss these definitions would be the CA/B Forum.

Hi Dimitris,

Can you explain what about Peter's proposals are radical? It seems to me
to be mostly a clarification of existing intent, at least as far as
Mozilla policy is concerned.

Gerv

[Dimitris Zacharopoulos]

(something weird happened in the reply all. Re-sending).

On 11/11/2016 3:45 μμ, Gervase Markham wrote:
> On 11/11/16 13:26, Dimitris Zacharopoulos wrote:

>> Although this is very helpful so that people can better understand the
>> CA/B Forum's expectations and BR scope by introducing fresh language and
>> definitions (and make some definitions clearer), I believe that
>> proposing new definitions is a very radical move that would ultimately
>> cause even more confusion to CAs, auditors and relying parties. The best
>> place to discuss these definitions would be the CA/B Forum.

> Hi Dimitris,
>
> Can you explain what about Peter's proposals are radical? It seems to me
> to be mostly a clarification of existing intent, at least as far as
> Mozilla policy is concerned.
>
> Gerv
>
>

I was referring to not changing the definitions for which most people
are currently familiar with and are included in the BRs. IMHO defining
"CA" as a Certificate with CA:true when the BRs define a "CA" as "an
organization" is a big step to make. I thought Peter's proposal
included introducing these definitions in the Mozilla policy to clarify
the proper BR scope. My point is that we need to be as aligned with
existing BR definitions as possible to avoid more confusion. If these
definitions are to be improved/changed (something we're already working
on in the Forum's policy review WG), I believe the CA/B Forum is the
best place to discuss these changes.

Dimitris.

[Peter Bowen]

On Fri, Nov 11, 2016 at 6:03 AM, Dimitris Zacharopoulos
<ji...@it.auth.gr> wrote:
> (something weird happened in the reply all. Re-sending).
>
> On 11/11/2016 3:45 μμ, Gervase Markham wrote:
>>
>> On 11/11/16 13:26, Dimitris Zacharopoulos wrote:
>>>

>>> Although this is very helpful so that people can better understand the
>>> CA/B Forum's expectations and BR scope by introducing fresh language and
>>> definitions (and make some definitions clearer), I believe that
>>> proposing new definitions is a very radical move that would ultimately
>>> cause even more confusion to CAs, auditors and relying parties. The best
>>> place to discuss these definitions would be the CA/B Forum.
>>

>> Hi Dimitris,
>>
>> Can you explain what about Peter's proposals are radical? It seems to me
>> to be mostly a clarification of existing intent, at least as far as
>> Mozilla policy is concerned.
>>
>> Gerv
>>
>>
>
> I was referring to not changing the definitions for which most people are
> currently familiar with and are included in the BRs. IMHO defining "CA" as a
> Certificate with CA:true when the BRs define a "CA" as "an organization" is
> a big step to make. I thought Peter's proposal included introducing these
> definitions in the Mozilla policy to clarify the proper BR scope. My point
> is that we need to be as aligned with existing BR definitions as possible to
> avoid more confusion. If these definitions are to be improved/changed
> (something we're already working on in the Forum's policy review WG), I

> believe the CA/B Forum is the best place to discuss these changes.

Dimitris,

I agree that the definitions I wrote may not align perfectly with
those that the CA/Browser Forum Policy Review WG has been using.

However, after discussions at the F2F, discussions about why
disclosure of all CA Certificates in SalesForce (vs. all unique Issuer
DNs) is important, and discussions with others experienced in running
PKIs, I believe that it it critical we get this right.

CA Operators, CA Key Pairs, Certification Authorities, CA
Distinguished Names, and CA Certificates are all distinct things.
Each of which certain relationships to the others, which are
frequently one-to-many or many-to-one, so it is important that we get
things clearly defined. This text is my attempt to start documenting
those relationships.

It it clear to me that we don't have a common understanding of the
"WebPKI" and what organizations and people wishing to participate in
the WebPKI should expect. It is also clear that we have an ever
increasing number of organizations and people wishing to either bring
their existing PKI into the WebPKI or start a new PKI to join the
WebPKI. I think it is critical we help them understand how the WebPKI
works and what to expect. In virtually every conversation I've had,
someone gets surprised by how the WebPKI works. We need to fix this
so there is a common understanding. Only then can we write effective
requirements.

Thanks,
Peter

P.S. I disagree that the CA/Browser Forum is the best place for this
discussion. The WebPKI is larger than the CA/BF and members of the
CA/BF have clearly said that many parts of the WebPKI are out of scope
for the CA/BF, as it exists today.

[Peter Bowen]

On Fri, Nov 11, 2016 at 4:42 AM, Gervase Markham <ge...@mozilla.org> wrote:
> Hi Peter,
>
> On 11/11/16 01:42, Peter Bowen wrote:

>> 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.
>

> This is helpful, thank you. Is it your proposal that this, or something
> like it, would be incorporated into Mozilla's root store policy as a
> "Scope" section or similar name?

Yes.

> The following issues with our current policy may be relevant:
> https://github.com/mozilla/pkipolicy/issues/27
> https://github.com/mozilla/pkipolicy/issues/5

I think any increase in requirements needs to be carefully considered
given that many Root CAs are included in multiple browser trust
stores. For example, forbidding DSA would impact all browsers.

>> 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.
>

> I sort of think I know what you mean here, but could you expand this
> last part?

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 might be completely disjoint sets of properties in the subjects
of certificates.

>> 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.
>

> This is true, but is it important enough to be put here? What practical
> affect does it have to acknowledge this truth?

This is a point of confusion for many CAs attempting to join the
WebPKI. They usage of the DN to hold arbitrary non-hierarchical
properties is not at all obvious. For example, EV certificates
contain two properties containing country code and other certificates
might not contain any country code.

>> Definitions:
>
> Is this also your take on how best to resolve the issue currently before
> the CAB Forum about how to use consistent definitions of things like
> "CA" in the BRs?
>

>> Certification Authority (CA) - a logical entity which uses its private
>> key to sign certificates.
>

> Is this too broad? An intermediate certificate might meet this
> definition. Why do we need this definition if we have CAO and CAKP?

A CA is not a certificate. It is the tuple (CAKP, CADN). The
requirements are not intended to only apply to Root CAs, so it would
be accurate that a CA that is cross-signed/subordinated to a Root CA
would meet the definition. The scope is designed to be explicitly
applied to a CA then cascade down according to the rules.

>> Cross-Certificate - a CA Certificate where the Issuer and Subject
>> Distinguished Names are not the same
>

> I would call this an Intermediate Certificate. A cross certificate is an
> informal term for a certificate which ties two previously-separated
> trees of certificates together.

This comes directly from RFC 5280, section 3.2:

"This specification covers two classes of certificates: CA
certificates and end entity certificates. CA certificates may be
further divided into three classes: cross-certificates, self-issued
certificates, and self-signed certificates. Cross-certificates are
CA certificates in which the issuer and subject are different
entities. Cross-certificates describe a trust relationship between
the two CAs. [...] Self-
signed certificates are self-issued certificates where the digital
signature may be verified by the public key bound into the
certificate. Self-signed certificates are used to convey a public
key for use to begin certification paths. End entity certificates
are issued to subjects that are not authorized to issue certificates."

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

> I thought you weren't supposed to do "CA: false" explicitly?

The value is false but the Distinguished Encoding Rules (DER) that
govern serialization into bytes say to leave out default values.

>> 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 ‘?’
>

> Is "?" for CT?

Yes. I was trying to ensure that these rules grandfather in things
that are expected, which includes the draft Precerts at least one CA
signs.

>> Requirements:
>>
>> 1) The CA must have exactly one CA private key.
>

> One might add for clarity "A CAO operates one or more CAs."

Yes, this is an important clarification.

>> 7) End-entity Certificates must include an Extended Key Usage
>> extension if one of the following is true:
>

> Why is this not required all the time?

CAs issue lots of kinds of certificates. I wanted to avoid collisions
with completely unrelated certificate types.

>> 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
>

> I would leave out anyExtendedKeyUsage - Firefox, at least, doesn't
> recognise it.

Agreed Firefox does not, but other browsers do. It ca be dropped if
this is adopted as a Firefox-specific doc.

>> 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
>

> Again, if this were a Mozilla document, this would not be necessary.
>

>> 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
>

> What is that?

The Google draft Andrew Whalley published.

>> 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
>

> Why define EV this way, and not any other?

EV is really hard to pin down. I purposefully avoided any discussion
of Certificate Policy and Policy Mappings extensions, as there is
little consistency in how they are handled in WebPKI. I could add a
clause that inclusion of 2.23.140.1.1 in a Certificate Policy
extension in an End-Entity certificate requires Extended Validation of
the subject, but that alone would skip many EV certs that should be in
scope.

Thanks,
Peter

[Nick Lamb]

On Friday, 11 November 2016 19:51:28 UTC, Peter Bowen wrote:
> EV is really hard to pin down. I purposefully avoided any discussion
> of Certificate Policy and Policy Mappings extensions, as there is
> little consistency in how they are handled in WebPKI. I could add a
> clause that inclusion of 2.23.140.1.1 in a Certificate Policy
> extension in an End-Entity certificate requires Extended Validation of
> the subject, but that alone would skip many EV certs that should be in
> scope.

Isn't it the case that Microsoft's root store policy demands 2.23.140.1.1
under their ongoing rule 4.A.15 ? I had sort-of assumed Mozilla would eventually take the same stance.

[Gervase Markham]

On 11/11/16 19:51, Peter Bowen wrote:
>> The following issues with our current policy may be relevant:
>> https://github.com/mozilla/pkipolicy/issues/27
>> https://github.com/mozilla/pkipolicy/issues/5
>
> I think any increase in requirements needs to be carefully considered
> given that many Root CAs are included in multiple browser trust
> stores. For example, forbidding DSA would impact all browsers.

Please note that in the appropriate bug :-)

>>> Certification Authority (CA) - a logical entity which uses its private
>>> key to sign certificates.
>>
>> Is this too broad? An intermediate certificate might meet this
>> definition. Why do we need this definition if we have CAO and CAKP?
>
> A CA is not a certificate. It is the tuple (CAKP, CADN).

Ah. That would be a useful explanatory extra sentence.

> This comes directly from RFC 5280, section 3.2:
>
> "This specification covers two classes of certificates: CA
> certificates and end entity certificates. CA certificates may be
> further divided into three classes: cross-certificates, self-issued
> certificates, and self-signed certificates.

That's as may be, but I suggest that normal usage has moved on. I
certainly don't see that usage of cross-certificate.

>>> a) Ensure the End-Entity certificates follows the S/MIME Certificate
>>> Profile: Minimum
>>
>> What is that?
>
> The Google draft Andrew Whalley published.

I'm not sure I'm familiar with that; URL?

Gerv

[Rob Stradling]

On 14/11/16 09:25, Gervase Markham wrote:
<snip>

>>>> a) Ensure the End-Entity certificates follows the S/MIME Certificate
>>>> Profile: Minimum
>>>
>>> What is that?
>>
>> The Google draft Andrew Whalley published.
>

> I'm not sure I'm familiar with that; URL?

The archive of Andrew's post is empty for some reason:
https://cabforum.org/pipermail/public/2016-October/008592.html

Andrew's document is "available here":
https://drive.google.com/open?id=0B8nbdAUn7RfQOElGNlhaQTJmYWM


Here's what his post said:

"Greetings,

As I mentioned at the face to face meeting, Gmail will be rolling out
the ability for some users to protect their email with S/MIME. While
the product details will be announced in due course, we have produced a
profile that must be met for certificates to pass validation. In terms
of accepted roots, the list is yet to be published but those roots that
have the email trust bit set for the programs currently using the CA
Community in Salesforce are highly likely to be accepted.

The document is available here.

Please let me know if you have any comments or questions,

Thanks,

Andrew"

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online