1448093 - Add 2 Microsoft Roots to Mozilla's Root Store

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[bryand]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299

Comment 1

[bryand]

Attachment: Microsoft Root Inclusion Application

Comment 2

[Kathleen Wilson]

Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

In the meantime, please attach your CA's BR Self Assessment to this bug.

https://wiki.mozilla.org/CA/BR_Self-Assessment

https://wiki.mozilla.org/CA/Information_Checklist#Baseline_Requirements_Self_Assessement

Comment 3

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #2)
> Acknowledging receipt of this root inclusion request. I have a huge backlog
> of CA updates/requests to review, so this has been added to my list. I will
> update this bug when I begin information verification of this request as per
> step #2 of our process:
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview
> 
> In the meantime, please attach your CA's BR Self Assessment to this bug.
> 
> https://wiki.mozilla.org/CA/BR_Self-Assessment
> 
> https://wiki.mozilla.org/CA/
> Information_Checklist#Baseline_Requirements_Self_Assessement

This request is next on my list to review, so please attach your BR Self Assessment asap.

Comment 4

[bryand]

Attachment: Microsoft PKI Services BR Self Assessment

Thanks for the heads up.  Here is our BR Self Assessment.  Please let me know if you have any questions or need clarification on anything.

Comment 5

[Kathleen Wilson]

Attachment: CPv3.0.docx

Comment 6

[Kathleen Wilson]

Attachment: CPSv3.0.docx

Comment 7

[Kathleen Wilson]

When do you expect https://www.microsoft.com/pkiops/docs/repository.htm to be updated with these roots, their test websites, and the current version of the CP and CPS?

Comment 8

[Kathleen Wilson]

Please also either add links to the audit statements for these roots to the repository, or attach them to this bug.

Comment 9

[bryand]

