Request to Include 4 Microsoft Root CAs

[Wayne Thayer]

This request is for inclusion of the Microsoft RSA Root Certificate
Authority 2017, Microsoft ECC Root Certificate Authority 2017, Microsoft EV
RSA Root Certificate Authority 2017, and Microsoft EV ECC Root Certificate
Authority 2017 trust anchors as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448093

* BR Self Assessment is
https://bugzilla.mozilla.org/attachment.cgi?id=8989260

* Summary of Information Gathered and Verified:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000275

* Root Certificate Download URL:
https://www.microsoft.com/pkiops/docs/repository.htm

* CP/CPS:
** CP:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CP_v3.1.2.pdf
** CPS:
https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.3.pdf

* This request is to include the roots with the websites trust bit enabled,
and with EV treatment.

* Test Websites
** Valid: https://actrsaevroot2017.pki.microsoft.com/,
https://actrsaroot2017.pki.microsoft.com/,
https://acteccevroot2017.pki.microsoft.com/,
https://acteccroot2017.pki.microsoft.com/
** Expired: https://exprsaevroot2017.pki.microsoft.com/,
https://exprsaroot2017.pki.microsoft.com/,
https://expeccevroot2017.pki.microsoft.com/,
https://expeccroot2017.pki.microsoft.com/
** Revoked: https://rvkrsaevroot2017.pki.microsoft.com/,
https://rvkrsaroot2017.pki.microsoft.com/,
https://rvkeccevroot2017.pki.microsoft.com/,
https://rvkeccroot2017.pki.microsoft.com/

* CRL URLs:
** ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20ECC%20Root%20Certificate%20Authority%202017.crl
** RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crl
** EV ECC:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20ECC%20Root%20Certificate%20Authority%202017.crl
** EV RSA:
http://www.microsoft.com/pkiops/crl/Microsoft%20EV%20RSA%20Root%20Certificate%20Authority%202017.crl

* OCSP URL:http://ocsp.msocsp.com

* Audit: Annual audits are performed by BDO according to the WebTrust for
CA, BR, and EV audit criteria.
** WebTrust for CA: https://bugzilla.mozilla.org/attachment.cgi?id=9083810
** BR: https://bugzilla.mozilla.org/attachment.cgi?id=9083812
** EV: https://bugzilla.mozilla.org/attachment.cgi?id=9083813

I’ve reviewed the CP, CPS, BR Self Assessment, and related information for
inclusion of the Microsoft roots that are being tracked in this bug and
have the following comments:

==Good==
* A root key generation ceremony audit report has been provided [1].

==Meh==
* CPS section 3.2.4 stated that OU is not verified, however, BR section
7.1.4.2.2(i) does place requirements on this field, and the CPS made it
unclear if these requirements are met. This was clarified in the latest
version of the CPS.
* CPS section 3.2.5 stated that Microsoft PKI Services shall verify
authority for all certificate requests, and that for Domain Validated
requests, this is done using one of the methods described in the BRs.
Section 3.2.5 of the BRs only describes validation of authority for OV
certificates using a reliable method of communication. This was clarified
in the latest version of the CPS.
* CPS section 6.1.5 indicated that P-512 keys may be used, which would
violate Mozilla policy. This was corrected in the latest version of the CPS.
* The content-type header in CRL responses is not set to
'application/pkix-crl' but to 'application/octet-stream' (RFC 5280, section
4.2.1.13). Microsoft explanation: the reason for the content-type being set
to octet-stream is that we use a content upload service at Microsoft that
hosts different types of content. All of the content in the service is
hosted in Azure’s BLOB storage and the content type by default is octet
stream. This has not been an issue because the browsers will resolve the
file type based on the extension in the file name. It should also be noted
that the RFC 5280 shows SHOULD rather than MUST.

==Bad==
* It had been more than a year since the CP was updated when I reviewed
this request. CPS and BR section 2 require annual updates. The CP was
updated on 5-August.
* CP/CPS section 1.5.2 did not meet the BR 4.9.3 requirement to provide
clear problem reporting instructions. This was corrected in the latest
versions of the CP and CPS.
* A number of unrevoked certificates chaining to the Microsoft RSA Root
Certificate Authority 2017 have recently been issued with BR violations [2]

This begins the 3-week comment period for this request [3].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of these roots into the Mozilla CA program.

- Wayne

[1] https://bug1448093.bmoattachments.org/attachment.cgi?id=8986854
[2]
https://crt.sh/?caid=109424&opt=cablint,zlint,x509lint&minNotBefore=2019-05-01
[3] https://wiki.mozilla.org/CA/Application_Process

