Re: Enable Email trust bit for Actalis root cert
On 1/13/16 12:27 PM, Kathleen Wilson wrote: On 12/9/15 4:09 PM, Kathleen Wilson wrote: 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. 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. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Enable Email trust bit for Actalis root cert
On 12/9/15 4:09 PM, Kathleen Wilson wrote: 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. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Enable Email trust bit for Actalis root cert
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
