1040072 - Add MULTICERT Root Certificate

Status: RESOLVED WONTFIX

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

Description

[ca.forum]

Attachment: GeneralinformationabouttheCA.pdf

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Comment 1

[ca.forum]

Attachment: Accreditation of MULTICERT Root CA by Gabinete Nacional de Segurança

Comment 2

[him]

Super CA?

Comment 3

[Kathleen Wilson]

I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification



(In reply to him from comment #2)
> Super CA?

I don't know.

Sara, please see the description of a Super-CA, and clarify.
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs

Comment 4

[ca.forum]

Yes, it is a Super CA. This is a Offline SuperCA which issue certificate for other MULTICERT Subordinate CA's. 

All CA's, including SuperCA, are audited annually.

Comment 5

[ca.forum]

Website for testing
https://promotor.teste.multicert.com/

Comment 6

[him]

It is not a requirement (at least of the CA/B Baseline) but do you plan on adding the CA Issuers extension?

Comment 7

[ca.forum]

We're not using at the moment. However, we are planing to include this extension in the certificate profiles as soon as possible.

Comment 8

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness, and provide the necessary information in this bug.

Comment 9

[ca.forum]

Attachment: New document with reviewed information and new audit statements.

New document with reviewed information and new audit statements.

Comment 10

[Kathleen Wilson]

Please attach the audit statements directly to this bug.

>> This does respect to our subordinates MULTICERT CA 002 and MULTICERT CA 001 wich are, for now,
signed by Baltimore as well.

Does this mean that the subordinate "MULTICERT CA 002" is signed by both "MULTICERT Root Certification Authority 01" and "Baltimore CybertTrust Root"?

Comment 11

[Kathleen Wilson]

Attachment: 1040072-CAInformation.pdf

I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information (search for NEED in the pdf).

Comment 12

[ca.forum]

(In reply to Kathleen Wilson from comment #10)
> Please attach the audit statements directly to this bug.
> 
> >> This does respect to our subordinates MULTICERT CA 002 and MULTICERT CA 001 wich are, for now,
> signed by Baltimore as well.
> 
> Does this mean that the subordinate "MULTICERT CA 002" is signed by both
> "MULTICERT Root Certification Authority 01" and "Baltimore CybertTrust Root"?

Yes Kathleen. For now, MULTICERT CA 001 and 002 are signed by both MULTICERT and Baltimore Root CA's.

Comment 13

[ca.forum]

Attachment: ETSI 101 456 Audit

Comment 14

[ca.forum]

Attachment: ETSI 102 042 /BR Audit

Comment 15

[Kathleen Wilson]

(In reply to ca.forum from comment #14)
> Created attachment 8651752 [details]
> ETSI 102 042 /BR Audit

When audit statements are provided by the Certification Authority rather than having an audit statement posted on the auditor's website, the Mozilla process requires doing an independent verification of the authenticity of the audit statements that have been provided. Therefore, I have sent email to [e-mail] to confirm the authenticity of the audit statement.


As per Comment #11, the following items are still needed:

1) NEED to resolve all errors listed here:
https://certificate.revocationcheck.com/promotor.teste.multicert.com

2) NEED: Please carefully read sections 8 through 14 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
and confirm that all future subCAs of MULTICERT will be required to be audited by an independent, competent party according to the ETSI or WebTrust audit criteria as per sections 11 through 14 of Mozilla's policy (unless they are technically constrained as described in section 9 of Mozilla policy).
Is this audit requirement in your CP/CPS? 

3) NEED URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying that the email address to be included in the certificate is owned/controlled by the certificate subscriber.
as per item #4 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

4) NEED URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates as per item #4 of
https://wiki.mozilla.org/CA:Information_checklist#CA_Hierarchy_information_for_each_root_certificate

Comment 16

[ca.forum]

1) NEED to resolve all errors listed here:
https://certificate.revocationcheck.com/promotor.teste.multicert.com

[MULTICERT] MULTICERT Certification Authority exists since 2008 and was always signed by Baltimore. Last year, MULTICERT wage on its own Root Certification Authority.  Thinking on our clients, We decide to maintain the Baltimore Root while our root was not recognized in every systems. 
 
