Re: Request to Include 4 Microsoft Root CAs
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include 4 Microsoft Root CAs
(Replying for the correct address this time) On Fri, Aug 16, 2019 at 4:28 PM Jason via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include 4 Microsoft Root CAs
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 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-security-policy@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: >> > 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=0275 >> > >> > * 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 an
Re: Request to Include 4 Microsoft Root CAs
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-security-policy@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: > > 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=0275 > > > > * 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
Re: Request to Include 4 Microsoft Root CAs
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: > 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=0275 > > * 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
Re: Request to Include 4 Microsoft Root CAs
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy