Re: HARICA Root Renewal Request
On 12/10/15 3:29 PM, Kathleen Wilson wrote: This request is to include the “Hellenic Academic and Research Institutions RootCA 2015” and “Hellenic Academic and Research Institutions ECC RootCA 2015” root certificates, and enable the Websites and Email trust bits for both roots. Hellenic Academic and Research Institutions Certification Authority (HARICA) is a non-profit organization serving the Greek Academic and Research Community; operated by the Greek Universities Network (www.gunet.gr). The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1201423 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=8697399 Does anyone need more time to review this request from HARICA to include the “Hellenic Academic and Research Institutions RootCA 2015” and “Hellenic Academic and Research Institutions ECC RootCA 2015” root certificates, and enable the Websites and Email trust bits for both roots? The draft of their updated CP/CPS is attached to the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1201423#c13 If no one needs more time to review this request, 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
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: ComSign Root Renewal Request
On 12/10/15 12:01 PM, Kathleen Wilson wrote: This request is to include the "ComSign Global Root CA" root certificate, and enable the Websites and Email trust bits. This root will eventually replace the "ComSign CA" root certificate that is currently included in NSS, and was approved in bug #420705. ComSign is owned by Comda, Ltd., and was appointed by the Justice Ministry as a CA in Israel in accordance with the Electronic Signature Law 5761-2001. ComSign has issued electronic signatures to thousands of business people in Israel. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=675060 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=8697333 Noteworthy points: * The primary documents are the CP and CPS, provided in Hebrew and English. Only the Hebrew version of the CPS was approved by the Israeli CA Registrar. The English version of the CPS adds procedures dealing with SSL certificates, which are not regulated under Israel's Elctronic Signature Law. Document Repository: https://www.comsign.co.il/ Document Repository (English): https://www.comsign.co.uk/?page_id=1282 CPS: http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf * CA Hierarchy: This root has internally-operated subordinate CAs: ComSign ISA Global CA, ComSign Corporation CA, ComSign Professionals CA, and ComSign Organizational CA. CA Hierarchy Diagram: https://bugzilla.mozilla.org/attachment.cgi?id=8608692 * This request is to enable the Websites and Email trust bits. ComSign is not requesting EV treatment at this time. ** Note: The English version of the CPS adds procedures dealing with SSL certificates, which are not regulated under Israel's Electronic Signature Law. So, the SSL verification procedures are only part of the English version of the CPS. ** CPS section 3.2.7.1: As part of the identification process, a unique secret code (the "Secret Code" will be mailed by Comsign to the Applicant's e-mail address. The Secret Code will be mailed during the coordination stage preceding the Applicant's personal appearance for the identification process. The Applicant will provide the Secret Code to the coordination clerk during the telephone conversation coordinating the Applicant's personal appearance. If the provided Secret Code is correct, the coordination clerk will transfer it to the identification clerk together with all other data pertaining to the applicant (including the applicant's e-mail address). ** CPS section 3.2.7.2: In the event of a non-coordinated visit to Comsign offices (as well as in any other event) the identification clerk will mail the Secret Code during the identification process (Comsign will provide the Applicant with internet access). ** CPS section 3.2.7.3. The Applicant must provide the Secret Code in the application form. The identification clerk will verify the matching of the Secret Code in the application form with the one reported by the coordination clerk (or by the applicant himself in a non-coordinated visit to Comsign offices) as well as the matching of the e-mail address in the application form with the address reported by the coordination clerk. Alternatively, the identification clerk will verify the matching of the Secret Code in the application form to the one mailed by the identification clerk to the e-mail address provided by the Applicant in the application form. ** CPS section 3.2.7.4: Only the e-mail address to which the verified Secret Code was mailed will appear in the electronic certificate issued by Comsign to the Applicant. ** CPS section 3.2.8.1: For issuing certificates to organizations requesting SSL certificates, Comsign performs domain name owner verification to detect cases of homographic spoofing of IDNs. Comsign employs an automated or manual process that searches various ‘whois’ services to find the owner of a particular domain. A search failure result is flagged and the RA rejects the Certificate Request. Additionally, the RA rejects any domain name that visually appears to be made up of multiple scripts within one hostname label. Note: Orders for major corporations, well known trademarks and financial institutions may be queued for further security reviews prior to issuance. In the event an order is queued for review the administrative contact must be a full time employee of the company for successful issuance. A verification telephone call with the administrative contact may be required. - Verification methods include one of the following: *** 3.2.8.1.1 EMail-based DCV An email is sent to an administrative contact for the required domain. The email will contain a unique validation code and link. Clicking the link and entering the code will prove domain control. Valid email addresses are: Any email address listed in the "whois" records. The following generic admin type email addresses AT
Re: SHA1 certs issued this year chaining to included roots
On 19/01/16 21:13, Charles Reiss wrote:
On 01/19/16 11:49, Jakob Bohm wrote:
If there is no OCSP, it obviously cannot be stapled.
The CA/Browser forum BRs contemplate OCSP stapling without an OCSP responder
being listed in the certificate in section 7.1.2.2.c ("The HTTPURL of the
Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
“staples” the OCSP response for the Certificate in its TLS handshakes
[RFC4366].") I assume the idea is that the OCSP responder URL would be manually
configured in the server and that this would make the certificate slightly
smaller.
IIRC, the original motivation for this text was to make it possible to
suppress OCSP requests directly from TLS clients (that don't support
OCSP Stapling). In particular, there was a concern that some OCSP
responders might not be able to cope with the OCSP traffic generated by
certs used by sites with extremely high numbers of users.
At the time, Firefox didn't support OCSP Stapling, and it was much less
common for CAs to use CDNs for their OCSP responders. (Indeed, some CAs
didn't even support OCSP back then).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
