Do We Now Require Separate Cross-certificates for SSL and S/MIME?

[Wayne Thayer]

During a 2.6 policy discussion [1], we agreed to add the following language
to section 5.3 "Intermediate Certificates":

> Intermediate certificates created after January 1, 2019:
>
>
> * MUST contain an EKU extension; and,
> * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
> * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection
> KeyPurposeIds in the same certificate.
>

It has been pointed out to me that the very next paragraph of section 5.3
states:

These requirements include all cross-certified certificates which chain to
> a certificate that is included in Mozilla’s CA Certificate Program.
>

The term "cross-certified certificates" could refer to the actual
cross-certificate, or it could refer to intermediate certificates that
chain up to the cross certificate. In the case of a root that is being
cross-certified, the former interpretation effectively means that distinct
cross-certificates would be required for serverAuth and emailProtection, as
follows:

1 - Root <-- Cross-certificate (EKU=emailProtection) <-- Intermediate
certificate (EKU=emailProtection) <-- leaf certificate (S/MIME)
2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate
certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS)

Should our policy require cross-certificates to be constrained to either
serverAuth or emailProtection via EKU, or should this requirement only
apply to [all other] intermediate certificates?

What is the correct interpretation of section 5.3 of the policy as
currently written?

I would appreciate everyone's input on these questions.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/QIweY3cHRyA/vbtnfJ4zCAAJ

[Bruce]

Note the BRs define Cross Certificate as "a certificate that is used to establish a trust relationship between two Root CAs."

I think the intent was to technically restrict subordinate CAs or rather CAs which are online and issue end entity certificates. My assumption is that we want to 1) not allow a subordinate CA to issue a certificate which it was no intended to issue and 2) mitigate the risk if an online subordinate CA has been compromised.

Typically, if an old root cross-certifies a new root, the purpose is to give the new root browser/OS ubiquity. The new root may be used to support end entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, Code Signing, Document Signing, Time-stamping ...). If we restrict the cross-certificate, then this will limit the use of a new root. Also note that the new root is 1) not an issuing CA and 2) is offline, so the mitigation of technical restriction may already be satisfied.

Thanks, Bruce.

[Tim Hollebeek]

Doesn't the "created after January 1, 2019" mean that there is no problem with old crosses? It would just be a new policy for new crosses as of next year?

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Bruce via
> dev-security-policy
> Sent: Thursday, July 12, 2018 10:28 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> S/MIME?
>
> Note the BRs define Cross Certificate as "a certificate that is used to establish a
> trust relationship between two Root CAs."
>
> I think the intent was to technically restrict subordinate CAs or rather CAs
> which are online and issue end entity certificates. My assumption is that we
> want to 1) not allow a subordinate CA to issue a certificate which it was no
> intended to issue and 2) mitigate the risk if an online subordinate CA has been
> compromised.
>
> Typically, if an old root cross-certifies a new root, the purpose is to give the
> new root browser/OS ubiquity. The new root may be used to support end
> entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, Code
> Signing, Document Signing, Time-stamping ...). If we restrict the cross-
> certificate, then this will limit the use of a new root. Also note that the new
> root is 1) not an issuing CA and 2) is offline, so the mitigation of technical
> restriction may already be satisfied.
>
> Thanks, Bruce.
>
> On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:

> https://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH
> iAL
> > jfsD2zgM=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy-
> 9DLApGl29o_1WR_vWTXMDk0d9kBFu
> >
> rU6JcvMPF1WEp4WBRfAgKXpN15C1244hstaDLxsVmE8bwd8UMj0MNvk5w_Q
> C8ibEWzPC_L
> > UljJwJbyQ12v-
> eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWAR
> > mueHAHVd9wo-
> Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1
> > Lo77olEchKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS-
> GdV0BnikfsrccHi35Z67abn6
> > -KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE-
> HQoRmqNABl-nFDxHu
> > Oru-
> 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv
> Y6H_
> >
> W_xOw3VB6Mp7gtxMSK0v72SLI%3D&u=https%3A%2F%2Fgroups.google.com
> %2Fd%2Fm
> > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31p
> FYXlE5W5k=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy-
> 9DLApGl29o_1WR_vWTXMDk0d9kBFurU6JcvMPF1WEp4WBRfAgKXpN15C1244
> hstaDLxsVmE8bwd8UMj0MNvk5w_QC8ibEWzPC_LUljJwJbyQ12v-
> eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWARmueHAH
> Vd9wo-
> Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1Lo77olE
> chKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS-GdV0BnikfsrccHi35Z67abn6-
> KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE-HQoRmqNABl-
> nFDxHuOru-
> 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv
> Y6H_W_xOw3VB6Mp7gtxMSK0v72SLI%3D&u=https%3A%2F%2Flists.mozilla.or
> g%2Flistinfo%2Fdev-security-policy

[Bruce]

Agreed that old cross-certificates will not be impacted, but this does impact new cross-certificates. I assume the work around would be to just issue more than one cross-certificate with different EKUs, but I don't assume that was intended by this policy change.

Bruce.

[Tim Hollebeek]

Yeah, I agree I don’t think it was intended. But now that I am aware of the issue, I think the crossing workaround per EKU is actually a good thing for people to be doing. Unless someone can point out why it's bad ...

Might want to give people a little more time to plan and adapt to that change though since I doubt anyone thought of it and people need planning runway to change their procedures if it is going to be interpreted this way.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Bruce via
> dev-security-policy
> Sent: Friday, July 13, 2018 10:17 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> S/MIME?
>

> Agreed that old cross-certificates will not be impacted, but this does impact
> new cross-certificates. I assume the work around would be to just issue more
> than one cross-certificate with different EKUs, but I don't assume that was
> intended by this policy change.
>
> Bruce.
>
> On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote:

> https://clicktime.symantec.com/a/1/wNze3hZcZDNkGJs2uz-
> SeEqGu_7QRemtNV2zTN4w6eA=?d=UWO2h2txAwcfMe5bqfj4PnyJC-fPf-
> jWINE8QAK6rKZhjWzUPs2jCHsJL_KIV6tsKYcbL2mfdvUjwCVFDiT3BvhiR5V29scB
> NCPx3iSBUFGl4Hch0iE4oi7chSA365HSr4m2CYJGYldzjUmox9DS7D7rArUAHY1XB
> Mek0obO98xn3LgdmNKeL5XUoGDW4Q85610Pj4Aa_0hbpgKzl870mCIXsGjH4Xl
> y28s1mHQU1dGwygaOH4n6iK6GqI1xJ20HjyZaQOkY8Sk5PE5xb8f1Cv_WcHNsPt
> Wnum0eUZ9_Sn904q_2Q1aXb7Y0weCKKCaU9ELY6ugItt8ngKWOHmtVyo0Ef-
> 3FzIfu1UTDqGWG169kW0w4F611kLa1gnEhpP8HmcECC0eThNLgqX57tzbUED6
> RF0iM96G520RE6U2hL2sj-
> TafMqmwPdgMMlyEaDeri1vaMgRhWihiFj8th7o1JcIa5PfWas8KYPzteyOYY2jDT
> 2EfeLpWB2b7&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> security-policy

[Wayne Thayer]

On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Yeah, I agree I don’t think it was intended. But now that I am aware of
> the issue, I think the crossing workaround per EKU is actually a good thing
> for people to be doing. Unless someone can point out why it's bad ...
>
>
>

I'd like to consider any new restrictions on cross-certificates separately.
I've created https://github.com/mozilla/pkipolicy/issues/145 to track this
idea, and added that if we go that far we should also think about
restricting roots to either the Mozilla websites or email trust bit.

Might want to give people a little more time to plan and adapt to that
> change though since I doubt anyone thought of it and people need planning
> runway to change their procedures if it is going to be interpreted this way.
>
>
>

It seems that we have agreement that the current change was not intended to
apply to cross certificates. I think that is the meaning of the existing
language, but it would be clearer if the final paragraph of section 5.3 was
amended to:

These requirements include all intermediate certificates signed by
cross-certificates which chain to a certificate that is included in

Mozilla’s CA Certificate Program.

Questions:
- does anyone object to that new wording?
- should the official policy be updated with this change prior to 1-Jan
when the requirement to separate usages of new intermediate certificates
goes into effect, or can this wait since it is only a clarification?

- Wayne

-Tim
>
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of
> Bruce via
> > dev-security-policy
> > Sent: Friday, July 13, 2018 10:17 AM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> > S/MIME?
> >

> > Agreed that old cross-certificates will not be impacted, but this does
> impact
> > new cross-certificates. I assume the work around would be to just issue
> more
> > than one cross-certificate with different EKUs, but I don't assume that
> was
> > intended by this policy change.
> >
> > Bruce.
> >
> > On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote:

> > > > KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE-
> > HQoRmqNABl-
> > > > nFDxHuOru-
> > > >
> > 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv
> > > >
> > Y6H_W_xOw3VB6Mp7gtxMSK0v72SLI%3D&u=https%3A%2F%2Flists.mozilla.or
> > > > g%2Flistinfo%2Fdev-security-policy
> >

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://clicktime.symantec.com/a/1/wNze3hZcZDNkGJs2uz-
> > SeEqGu_7QRemtNV2zTN4w6eA=?d=UWO2h2txAwcfMe5bqfj4PnyJC-fPf-
> > jWINE8QAK6rKZhjWzUPs2jCHsJL_KIV6tsKYcbL2mfdvUjwCVFDiT3BvhiR5V29scB
> > NCPx3iSBUFGl4Hch0iE4oi7chSA365HSr4m2CYJGYldzjUmox9DS7D7rArUAHY1XB
> > Mek0obO98xn3LgdmNKeL5XUoGDW4Q85610Pj4Aa_0hbpgKzl870mCIXsGjH4Xl
> > y28s1mHQU1dGwygaOH4n6iK6GqI1xJ20HjyZaQOkY8Sk5PE5xb8f1Cv_WcHNsPt
> > Wnum0eUZ9_Sn904q_2Q1aXb7Y0weCKKCaU9ELY6ugItt8ngKWOHmtVyo0Ef-
> > 3FzIfu1UTDqGWG169kW0w4F611kLa1gnEhpP8HmcECC0eThNLgqX57tzbUED6
> > RF0iM96G520RE6U2hL2sj-
> > TafMqmwPdgMMlyEaDeri1vaMgRhWihiFj8th7o1JcIa5PfWas8KYPzteyOYY2jDT
> > 2EfeLpWB2b7&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> > security-policy

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Bruce]

Since this is only a clarification, then I think the change can wait until the next update of the Mozilla policy.

Thanks, Bruce.

[Wayne Thayer]

Kathleen pointed out that one of the purposes of this section is to require
disclosure of cross-certificates, and my first attempted fix seems to
violate that purpose. Here is my second attempt to clarify the language in
section 5.3:

https://github.com/mozilla/pkipolicy/commit/43bdf5d6e97cdda0d8b11ee0f602a5282e848874

I would appreciate everyone's comments on this proposed change.

If we agree that this achieves the intended effect of requiring separation
of intermediate certificates by usage but excluding cross-certificates from
this requirement, then I now believe it will be best for me to publish an
update of the policy.

- Wayne

On Tue, Jul 17, 2018 at 10:42 AM Bruce via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

[Wayne Thayer]

Having received no comments on this proposal, I plan to go ahead and
publish version 2.6.1 of the Mozilla Root Store Policy with the third
paragraph of section 5.3 clarified as follows:

Intermediate certificates created after January 1, 2019, with the exception
of cross-certificates that share a private key with a corresponding root
certificate:

* MUST contain an EKU extension; and,
* MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
* MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection
KeyPurposeIds in the same certificate.

- Wayne

On Wed, Jul 18, 2018 at 11:55 AM Wayne Thayer <wth...@mozilla.com> wrote:

> Kathleen pointed out that one of the purposes of this section is to
> require disclosure of cross-certificates, and my first attempted fix seems
> to violate that purpose. Here is my second attempt to clarify the language
> in section 5.3:
>
>
> https://github.com/mozilla/pkipolicy/commit/43bdf5d6e97cdda0d8b11ee0f602a5282e848874
>
> I would appreciate everyone's comments on this proposed change.
>
> If we agree that this achieves the intended effect of requiring separation
> of intermediate certificates by usage but excluding cross-certificates from
> this requirement, then I now believe it will be best for me to publish an
> update of the policy.
>
> - Wayne
>
> On Tue, Jul 17, 2018 at 10:42 AM Bruce via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>

[Wayne Thayer]

The updated 2.6.1 version of the Mozilla Root Store policy resulting from
this discussion is now published:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

- Wayne

On Mon, Aug 6, 2018 at 3:28 PM Wayne Thayer <wth...@mozilla.com> wrote:

> Having received no comments on this proposal, I plan to go ahead and
> publish version 2.6.1 of the Mozilla Root Store Policy with the third
> paragraph of section 5.3 clarified as follows:
>
> Intermediate certificates created after January 1, 2019, with the
> exception of cross-certificates that share a private key with a
> corresponding root certificate:

> * MUST contain an EKU extension; and,
> * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,
> * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection
> KeyPurposeIds in the same certificate.
>

> - Wayne
>
>>
>>