[Jason]

Hi All,

This is Jason from the Microsoft PKI Services team. I’d like to add some context to the note about the certs issued from the Microsoft RSA Root Certificate Authority 2017. As you can see, these were all issued to a domain registered to Microsoft. While these clearly violate the Subject profile requirements in Section 7 of the BRs, nearly all the certs listed meet the requirements for Test Certificate as listed in Section 1.6.1 of the BRs, including the presence of the “Test” OID (2.23.140.2.1) in a critical extension. A few of the test issuances did not meet the requirements of 1.6.1 and we have adjusted our policy enforcement mechanisms accordingly as a result. That said, we have created an incident around this for purposes of reporting to our auditors. Please feel free to let me know if you have questions.

Thanks,
Jason Cooper

[Daniel Marschall]

Hello,

Is there an EV Policy OID assigned? I can't find it.

- Daniel

[Wayne Thayer]

Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV.

Unless a CA has an existing EV policy OID associated with root(s) in our
program, we have been strongly encouraging the use of the CAB Forum OID.

This request is past the 3-week minimum discussion period. If no
significant comments are posted, I will close it on Tuesday 10-September.

- Wayne

On Mon, Aug 19, 2019 at 2:57 AM Daniel Marschall via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> Hello,
>
> Is there an EV Policy OID assigned? I can't find it.
>
> - Daniel
>
>
> Am Mittwoch, 14. August 2019 00:42:44 UTC+2 schrieb Wayne Thayer:

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Wayne Thayer]

Having received no further comments, I have recommended approval of this
request in bug 1448093.

- Wayne

On Thu, Sep 5, 2019 at 5:16 PM Wayne Thayer <wth...@mozilla.com> wrote:

> Microsoft will use the CAB Forum OID 2.23.140.1.1 for EV.
>
> Unless a CA has an existing EV policy OID associated with root(s) in our
> program, we have been strongly encouraging the use of the CAB Forum OID.
>
> This request is past the 3-week minimum discussion period. If no
> significant comments are posted, I will close it on Tuesday 10-September.
>
> - Wayne
>
> On Mon, Aug 19, 2019 at 2:57 AM Daniel Marschall via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>
>> Hello,
>>
>> Is there an EV Policy OID assigned? I can't find it.
>>
>> - Daniel
>>
>>
>> Am Mittwoch, 14. August 2019 00:42:44 UTC+2 schrieb Wayne Thayer:

[Ryan Sleevi]

(Replying for the correct address this time)

While this thread has closed, and Microsoft's roots have been included, I
want to circle back on this, as recently another CA brought this up.

Microsoft's answer here is not correct, and is actually quite concerning.
Microsoft included the "Test" OID ( 2.23.140.2.1 ) not as a critical
/extension OID/, but as the contents within an extension (specifically,
certificatePolicies).

This is actually quite concerning. The purpose of the "Test" OID was to be
a 'poison' extension - i.e. an unrecognized critical extension that
prevents the certificate from being usable - not a general "you can stick
this anywhere in the cert" (e.g. within a QCStatements, for example).

However, equally important is that while the term "Test Certificate" is
included within the BRs, it's actually part of a specific reference to a
particular validation method, within 3.2.2.4.9, which MUST NOT be used.

So there's nothing in the BRs that authorize this Test Certificate, and the
certificate does not contain "an extension with the specified Test
Certificate CABF OID (2.23.140.2.1)" - i.e. an extension with the OID
"2.23.140.2.1" is not present.

I felt it important to correct this, on the thread, since this was the
first occurrence of this misinterpretation. It also represents a Serious
Misissuance by Microsoft, as it not only missed the requirements for Test
Certificate, but also missed where they were explicitly forbidden from use.

[wth...@gmail.com]

I’d like to update everyone on the status of this Microsoft root inclusion request:

After it was approved, Kathleen filed bug #1582254 [1] requesting that these four roots be added to NSS. Then it was pointed out in a different mozilla.dev.security.policy thread [2] that the roots submitted for inclusion contained a null character at the end of the CPS URI. In response, Microsoft filed incident bug #1598390 [3], and in that bug it was further pointed out that the same problem affected intermediates in the hierarchy. Microsoft decided to remediate the problem by creating new roots and intermediates to replace the affected certificates. I have recommended in bug #1582254 [1] that Mozilla proceed with the addition of the corrected roots to NSS.

Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1582254
[2] https://groups.google.com/d/msg/mozilla.dev.security.policy/ui5XV7wbalw/4n20lWvYBAAJ
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1598390