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

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=E2=80=99s CA Certificate Progra=
m.
>

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=3DemailProtection) <-- Intermediate
certificate (EKU=3DemailProtection) <-- leaf certificate (S/MIME)
2 - Root <-- Cross-certificate (EKU=3DserverAuth) <-- Intermediate
certificate (EKU=3DserverAuth) <-- 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/vbt=
nfJ4zCAAJ
0
Wayne
7/10/2018 11:21:07 PM
mozilla.dev.security.policy 1337 articles. 2 followers. Post Follow

9 Replies
49 Views

Similar Articles

[PageSpeed] 20

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

I think the intent was to technically restrict subordinate CAs or rather CA=
s 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 w=
as no intended to issue and 2) mitigate the risk if an online subordinate C=
A has been compromised.=20

Typically, if an old root cross-certifies a new root, the purpose is to giv=
e 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 cro=
ss-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 o=
f technical restriction may already be satisfied.

Thanks, Bruce.=20

On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:
> During a 2.6 policy discussion [1], we agreed to add the following langua=
ge
> to section 5.3 "Intermediate Certificates":
>=20
> > 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.
> >
>=20
> It has been pointed out to me that the very next paragraph of section 5.3
> states:
>=20
> These requirements include all cross-certified certificates which chain t=
o
> > a certificate that is included in Mozilla=E2=80=99s CA Certificate Prog=
ram.
> >
>=20
> 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 distinc=
t
> cross-certificates would be required for serverAuth and emailProtection, =
as
> follows:
>=20
> 1 - Root <-- Cross-certificate (EKU=3DemailProtection) <-- Intermediate
> certificate (EKU=3DemailProtection) <-- leaf certificate (S/MIME)
> 2 - Root <-- Cross-certificate (EKU=3DserverAuth) <-- Intermediate
> certificate (EKU=3DserverAuth) <-- leaf certificate (SSL/TLS)
>=20
> 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?
>=20
> What is the correct interpretation of section 5.3 of the policy as
> currently written?
>=20
> I would appreciate everyone's input on these questions.
>=20
> - Wayne
>=20
> [1]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/QIweY3cHRyA/v=
btnfJ4zCAAJ

0
Bruce
7/12/2018 2:27:31 PM
------=_NextPart_000_0BBB_01D41A7F.B8F527B0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=3Ddigicert.com@lists.mozilla.org] On Behalf Of =
Bruce via
> dev-security-policy
> Sent: Thursday, July 12, 2018 10:28 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> S/MIME?
>=20
> Note the BRs define Cross Certificate as "a certificate that is used =
to establish a
> trust relationship between two Root CAs."
>=20
> 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.
>=20
> 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.
>=20
> Thanks, Bruce.
>=20
> On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:
> > 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=E2=80=99s 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=3DemailProtection) <-- =
Intermediate
> > certificate (EKU=3DemailProtection) <-- leaf certificate (S/MIME)
> > 2 - Root <-- Cross-certificate (EKU=3DserverAuth) <-- Intermediate
> > certificate (EKU=3DserverAuth) <-- 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://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH
> iAL
> > jfsD2zgM=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Fgroups.google.com
> %2Fd%2Fm
> > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ
>=20
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31p
> FYXlE5W5k=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Flists.mozilla.or
> g%2Flistinfo%2Fdev-security-policy

------=_NextPart_000_0BBB_01D41A7F.B8F527B0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ
Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw
CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl
cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw
05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW
sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF
YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP
QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn
AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T
AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9
bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E
gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz
c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k
76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX
mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP
KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx
e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5
oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN
AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz
MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB
MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A
J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+
yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo
8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh
rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV
HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp
Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA
ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0
AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA
ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh
AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP
2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ
pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI
EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB
VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes
EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTgwNzEzMTIwMTM2WjAvBgkqhkiG9w0BCQQxIgQggXE06PvIqdcQBvH/DlpdcXF06+Zd
wYfjvsh3Hl+2dF4wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAD2T18xF31Ghmmgt7yC33NQmtiOND3veEowiWqhTsOEZQI+Eno2jYjGBBPznASkUYufE0kRq
XH+99z7o8G5zH3tRrfHLo5MAGBG93Y9zdcwj1DyJ0mrjUskrLwAQPAd9n/e28NZoe+6YcrFYSfMf
moclmAE2wmw+pgXdftGZ21eHV4tFvWADTFbUCakTVArxAeZcPHbKalAfnQ+C4sEzHzrcDb04dW8j
QZx8G+L4jvFvZSUmWydJdck4PQY8aPzongvL7skHXs4SX0sf/l6A63EfL7Z5lxZA/N8VAmFhEjRF
5rlC0LxPmeOCTDtP6X4+BG/v8nle7VxP4hvGjWVwDXwAAAAAAAA=

------=_NextPart_000_0BBB_01D41A7F.B8F527B0--
0
Tim
7/13/2018 12:01:47 PM
Agreed that old cross-certificates will not be impacted, but this does impa=
ct 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 tha=
t was intended by this policy change.

Bruce.

On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote:
> 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 nex=
t year?
>=20
> -Tim
>=20
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=3Ddigicert.com@lists.mozilla.org] On Behalf Of Br=
uce via
> > dev-security-policy
> > Sent: Thursday, July 12, 2018 10:28 AM
> > To: mozilla-dev-security-policy@lists.mozilla.org
> > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> > S/MIME?
> >=20
> > Note the BRs define Cross Certificate as "a certificate that is used to=
 establish a
> > trust relationship between two Root CAs."
> >=20
> > I think the intent was to technically restrict subordinate CAs or rathe=
r CAs
> > which are online and issue end entity certificates. My assumption is th=
at we
> > want to 1) not allow a subordinate CA to issue a certificate which it w=
as no
> > intended to issue and 2) mitigate the risk if an online subordinate CA =
has been
> > compromised.
> >=20
> > 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 Au=
th, 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 te=
chnical
> > restriction may already be satisfied.
> >=20
> > Thanks, Bruce.
> >=20
> > On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote:
> > > 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=E2=80=99s CA Certificate =
Program.
> > > >
> > >
> > > The term "cross-certified certificates" could refer to the actual
> > > cross-certificate, or it could refer to intermediate certificates tha=
t
> > > chain up to the cross certificate. In the case of a root that is bein=
g
> > > 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=3DemailProtection) <-- Intermedia=
te
> > > certificate (EKU=3DemailProtection) <-- leaf certificate (S/MIME)
> > > 2 - Root <-- Cross-certificate (EKU=3DserverAuth) <-- Intermediate
> > > certificate (EKU=3DserverAuth) <-- 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://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH
> > iAL
> > > jfsD2zgM=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Fgroups.google.com
> > %2Fd%2Fm
> > > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ
> >=20
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31p
> > FYXlE5W5k=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Flists.mozilla.or
> > g%2Flistinfo%2Fdev-security-policy

0
Bruce
7/13/2018 2:16:49 PM
------=_NextPart_000_0BED_01D41ACC.542C31A0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yeah, I agree I don=E2=80=99t 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=3Ddigicert.com@lists.mozilla.org] On Behalf Of =
Bruce via
> dev-security-policy
> Sent: Friday, July 13, 2018 10:17 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Re: Do We Now Require Separate Cross-certificates for SSL and
> S/MIME?
>=20
> 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.
>=20
> Bruce.
>=20
> On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote:
> > 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=3Ddigicert.com@lists.mozilla.org] On Behalf =
Of
> > > bounces+Bruce via
> > > dev-security-policy
> > > Sent: Thursday, July 12, 2018 10:28 AM
> > > To: mozilla-dev-security-policy@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:
> > > > 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=E2=80=99s 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=3DemailProtection) <--
> > > > Intermediate certificate (EKU=3DemailProtection) <-- leaf
> > > > certificate (S/MIME)
> > > > 2 - Root <-- Cross-certificate (EKU=3DserverAuth) <-- =
Intermediate
> > > > certificate (EKU=3DserverAuth) <-- 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://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH
> > > iAL
> > > > jfsD2zgM=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Fgroups.google.com
> > > %2Fd%2Fm
> > > > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ
> > >
> > > _______________________________________________
> > > dev-security-policy mailing list
> > > dev-security-policy@lists.mozilla.org
> > >
> https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31
> > > p
> > > FYXlE5W5k=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Flists.mozilla.or
> > > g%2Flistinfo%2Fdev-security-policy
>=20
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/wNze3hZcZDNkGJs2uz-
> SeEqGu_7QRemtNV2zTN4w6eA=3D?d=3DUWO2h2txAwcfMe5bqfj4PnyJC-fPf-
> jWINE8QAK6rKZhjWzUPs2jCHsJL_KIV6tsKYcbL2mfdvUjwCVFDiT3BvhiR5V29scB
> NCPx3iSBUFGl4Hch0iE4oi7chSA365HSr4m2CYJGYldzjUmox9DS7D7rArUAHY1XB
> Mek0obO98xn3LgdmNKeL5XUoGDW4Q85610Pj4Aa_0hbpgKzl870mCIXsGjH4Xl
> y28s1mHQU1dGwygaOH4n6iK6GqI1xJ20HjyZaQOkY8Sk5PE5xb8f1Cv_WcHNsPt
> Wnum0eUZ9_Sn904q_2Q1aXb7Y0weCKKCaU9ELY6ugItt8ngKWOHmtVyo0Ef-
> 3FzIfu1UTDqGWG169kW0w4F611kLa1gnEhpP8HmcECC0eThNLgqX57tzbUED6
> RF0iM96G520RE6U2hL2sj-
> TafMqmwPdgMMlyEaDeri1vaMgRhWihiFj8th7o1JcIa5PfWas8KYPzteyOYY2jDT
> 2EfeLpWB2b7&u=3Dhttps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> security-policy

