Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Enable Email trust bit for Actalis root cert

275 views
Skip to first unread message

Kathleen Wilson

unread,
Dec 9, 2015, 7:09:58 PM12/9/15
to mozilla-dev-s...@lists.mozilla.org
This request is 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.

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

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1176188

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8646022

Noteworthy points:

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

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

* CA Hierarchy: This root issues internally-operated subordinate CAs.
CPS section 1.3.1:
** The Root CA is used for issuing Sub CA certificates and related CRLs
only, and is kept off-line when not in use, whereas end-entity
certificates are issued by Sub CAs.
** Within the framework of the service described in this document, both
CA roles (Root CA and Sub CA) are played by Actalis

* This request is to enable the email trust bit. This root certificate
currently has the Websites and Code Signing trust bits enabled. This
root certificate is also currently enabled for EV treatment.

** Authentication of organization and individual identity is described
in sections 3.2.2 and 3.2.3 of the CPS.

** CPS section 3.3.1: 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.

** CPS section 3.3.2 describes EV SSL organization verification procedures

** CP for Email Certs section 3.2.1: 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.

* Root Certificate Download URL: Already included

* EV Policy OID: 1.3.159.1.17.1

* Test website: https://ssltest-a.actalis.it:8443/

* 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

CRL URLs:
http://portal.actalis.it/Repository/AUTH-ROOT/getLastCRL
http://crl03.actalis.it/Repository/AUTH-G3/getLastCRL

* 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

* Potentially Problematic Practices: None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from Actalis to turn on the
Email trust bit for the "Actalis Authentication Root CA" root certificate.

At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

Kathleen Wilson

unread,
Jan 13, 2016, 3:28:02 PM1/13/16
to mozilla-dev-s...@lists.mozilla.org
Does anyone need more time to review this request from Actalis to turn
on the Email trust bit for the currently-included "Actalis
Authentication Root CA" root certificate?

If not, and no one has any questions/concerns about this request, then I
will close this discussion and recommend approval in the bug.

Thanks,
Kathleen



Kathleen Wilson

unread,
Jan 20, 2016, 5:10:45 PM1/20/16
to mozilla-dev-s...@lists.mozilla.org
This discussion about enabling the Email trust bit for the
already-included "Actalis Authentication Root CA" root certificate was
started on December 9, and no questions or concerns have been raised.


Therefore, I am closing this discussion and will recommend approval in
the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1176188

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen

0 new messages