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 < [email protected]> 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=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 > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