(In reply to Kathleen Wilson from comment #7)
> When do you expect https://www.microsoft.com/pkiops/docs/repository.htm to
> be updated with these roots, their test websites, and the current version of
> the CP and CPS?

The new site is build and ready to deploy.  Certs are being issued this week.  The new site should be up by the end of the week or the beginning of next week.

Comment 10

[bryand]

(In reply to bryand from comment #9)
> (In reply to Kathleen Wilson from comment #7)
> > When do you expect https://www.microsoft.com/pkiops/docs/repository.htm to
> > be updated with these roots, their test websites, and the current version of
> > the CP and CPS?
> 
> The new site is built and ready to deploy.  Certs are being issued this
> week.  The new site should be up by the end of the week or the beginning of
> next week.

Comment 11

[Kathleen Wilson]

I deleted the CP and CPS that I had attached (which I got out of the attached application doc), because they must not be the correct version -- too much direct copy-paste from the CABF BR document.

Please add a comment to this bug when the information about these root certs is available in the repository.

Please also provide response (via comment in this bug) to:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
1. Publicly Available CP and CPS:
1.1 Revision Table, updated annually: 
1.2 CAA Domains listed in CP/CPS: 
2. Audit Criteria:
3. Revocation of Compromised Certificates:
4. Verifying Domain Name Ownership:
5. Verifying Email Address Control:
6. DNS names go in SAN:
7. OCSP:
- OCSP SHALL NOT respond "Good" for unissued certs:
8. Network Security Controls:

and

https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
1. Long-lived Certificates:
2. Non-Standard Email Address Prefixes for Domain Ownership Validation:
3. Issuing End Entity Certificates Directly From Roots:
4. Distributing Generated Private Keys in PKCS#12 Files:
5. Certificates Referencing Local Names or Private IP Addresses:
6. Issuing SSL Certificates for .int Domains:
7. OCSP Responses Signed by a Certificate Under a Different Root:
8. Issuance of SHA-1 Certificates:
9. Delegation of Domain / Email Validation to Third Parties:

Comment 12

[bryand]

Attachment: Microsoft Independant Auditor Report

Attached Independent Auditor report for roots submitted for inclusion.

Comment 13

[bryand]

(In reply to Kathleen Wilson from comment #8)
> Please also either add links to the audit statements for these roots to the
> repository, or attach them to this bug.

Posted.

Comment 14

[bryand]

Attachment: Microsoft CP v3.1

Comment 15

[bryand]

Attachment: Microsoft CPS v3.1

Comment 16

[bryand]

(In reply to Kathleen Wilson from comment #11)
> I deleted the CP and CPS that I had attached (which I got out of the
> attached application doc), because they must not be the correct version --
> too much direct copy-paste from the CABF BR document.
> 
> Please add a comment to this bug when the information about these root certs
> is available in the repository.
> 
> Please also provide response (via comment in this bug) to:
> 
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
> 1. Publicly Available CP and CPS:
> 1.1 Revision Table, updated annually: 
> 1.2 CAA Domains listed in CP/CPS: 
> 2. Audit Criteria:
> 3. Revocation of Compromised Certificates:
> 4. Verifying Domain Name Ownership:
> 5. Verifying Email Address Control:
> 6. DNS names go in SAN:
> 7. OCSP:
> - OCSP SHALL NOT respond "Good" for unissued certs:
> 8. Network Security Controls:
> 
> and
> 
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
> 1. Long-lived Certificates:
> 2. Non-Standard Email Address Prefixes for Domain Ownership Validation:
> 3. Issuing End Entity Certificates Directly From Roots:
> 4. Distributing Generated Private Keys in PKCS#12 Files:
> 5. Certificates Referencing Local Names or Private IP Addresses:
> 6. Issuing SSL Certificates for .int Domains:
> 7. OCSP Responses Signed by a Certificate Under a Different Root:
> 8. Issuance of SHA-1 Certificates:
> 9. Delegation of Domain / Email Validation to Third Parties:

I deleted the CP and CPS that I had attached (which I got out of the attached application doc), because they must not be the correct version -- too much direct copy-paste from the CABF BR document. 

[bryand] Posted version v3.1 of both the CP and CPS.  If there are particular areas within these documents that require more detail, please let us know.

Please add a comment to this bug when the information about these root certs is available in the repository. Please also provide response (via comment in this bug) to:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices 

1. Publicly Available CP and CPS: [bryand] Website repository should be updated by 6/25/2018 with the latest CP/CPS.

1.1 Revision Table, updated annually: [bryand] Both the CP and the CPS have updated revision tables.  Section 2.3 of the CP and CPS state that review and version updates will occur annually.

1.2 CAA Domains listed in CP/CPS: [bryand] Addressed in section 4.2.4.

2. Audit Criteria: [bryand] Links to the WebTrust CA audit reports is available on the website repository.
(https://cert.webtrust.org/ViewSeal?id=2303) 
 
3. Revocation of Compromised Certificates: [bryand] Section 4.9 of the CPS outlines revocations procedures.

4. Verifying Domain Name Ownership: [bryand] The BR self-assessment describes which methods Microsoft will use.  The CP and/or CPS will be updated with the next revision.

5. Verifying Email Address Control: [bryand] We do not intend to provide certificates from these roots for digital signing or encrypted email. 

6. DNS names go in SAN: [bryand] We understand the BR requirements #9.2.1 and #9.2.2 and adhere to those requirements. 

7. OCSP: [bryand] The OCSP service being used conforms to these requirements.
- OCSP SHALL NOT respond "Good" for unissued certs: [bryand] Understood.

8. Network Security Controls: [bryand] We understand the Network and Certificate System Security Requirements and are currently being audited against those as part of our ongoing WebTrust audits.  

and https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices 

1. Long-lived Certificates: [bryand] Our CPS (section 6.3.2) states our policy for validity periods that comply with the BRs.

2. Non-Standard Email Address Prefixes for Domain Ownership Validation: [bryand] These requirements are understood and WHOIS contact information will be used for this process.

3. Issuing End Entity Certificates Directly From Roots: [bryand] This is not allowed per section 6.1.7 of our CPS.

4. Distributing Generated Private Keys in PKCS#12 Files: [bryand] We do not generate private keys for our subscribers.

5. Certificates Referencing Local Names or Private IP Addresses: [bryand] This is understood.

6. Issuing SSL Certificates for .int Domains: [bryand] Understood.

7. OCSP Responses Signed by a Certificate Under a Different Root: [bryand] Understood.

8. Issuance of SHA-1 Certificates: [bryand] SHA-1 certificates are not supported as outlined in section 6.1.5 of CPS.

9. Delegation of Domain / Email Validation to Third Parties: [bryand] No delegation is permitted per section 1.3.2 of the CPS.

Comment 17

[Kathleen Wilson]

Please explain the relation between the CP and CPS. 
In particular, what does it mean when the CPS has information about something, but the CP says "No Stipulation"?
CPS section 3.2.2.4 has direct copy-paste from corresponding sections of the BRs, but the corresponding sections in the CP say "No Stipulation".
CPS section 6.7 has info about network security controls, but CP section 6.7 says: "No Stipulation".
CPS section 6.3.2 has info about certificate validity periods, but CP section 6.3.2 says: "No Stipulation".

Also, where in the CP/CPS does it say that those documents apply to these root certs, and the intermediate certs or issuing-CAs in their hierarchies?

Where in the CP/CPS are the following described?
- If these root certs can have externally-operated subCAs or cross-certificates
- If external Registration Authorities are allowed, and can can do domain name verification for SSL certs
- What technical and contractual controls are in place if such external subCAs or RAs are allowed for these roots

Comment 18

[Kathleen Wilson]

Also, in both the CP and CPS it says:
7.1.4.2.1. Subject Alternative Name Extension
No Stipulation

What does that mean in regards to 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#DNS_names_go_in_SAN

Comment 19

[Kathleen Wilson]

Also, both CP and CPS says:
"3.2.2.5 Authentication for an IP Address
No Stipulation"
I'm not sure how to interpret that in regards to
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Certificates_Referencing_Local_Names_or_Private_IP_Addresses

CPS 6.1.5 Key Sizes has info, but CP section 6.1.5 says "No Stipulation"

CPS 1.3.2 Registration Authorities
No RA functions are delegated to third parties by Microsoft PKI Services
OK, but
CP 1.3.2 Registration Authorities
A Registration Authority (RA) is any Legal Entity that is responsible for identification and authentication of Subjects of Certificates, but is not a CA, and hence does not sign or issue Certificates. An RA MAY assist in the Certificate Application process or revocation process or both. When “RA” is used as an adjective to describe a role or function, it does not necessarily imply a separate body, but can be part of the CA.

So, not clear if external RAs are allowed. And if allowed, can they verify domain names for SSL certs...

Comment 20

[Kathleen Wilson]

Also, it appears that you are requesting EV-treatment for these root certs, but I am not finding sufficient info about how the CA must perform verification of identity of the cert subscriber, the authority of the cert subscriber to act on behalf of the organization.

CPS
3.2.2 Authentication of Organization and Domain Identity  -- seems OK to me
3.2.2.1 Identity -- seems OK to me
3.2.3 Authentication of Individual Identity  -- not OK
No Stipulation
3.2.4 Non-Verified Subscriber Information -- not OK
No Stipulation
3.2.5 Validation of Authority  -- does not provide enough info about what the CA must do
Validation of authority (i.e. the determination of whether an Applicant or Subscriber has specific rights, entitlements, or permissions, including the permission to act on behalf of an organization to obtain a Certificate) is the responsibility of the Issuing CA or CA-appointed Registration Authorities (RA). Validation procedures SHALL be conducted as described in the Issuing CA’s CPS document and in accordance to the CAB Forum’s Baseline Requirements and EV Guidelines.


CP -- insufficient, especially for EV treatment
3.2.2 Authentication of Organization and Domain Identity
The Issuing CA SHALL verify the identity of the organization and authority of the Applicant to request Certificates on behalf of the organization, in accordance to procedures set forth in the CAB Forum’s Baseline Requirements.
3.2.2.1 Identity
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
3.2.5 Validation of Authority
Validation of authority (i.e. the determination of whether an Applicant or Subscriber has specific rights, entitlements, or permissions, including the permission to act on behalf of an organization to obtain a Certificate) is the responsibility of the CA or CA-appointed Registration Authority (RA).

Comment 21

[bryand]

(In reply to Kathleen Wilson from comment #17)
> Please explain the relation between the CP and CPS. 
> In particular, what does it mean when the CPS has information about
> something, but the CP says "No Stipulation"?
> CPS section 3.2.2.4 has direct copy-paste from corresponding sections of the
> BRs, but the corresponding sections in the CP say "No Stipulation".
> CPS section 6.7 has info about network security controls, but CP section 6.7
> says: "No Stipulation".
> CPS section 6.3.2 has info about certificate validity periods, but CP
> section 6.3.2 says: "No Stipulation".
> 
> Also, where in the CP/CPS does it say that those documents apply to these
> root certs, and the intermediate certs or issuing-CAs in their hierarchies?
> 
> Where in the CP/CPS are the following described?
> - If these root certs can have externally-operated subCAs or
> cross-certificates
> - If external Registration Authorities are allowed, and can can do domain
> name verification for SSL certs
> - What technical and contractual controls are in place if such external
> subCAs or RAs are allowed for these roots

Please explain the relation between the CP and CPS. 
In particular, what does it mean when the CPS has information about something,
but the CP says "No Stipulation"?
[bryand]The CP was written to allow for multiple CPS to be governed by it.  Therefore, the CP has less detail and specifics as it accounts for other hierarchies controlled by a different CPS than the one that governs the roots we are asking for inclusion to the trusted root program.

CPS section 3.2.2.4 has direct copy-paste from corresponding sections of the
BRs, but the corresponding sections in the CP say "No Stipulation".
CPS section 6.7 has info about network security controls, but CP section 6.7
says: "No Stipulation".
CPS section 6.3.2 has info about certificate validity periods, but CP section
6.3.2 says: "No Stipulation".

Also, where in the CP/CPS does it say that those documents apply to these root
certs, and the intermediate certs or issuing-CAs in their hierarchies?
[bryand] The posted CPS is specific to these roots only and the operation and control of any intermediate or issuing CAs under them.

Where in the CP/CPS are the following described?
- If these root certs can have externally-operated subCAs or cross-certificates [bryand] There will be no externally operated subCAs or cross certificates from these roots.

- If external Registration Authorities are allowed, and can can do domain name [bryand] No external RA is allowed.
verification for SSL certs
- What technical and contractual controls are in place if such external subCAs
or RAs are allowed for these roots
[bryand] There will be no externally operated subCAs or RAs from these roots.

Comment 22

[bryand]

(In reply to Kathleen Wilson from comment #18)
> Also, in both the CP and CPS it says:
> 7.1.4.2.1. Subject Alternative Name Extension
> No Stipulation
> 
> What does that mean in regards to 
> https://wiki.mozilla.org/CA/
> Required_or_Recommended_Practices#DNS_names_go_in_SAN

Also, in both the CP and CPS it says:
7.1.4.2.1. Subject Alternative Name Extension
No Stipulation

What does that mean in regards to 
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#DNS_names_go_in_SAN
[bryand] We understand this requirement and our templates enforce this.

Comment 23

[bryand]

(In reply to Kathleen Wilson from comment #19)
> Also, both CP and CPS says:
> "3.2.2.5 Authentication for an IP Address
> No Stipulation"
> I'm not sure how to interpret that in regards to
> https://wiki.mozilla.org/CA/
> Forbidden_or_Problematic_Practices#Certificates_Referencing_Local_Names_or_Pr
> ivate_IP_Addresses
> 
> CPS 6.1.5 Key Sizes has info, but CP section 6.1.5 says "No Stipulation"
> 
> CPS 1.3.2 Registration Authorities
> No RA functions are delegated to third parties by Microsoft PKI Services
> OK, but
> CP 1.3.2 Registration Authorities
> A Registration Authority (RA) is any Legal Entity that is responsible for
> identification and authentication of Subjects of Certificates, but is not a
> CA, and hence does not sign or issue Certificates. An RA MAY assist in the
> Certificate Application process or revocation process or both. When “RA” is
> used as an adjective to describe a role or function, it does not necessarily
> imply a separate body, but can be part of the CA.
> 
> So, not clear if external RAs are allowed. And if allowed, can they verify
> domain names for SSL certs...
Also, both CP and CPS says:
"3.2.2.5 Authentication for an IP Address
No Stipulation"
I'm not sure how to interpret that in regards to
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Certificates_Referencing_Local_Names_or_Private_IP_Addresses
[bryand] We understand this requirement and will not allow this.

CPS 6.1.5 Key Sizes has info, but CP section 6.1.5 says "No Stipulation"
[bryand] Again, the CP is overarching governance document across different hierarchies that each have their own CPS.  The CPS posted here is only for the roots that are submitted for inclusion in the trusted root program.

CPS 1.3.2 Registration Authorities
No RA functions are delegated to third parties by Microsoft PKI Services
OK, but
CP 1.3.2 Registration Authorities
A Registration Authority (RA) is any Legal Entity that is responsible for
identification and authentication of Subjects of Certificates, but is not a CA,
and hence does not sign or issue Certificates. An RA MAY assist in the
Certificate Application process or revocation process or both. When “RA” is
used as an adjective to describe a role or function, it does not necessarily
imply a separate body, but can be part of the CA.

So, not clear if external RAs are allowed. And if allowed, can they verify
domain names for SSL certs...
[bryand] The CP does not restrict it but the CPS for these roots does as described above.

Comment 24

[bryand]

(In reply to Kathleen Wilson from comment #20)
> Also, it appears that you are requesting EV-treatment for these root certs,
> but I am not finding sufficient info about how the CA must perform
> verification of identity of the cert subscriber, the authority of the cert
> subscriber to act on behalf of the organization.
> 
> CPS
> 3.2.2 Authentication of Organization and Domain Identity  -- seems OK to me
> 3.2.2.1 Identity -- seems OK to me
> 3.2.3 Authentication of Individual Identity  -- not OK
> No Stipulation
> 3.2.4 Non-Verified Subscriber Information -- not OK
> No Stipulation
> 3.2.5 Validation of Authority  -- does not provide enough info about what
> the CA must do
> Validation of authority (i.e. the determination of whether an Applicant or
> Subscriber has specific rights, entitlements, or permissions, including the
> permission to act on behalf of an organization to obtain a Certificate) is
> the responsibility of the Issuing CA or CA-appointed Registration
> Authorities (RA). Validation procedures SHALL be conducted as described in
> the Issuing CA’s CPS document and in accordance to the CAB Forum’s Baseline
> Requirements and EV Guidelines.
> 
> 
> CP -- insufficient, especially for EV treatment
> 3.2.2 Authentication of Organization and Domain Identity
> The Issuing CA SHALL verify the identity of the organization and authority
> of the Applicant to request Certificates on behalf of the organization, in
> accordance to procedures set forth in the CAB Forum’s Baseline Requirements.
> 3.2.2.1 Identity
> No Stipulation
> 3.2.3 Authentication of Individual Identity
> No Stipulation
> 3.2.4 Non-Verified Subscriber Information
> No Stipulation
> 3.2.5 Validation of Authority
> Validation of authority (i.e. the determination of whether an Applicant or
> Subscriber has specific rights, entitlements, or permissions, including the
> permission to act on behalf of an organization to obtain a Certificate) is
> the responsibility of the CA or CA-appointed Registration Authority (RA).
Also, it appears that you are requesting EV-treatment for these root certs, but
I am not finding sufficient info about how the CA must perform verification of
identity of the cert subscriber, the authority of the cert subscriber to act on
behalf of the organization.

CPS
3.2.2 Authentication of Organization and Domain Identity  -- seems OK to me
3.2.2.1 Identity -- seems OK to me
3.2.3 Authentication of Individual Identity  -- not OK
No Stipulation [bryand]We will not be issuing to any natural persons from these roots. 
3.2.4 Non-Verified Subscriber Information -- not OK
No Stipulation [bryand]We reviewed other trusted CAs and found limited or similar information.  We will review and update our CPS to provided additional specifics for our next revision.
3.2.5 Validation of Authority  -- does not provide enough info about what the
CA must do
Validation of authority (i.e. the determination of whether an Applicant or
Subscriber has specific rights, entitlements, or permissions, including the
permission to act on behalf of an organization to obtain a Certificate) is the
responsibility of the Issuing CA or CA-appointed Registration Authorities (RA).
Validation procedures SHALL be conducted as described in the Issuing CA’s CPS
document and in accordance to the CAB Forum’s Baseline Requirements and EV
Guidelines.
[bryand] We will update our CPS to reflect more specifics in these areas.  I will post the new version in approximately one week.


CP -- insufficient, especially for EV treatment
3.2.2 Authentication of Organization and Domain Identity
The Issuing CA SHALL verify the identity of the organization and authority of
the Applicant to request Certificates on behalf of the organization, in
accordance to procedures set forth in the CAB Forum’s Baseline Requirements.
3.2.2.1 Identity
No Stipulation
3.2.3 Authentication of Individual Identity
No Stipulation
3.2.4 Non-Verified Subscriber Information
No Stipulation
3.2.5 Validation of Authority
Validation of authority (i.e. the determination of whether an Applicant or
Subscriber has specific rights, entitlements, or permissions, including the
permission to act on behalf of an organization to obtain a Certificate) is the
responsibility of the CA or CA-appointed Registration Authority (RA).
[bryand] The CP will not cover the EV specifics for validation, but the CPS should (see above).

Comment 25

[Kathleen Wilson]

OK. Please add a comment to this bug when:
* the CPS has been updated
* test websites are available
* https://www.microsoft.com/pkiops/docs/repository.htm has been updated

Comment 26

[Jason Cooper]

The repository and test pages have been updated. https://www.microsoft.com/pkiops/docs/repository.htm

The CPS changes are with our governance body for review and will be published as soon as possible.

Comment 27

[bryand]

Attachment: Microsoft PKI Services BR Self Assessment -Updated

Minor numbering correction.

Comment 28

[bryand]

Attachment: Microsoft_PKI_Services_CP_v3.1.1

Comment 29

[bryand]

Attachment: Microsoft_PKI_Services_CPS_v3.1.1.

Comment 30

[Kathleen Wilson]

I will be reviewing this request again soon. However, I am still stuck on the following problems with this request.

1) The CP allows for other, yet-to-be-determined CPS's to state how the BRs are met and what sorts of audits are performed.

For example, Section 8.1 of the CPS says: "The CA must have an independent auditor annually assess the CA’s compliance to the stated requirements and practices of this CPS, the CP, and/or the CAB Forum’s Baseline Requirements and EV Guidelines."

While I'm not convinced that the "and/or" passes muster, it is better than what the CP says...

Section 8.1 of the CP says: "The CA must have an independent auditor annually assess the CA’s compliance to the stated requirements and practices of the CP and respective CPS."

In the CP, it says:
"3.2.2.4 Validation of Domain Authorization or Control
No Stipulation"

So, if I am understanding this correctly, the CA could create a subCA in the future with its own CPS that allows for issuance of SSL certs but that does not get audited according to the BRs, and does not require domain validation according to the BRs.

It seems to me that the CP that governs all current and future subCAs must state the requirements for cert issuance within that hierarchy. 

And again, please see
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership


2) Please provide current WebTrust CA and WebTrust BR audit statements that meet Mozilla's requirements:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#313-audit-parameters
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information


3) Please test to verify that the test websites perform as expected. For example:
Fix errors listed here:
https://certificate.revocationcheck.com/actrsaevroot2017.pki.microsoft.com
https://certificate.revocationcheck.com/rvkrsaevroot2017.pki.microsoft.com

Comment 31

[Bryan.Dent]

Attachment: Microsoft Independant Auditor Report 2018

Comment 32

[Kathleen Wilson]

The following has been clarified for me:

Microsoft's CP applies to both their external (publicly trusted) CA operations as well as their internal (not publicly trusted) CA operations.

The Microsoft PKI Services CPS (Microsoft_PKI_Services_CPS) is for the external (publicly trusted) CA operations, so is the one governing the root certificates in this request.

The Microsoft PKI Services Corporate CPS (Microsoft_PKI_Services_Corporate-CPS) governs the private PKI of Microsoft PKI Services, so not relevant to this root inclusion request.


Therefore, I will proceed with Information Verification of this request, and one of my asks will be for the CA to update the Microsoft PKI Services CPS to bind that CPS to the root certificates that it applies to.

Comment 33

[Kathleen Wilson]

Attachment: 1448093-CA-Information-Sept14-2018.pdf

The attached document shows the information that has been verified. Search the document for "NEED" to see where further clarification is needed.

In particular, the CA needs to:

1) Update the Microsoft PKI Services CPS to bind that CPS to the root certificates that it applies to.

2) For each root provide a description of the PKI hierarchy rooted at or otherwise associated with the root CA certificate. And a list of all of the subordinate CAs that are signed by this root. Our preference is that this information be provided in the CPS.

3) Provide BR Audit statements that cover all 4 of the root certs.

4) Provide EV Audit statements that cover the 2 EV root certs.

5) Update the following sections of the CPS to replace "No Stipulation" with relevant information.
-- 3.2.2.5 Authentication for an IP Address 
-- 3.2.2.6 Wildcard Domain Validation 
-- 7.1.4.2.1. Subject Alternative Name Extension
(And clarify in section 3.1.1 that Subject Alternative Name (SAN) *MUST* be used for SSL certs.

6) Make sure that the SSL certs for the revoked test websites are actually revoked and in the corresponding CRLs.

7) Fix errors listed here:
https://certificate.revocationcheck.com/actrsaevroot2017.pki.microsoft.com
https://certificate.revocationcheck.com/actrsaroot2017.pki.microsoft.com
https://certificate.revocationcheck.com/acteccevroot2017.pki.microsoft.com
https://certificate.revocationcheck.com/acteccroot2017.pki.microsoft.com

8) Perform Lint testing to ensure that all certs issued in these CA hierarchies are BR and x.509 compliant
https://github.com/awslabs/certlint
https://github.com/kroeckx/x509lint
Or you can use: 
https://crt.sh/lintcert
https://crt.sh/linttbscert

