HARICA Root Renewal Request
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 Noteworthy points: * The primary documents are the CPS; provided in Greek and English Document Repository: http://www.harica.gr/procedures CPS: http://www.harica.gr/documents/CPS-EN.pdf * CA Hierarchy: ** The new roots will be cross-signed by “Hellenic Academic and Research Institutions RootCA 2011” to assist the rollover. ** “Hellenic Academic and Research Institutions RootCA 2011” currently has 20 internally operated and technically-constrained subCAs. There is currently one externally-operated subordinate CA: - Aristotle University of Thessaloniki - http://www.auth.gr, http://it.auth.gr - http://www.pki.auth.gr/certs/AuthCentralCAR3.pem, (to be decommissioned by Sep 2015) - http://www.pki.auth.gr/certs/AuthCentralCAR4.pem - http://www.pki.auth.gr/certs/AuthCentralCAR5.pem - AuthCentralCAR4 and AuthCentralCAR5 issue sub-CAs and end user/server certificates - http://www.pki.auth.gr/documents/CPS-EN.pdf - Sections in CP/CPS demonstrating the measures to verify: -- Ownership of domain name: 3.2.2, 3.2.3.2 and 3.2.5 -- Ownership of e-mail: 3.2.2, 3.2.3.1 and 3.2.5 - For all certificates chaining up to these Sub-CA, both the organization and the ownership/control of the domain are verified. - This CA is currently operated by the same administration team as the HARICA Root CA. - OCSP: http://ocsp.pki.auth.gr - Audit: http://pki.auth.gr/documents/AUTH-ETSI_CERTIFICATE_AUTH_W_ANNEX ** “Hellenic Academic and Research Institutions ECC RootCA 2015” currently has the following internally-operated subCAs: - Hellenic Academic and Research Institutions ECC AdminCA R1 We plan to issue the following internally operated subCAs for specific usages: - ECC Client Authentication and SecureEmail - ECC Code Signing - ECC SSL (DV/OV) Server Certificates There are currently no externally operated subCAs issued from this root. According to our CP/CPS, in case of externally operated CAs, they will either be technically constrained or publicly disclosed and audited. * This request is to enable the Websites and Email trust bits for both root certs. HARICA is not requesting EV treatment. ** CPS section 3.2.3.1: HARICA central RA uses three methods for e-mail ownership and control verification: - The first method uses simple e-mail verification. The user enters the e-mail address at the initial certificate request form and a verification e-mail is sent to the user with a link to a unique web page. After following this link, an e-mail is sent to the institution's network operation center mail administrator that requires an approval based on the full name entered by the user and the user's email. This approval requires the identification of the user with his/her physical presence and an acceptable official document. - The second method uses an LDAP server. The user enters the personal e-mail address at the initial certificate request form and the corresponding password. This information is verified against the institution's LDAP server. If the verification is successful, the RA queries the real name of the user and creates the certificate request. In order for a user to be listed in the Institutional Directory server, the institution must have verified the user with his/her physical presence and an acceptable official photo-id document. - The third method uses a Single Sign On (SSO) architecture based on the SAML specification. The user enters the personal e-mail address at the initial request form and is then redirected to the appropriate web page of the Identity Provider. The Identity Provider verifies the user and returns the real name and the email address of the user as attributes to the Registration Authority. In order for a user to be verified by the Identity Provider of an institution, the institution must have verified the user with his/her physical presence and an acceptable official photo-id document. ** CPS section 3.2.3.2: For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certifiate was issued, the Applicant either is the Domain Name Registrant or has control over the FQDN by: - Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar, - Communicati
Re: ComSign Root Renewal Request
On 12/10/15 20:01, 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. [snip] > * 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 Via Censys.io, I noticed a subCA with CN "Comsign EV SSL CA" whose subCA cert is reproduced below. -BEGIN CERTIFICATE- MIIG1zCCBL+gAwIBAgIQcybbitmPn4IXQtwZX2fD8DANBgkqhkiG9w0BAQsFADBF MR8wHQYDVQQDExZDb21TaWduIEdsb2JhbCBSb290IENBMRUwEwYDVQQKEwxDb21T aWduIEx0ZC4xCzAJBgNVBAYTAklMMB4XDTE1MDkyNDExMTgyM1oXDTI1MTAyMjE5 MDAwMFowUzELMAkGA1UEBhMCSUwxETAPBgNVBAcTCFRlbCBBdml2MRUwEwYDVQQK EwxDb21zaWduIEx0ZC4xGjAYBgNVBAMTEUNvbXNpZ24gRVYgU1NMIENBMIICIjAN BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA9802wpU9bUwRopTfxwDsjugmljHX MVMt4stqAZuCZO2EbHAvFVdT9vGnzQ2AxbHEpTPTlJZdBpYsUKZPZW56MEs17a9R SYIDJWRs2GrmQIFoSxqIkjkHCpfzzAA6UM4PvqTYuCkvmaUEV3GtK3RvVfSqYlCQ Kszcj+BLq5q9lvfQh4ygN8Cgj+O7s8svh+D08ho7LHyf23Ng+lrYea+zlJosn+9C f97DpkK+Ceg1wgjmFPWE6vKil1euayyf69NLlufkbd99Dej0JUX0hPkewNEbPXc9 wANWQBC/HAu/QR4cLmMIU+MbSFPVBZmUIyZKQnEe4AVcnpk4rL7HV7xOb/Q1JGOE wkyoXWMHh+qaxzmYxA27360LTvQ+ik6cOruCZhFIT/3G9bF9vx0D0wn7MTJuiaoI MMjT8ayBGsqB3U31omLHo2AXLwpBC1thj4aYSMFio/vIRfglslny/cQM6RXt1Xk6 qC/b1JUK1boUnjFgxjClG/dmSdjJrK0T/zr11oKaxEkdZ2FjHXwBgsF2/MVGCqvK Kv6hAgmptEl4kvrgk+O5RGDfceNE28OpJJ89Ew/UnAHhaRqVzo1yT6MHD2Pw5Rnx sau7cVblH7iGu+GXOLBH6QjjrQs5Ul9jXQQ0waFQOE2B0i2lZicP9t05bh+445dH EUU8BojywPEbNn8CAwEAAaOCAbMwggGvMIGCBggrBgEFBQcBAQR2MHQwKwYIKwYB BQUHMAGGH2h0dHA6Ly9vY3NwMS5jb21zaWduLmNvLmlsL29jc3AwRQYIKwYBBQUH MAKGOWh0dHA6Ly9mZWRpci5jb21zaWduLmNvLmlsL2NhY2VydC9Db21TaWduR2xv YmFsUm9vdENBLmNydDAfBgNVHSMEGDAWgBQCRZPYDUhirGm6rgZbPvuqJpFQsTAS BgNVHRMBAf8ECDAGAQH/AgEAMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUF BwIBFhxodHRwOi8vd3d3LmNvbXNpZ24uY28uaWwvQ1BTMIGEBgNVHR8EfTB7MDyg OqA4hjZodHRwOi8vZmVkaXIuY29tc2lnbi5jby5pbC9jcmwvQ29tU2lnbkdsb2Jh bFJvb3RDQS5jcmwwO6A5oDeGNWh0dHA6Ly9jcmwxLmNvbXNpZ24uY28uaWwvY3Js L0NvbVNpZ25HbG9iYWxSb290Q0EuY3JsMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E FgQU7fGGKZqDjBRnn7pjoL3PRHlkAdIwDQYJKoZIhvcNAQELBQADggIBAHxBbq2k jzKZVcI6kL++GGAfojlBv/x2ci6q0c7LOois6Mu+QiD3QhplSuZtAY5GZ7rLdN28 3cI4ufh+roNGmZDuh6E4ZMQG1Kd+DbfpCsEKo8tq5nmXCjdp2f4+eK2LAuXb0Z38 fsodqjnsGfMJuVg1F4ofRzX/WnfY2vgVV5Fo7ng5hwdVzIsywxgTd4JBCrfZJsRE Ci+mxfIu5kEZiSftciaoFjqWkI+HUYE3H+Fsmq0K59sMg5oYZpwo/LFBKfRIBunC IBKNCODFTVIwXjtrY3xkAYPac6XmTDTNqwu7sLscZ9K4psBJokhe4HVFrVarXpXi khFSTlkD4ZTgJSnikmmgBzlPieMUqeGfu7vWymVIhU+2bbS/orDrX8Sm5QIMw3xz WMuPmGwB3FVzBc9TdqjNdw1+iHgCIEpvuBiLIMsIAkRQzaxifYcrTv6zFx5xRKuQ MWKLgyGeTG+WZscOtP7eWxwvzhGMmAAahUqSgCvp01lk5rtOzYF4kYM4fvQRnkJB MmgZ0gEbUtjxPI8JiOc9sI6I73M8IC7LqrqI3NXQoVyri0smRD5elgIHfksBrOS1 Yl6zC5ekM0GDkatfX7l29OteGtVHVaUj4Ti+esT/D8CuBL9bHqIMjrJePzuE29+Z GgiV55sP/5iWAHIhoqvHBmswvEEHBozrAh6I -END CERTIFICATE- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
ComSign Root Renewal Request
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 e
Re: Certum Root Renewal Request
On 12/3/15 4:00 PM, Kathleen Wilson wrote: Please let me know if you need more time to review this request from Unizeto Certum to include the “Certum Trusted Network CA 2” root certificate, turn on the websites and email trust bits, and enable EV treatment. This is the next generation of the “Certum Trusted Network CA” root cert that was included via bug #532377. Otherwise, I will assume everyone is OK with this request, and move forward with recommending approval. This discussion has been open for over two months, and only one concern was raised (and resolved). Therefore, I am now closing this discussion and will recommend approval of this request in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=999378 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: Name issues in public certificates
Am 10.12.2015 um 15:47 schrieb Peter Bowen: > Apologies for this. I will get the tool updated to ensure that IPv6 > addresses do not cause a flag. Thank you for fixing this! Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Validating a Domain Registrant
On 10/12/2015 05:36, Peter Kurrasch wrote: (changed the subject since we're not talking about SECOM anymore) Thanks for the info, Kathleen. Originally my concern was mostly with domain registrant proxies (if that's the preferred term?) but after reviewing BR v1.3.1 I'm afraid my concerns have grown. All of the items listed under section 3.2.2.4 have problems but some are worse than others (and there probably is no ideal solution anyway). I offer the following: 1) Item 4 is not only exploitable but in fact has already been exploited. I think the incident came up in this forum but if not I'll try to dig up an article. Either way, I suggest that the Mozilla policy be to specifically forbid this practice by CA's seeking inclusion in the trust store and that the CA policy docs state they will not use any "magic" email addresses. Of course I would encourage the CABF to remove this item from the BR, but Mozilla should take action on this regardless. This is actually the most common way for "domain validated" certificates. It uses a standard defined point of contact that has a reasonable chance of being done by a different computer system than the one protected by a web server TLS certificate, thus reducing the chance of a web server compromise escalating to obtaining a fraudulent certificate for permanently hijacking that site. 2) Item 6 should be forbidden as well. Demonstrating control over a website is not the same as having practical control over a domain. Seizing control over someone else's website can be a fairly straightforward process in some cases, so manipulating a web page proves only that it can be manipulated. Again my recommendation is for Mozilla to forbid the practice, for the CA policy documents to explicitly state that the method will not be used, and that the BR be updated in due time. That argument is the reason #4 is more popular. However not all webserver domains have e-mail servers handling them, which is why #6 (or a similar technique for DNS) is sometimes used. 3) Both items 5 and 7 are entirely too ambiguous and open-ended. (I tried to find any specifications on what a domain authorization document must contain but didn't see it.) As written, I could declare ownership in a number of silly ways that a less scrupulous CA might just accept. I can appreciate that CA's might want and need flexibility in how they perform the verification, so it's important that CA's also document their verification procedures in some detail in their policy docs. #7 covers a lot of cases that cannot be reasonably enumerated in the BR, but should be listed in the specific CPS, for example: - The CA is itself the subject of the certificate - Ultra high security procedures involving direct non-Internet contact between the CA and the subject. For example Government CAs often uses government internal identity checking procedures when issuing certificates for Government entities. - Regular high security procedures such as requiring the subject to appear in person with specific kinds of identity proof combined with checks against official records. - A (Sub)CA issuing e-mail and client certificates to its employees. - Previously validated CA customers logging on to a secure CA web portal to request additonal certificates. - Renewal via proof of possession of the prior certificate. As for #5 a domain authorization document is often a message from the WHOIS registrant of the domain that another party is allowed to request the certificate. Some common cases: - The web page is hosted on a shared server and the hosting provider wants to add the domain name as a SubjectAlternativeName to the certificate that handles incoming https for all the domains hosted on a given IP address. Here the verified domain owner issues a form letter authorizing the hosting provider to make that request from their chosen CA. - The web page is held "in trust" for its true owner by a related party (e.g. the domain may be registered in the name of an executive or sister company yet the certificate is requested by the IT department elsewhere in the legal structure of a big organization). - The certificate requesting is done by an outsourced IT organization and the actual owner issues a letter authorizing that outsourced IT organization to request the certificate. - The domain is registered via a proxy and the proxy then issues a document allowing the true owner to request the certificate. The CA must validate the originator of the message as thoroughly as it would have a requestor-on-own-behalf and be equally thorough in validating that the requestor is the entity named in the authorization document. In practice the authorization document is required to refer specifically to a single request via e.g. a date or some identifying number. My recommendation is for Mozilla to require a detailed description of any custom procedures that a CA intends to use. The description would be included in
Re: Second Discussion of ANF Root Inclusion Request
Thanks Kathleen. I'm Enric Castillo from ANF Autoridad de Certificación, and I will be reviewing and answering your questions. Thanks for your collaboration. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name issues in public certificates
On Thu, Dec 10, 2015 at 6:07 AM, Matthias Hunstock wrote: > Am 09.12.2015 um 18:46 schrieb Peter Bowen: > >> Do you have an example where you think IPv6 addresses are not being >> handled correctly? > > Serial 19D70E1B381579 in your document is the example I stumbled upon. > > I managed to get the complete cert from the server and cannot see any > issues there. > > It is flagged as "_unqualified" though it has a global unicast IPv6 > address, beside other SubjectAlternativeNames. You are correct. There is a logic bug and it is flagging properly encoded ipv6 addresses in the SAN as unqualified. There are 9 certificates in CT that have IPv6 addresses. Apologies for this. I will get the tool updated to ensure that IPv6 addresses do not cause a flag. For now, however, please ignore any "unqualified" result for a SAN:IP row. This rule should be impossible to hit for that data type. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Name issues in public certificates
Am 09.12.2015 um 18:46 schrieb Peter Bowen: > Do you have an example where you think IPv6 addresses are not being > handled correctly? Serial 19D70E1B381579 in your document is the example I stumbled upon. I managed to get the complete cert from the server and cannot see any issues there. It is flagged as "_unqualified" though it has a global unicast IPv6 address, beside other SubjectAlternativeNames. Regards Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