------=_NextPart_000_0BED_01D41ACC.542C31A0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ
Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw
CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl
cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw
05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW
sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF
YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP
QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn
AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T
AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9
bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E
gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz
c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k
76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX
mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP
KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx
e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5
oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN
AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz
MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB
MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A
J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+
yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo
8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh
rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV
HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp
Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA
ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0
AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA
ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh
AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP
2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ
pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI
EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB
VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes
EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTgwNzEzMjEwOTU4WjAvBgkqhkiG9w0BCQQxIgQgvMzz3etlbY3LZftw5thjezVIXnfk
Y4DnOMeaeTNNGN0wgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAEIfzrDFutR3qleplFXCyJVlYBgE/GEo/Hf2m0yPVqkEK9X+4zN0WzdKgmtNXfvaChLXGNYR
wBp6iEov8DDh2Di5yjpmtcYjxDrk+njfWgPO34lmcWywYDkEEdcX5AAHFEXzWIDyNxuAxg/TAZD3
zieeSpRqNMVJaAbHuJaJJm/FgTLeO4Km3lEvyD+I4TirDE7JoLe2+9uyL3sROq4NeoJ4BbNVzQ9H
eExjwH43heMB4ZAgvb2YOkwmNWRCituz4IuWy5AakZue/HtWitBwuFYP5jvlhlYoRm3LABmYTg+X
SZyKu9VJJF0B9CLHUOFCjsnEsvvwfgmFtzzVYmtVVhwAAAAAAAA=

------=_NextPart_000_0BED_01D41ACC.542C31A0--
0
Tim
7/13/2018 10:48:36 PM
On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Yeah, I agree I don=E2=80=99t think it was intended.  But now that I am a=
ware of
> the issue, I think the crossing workaround per EKU is actually a good thi=
ng
> 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 w=
ay.
>
>
>
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=E2=80=99s 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=3Ddigicert.com@lists.mozilla.org] On Behalf Of
> Bruce via
> > dev-security-policy
> > Sent: Friday, July 13, 2018 10:17 AM
> > To: mozilla-dev-security-policy@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:
> > > 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=3Ddigicert.com@lists.mozilla.org] On Behalf O=
f
> > > > bounces+Bruce via
> > > > dev-security-policy
> > > > Sent: Thursday, July 12, 2018 10:28 AM
> > > > To: mozilla-dev-security-policy@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 use=
d
> > > > 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 issu=
e
> > > > 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 i=
s
> > > > 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:
> > > > > During a 2.6 policy discussion [1], we agreed to add the followin=
g
> > > > > 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=E2=80=99s CA Certific=
ate
> 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 tha=
t
> > > > > 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=3DemailProtection) <--
> > > > > Intermediate certificate (EKU=3DemailProtection) <-- leaf
> > > > > certificate (S/MIME)
> > > > > 2 - Root <-- Cross-certificate (EKU=3DserverAuth) <-- Intermediat=
e
> > > > > certificate (EKU=3DserverAuth) <-- 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 a=
s
> > > > > currently written?
> > > > >
> > > > > I would appreciate everyone's input on these questions.
> > > > >
> > > > > - Wayne
> > > > >
> > > > > [1]
> > > > >
> > > >
> > https://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH
> > > > iAL
> > > > > jfsD2zgM=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Fgroups.google.com
> > > > %2Fd%2Fm
> > > > > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ
> > > >
> > > > _______________________________________________
> > > > dev-security-policy mailing list
> > > > dev-security-policy@lists.mozilla.org
> > > >
> > https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31
> > > > p
> > > > FYXlE5W5k=3D?d=3D5n7PC5UMMMf8ow60aA_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=3Dhttps%3A%2F%2Flists.mozilla.or
> > > > g%2Flistinfo%2Fdev-security-policy
> >
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://clicktime.symantec.com/a/1/wNze3hZcZDNkGJs2uz-
> > SeEqGu_7QRemtNV2zTN4w6eA=3D?d=3DUWO2h2txAwcfMe5bqfj4PnyJC-fPf-
> > jWINE8QAK6rKZhjWzUPs2jCHsJL_KIV6tsKYcbL2mfdvUjwCVFDiT3BvhiR5V29scB
> > NCPx3iSBUFGl4Hch0iE4oi7chSA365HSr4m2CYJGYldzjUmox9DS7D7rArUAHY1XB
> > Mek0obO98xn3LgdmNKeL5XUoGDW4Q85610Pj4Aa_0hbpgKzl870mCIXsGjH4Xl
> > y28s1mHQU1dGwygaOH4n6iK6GqI1xJ20HjyZaQOkY8Sk5PE5xb8f1Cv_WcHNsPt
> > Wnum0eUZ9_Sn904q_2Q1aXb7Y0weCKKCaU9ELY6ugItt8ngKWOHmtVyo0Ef-
> > 3FzIfu1UTDqGWG169kW0w4F611kLa1gnEhpP8HmcECC0eThNLgqX57tzbUED6
> > RF0iM96G520RE6U2hL2sj-
> > TafMqmwPdgMMlyEaDeri1vaMgRhWihiFj8th7o1JcIa5PfWas8KYPzteyOYY2jDT
> > 2EfeLpWB2b7&u=3Dhttps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> > security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
0
Wayne
7/16/2018 11:24:45 PM
On Monday, July 16, 2018 at 7:25:09 PM UTC-4, Wayne Thayer wrote:
> On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>=20
> > Yeah, I agree I don=E2=80=99t think it was intended.  But now that I am=
 aware of