9) Make sure that your EV test websites are set up correctly, and then verify by testing here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 34

[Bryan.Dent]

Thanks.  We are reviewing now and are in the process of making the appropriate changes/updates.  We'll follow up if we have any questions or need clarification.

Comment 35

[Kathleen Wilson]

We have added a section to our Required Practices page:

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647

In particular, please note the bullet points regarding the use of "No Stipulation", and how Mozilla will interpret it in CP/CPS documents.

Comment 36

[Bryan.Dent]

Attachment: Microsoft_PKI_Services_CPS_v3.1.2.

Comment 37

[Bryan.Dent]

Attachment: Microsoft PKI EV SSL Indp Acct Report and Mgmt Assertion November 2018

Comment 38

[Bryan.Dent]

Attachment: Microsoft PKI SSL BR Indp Acct Report and Mgmt Assertion November 2018

Comment 39

[Bryan.Dent]

Here is our responses.  Latest CPS and audit reports have also been uploaded.  Please let us know if you have any questions or need clarification on anything.

1)	Update the Microsoft PKI Services CPS to bind that CPS to the root certificates that it applies to.
[MS] CPS has been updated to reflect the appropriate roots within scope.
2)	For each root provide a description of the PKI hierarchy rooted at or otherwise associated with the root CA certificate. And a list of all of the subordinate CAs that are signed by this root. Our preference is that this information be provided in the CPS.
[MS] CPS has been updated with a list of subordinate CAs within scope.
3)	Provide BR Audit statements that cover all 4 of the root certs.
[MS] The audit statements have been attached to this bug.
4)	Provide EV Audit statements that cover the 2 EV root certs.
[MS] The audit statements have been attached to this bug.
5)	Update the following sections of the CPS to replace "No Stipulation" with relevant information. 
-- 3.2.2.5 Authentication for an IP Address 
-- 3.2.2.6 Wildcard Domain Validation 
-- 7.1.4.2.1. Subject Alternative Name Extension 
(And clarify in section 3.1.1 that Subject Alternative Name (SAN) *MUST* be used for SSL certs.
 [MS] CPS has been updated to clarify these points.
6)	Make sure that the SSL certs for the revoked test websites are actually revoked and in the corresponding CRLs.
[MS] Complete.
7)	Fix errors listed here: https://certificate.revocationcheck.com/actrsaevroot2017.pki.microsoft.com
 https://certificate.revocationcheck.com/actrsaroot2017.pki.microsoft.com 
https://certificate.revocationcheck.com/acteccevroot2017.pki.microsoft.com
 https://certificate.revocationcheck.com/acteccroot2017.pki.microsoft.com
	[MS] These have been tested and addressed where necessary.  Explanation of content type error below.  Please let us know if you need additional information or clarification.
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.  
8)	Perform Lint testing to ensure that all certs issued in these CA hierarchies are BR and x.509 compliant 
https://github.com/awslabs/certlint 
https://github.com/kroeckx/x509lint
 Or you can use: 
https://crt.sh/lintcert
 https://crt.sh/linttbscert
	[MS] All certificates have been tested and are compliant.
9)	Make sure that your EV test websites are set up correctly, and then verify by testing here:
a.	https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
 [MS] All tests completed and compliant.

Comment 40

[Kathleen Wilson]

Mozilla's process has changed from using PDF documents to directly pulling information from the Root Inclusion Case in the CCADB. The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000275

Please verify the information.

Mozilla is also moving to a process in which CAs requesting inclusion in our program are asked to enter the applicable CA hierarchies into the system. Instructions are here:

https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

Please also:

1) Provide instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, or any other matter related to certificates. Preference is an email address that the CA closely monitors.
Examples: https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport

2) Resolve the SEC_ERROR_OCSP_INVALID_SIGNING_CERT error being returned by the EV Checker
https://tls-observatory.services.mozilla.com/static/ev-checker.html
OCSP errors also reported here: https://crt.sh/ocsp-responders

