1176188 - Enable email trust bit for Actalis Authentication Root CA

Status: RESOLVED FIXED

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

Description

[Adriano Santoni]

This is a request to turn on the mail trust bit for the Actalis root named "Actalis Authentication Root CA".

Our root is already trusted for secure email on all other platforms, with the sole exception of Mozilla, so we would like the email trust bit to be enabled for our root in Mozilla as well.

All information about our current S/MIME certificate services can be found at the following address: 
https://www.actalis.it/products/certificates-for-secure-electronic-mail.aspx

At present, we only have one S/MIME policy:
https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx

This policy incorporates by reference our CPS, to be found here:
https://www.actalis.it/documenti-en/cps-for-ssl-server-and-code-signing.pdf

Our current audit statement does not yet cover these certificates, but the next one will.

Comment 1

[Kathleen Wilson]

Attachment: 1176188-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.

Comment 2

[Adriano Santoni]

Find below the additional information requested:

CP/CPS for email certs
======================
I already provided the link to the relevant CP upon submitting this bug:
https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx

Please note that this CP includes by reference our CPS, which is found at:
https://www.actalis.it/documenti-en/cps-for-ssl-server-and-code-signing.pdf


Auditor Qualifications
======================
Our auditor, IMQ, meets the requirements of ETSI 102 042 - Annex E (Auditors qualification) as it is accredited by Accredia based on ISO/IEC 17021 and ISO 27006, where Accredia is the Italian MLA signatory (as it can be seen on http://www.european-accreditation.org). The accreditations of IMQ can be found at
http://www.accredia.it/ppsearch/accredia_orgmask.jsp?PPSEARCH_ORG_SEARCH_MASK_ORG=0040

Email Address Verification Procedures
=====================================
The procedure can be found under paragraph 3.2.1 of our CP, and I am quoting it below:

"The only element of the requestor’s identity that is collected and verified by the CA is the requestor’s
email address. This is checked by sending a random code to the alleged email address specified
by the requestor in the on-line certificate request form, then asking the requestor to also enter
such code before the certificate request is accepted. The requestor’s ability to enter the correct code
proves that the specified email address exists and the requestor has access to it."

Comment 3

[David E. Ross]

(In reply to adriano.santoni from comment #2)
> "The only element of the requestor’s identity that is collected and verified
> by the CA is the requestor’s
> email address. This is checked by sending a random code to the alleged email
> address specified
> by the requestor in the on-line certificate request form, then asking the
> requestor to also enter
> such code before the certificate request is accepted. The requestor’s
> ability to enter the correct code
> proves that the specified email address exists and the requestor has access
> to it."

This merely proves that the requester has access to the E-mail address.  It does not prove the requester owns the address.

Comment 4

[Adriano Santoni]

Mozilla does not require the CA to assess that the requestor *owns* the address:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

In fact, it reads: "for a certificate to be used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf"

And that's precisely what we do: we take a reasonable measure to verify that the requestor either controls or has access to the mailbox. If the requestor can read the mailbox, either she is the mailbox owner, or she has been allowed by the owner to use that mailbox. In either case, it's ok. Recipients of mail messages sent from that mailbox cannot distinguish the two persons (mailbox "owner" vs. mailbox "user"), based on just the sender's email address, and our S/MIME certificates only contain the email address.

Besides, this procedure is already used by other CAs whos Root is trusted in Mozilla for secure email.

Comment 5

[David E. Ross]

I do not think "access" equals "control".

Comment 6

[Kathleen Wilson]

(In reply to David E. Ross from comment #5)
> I do not think "access" equals "control".

Hi David,

To date, we have allowed this type of challenge-response mechanism, and it is commonly used by the CAs.

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
"The recommended way to satisfy this requirement is to perform a challenge-response type of procedure in which the CA sends email to the email address to be included in the certificate, and the applicant must respond in a way that demonstrates that they have control over that email address. For instance, the CA may send an email to the address to be included in the certificate, containing secret unpredictable information, giving the applicant a limited time to use the information within."

If you think we should change this, then please start a discussion about it in the mozilla.dev.security.policy forum.

Thanks,
Kathleen

Comment 7

[Kathleen Wilson]

Attachment: 1176188-CAInformation-Complete.pdf

Comment 8

[Kathleen Wilson]

I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 9

[Adriano Santoni]

Our latest ETSI TS 102 042 audit statement was just published on our web site at:
https://www.actalis.it/documenti-en/actalisca_audit_statement.pdf

This audit statement shows that also our S/MIME certificates conforms to ETSI TS 102 042, policy LCP.

Comment 10

[Kathleen Wilson]

(In reply to adriano.santoni from comment #9)
> Our latest ETSI TS 102 042 audit statement was just published on our web
> site at:
> https://www.actalis.it/documenti-en/actalisca_audit_statement.pdf
> 
> This audit statement shows that also our S/MIME certificates conforms to
> ETSI TS 102 042, policy LCP.

I exchanged email with the auditor to confirm the authenticity of the audit statement.

Comment 11

[Kathleen Wilson]

I am now opening the public discussion period for this request from Actalis to turn on the Email trust bit for the "Actalis Authentication Root CA" root certificate that was included via Bugzilla Bug #520557, and enabled for EV via Bugzilla Bug #957548.  

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Enable Email trust bit for Actalis root cert".

Please actively review, respond, and contribute to the discussion.

A representative of Actalis must promptly respond directly in the discussion thread to all questions that are posted.

Comment 12

[Kathleen Wilson]

The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical]. 
I am not aware of instances where Actalis has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
Actalis appears to provide a service relevant to Mozilla users. Actalis CA has a wide number of customers, mainly banks and local government. Actalis is a Qualified certification service provider according to the EU Signature Directive (Directive 1999/93/EC). 

Root Certificate Name: Actalis Authentication Root CA
O From Issuer Field: Actalis S.p.A./03358520967
Trust Bits: Code; Email; Websites
EV Policy OID: 1.3.159.1.17.1

Root Certificate Download URL: Already included

Certificate Summary: Requesting that the email trust bit be turned on for the "Actalis Authentication Root CA" root certificate that was included via Bugzilla Bug #520557, and enabled for EV via Bugzilla Bug #957548.

* The primary documents are the CP for Email Certs and the CPS for SSL and Code Signing Certs; provided in Italian and English. 

Document Repository: http://www.actalis.it/area-download.aspx
CP: https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx
CPS: https://www.actalis.it/documenti-en/cps-for-ssl-server-and-code-signing.aspx
CP/CPS for Email Certs: https://www.actalis.it/documenti-it/caact-free-s-mime-certificates-policy.aspx
CP/CPS for SSL and Code Signing Certs: https://www.actalis.it/documenti-en/cps-for-ssl-server-and-code-signing.pdf

Inclusion Policy Section 18 [Certificate Hierarchy]
This root signs internally-operated intermediate certificates that sign end-entity certificates.
Externally Operated SubCAs: None. None planned.
Cross Signing: 	None. None planned.

Inclusion Policy Section 7 [Validation]. 
Actalis appears to meet the minimum requirements for subscriber verification, as follows:

* SSL Verification Procedures: According to section 3.3.1 of the CPS, For SSL Server certificates, the CA verifies that all FQDNs and IP address to be included in the certificate are under the control of the Applicant organization, or his parent organization. These checks are carried out by different methods, depending on the case and the certificate class:
- by means of WHOIS queries (+ reverse DNS lookups for IP addresses) to reliable DNS information sources.
- by querying the relevant DNS Registrars or governmental domain registration agencies, as appropriate;
- by communicating with the domain administrator via e-mail, using an e-mail address obtainned by pre-pending a “admin”, “administrator”, “webmaster”, “hostmaster”, or “postmaster” to the domain name (this latter is obtained by pruning zero or more components from the requested FQDN).
Should one or more of those FQDNs and/or IP addresses be managed by an entity other than the Applicant or their parent organization, the Applicant is required to provide evidence to the CA that they have been formally delegated by the domains’ owner to manage those domains and/or IP addresses.

* EV SSL Verification Procedures: CPS section 3.3.2.

* Email Verification Procedures: According to section 3.2.1 of the CP/CPS for Email Certs, The only element of the requestor’s identity that is collected and verified by the CA is the requestor’s email address. This is checked by sending a random code to the alleged email address specified by the requestor in the on-line certificate request form, then asking the requestor to also enter such code before the certificate request is accepted. The requestor’s ability to enter the correct code proves that the specified email address exists and the requestor has access to it.
No other attributes (e.g. name, surname, affiliation, etc.) are collected or verified by the CA, as they are not inserted into the certificate.

Code Signing Subscriber Verification Procedure: 	CPS section 1.3.3.

Certificate Revocation
CRL URLs: http://portal.actalis.it/Repository/AUTH-ROOT/getLastCRL
http://crl03.actalis.it/Repository/AUTH-G3/getLastCRL
OCSP URLs: http://portal.actalis.it/VA/AUTH-ROOT
http://ocsp03.actalis.it/VA/AUTH-G3
OCSP responses have an expiration time of 1 day

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by IMQ, according to the ETSI TS 102 042 criteria.
http://www.actalis.it/documenti-en/actalisca_audit_statement.pdf

Based on this assessment I intend to approve this request from Actalis to turn on the email trust bit for the already-included "Actalis Authentication Root CA" root certificate.

Comment 13

[Kathleen Wilson]

As per the summary in Comment #12, and on behalf of Mozilla I approve this request from Actalis to turn on the Email trust bit for the following root certificate:

** "Actalis Authentication Root CA" (websites, email, code), EV already enabled

I will file the NSS bug for the approved change.