That’s why you have that problem in the OCSP. The url promotor.teste.multicert.com is using a ssl certificate and the server has the MULTICERT chain configured. However, in order to have a correct response to our client, we have, in the OCSP service, a responder with the Baltimore Chain.  


2) NEED: Please carefully read sections 8 through 14 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
and confirm that all future subCAs of MULTICERT will be required to be audited by an independent, competent party according to the ETSI or WebTrust audit criteria as per sections 11 through 14 of Mozilla's policy (unless they are technically constrained as described in section 9 of Mozilla policy).
Is this audit requirement in your CP/CPS? 

[MULTICERT]http://pkiroot.multicert.com/pol/CPS_MULTICERT_PJ.ECRAIZ_24.1.1_0001_en.pdf --> Chapter 9


3) NEED URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying that the email address to be included in the certificate is owned/controlled by the certificate subscriber.
as per item #4 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

[MULTICERT] We are implementing this issue at the moment. The due   date is the 31 December. Until there, a new CP and CPS will be launched. 

4) NEED URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates as per item #4 of
https://wiki.mozilla.org/CA:Information_checklist#CA_Hierarchy_information_for_each_root_certificate

[MULTICERT]  https://pki.multicert.com/index.html. You can find here all the subordinate CA’s belonging to MULTICERT PKI.

Comment 17

[ca.forum]

About the ETSI 102 042 Audit Statement, is this issue closed?

Comment 18

[Kathleen Wilson]

(In reply to ca.forum from comment #16)
> 1) NEED to resolve all errors listed here:
> https://certificate.revocationcheck.com/promotor.teste.multicert.com
> 
> [MULTICERT] MULTICERT Certification Authority exists since 2008 and was
> always signed by Baltimore. Last year, MULTICERT wage on its own Root
> Certification Authority.  Thinking on our clients, We decide to maintain the
> Baltimore Root while our root was not recognized in every systems. 
>  
> That’s why you have that problem in the OCSP. The url
> promotor.teste.multicert.com is using a ssl certificate and the server has
> the MULTICERT chain configured. However, in order to have a correct response
> to our client, we have, in the OCSP service, a responder with the Baltimore
> Chain.  
> 


I don't understand.

Do you have your own OCSP service?

Can you set up a test server that does not have any dependency on the Baltimore Chain or OCSP service?

Comment 19

[ca.forum]

We do have our own OCSP, however we must have the Baltimore chain configured in the OCSP service until we have our Root CA available in Mozilla trusted store.

However, we are trying to set up a testing environment like you ask.

Comment 20

[ca.forum]

The new test server wihtout any depency from Baltimore is available for testing.

https://promotor.teste.multicert.com

Comment 21

[Kathleen Wilson]

(In reply to ca.forum from comment #20)
> The new test server wihtout any depency from Baltimore is available for
> testing.
> 
> https://promotor.teste.multicert.com


Still getting errors:
https://certificate.revocationcheck.com/promotor.teste.multicert.com

Comment 22

[ca.forum]

We can not explain why this error occurs.

We have study the OCSP response for promotor.teste.multicert.com as well for www.cgd.com using https://certificate.revocationcheck.com.

The problem existing with multicert ocsp signature doesn’t happens with cgd ocsp signature. In order to find out what this error is, we had download both OCSP requests and responses from this site and analyzed them with OpenSSL. 

The signature is performed the same way. Apparently the site doesn’t publish the multicert OCSP signing certificate, but, if you use the OpenSSL to decode the OCSP response, you'll be able to get it.
In other hand, we issue millions of ocsp responses, and we have no complains.
You may find attached all the results.
Is this site (https://certificate.revocationcheck.com) owned by Mozilla?

Comment 23

[ca.forum]

Attachment: OCSP_Clarification.pdf

We can not explain why this error occurs.

We have study the OCSP response for promotor.teste.multicert.com as well for www.cgd.com using https://certificate.revocationcheck.com.

The problem existing with multicert ocsp signature doesn’t happens with cgd ocsp signature. In order to find out what this error is, we had download both OCSP requests and responses from this site and analyzed them with OpenSSL. 

The signature is performed the same way. Apparently the site doesn’t publish the multicert OCSP signing certificate, but, if you use the OpenSSL to decode the OCSP response, you'll be able to get it.
In other hand, we issue millions of ocsp responses, and we have no complains.
You may find attached all the results.
Is this site (https://certificate.revocationcheck.com) owned by Mozilla?

Comment 24

[Kathleen Wilson]

(In reply to ca.forum from comment #23)
> Is this site (https://certificate.revocationcheck.com) owned by Mozilla?

I have sent email to the owner of the revocationcheck site to see if he can determine what the cause of the error is.

In the meantime, please let me know when the updated CP/CPS are available as per Comment #16.
> 3) NEED URLs and section/page number information pointing directly to the
> sections of the CP/CPS documents that describe the procedures for verifying
> that the email address to be included in the certificate is owned/controlled
> by the certificate subscriber.
> as per item #4 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices
> 
> [MULTICERT] We are implementing this issue at the moment. The due   date is
> the 31 December. Until there, a new CP and CPS will be launched.

Comment 25

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #24)
> (In reply to ca.forum from comment #23)
> > Is this site (https://certificate.revocationcheck.com) owned by Mozilla?
> 
> I have sent email to the owner of the revocationcheck site to see if he can
> determine what the cause of the error is.

Here's his reply: The server returns a response signed with a "1.3.14.3.2.29" signature algorithm instead of "1.2.840.113549.1.1.5".

> 
> In the meantime, please let me know when the updated CP/CPS are available as
> per Comment #16.
> > 3) NEED URLs and section/page number information pointing directly to the
> > sections of the CP/CPS documents that describe the procedures for verifying
> > that the email address to be included in the certificate is owned/controlled
> > by the certificate subscriber.
> > as per item #4 of
> > https://wiki.mozilla.org/CA:
> > Information_checklist#Verification_Policies_and_Practices
> > 
> > [MULTICERT] We are implementing this issue at the moment. The due   date is
> > the 31 December. Until there, a new CP and CPS will be launched.

Comment 26

[ca.forum]

(In reply to Kathleen Wilson from comment #25)
> (In reply to Kathleen Wilson from comment #24)
> > (In reply to ca.forum from comment #23)
> > > Is this site (https://certificate.revocationcheck.com) owned by Mozilla?
> > 
> > I have sent email to the owner of the revocationcheck site to see if he can
> > determine what the cause of the error is.
> 
> Here's his reply: The server returns a response signed with a
> "1.3.14.3.2.29" signature algorithm instead of "1.2.840.113549.1.1.5".

MULTICERT - Problem resolved. Please Check at https://certificate.revocationcheck.com. Don't forget to clear the browser chache.
> 
> > 
> > In the meantime, please let me know when the updated CP/CPS are available as
> > per Comment #16.
> > > 3) NEED URLs and section/page number information pointing directly to the
> > > sections of the CP/CPS documents that describe the procedures for verifying
> > > that the email address to be included in the certificate is owned/controlled
> > > by the certificate subscriber.
> > > as per item #4 of
> > > https://wiki.mozilla.org/CA:
> > > Information_checklist#Verification_Policies_and_Practices
> > > 
> > > [MULTICERT] We are implementing this issue at the moment. The due   date is
> > > the 31 December. Until there, a new CP and CPS will be launched.

[MULTICERT] . We are implementing a new feature to automatically confirm the user email. 31 of January is the due date.

Comment 27

[Kathleen Wilson]

(In reply to ca.forum from comment #13)
> Created attachment 8651751 [details]
> ETSI 101 456 Audit

(In reply to ca.forum from comment #14)
> Created attachment 8651752 [details]
> ETSI 102 042 /BR Audit

I have exchanged email with the auditor to confirm the authenticity of these audit statements.

Comment 28

[Kathleen Wilson]

(In reply to ca.forum from comment #26)
> [MULTICERT] . We are implementing a new feature to automatically confirm the
> user email. 31 of January is the due date.

Please update this bug when the updated CP/CPS is available.

Comment 29

[ca.forum]

We are now confirming User email on the Subject registration. 

Please see page 21 at the url https://pki.multicert.com/pol/cp/MULTICERT_PJ.CA3_24.1.2_0002_en.pdf.

Comment 30

[Kathleen Wilson]

(In reply to ca.forum from comment #29)
> We are now confirming User email on the Subject registration. 
> 
> Please see page 21 at the url
> https://pki.multicert.com/pol/cp/MULTICERT_PJ.CA3_24.1.2_0002_en.pdf.

Thanks!

I was just testing BR compliance, and got an error...

http://cert-checker.allizom.org/
Root Cert: http://pkiroot.multicert.com/cert/MCRootCA.cer
Test Website: https://promotor.teste.multicert.com/

/C=PT/O=MC/OU=Certificado SSL/CN=promotor.teste.multicert.com
...
    Error
        BR certificates with organizationName must include either localityName or stateOrProvinceName

Please comment in this bug when the error has been resolved.

Comment 31

[ca.forum]

Problem solved.

This issue was related to a certificate profile we have for testing the production certificate chain. We had issued a few certificates for chain testing and this one was, in a wrong way, included in this tests.

We have just correct this situation by issuing a new certificate in the right profile, which is online now.

Comment 32

[Kathleen Wilson]

Attachment: 1040072-CAInformation-Complete.pdf

Comment 33

[Kathleen Wilson]

This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

Comment 34

[ca.forum]

Attachment: New ETSI 102 042 /BR Audit Statment 2016

Comment 35

[Kathleen Wilson]

(In reply to ca.forum from comment #34)
> Created attachment 8746964 [details]
> New ETSI 102 042 /BR Audit Statment 2016

As per Mozilla's process, I have exchanged email with the auditor to confirm the authenticity of this audit statement.

Comment 36

[ca.forum]

Attachment: New ETSI 101 456 GNS Statement 2016

Comment 37

[Kathleen Wilson]

MULTICERT, Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.

Comment 38

[ca.forum]

Attachment: eIDAS_eSEALS_2017_AuditStatement.jpg

Comment 39

[ca.forum]

Attachment: eiDAS_eSIGN_2017_AuditStatement.jpg

Comment 40

[ca.forum]

Attachment: eIDAS_eWEB_2017_AuditStatement.pdf

Comment 41

[ca.forum]

Attachment: eIDAS_Timestamping_2017_ AuditStatement.jpg

Comment 42

[Kathleen Wilson]

Still waiting for CA's BR Self Assessment, per Comment #37.

Comment 43

[ca.forum]

Kathleen,

We expect to update it next week. 

Regards,

Sara

Comment 44

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 45

[Wayne Thayer]

MULTICERT: Are you still planning to provide a BR Self Assessment?

Also, I took a quick look at this request and identified the following problems:

1. The test site promotor.teste.multicert.com is not accessible
2. The most recent audit statement you provided do not contain all information required by Mozilla policy section 3.1.4 (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/)
3. The CP and CPS were last updated in 2014 and 2015 respectively
4. The document described as the 'SSL CP' (https://pki.multicert.com/pol/cp/MULTICERT_PJ.CA3_24.1.2_0009_pt.pdf) hasn't been translated, doesn't appear to be in RFC 2527 or RFC 3647 format, and doesn't appear to contain all information required by the BRs.
5. A bunch of errors are being identified for certs issued under this root: https://crt.sh/?caid=1602&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01

Comment 46

[ca.forum]

Yes. We are working on it, with a few delays, but we pretend to provide it in the next week. 

We are also analyzing the problem identified.

Comment 47

[ca.forum]

Attachment: 2017 SSL Audit Statement

Comment 48

[Kathleen Wilson]

Moving this bug back to the Information Verification phase, step 2 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

The status if this request is that we are waiting for the CA to attach their BR Self Assessment to this bug.

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

Comment 49

[ca.forum]

Attachment: MulticertBRSelfAssessment10042018.pdf

Hello,

My name is Carla Coutinho, i work in Multicert.
Find attached the Self Assessment for Multicert CA.

Any doubts, feel free to ask.

Best regards,
Carla Coutinho

Comment 50

[ca.forum]

Attachment: 2017 eSign Audit Statement

Comment 51

[ca.forum]

Attachment: 2017 eSeal Audit Statement

Comment 52

[ca.forum]

Attachment: 2017 TSA Audit Statement

Comment 53

[David E. Ross]

Why does this bug report have the severity = critical?  This bug requests an enhancement to the NSS database, not a fix to a discrepancy that represents a loss of existing functionality.

Comment 54

[ca.forum]

My mistake, back to normal

Comment 55

[ca.forum]

Url's for Testing:

https://expired.mtrust.online/ - with an expired certificate
https://revoked.mtrust.online/ - with a revoked certificate
https://demo.mtrust.online/ - with a valid certificate

Comment 56

[ca.forum]

Attachment: 2017 SSL Audit Statement

Comment 57

[ca.forum]

Attachment: 2017 eSeal Audit Statement

Comment 58

[ca.forum]

Attachment: 2017 eSign Audit Statement

Comment 59

[ca.forum]

Attachment: 2017 TSA Audit Statement

Comment 60

[Wayne Thayer]

Reference to MULTICERT misissuance under Camerfirma root: https://bugzilla.mozilla.org/show_bug.cgi?id=1481862

Comment 61

[Kathleen Wilson]

Attachment: 1040072-CA-Information-Aug15-2018.pdf

Attached is the information that has been verified for this request. Within the document search for "NEED" to find where further information is needed from the CA.

In particular:

1) The Audit Statements do not properly specify the audit period start and end dates. 
Audit period is NOT the same as the dates that the audit was performed.
Reference:
Sections 3.1.3 and 3.1.4 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
and
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.0.pdf
Audit Period: In a period-of-time audit, the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined in section 8.1.

2) There is a Confidentiality clause at the top of both of the CP and CPS documents. This is problematic, because Mozilla requires the CA's CP/CPS to be publicly disclosed.
Note that the CP and CPS are published on the CA's website:
https://pki.multicert.com/index.html
So I recommend that the CA remove the confidentiality clauses. 

3) Are you requesting the Email (S/MIME) trust bit for this root?
If requesting the Email (S/MIME) trust bit, then the CP and/or CPS must explain how the CA confirms that the certificate requester owns/controls the email address to be included in the certificate.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

4) Please check that the test websites are serving up the version of the intermediate certificate that chains up to the MULTICERT Root Certification Authority 01 root. I have the MULTICERT Root Certification Authority 01 root imported, but when I disable the Baltimore CyberTrust Root, the SSL validation does not switch over to the MULTICERT Root Certification Authority 01, so the test website fails.

5) Please explain the Lint testing errors:
https://crt.sh/?caid=5842&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04
https://crt.sh/?caid=1602&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04
https://crt.sh/?caid=84368&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04
https://crt.sh/?caid=15339&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04

6) It appears that MULTICERT CA allows for externally-operated subordinate CAs. However, I did not find text in the CP or CPS stating that such externally-operated subCAs must follow the rules of the CP/CPS and must be externally-audited (as per the BRs and Mozilla's requirements), or must be technically constrained, etc.

Comment 62

[ca.forum]

Dear Kathleen,

We are reviewing your inputs and expect to respond within the next few days.

Regards

Sara

Comment 63

[ca.forum]

Dear Kathleen,

Please find below comments to the issues that you posted:

1) The Audit Statements do not properly specify the audit period start and end dates. 
Audit period is NOT the same as the dates that the audit was performed.
Reference:
Sections 3.1.3 and 3.1.4 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
and
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.0.pdf
Audit Period: In a period-of-time audit, the period between the first day (start) and the last day of operations (end) covered by the auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined in section 8.1.

-> The audit was performed between 03.08.2017 to 24.08.2017. In accordance with the requirement 7.6 b) of EN 319 403, “a TSP audit may be passed with pending nonconformities provided that these do not impact the ability of the TSP to meet the intended service. This certification decision is conditional upon to the implementation of corrective actions within 3 months after conclusion of the audit (depending on the type and criticality of the correction(s))”. So, between 03.08.2017 to 24.08.2017 it was performed the audit, and between 3.11.2017 to 19.12.2017, it was performed a new audit, to verify if the non-conformities identified before was resolved.
If necessary, we can provide the auditor contact so you can check.

2) There is a Confidentiality clause at the top of both of the CP and CPS documents. This is problematic, because Mozilla requires the CA's CP/CPS to be publicly disclosed.
Note that the CP and CPS are published on the CA's website:
https://pki.multicert.com/index.html
So I recommend that the CA remove the confidentiality clauses.

-> The new version publicly available does not have the confidentiality clause:
CP (https://pki.multicert.com/docs/EN/MULTICERT_PJ.ECRAIZ_426_en.pdf)
CPS (https://pki.multicert.com/docs/EN/MULTICERT_PJ.ECRAIZ_427_en.pdf)
Subordinate CA Policy (http://pkiroot.multicert.com/politicas/MULTICERT_PJ.ECRAIZ_405_en.pdf)


3) Are you requesting the Email (S/MIME) trust bit for this root?
If requesting the Email (S/MIME) trust bit, then the CP and/or CPS must explain how the CA confirms that the certificate requester owns/controls the email address to be included in the certificate.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

-> Yes, We are requesting the Email trust bit. We validate that the subscriber of the certificate have the possession of the email. We perform this validation in a challenge-response method, in accordance with section 3.2.2 of the CPS.

4) Please check that the test websites are serving up the version of the intermediate certificate that chains up to the MULTICERT Root Certification Authority 01 root. I have the MULTICERT Root Certification Authority 01 root imported, but when I disable the Baltimore CyberTrust Root, the SSL validation does not switch over to the MULTICERT Root Certification Authority 01, so the test website fails.

-> We have corrected the hierarchy chain of the test websites:
Website with valid certificate: https://promotor.teste.multicert.com/
Website with expired certificate: https://expired.mtrust.online/
Website with revoked certificate: https://revoked.mtrust.online/

5) Please explain the Lint testing errors:

https://crt.sh/?caid=5842&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04
-> ERROR: CA certificates must include CRL Signing  This certificate is revoked.
-> The remaining certificates are not SSL OV certificates, but OCSP or TSA certificates. In this case, the filter from crt.sh shouldn’t have been applied. Is this understanding correct?

https://crt.sh/?caid=1602&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04
-> Most of the certificates presented in this filter are revoked or expired. In fact, most of them are not SSL Certificate, but OCSP, TSA and Qualified Signature certificates. Once more, this shouldn’t be on the filter, only SSL certificates. However, we do know that some of them are active and with problems essentially on the 'Organization Name' field that must be less than 64 characters.
To resolve all issues identified and also to give to ours costumers a new version of the Certificate Transparency (initially we were using OCSP stapling and now we implemented the Certificate Extension.), Multicert had established a plan to replace all SSL certificates. We are already replacing the SSL certificates, in phases. Until the end of December this year, we will revoke the previous SSL certificates.

https://crt.sh/?caid=84368&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04´
-> All certificates presented in this filter are revoked.

https://crt.sh/?caid=15339&opt=cablint,zlint,x509lint&minNotBefore=2014-04-04
-> All certificates presented in this filter are OCSP or TSA certificates.

6) It appears that MULTICERT CA allows for externally-operated subordinate CAs. However, I did not find text in the CP or CPS stating that such externally-operated subCAs must follow the rules of the CP/CPS and must be externally-audited (as per the BRs and Mozilla's requirements), or must be technically constrained, etc.

-> We added a section to describe the external certification authorities, in section 1.3.1.1 in CP and CPS. Also, this section refers to the Subordinate CA Policy publicly available, where we describe the practices for external certification authorities. The policy is available here: http://pkiroot.multicert.com/politicas/MULTICERT_PJ.ECRAIZ_405_en.pdf


Available for any question,
Best Regards,
Patrícia Silva

Comment 64

[Wayne Thayer]

MULTICERT misissuance of certificates with validity periods greater than 825 days is documented in bug #1509002

Comment 65

[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. Search in the page for the word "NEED" to see where further clarification is requested.

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

In particular, the CA needs to provide:

1) 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.

2) Updated audit statements per 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information 
and 
https://bugzilla.mozilla.org/show_bug.cgi?id=1502957#c16

3) Resolution to https://bugzilla.mozilla.org/show_bug.cgi?id=1509002
"Camerfirma: MULTICERT certificates with a validity period greater than 825 days"

Comment 66

[Ben Wilson]

Today I sent an email to MULTICERT inquiring whether or not they intend to pursue this root inclusion request.

Comment 67

[Ben Wilson]

MULTICERT responded that they will submit new RSA and ECC root CA certificates when they are ready.

Comment 68

[ca.forum]

Many thanks for updating this bug.

I suggest this one to be closed now and we will file a new one when we are ready to start the process.