Comment 41

[Bryan.Dent]

We have verified the content in the CCADB and added the additional hierarchy information.

All inquiries and incidents can be initiated using the [e-mail] alias or the associated link on the public facing repository at https://www.microsoft.com/pkiops/docs/repository.htm  

We are working with our OCSP service provider to address the error referenced above and expect it will be resolved soon.

Comment 42

[Kathleen Wilson]

(In reply to Bryan.Dent from comment #41)
> We have verified the content in the CCADB and added the additional hierarchy
> information.
> 
> All inquiries and incidents can be initiated using the
> [e-mail] alias or the associated link on the
> public facing repository at
> https://www.microsoft.com/pkiops/docs/repository.htm  
> 

Thanks.

> We are working with our OCSP service provider to address the error
> referenced above and expect it will be resolved soon.

Please add a comment to this bug when the OCSP errors have been resolved.

Comment 43

[Bryan.Dent]

We have addressed the error(s) and believe we are now compliant. Please let us know if you find any other issues or have any questions.

Comment 44

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000275

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

Comment 45

[Jason Cooper]

Attachment: Microsoft PKI WTCA Indp Acct Opinion and Mgmt Assertion Dec 2018

Attaching our most recent Auditor Opinion Letters

Comment 46

[Jason Cooper]

Attachment: Microsoft PKI WTBR Indp Acct Opinion and Mgmt Assertion Dec 2018 - FINAL - SECURED.pdf

Attaching most recent Auditor Opinion Letters.

Comment 47

[Jason Cooper]

Attachment: Microsoft PKI WTEV SSL Indp Acct Opinion and Mgmt Assertion Dec 2018

Attaching most recent Auditor Opinion Letters.

Comment 48

[Jason Cooper]

I added the most recent opinion letters from our auditors to this bug. I'll make another post once repository site is updated with new WebTrust seals.

Comment 49

[Jason Cooper]

The seals with links to WebTrust management and auditor letters are live on our repository site. https://www.microsoft.com/pkiops/docs/repository.htm

Comment 50

[Kathleen Wilson]

I entered the new audits into the root inclusion case:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000275

Then ran Audit Letter Validation (ALV), which failed to find this SHA256 Thumbprint in the audit statement:
Root Case No. R00000633
Microsoft ECC Root Certificate Authority 2017
FEA1884AB3AEA6D0DBEDBE4B9CD9FEC8655116300A86A856488FC488BB4B44D2

I have verified that this thumbprint is not in the audit statements.

The table of in-scope CAs that is duplicated in both the Management's Assertions and the audit statements has two problems:

1. incorrect SHA256 Thumbprint for Microsoft ECC Root Certificate Authority 2017
2. incorrect SHA256 Thumbprint for Microsoft EV RSA Root Certificate Authority 2017

Also, did the EV audit really include the two non-EV roots? (as specified in the table in the EV Management's Assertion and audit statement)

Comment 51

[Jason Cooper]

I just discussed with auditors and we are working on uploading the correct appendices. Thanks for catching this issue. Regarding the audit scope, yes, we had all four roots audited to the same certification levels (WTCA, WTBR and WTEV). I'll post an update when the statements on WebTrust site are fixed.

Comment 52

[Jason Cooper]

This issue has been fixed. The correct statements are available on the WebTrust site.

Comment 53

[Kathleen Wilson]

(In reply to Jcooper from comment #52)

This issue has been fixed. The correct statements are available on the WebTrust site.

ALV passes now. Thanks.

I think I must be missing one of your WebTrust CA audit statements...

Prior WebTrust CA audit:
https://bugzilla.mozilla.org/attachment.cgi?id=9009197
Standard Audit Period Start Date: 5/1/2017
Standard Audit Period End Date: 4/30/2018

Current WebTrust CA audit:
https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=230016
Standard Audit Period Start Date: 11/1/2018
Standard Audit Period End Date: 12/31/2018

So there appears to be gap of auditing between 4/30/2018 and 11/1/2018.
Please advise.

Comment 54

[Jason Cooper]

Thanks, glad we got that resolved.

Our annual audit period is 5/1 to 4/30, so we are in process of closing out the audit for 5/1/2018 to 4/30/2019. That audit includes the period you note. We did an additional/concurrent Period of Time audit from 11/1/2018 to 12/31/2018 on top of the annual audit period. That is the audit that resulted in the current seals on our repository and corresponding statements on the WebTrust site.

Does that make sense?

Comment 55

[Kathleen Wilson]

(In reply to Jcooper from comment #54)

Thanks, glad we got that resolved.

Our annual audit period is 5/1 to 4/30, so we are in process of closing out the audit for 5/1/2018 to 4/30/2019. That audit includes the period you note. We did an additional/concurrent Period of Time audit from 11/1/2018 to 12/31/2018 on top of the annual audit period. That is the audit that resulted in the current seals on our repository and corresponding statements on the WebTrust site.

Does that make sense?

Yes. Thank you for the clarification.

Comment 56

[Wayne Thayer]

I have completed a preliminary review of the information gathered and have the following comments:

• This application states that normal audit period ends on 4/30. When can you provide the audit statements for full period up to 5/1/2019?
• CPS section 3.2.4 states that OU is not verified, however, BR section 7.1.4.2.2(i) does place requirements on this field, and the CPS makes it unclear if these requirements are met.
• CPS section 3.2.5 states 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. Please confirm that Microsoft implements the method described in BR section 3.2.5 for OV certificates.
• CPS section 6.1.5 indicates that P-512 keys may be used. Please confirm that Microsoft aware that this violates section 5.1 of the Mozilla Root Store policy.
• It’s been more than a year since the CP has been updated. CPS and BR section 2 require annual updates.
• CP/CPS section 1.5.2 does not meet the BR 4.9.3 requirement to provide clear problem reporting instructions.

Would Microsoft like to make any CP/CPS updates before I begin the discussion period? I recommend resolving at least the last two comments.

Comment 57

[Jason Cooper]

Thanks for completing your preliminary review. We are in the process making changes to all CP/CPS documents with our PKI Policy Authority and should have then done in the next week or so. We should also have the audit statements available for your review in the same time frame. I'll report back shortly with updates as I have them. I agree that it makes sense to resolve these open items prior to discussion.

Comment 58

[Jason Cooper]

We have published updated CP/CPS documents that should address Wayne's observations as noted above. Please let us know if you have any questions. You can view the updated documents and the renewed WebTrust seals with links to current audit statements on our repository site

https://www.microsoft.com/pkiops/docs/repository.htm

I'll upload the audit statements to this thread as well. When are you planning to begin the discussion period?

Comment 59

[Jason Cooper]

Attachment: Microsoft PKI WTCA Indp Acct Opinion and Mgmt Assertion Apr 2019.pdf

Comment 60

[Jason Cooper]

Attachment: Microsoft PKI WTBR Indp Acct Opinion and Mgmt Assertion Apr 2019.pdf

Comment 61

[Jason Cooper]

Attachment: Microsoft PKI WTEV SSL Indp Acct Opinion and Mgmt Assertion Apr 2019.pdf

Comment 62

[Wayne Thayer]

Discussion period has begun: https://groups.google.com/d/msg/mozilla.dev.security.policy/Q2k_5eGXqmA/Tp373WeNAQAJ

Comment 63

[Jason Cooper]

Hi Wayne,

Do you have any questions or concerns now that the discussion period has closed? Please advise on next steps.

Comment 64

[Wayne Thayer]

The discussion period for this request has ended. I believe that all questions have been answered, so I am recommending approval of this request.

Link to the discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/Q2k_5eGXqmA/Tp373WeNAQAJ

Comment 65

[Kathleen Wilson]

As per Comment #64, and on behalf of Mozilla I approve this request from Microsoft Corporation to include the following root certificates:

** 'Microsoft RSA Root Certificate Authority 2017' (Websites)
** 'Microsoft ECC Root Certificate Authority 2017' (Websites)
** 'Microsoft EV RSA Root Certificate Authority 2017' (Websites), enable EV
** 'Microsoft EV ECC Root Certificate Authority 2017' (Websites), enable EV

I will file the NSS and PSM bugs for the approved changes.

Comment 66

[Kathleen Wilson]

I have filed bug #1582254 against NSS and bug #1582258 against PSM for the actual changes.

Comment 67

[Ryan Sleevi]

Kathleen: I was doing some spot checks on Mozilla policy compliance, specifically Section 5.3 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

The requirement is (formatted for readability)

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.

The certificate https://crt.sh/?q=623a0d3c6e325795aadaa36599301afd90392f46519f5b238fbe22936bbd5ccc was issued by the "Microsoft EV RSA Root Certificate Authority 2017" (mentioned in Comment #65), created on 2019-05-14, and lacks an EKU. I wasn't sure whether to open a CA incident for this, considering that Bug #1582254 is not yet resolved, and the CA was not part of the Mozilla program at the time. Thoughts?

Comment 68

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #67)

The certificate https://crt.sh/?q=623a0d3c6e325795aadaa36599301afd90392f46519f5b238fbe22936bbd5ccc was issued by the "Microsoft EV RSA Root Certificate Authority 2017" (mentioned in Comment #65), created on 2019-05-14, and lacks an EKU. I wasn't sure whether to open a CA incident for this, considering that Bug #1582254 is not yet resolved, and the CA was not part of the Mozilla program at the time. Thoughts?

Ryan, Please proceed with creating the CA Incident bug. Thanks!

Comment 69

[Julio Montano]

The four roots to be added to the Mozilla trusted root program are as follows:

http://www.microsoft.com/pkiops/certs/Microsoft ECC Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft RSA Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft EV ECC Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft EV RSA Root Certificate Authority 2017.crt

Comment 70

[Kathleen Wilson]

(In reply to Julio Montano from comment #69)

The four roots to be added to the Mozilla trusted root program are as follows:

http://www.microsoft.com/pkiops/certs/Microsoft ECC Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft RSA Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft EV ECC Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft EV RSA Root Certificate Authority 2017.crt

Julio, Please provide audit statements and test websites (valid, revoked, expired) for all of the new root certs.

Comment 71

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #70)

Julio, Please provide audit statements and test websites (valid, revoked, expired) for all of the new root certs.

Please also update section 1.1 of the CPS to include the new roots and issuing CAs.

Comment 72

[John Mason]

Microsoft is ready to include 2 new roots at this time, as the 2 EV roots we were hoping to include have been impacted by Covid-19 prioritizations.

The 2 roots we would like included now are:
http://www.microsoft.com/pkiops/certs/Microsoft ECC Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft RSA Root Certificate Authority 2017.crt

Here is the information for each Root.

• Microsoft ECC Root Certificate Authority 2017

o Test Websites
 Valid - http://acteccroot2017.pki.microsoft.com/
 Revoked - http://rvkeccroot2017.pki.microsoft.com/
 Expired - http://expeccroot2017.pki.microsoft.com/

o Audit Statements
 WTCA
• https://www.microsoft.com/pkiops/docs/Content/seals/Microsoft%20WTCA%20Indp%20Acct%20Opinion%20and%20Mgmt%20Assertion%20Dec%202019%20-%20Final%20-%20SECURED.pdf
 WTEV
• https://www.microsoft.com/pkiops/docs/Content/seals/Microsoft%20WTEV%20SSL%20Indp%20Acct%20Opinion%20and%20Mgmt%20Assertion%20Dec%202019%20-%20Final%20-%20SECURED.pdf
 WTBR
• https://www.microsoft.com/pkiops/docs/Content/seals/Microsoft%20WTBR%20Indp%20Acct%20Opinion%20and%20Mgmt%20Assertion%20Dec%202019%20-%20Final%20-%20SECURED.pdf

o CPS with Roots and Issuing CA’s
 https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.4.pdf

• Microsoft RSA Root Certificate Authority 2017

o Test Websites
 Valid - http://actrsaroot2017.pki.microsoft.com/
 Revoked - http://rvkrsaroot2017.pki.microsoft.com/
 Expired - http://exprsaroot2017.pki.microsoft.com/

o Audit Statements
 WTCA
• https://www.microsoft.com/pkiops/docs/Content/seals/Microsoft%20WTCA%20Indp%20Acct%20Opinion%20and%20Mgmt%20Assertion%20Dec%202019%20-%20Final%20-%20SECURED.pdf
 WTEV
• https://www.microsoft.com/pkiops/docs/Content/seals/Microsoft%20WTEV%20SSL%20Indp%20Acct%20Opinion%20and%20Mgmt%20Assertion%20Dec%202019%20-%20Final%20-%20SECURED.pdf
 WTBR
• https://www.microsoft.com/pkiops/docs/Content/seals/Microsoft%20WTBR%20Indp%20Acct%20Opinion%20and%20Mgmt%20Assertion%20Dec%202019%20-%20Final%20-%20SECURED.pdf

o CPS with Roots and Issuing CA’s
 https://www.microsoft.com/pkiops/Docs/Content/policy/Microsoft_PKI_Services_CPS_v3.1.4.pdf

Please Note:
• All Microsoft PKI Services Governance, Audit and CA information can be found in our PKI Repository located here (https://www.microsoft.com/pkiops/docs/repository.htm).
• In December of 2019 our WTBR audit included a Modified Opinion related to an audit log issue that was disclosed in Bugzilla Bug 1602999 (https://bugzilla.mozilla.org/show_bug.cgi?id=1602999). The bug is now resolved, and the issue is fixed. We just concluded another WTBR audit period with our auditors (1/1/20 – 4/30/20) that is on track , as of this writing, for a clean opinion and that audit letter will be available in late June.

Comment 73

[Kathleen Wilson]

(In reply to John Mason from comment #72)

Microsoft is ready to include 2 new roots at this time, as the 2 EV roots we were hoping to include have been impacted by Covid-19 prioritizations.

The 2 roots we would like included now are:
http://www.microsoft.com/pkiops/certs/Microsoft ECC Root Certificate Authority 2017.crt
http://www.microsoft.com/pkiops/certs/Microsoft RSA Root Certificate Authority 2017.crt

I have filed bug #1641716 against NSS to include the 2 non-EV root certificates.

I have also updated the root inclusion case:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000275

Comment 74

[Kathleen Wilson]

Since this request has not been updated in 2 years, I'm going to do the following:

1. Change the title and Whiteboard to represent that only the 2 non-EV root certificates were added.

2. Close this request as resolved/fixed.

Microsoft may open a new request to include their EV root certificates if they are inclined to do so.