> > the issue, I think the crossing workaround per EKU is actually a good t=
hing
> > 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 separatel=
y.
> I've created https://github.com/mozilla/pkipolicy/issues/145 to track thi=
s
> 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.
>=20
> 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 planni=
ng
> > 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 w=
as
> amended to:
>=20
> These requirements include all intermediate certificates signed by
> cross-certificates which chain to a certificate that is included in
> Mozilla=E2=80=99s CA Certificate Program.
>=20
> 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?

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

Thanks, Bruce.
0
Bruce
7/17/2018 5:41:18 PM
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/43bdf5d6e97cdda0d8b11ee0f602a52=
82e848874

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-security-policy@lists.mozilla.org> wrote:

> On Monday, July 16, 2018 at 7:25:09 PM UTC-4, Wayne Thayer wrote:
> > On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Yeah, I agree I don=E2=80=99t 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 intende=
d
> to
> > apply to cross certificates. I think that is the meaning of the existin=
g
> > 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=E2=80=99s 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 certificate=
s
> > goes into effect, or can this wait since it is only a clarification?
>
> Since this is only a clarification, then  I think the change can wait
> until the next update of the Mozilla policy.
>
> Thanks, Bruce.
>
>
0
Wayne
7/18/2018 6:55:54 PM
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 <wthayer@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 seem=
s
> to violate that purpose. Here is my second attempt to clarify the languag=
e
> in section 5.3:
>
>
> https://github.com/mozilla/pkipolicy/commit/43bdf5d6e97cdda0d8b11ee0f602a=
5282e848874
>
> I would appreciate everyone's comments on this proposed change.
>
> If we agree that this achieves the intended effect of requiring separatio=
n
> of intermediate certificates by usage but excluding cross-certificates fr=
om
> 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-security-policy@lists.mozilla.org> wrote:
>
>> On Monday, July 16, 2018 at 7:25:09 PM UTC-4, Wayne Thayer wrote:
>> > On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy =
<
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > > Yeah, I agree I don=E2=80=99t think it was intended.  But now that I=
 am aware
>> of
>> > > the issue, I think the crossing workaround per EKU is actually a goo=
d
>> 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 existi=
ng
>> > 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=E2=80=99s CA Certificate Program.
>> >
>> > Questions:
>> > - does anyone object to that new wording?
>> > - should the official policy be updated with this change prior to 1-Ja=
n
>> > when the requirement to separate usages of new intermediate certificat=
es
>> > goes into effect, or can this wait since it is only a clarification?
>>
>> Since this is only a clarification, then  I think the change can wait
>> until the next update of the Mozilla policy.
>>
>> Thanks, Bruce.
>>
>>
0
Wayne
8/6/2018 10:28:50 PM
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 <wthayer@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
>
>>
>>
0
Wayne
8/14/2018 11:34:27 PM
Reply: