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

ComSign Root Renewal Request

2,041 views
Skip to first unread message

Kathleen Wilson

unread,
Dec 10, 2015, 3:01:39 PM12/10/15
to mozilla-dev-s...@lists.mozilla.org
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 the domain
for which the certificate is being applied: admin@, administrator@,
postmaster@, hostmaster@, webmaster@
*** 3.2.8.1.2 DNS-based DCV
The CSR that Comsign receives from the Applicant will be hashed. The
hash values are provided to the Applicant, and it must be entered as a
DNS TXT record OR a DNS CNAME record for the domain. The hashes are to
be entered in DNS RR as follows: CNAME Example:
<Value of hash of CSR>.domainname.com CNAME <value of hash of
CSR>.comsign.co.uk.
TXT Example:
DCV TXT <value of hash of CSR>
*** 3.2.8.1.3 HTTP(S)-based DCV
The CSR that Comsign receives from the Applicant will be hashed. The
hash values are provided to you and you must create a simple plain-text
file and place this in the root of your webserver and served over
HTTP-only! The file and its content should be as follows:
http://domainname.com/<Upper case value of hash of CSR>.txt
OR http://domainname.com/<Upper case value of hash of CSR>.html
Content (as a plain text file): <Value of hash of CSR> Comsign

** CPS section 3.2.8.2. Authentication of Organization identity
Before issuing SSL certificate and whenever a certificate contains an
organization name, the identity of the organization and other enrolment
information provided by Certificate Applicants (except for Non-verified
Subscriber Information) is confirmed in accordance with the procedures
set forth in ComSign’s documented validation procedures. Comsign shall:
Determine that the organization exists by using at least one third party
identity proofing service or database, or alternatively, organizational
documentation issued by or filed with the applicable government agency
or competent authority that confirms the existence of the organization
or an authorised lawyer that confirm the existence of the organisation
according to local laws, confirm by telephone, confirmatory postal mail,
or comparable procedure to the SSL certificate applicant certain
information about the organization, that the organization has authorized
the certificate application request, and that the person submitting the
Certificate Application request on behalf of the certificate applicant
is authorized to do so.
Where a domain name is included in the SSL certificate - Comsign
authenticates the organization’s right to use that specific domain name
as a fully qualified domain name.

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=549246

* EV Policy OID: Not requesting EV treatment

* Test Website: https://fedir.comsign.co.il/test.html

* CRL URLs:
http://fedir.comsign.co.il/crl/ComSignGlobalRootCA.crl
http://fedir.comsign.co.il/crl/ComsignOrganizationalCa.crl
CPS Section 2.3: The published list of revoked certificates is valid for
24 hours.

* OCSP URL: http://ocsp1.comsign.co.il

* Audit: Annual audits are performed by Sharony-Shefler, according to
the WebTrust criteria.
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8599627
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8598250
EV Audit: Not requesting EV treatment
I have exchanged email with the auditor to confirm the authenticity of
the audit statements.

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

This begins the discussion of the request from ComSign to include the
"ComSign Global Root CA" root certificate, and enable the Websites and
Email trust bits.

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

Charles Reiss

unread,
Dec 10, 2015, 3:55:23 PM12/10/15
to mozilla-dev-s...@lists.mozilla.org
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-----


Eli Spitzer

unread,
Dec 14, 2015, 12:58:17 PM12/14/15
to mozilla-dev-s...@lists.mozilla.org
The SubCA "Comsign Ev SSL CA" is at its initial development stages. It was indeed created under "Comsign Global Root CA", but so far we only issued a handful of test certificates from it. We have no plans to issue public certificates from it at the moment, since the EV trust bit will not be active any time soon.

censys.io probably picked up the certificate from a test website that is used only for development purposes.

Comsign is not requesting the EV trust bit at the moment, but we are planning to so sometime in the near future. Probably not before the end of 2016.

Eli Spitzer | Information security & System Management | Comda

Charles Reiss

unread,
Dec 14, 2015, 1:59:03 PM12/14/15
to mozilla-dev-s...@lists.mozilla.org
On 12/14/15 17:56, Eli Spitzer wrote:
> The SubCA "Comsign Ev SSL CA" is at its initial development stages. It was
> indeed created under "Comsign Global Root CA", but so far we only issued a
> handful of test certificates from it. We have no plans to issue public
> certificates from it at the moment, since the EV trust bit will not be active
> any time soon.

Mozilla's policy requires subCAs to be publicly disclosed "before any []
subordinate CA is allowed to issue certificates." How was this performed for
this subCA?

Eli Spitzer

unread,
Dec 14, 2015, 2:56:08 PM12/14/15
to mozilla-dev-s...@lists.mozilla.org
On Monday, December 14, 2015 at 8:59:03 PM UTC+2, Charles Reiss wrote:
> On 12/14/15 17:56, Eli Spitzer wrote:
> > The SubCA "Comsign Ev SSL CA" is at its initial development stages. It was
> > indeed created under "Comsign Global Root CA", but so far we only issued a
> > handful of test certificates from it. We have no plans to issue public
> > certificates from it at the moment, since the EV trust bit will not be active
> > any time soon.
>
> Mozilla's policy requires subCAs to be publicly disclosed "before any []
> subordinate CA is allowed to issue certificates." How was this performed for
> this subCA?
>

The request to add "Comsign Global Root CA" was submitted to Mozilla on 2014-11-30.
The Comsign CA Hierarchy details was submitted to Mozilla on 2015-05-21
On both dates there was no SubCA called "Comsign EV SSL CA" in existence. It was created on 2015-09-24, as can be seen in the certificate that you have found.
Since this Root CA request is taking very long time to progress, naturally some processes and taking place in Comsign over time, and we are committed to disclose any development to Mozilla. However, this SubCA has never issued any certificate to end-entities other than Comsign itself. Moreover, this SubCA may even be revoked soon before it will ever do so, since for now it is strictly for testing purposes.
It is possible to say that it was a simple oversight, but in fact this SubCA does not ever fall under the requirement of the policy that it will not be "allowed to issue certificates" - since Comsign is not even considering to issue any certificate from it before we have the EV trust bit.


Charles Reiss

unread,
Dec 14, 2015, 4:18:10 PM12/14/15
to mozilla-dev-s...@lists.mozilla.org
The existence of test certificates which chain to this subordinate CA
certificate (like the one censys.io found) clearly puts it in the scope of
Mozilla's disclosure policy.

Mozilla's policy says "issue certificates", not "issue non-test certificates" or
"issue certificates to third-parties".

Kathleen Wilson

unread,
Dec 14, 2015, 8:36:22 PM12/14/15
to mozilla-dev-s...@lists.mozilla.org
This is a good example of why Mozilla's policy needs to be updated to be
more clear about this.

See the discussion called "Policy Update Proposal: Timeline for
Disclosing SubCAs"
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/EDRp1Fil3u8/ub33LOoDAgAJ

The CA Community in Salesforce will make it easier to disclose such
information too.

Thank you for raising this point. I will update my records with this
information, but I do not see it as a show-stopper for this request at
this time.

Kathleen


Kathleen Wilson

unread,
Jan 20, 2016, 6:46:21 PM1/20/16
to mozilla-dev-s...@lists.mozilla.org
Does anyone need more time to review this request from ComSign to
include the "ComSign Global Root CA" root certificate, and enable the
Websites and Email trust bits?

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 26, 2016, 1:35:47 PM1/26/16
to mozilla-dev-s...@lists.mozilla.org
On 1/20/16 3:45 PM, Kathleen Wilson wrote:
>
> Does anyone need more time to review this request from ComSign to
> include the "ComSign Global Root CA" root certificate, and enable the
> Websites and Email trust bits?
>
> If not, and no one has any questions/concerns about this request, then I
> will close this discussion and recommend approval in the bug.

I will be leaving this discussion open longer, because a couple folks
have let me know that they intend to review this request but need more time.

Thanks,
Kathleen


Peter Kurrasch

unread,
Jan 29, 2016, 7:24:32 PM1/29/16
to mozilla-dev-s...@lists.mozilla.org
I've reviewed the ComSign CPS and while it has a lot of legal language in it, it lacks a certain legal and technical precision that is needed in this case. For example, there is frequent use of the term "electronic certificate" which I think this document means "certificate used for electronic signatures of individual people" even though one might naturally include SSL/TLS and code signing certs as‎ such. Similarly, the use of "SSL" in this doc might also mean "code signing" but that is less clear. I was actually surprised to find code signing in section 3.2.9 given the lack of its even being mentioned elsewhere in the doc.

I can appreciate ComSign wanting to take a shortcut by adding on the SSL and code signing stuff to their already detailed doc but my recommendation is for ComSign to rework the document anyway. It's difficult for me to assess the security risk that this root might introduce to the wider Internet population. Based on my current understanding of this document I'd say the attack surface is "large", meaning there seem to be many gaps through which I might fraudulently obtain a ComSign certificate. Further, I would say the potential for harm that I can cause with that ill-gotten cert is probably "unlimited".

My hope is that by reworking the CPS document ComSign can more clearly articulate what is and is not possible when it comes to issuing and using their certs and, consequently, ‎my concerns about risk and damage are lessened. 


That said, I offer some specific comments:

* Section 1 should stipulate that The Law was enacted by the State of Israel and has jurisdiction in the relevant Israeli territories. I'm assuming that to be the case, anyway.

‎* I assume The Law does not apply to SSL/TLS certs. What about code signing? 

* There is a BR from CABF that covers code signing. I must admit I don't know the status of it but this CPS should at least acknowledge it and say if ComSign will adhere to it.

* In Section 1 where it says "some procedures dealing with SSL...are not part of the Hebrew version", this statement is insufficient. For example what about code signing? Which SSL procedures are actually in the Hebrew version? This has an important implication when it comes to statements like "only the Hebrew version is binding".

* I wasn't sure if a Registration Agent (Section 1.3.2) represents a business entity which is separate and apart from the ComSign company? Will ComSign bear any responsibility for the hiring of people at an RA, for example? This has a significant impact into my evaluation of the attack surface.‎ The greater the "space" between ComSign and the RA, the greater the chance for mistakes or bad acts to happen.

* Section 1.4., what are the usage terms for SSL/TLS and code signing certs? Is key sharing allowed for any of the certs issued by ComSign? If key sharing is not allowed, how is that enforced (and who does the enforcing)?

* Section 3.2.8.1.1. is provably insecure and should not be used to verify ownership or control of a domain. A WHOIS record might contain an email address of a proxy and is, therefore, unreliable. The "magic" email address names might be directed to an unauthorized person and, therefore, also unreliable. 

* Section 3.2.8.1.3. is also provably insecure and should not be used. Changing a website proves nothing and if I'm trying to exploit an existing domain for nefarious purposes I probably have control over the website anyway.

* Throughout the CPS I found some uses of the term "signature" to be ambiguous. Where possible it would be good to distinguish between a pen-and-paper signature and one that's in some electronic form. I do like that the issuance process is not completely electronic.


I do have concerns with other sections in this CPS but I would like to give ComSign a chance to respond or do rework before I get overly detailed. As I stated above, my hope is that a revised CPS will demonstrate that the attack surface is more "medium" and that the potential for damage is less than "unlimited"--that it is constrained in some way.


From: Kathleen Wilson
Sent: Wednesday, January 20, 2016 5:46 PM‎

On 12/10/15 12:01 PM, Kathleen Wilson wrote:

David Keeler

unread,
Jan 29, 2016, 8:03:21 PM1/29/16
to dev-secur...@lists.mozilla.org
On 12/10/2015 12:01 PM, Kathleen Wilson wrote:
...
The certificate presented by the test website specifies "ISRAEL" in the
Country field of the Subject DN, whereas I understand it should be the
two-letter country code "IL". Is there a mechanism in place to prevent
these sorts of errors?

Thanks,
David

signature.asc

Peter Bowen

unread,
Jan 29, 2016, 9:08:43 PM1/29/16
to Peter Kurrasch, mozilla-dev-s...@lists.mozilla.org
Peter,

I obviously do not represent ComSign, but several of the items in your list
are not really specific to the CPS and instead are more comments on the
Mozilla policies.

On Fri, Jan 29, 2016 at 4:24 PM, Peter Kurrasch <fhw...@gmail.com> wrote:

> * There is a BR from CABF that covers code signing. I must admit I don't
> know the status of it but this CPS should at least acknowledge it and say
> if ComSign will adhere to it.
>

There is not a BR from the CA/Browser Forum. A subset of the members of
the CABF drafted a BR, but it failed to be adopted as a Forum Guideline
when brought to a vote of the whole Forum. Concerns were raised on several
fronts, including some specific requirements. Therefore I don't think it
is necessary or appropriate for a CA to commit to adhere (or not adhere) to
a document that is still under development.

Additionally, Mozilla has determined that Code Signing is out of scope for
the Mozilla CA program. Therefore, as I understand it, whether a CA issues
certificates for code signing or not, and the terms under which is does so,
should not be in scope for review of their CPS in this forum.


> * Section 3.2.8.1.1. is provably insecure and should not be used to verify
> ownership or control of a domain. A WHOIS record might contain an email
> address of a proxy and is, therefore, unreliable. The "magic" email address
> names might be directed to an unauthorized person and, therefore, also
> unreliable.
>

The process described in 3.2.8.1.1 is the process that was included in the
Mozilla CA policy (https://wiki.mozilla.org/CA:CertInclusionPolicyV2.0) and
is now included in the CABF BRs. It is an approved process to verify
ownership or control of a domain.


> * Section 3.2.8.1.3. is also provably insecure and should not be used.
> Changing a website proves nothing and if I'm trying to exploit an existing
> domain for nefarious purposes I probably have control over the website
> anyway.
>

The process described in 3.2,8.1.3 is an implementation of section 3.2.2.4
(6) of the CABF BRs. It appears to be an approved process to verify
ownership or control.

Thanks,
Peter

Peter Kurrasch

unread,
Jan 29, 2016, 9:47:41 PM1/29/16
to Peter Bowen, mozilla-dev-s...@lists.mozilla.org
Thanks for the update on the code signing situation within CABF. Last I knew about it, it was‎ on the path towards adoption so it's good to know that's no longer the case.

Regarding the processes to verify ownership and control, I hope you're not suggesting we should continue to allow provably insecure procedures because ‎the BR says it's OK to use them?

Peter Bowen

unread,
Jan 29, 2016, 9:56:12 PM1/29/16
to Peter Kurrasch, mozilla-dev-s...@lists.mozilla.org
I'm suggesting that the we are being asked to review the CPS to ensure that
it conforms to the Mozilla CA policy. The processes to verify ownership or
control do conform to the current version of the policy. If you think that
this is bad policy, then it is something that should be addressed as part
of policy revision.

As this is a public comment period, it is of course fine to raise these (or
any other[1]) issues, however I don't think it is appropriate to treat
these as an issue the CA needs to resolve as they are conforming to the
Mozilla CA policy.

Thanks,
Peter

[1] as long as the Community Participation Guidelines are followed

On Fri, Jan 29, 2016 at 6:47 PM, Peter Kurrasch <fhw...@gmail.com> wrote:

> Thanks for the update on the code signing situation within CABF. Last I
> knew about it, it was‎ on the path towards adoption so it's good to know
> that's no longer the case.
>
> Regarding the processes to verify ownership and control, I hope you're not
> suggesting we should continue to allow provably insecure procedures because
> ‎the BR says it's OK to use them?
>
>
> *From: *Peter Bowen
> *Sent: *Friday, January 29, 2016 8:08 PM‎

Erwann Abalea

unread,
Feb 1, 2016, 6:17:10 AM2/1/16
to mozilla-dev-s...@lists.mozilla.org
Bonjour,

Le jeudi 10 décembre 2015 21:01:39 UTC+1, Kathleen Wilson a écrit :
> 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.
[...]
When sending a request to validate intermediate CA certificates (both Organizational and EV SSL) to this responder, the responder certificate signing the response is issued by Organizational CA instead of the Global Root CA.

Eli Spitzer

unread,
Feb 2, 2016, 12:22:31 PM2/2/16
to mozilla-dev-s...@lists.mozilla.org
Hello David,

It appears that you are absolutely right. We probably have a bug in the process of generating OV (Organization Validation) SSL certificates - some of the country codes in the subject information DN are being generated as full country names.
However, this bug does not affect Domain Validated SSL certificates. And since the CA is not yet actively issuing SSL certificates, and the only OV SSL certificates that we issued so far by this root are test certificates - then the easiest solution for us at the moment is to disable the OV SSL certificates mechanism and to leave active only the DV SSL certificates issuing mechanism.
We've issued a new DV SSL certificate for the test site, and we are now working to fix this bug. Only after the bug is fixed we shall re-activate our OV SSL issuing mechanism.
Thank you for your observation.

Eli Spitzer | Information security & System Management | Comsign

Eli Spitzer

unread,
Feb 2, 2016, 12:27:04 PM2/2/16
to mozilla-dev-s...@lists.mozilla.org
Hello,
This is due to temporary technical problem.
Up until 3 weeks ago the responder had a certificate signed by the root CA (Global Root CA) - but due to a hardware issue with the device which holds the responder's keys we had to replace the certificate. Since signing certificates by the Root CA server requires a major key ceremony, we scheduled to perform this ceremony during the next few days. Until then, the responder will use the Subordinate CA's OCSP certificate.

Jesus F

unread,
Feb 4, 2016, 4:38:34 AM2/4/16
to mozilla-dev-s...@lists.mozilla.org
Dear Mozilla community,

Reviewing the BR audit report of Comsign Ltd I have a few doubts regarding the audits accepted by Mozilla and may someone can help me.

The BR audit was conducted according to the WebTrust forCertification Authorites - SSL Baseline Requirements Audit Criteria version 1.1 and it's a point-of-time (as of April 26, 2015).
Although this audit criteria is accepted according to the Mozilla CA Certificate Inclusion Policy 2.2, the BR audit version 1.1 was superseded by Webtrust SSL Baseline with Network Security version 2.0 (effective for audit periods starting on or after July 1, 2014).

Webtrust audit criteria states that "The point-in-time readiness assessment shall be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and shall be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. (See SSL Baseline Requirements Section 17.4)". Should Mozilla expect a complete audit 90 days after the point-in-time BR audit report or after the first certificate (I don't know when was issued)?

In addition and regarding the OCSP Responder certificate with Serial Number: 0e:2b:cd:a4:aa:4f:8f:80:da:16:94:4e:ba:33:35:33, the validity is 3 years. According the RFC 6960 "A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently." Which is the maximum acceptable lifetime for this type of certificates that contains the id-pkix-ocsp-nocheck extension?

PS: Now I cannot test the OCSP due a server error "Code=503,Reason=Service Unavailable"

Best

Ryan Sleevi

unread,
Feb 4, 2016, 3:57:54 PM2/4/16
to mozilla-dev-s...@lists.mozilla.org
Reposting this, as Kathleen confirmed it made it to her, but not the list:

On Thu, December 10, 2015 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

Kathleen,

I've attempted to complete a review of the CPS as if this was a new
inclusion. I did not review the specific SSL CP, as I found enough
concerning information in the CPS that it did not seem to warrant the time
or energy.

Similar to past discussions, I've attempted to clarify this into three
sections - Good (which I believe should serve as examples for other CAs),
Meh (which are undesirable or inadvisable, but not strictly forbidden, or
which require further clarification), and Bad (things which I believe are
inconsistent with Mozilla policy or the interest of Mozilla users)

Per your email, I focused on
http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf
as the version of the CPS to review

== Good ==
* Section 3.2.8 thoroughly details the methods for domain name validation.
While I realize others have raised concerns (which I believe are unfounded
and not relevant to the discussion, as they're permitted by the BRs), I do
believe it's a positive sign to include such throughness within a CP/CPS.
* Section 4.1.1 provides substantial documentation about the roles and
parties involved in the issuance of certificates.

== Meh ==
* Page 7 of the CPS clearly documents the Hebrew version of the document
as binding. While this is likely relevant to their role within Israel of
issuing certificates qualified under the national scheme, to the Mozilla
community, I believe the English version is of interest and relevance. For
example, does Page 7 imply that ComSign may unilaterally update the Hebrew
version, without a corresponding update to the English version? Does that
facilitate Mozilla community review? At a minimum, the English version
should be seen as 'as binding' as the Hebrew version, which provides some
assurances about the consistency therein.
* Section 2.1 states that "The list of revoked certificates containing
their serial number and date of revocation is accessible for controlled
viewing." This implies that the revocation information is not freely and
publicly available, which contradicts the statements about the CRLs and
OCSP information being freely publicized within the Repository. Could
ComSign clarify what is meant by this section?
* Section 2.3 disclaims any responsibility if CRLs are not fetched every
time, every verification. This defeats many of the purposes of CRLs having
validity periods, and seems to discourage a scalable infrastructure.
* Section 3.2.5 indicates that certificate renewal is permitted. ComSign
should be aware that for the purposes of the Mozilla policy, the act of
renewal is seen as if it was a new certificate issuance. That is, at time
of "renewal", the renewed certificate must comply with all current and
in-force policies - it CANNOT violate the requirements in effect at the
time of signing (for example, a SHA-1 certificate CANNOT be renewed after
2016-01-01, as this would be new issuance)
* Section 3.2.8.2.2 has a typo (trough -> through)
* Sections 7.1 - 7.4 are unclear as to whether the EKUs enumerated
represent examples (and thus, issued certificates may include other such
EKUs), as the section titles imply, or whether they represent an
exhaustive list of what can appear within that field. If it is merely
exemplary, this does represent a concern as non-SSL certificates may
inadvertently be enabled for SSL if the wrong EKUs are presented.
* Section 7.1.4 documents multiple CRL locations may appear, but ComSign
should be aware that virtually all major clients ignore these multiple
URLs and will only check a single URL. Thus, it seems inefficient and
wasteful to encode as such.

== Bad ==
* The CPS does not appear to conform to either RFC 2527 or RFC 3647, as
required by the Baseline Requirements. The CPS seemingly follows 3647,
based on the rough outline, but Sections 9 and 10 definitely diverge. The
document states they were formulated according to ETSI TS 456, but that
does not seem an acceptable form.
* Examples of such divergence: Sections 1.3.3, 1.4.*, 3.2
* Section 3.2.6.1.2 does not seem to permit revocation based on
demonstrating proof of possession of a private key (which would seem
important if the customer loses the revocation code), nor does it permit
revocation based on writing (which MUST be supported, per 4.9.1.1 of the
Baseline Requirements v.1.3.1)
* Section 10.15.1 reserves ComSign the right to unilaterally employ
additional methods at ComSign's discretion. This seems to run counter to
the Mozilla Policy which obligates the CA to notify Mozilla of any
meaningful changes to the CP/CPS.
* ComSign fails to document and operate test URLs compliant with Section
2.2 of the Baseline Requirements, v1.3.1.
* ComSign has failed to document how CAA records are handled. While
ComSign was audited to v1.1.6 of the Baseline Requirements, and CAA was
not required until Ballot 125, which was incorporated into 1.2.0, ComSign
states in Section 10 that they adhere to the latest published version of
the Baseline Requirements (as the BRs require), which is demonstrably
false.
* Section 3.2.8.1.3 employs a validation method that, while permitted by
the Baseline Requirements at present, is recognized as a security risk and
is quite contentiously discussed within the CA/Browser Forum's Validation
Working Group. The use of methods like this have been used to cause
misissuance in the past, and for that reason the Mozilla community should
be suspicious about endorsing it, even if the BRs permit it.
* Section 3.3.4 fails to document procedures for rejecting certificate
requests for the reasons documented in Section 4.1.1 of v1.3.1 of the
Baseline Requirements.
* Section 4.8.1 fails to enumerate the methods listed in Section 4.9.1.1
of v1.3.1 of the Baseline Requirements.
* Contrary to Section 4.9.3 of the Baseline Requirements, ComSign does not
appear to have documented a means to report suspected misissuance or
compromise.
* Section 10.15.15 permits the suspension of certificates, which is
contrary to Section 4.9.3 of v1.3.1 of the Baseline Requirements.

I suspect that, on a more detailed analysis, one might find more aspects
of BR non-compliance. The structure of the CPS, and it's use of a
non-standard format, makes it exceptionally difficult to align ComSign's
stated practices with the requirements of the Baseline Requirements.

My recommendations, based on the failure of ComSign to routinely update
their practices and documentation to adhere to the developments within the
CA/Browser Forum, despite their CPS stating they do, would be to refuse
this renewal request and, given how long such requirements have existed
within the Baseline Requirements, to recommend that ComSign be scheduled
for removal, consistent with
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/

Eli Spitzer

unread,
Feb 8, 2016, 9:11:24 AM2/8/16
to mozilla-dev-s...@lists.mozilla.org
Thank you,
We will review all of these remarks and try to answer them in an orderly fashion.
Message has been deleted

Eli Spitzer

unread,
Mar 22, 2016, 12:45:43 PM3/22/16
to mozilla-dev-s...@lists.mozilla.org
Hello,
In response to the issues raised by Mr. Sleevi, we are making a number of changes in to ComSign's CPS.
Some of the issues raised here will be addressed by the changes in the CPS, while others will remain the same because we feel that they do not represent problems with our compliance to the Mozilla Policy.

Listed here are all of the replies in order of Mr. Sleevi's remarks (and with the division between 'Meh' and 'Bad').
The draft of the revised CPS can be viewed in this address:
"http://www.comsign.co.uk/wp-content/uploads/Comsign CPS-EN-v312-Draft.pdf"
It includes most of the suggested changed (red-lined), but it still has the existing CPS structure. We are planning to change the structure and order of sections as well.
Also, I would like to thank Mr. Sleevi, since this is an opportunity for us to improve our CPS and do some serious housekeeping, which we may not have done without his objections.

> == Meh ==
> * Page 7 of the CPS clearly documents the Hebrew version of the document
> as binding. While this is likely relevant to their role within Israel of
> issuing certificates qualified under the national scheme, to the Mozilla
> community, I believe the English version is of interest and relevance. For
> example, does Page 7 imply that ComSign may unilaterally update the Hebrew
> version, without a corresponding update to the English version? Does that
> facilitate Mozilla community review? At a minimum, the English version
> should be seen as 'as binding' as the Hebrew version, which provides some
> assurances about the consistency therein.

The Hebrew version of this CPS is binding in regards to matters of Israeli law and regulations, specifically for the purpose of issuing personal certificates in accordance with the Israeli Law of Electronic Signature - Hebrew being the formal and common language of the state of Israel. The scope of personal certificates which are bound to the Israeli law is defined by the Intermediate CA's that issue only this type of certificates - and no other types:
a. ComSign Professionals CA
b. ComSign Corporations CA
The English version of this CPS is binding in regards to matters of SSL certificates, Code signing and International Email certificates - which are not covered by the Israeli law of Electronic Signature.
The scope of certificates which are managed and operated according to the English version of this CPS is defined by the Intermediate CA that issues these certificates:
c. ComSign Organizational CA
These clarification will be added to the upcoming revision of the CPS and can be reviewd in the linked draft.

> * Section 2.1 states that "The list of revoked certificates containing
> their serial number and date of revocation is accessible for controlled
> viewing." This implies that the revocation information is not freely and
> publicly available, which contradicts the statements about the CRLs and
> OCSP information being freely publicized within the Repository. Could
> ComSign clarify what is meant by this section?

The language in this section is indeed vague and unclear. We are revising this paragraph to make it clear that certificate revocation is always freely and publically accessible, including the list of serial numbers of certificates that were revoked and the date and time of the revocation. This information is of course part of ComSign's signed CRL files and signed OCSP responses, as required by Mozilla's policy.

> * Section 2.3 disclaims any responsibility if CRLs are not fetched every
> time, every verification. This defeats many of the purposes of CRLs having
> validity periods, and seems to discourage a scalable infrastructure.

The reservation that appears in this section states that the most updated CRL is the one published by ComSign. This is pretty straight-forward: certificate may be revoked at any time, and according to some standards that we are committed to (e.g. CWA 14167-1 [RM2.2]) any revocation is reflected immediately in our CRL and OCSP service. If any client software is configured to retrieve revocation information only according to the "Next Update" field of the CRL, then it will be aware of new revocation entries some time after they are first published.

> * Section 3.2.5 indicates that certificate renewal is permitted. ComSign
> should be aware that for the purposes of the Mozilla policy, the act of
> renewal is seen as if it was a new certificate issuance. That is, at time
> of "renewal", the renewed certificate must comply with all current and
> in-force policies - it CANNOT violate the requirements in effect at the
> time of signing (for example, a SHA-1 certificate CANNOT be renewed after
> 2016-01-01, as this would be new issuance)

Agreed. The section regarding renewal of certificate has no precedence over other sections of the CPS which explicitly declare compliance to Mozilla's or CA/B forum's policies (e.g. validity periods).
In the upcoming revision the CPS we may add a clarification stating that the policies and limitations that apply to any renewed certificate are those which are valid at the time of the renewal of the certificate. This can be reviewd in the linked draft.

> * Section 3.2.8.2.2 has a typo (trough -> through)

Will be corrected in the upcoming CPS version, and can be reviewd in the linked draft.

> * Sections 7.1 - 7.4 are unclear as to whether the EKUs enumerated
> represent examples (and thus, issued certificates may include other such
> EKUs), as the section titles imply, or whether they represent an
> exhaustive list of what can appear within that field. If it is merely
> exemplary, this does represent a concern as non-SSL certificates may
> inadvertently be enabled for SSL if the wrong EKUs are presented.

The certificate structure listed is a statement of the certificates issued by ComSign. It does not represent mere examples. This includes any EKU listed as part of the certificate structure. A clarification can be reviewd in the linked draft.

> * Section 7.1.4 documents multiple CRL locations may appear, but ComSign
> should be aware that virtually all major clients ignore these multiple
> URLs and will only check a single URL. Thus, it seems inefficient and
> wasteful to encode as such.

The second CRL location may be ignored by some clients, but we intend to leave it as it is.

> == Bad ==
> * The CPS does not appear to conform to either RFC 2527 or RFC 3647, as
> required by the Baseline Requirements. The CPS seemingly follows 3647,
> based on the rough outline, but Sections 9 and 10 definitely diverge. The
> document states they were formulated according to ETSI TS 456, but that
> does not seem an acceptable form.
> * Examples of such divergence: Sections 1.3.3, 1.4.*, 3.2

We are planning to re-order the CPS and to apply the RFC structure in one of the next CPS revisions.

> * Section 3.2.6.1.2 does not seem to permit revocation based on
> demonstrating proof of possession of a private key (which would seem
> important if the customer loses the revocation code), nor does it permit
> revocation based on writing (which MUST be supported, per 4.9.1.1 of the
> Baseline Requirements v.1.3.1)

We do not support revocation based on demonstrating proof of possession of a private key. As stated in this section, we offer other means of validating the identity of a person requesting certificate revocation.
Regarding a request in writing, we shell add an explicit addition to this section which lists writing as an acceptable method of requesting revocation with regards to SSL certificates. This also applies to section 4.8.1 in ComSIgn's CPS. These additions can be reviewd in the linked draft.

> * Section 10.15.1 reserves ComSign the right to unilaterally employ
> additional methods at ComSign's discretion. This seems to run counter to
> the Mozilla Policy which obligates the CA to notify Mozilla of any
> meaningful changes to the CP/CPS.

This is a "General Statement of Conformity" section, which states that all of ComSign's methods of performing tasks related to certificate issuance will comply with the policies of the Certification Authority / Browser Forum ("CAB Forum").
It also stated that "In case multiple or alternative methods or options are possible by the baseline requirements or guidelines ... ComSign reserves the right to choose any of the methods or options applicable". The methods themselves are listed and enumerated throw-out the CPS.
There is no mention in this section of the option to add additional methods, or to make any major or meaningful change to the CP/CPS. Of course ComSign is obligated and WILL notify Mozilla of any meaningful change in its CP/CPS, but this is not relevant to this section.

> * ComSign fails to document and operate test URLs compliant with Section

The linked to the test URL's will be added to the CPS in the upcoming revision. They can be reviewd in the linked draft.

> 2.2 of the Baseline Requirements, v1.3.1.
> * ComSign has failed to document how CAA records are handled. While
> ComSign was audited to v1.1.6 of the Baseline Requirements, and CAA was
> not required until Ballot 125, which was incorporated into 1.2.0, ComSign
> states in Section 10 that they adhere to the latest published version of
> the Baseline Requirements (as the BRs require), which is demonstrably
> false.

ComSign's approach for handling CAA records will be stated in the upcoming revision of the CPS.
In addition, we will amend the statement regarding the latest published version of the Baseline Requirements, to be the exact version which we comply with.
Both these additions can be reviewd in the linked draft.

> * Section 3.2.8.1.3 employs a validation method that, while permitted by
> the Baseline Requirements at present, is recognized as a security risk and
> is quite contentiously discussed within the CA/Browser Forum's Validation
> Working Group. The use of methods like this have been used to cause
> misissuance in the past, and for that reason the Mozilla community should
> be suspicious about endorsing it, even if the BRs permit it.

HTTP based Domain Control Validation is a method which is explicitly permitted by the Baseline Requirements, the Mozilla policy does not forbidden this method, and a number of well-known public CA's use this method.
In accordance with these facts ComSign still reserved the right to use this method.

> * Section 3.3.4 fails to document procedures for rejecting certificate
> requests for the reasons documented in Section 4.1.1 of v1.3.1 of the
> Baseline Requirements.

ComSign's systems were audited according to "WebTrust for Certification Authorities - SSL Baseline Requirements" and the requirement in section 4.1.1 of the Baseline Requirements is covered by section 4.7 of the WebTrust criteria. However, due to an oversight the adherence to this section was not included in the CPS. This will be corrected in the upcoming CPS revision, and can be reviewd in the linked draft.

> * Section 4.8.1 fails to enumerate the methods listed in Section 4.9.1.1
> of v1.3.1 of the Baseline Requirements.

In the upcoming CPS revision we will specify additional revocation reasons in order to comply with section 4.9.1.1. They can be reviewd in the linked draft.

> * Contrary to Section 4.9.3 of the Baseline Requirements, ComSign does not
> appear to have documented a means to report suspected misissuance or
> compromise.

In the upcoming CPS revision we will specify the means to report such information in accordance with section 4.9.3. It can be reviewd in the linked draft.

> * Section 10.15.15 permits the suspension of certificates, which is
> contrary to Section 4.9.3 of v1.3.1 of the Baseline Requirements.

Certificate suspension is a practice used by ComSign only in relation to personal certificates and not SSL certificates.
In the upcoming CPS revision we will specify a clarification for the issue. It can be reviewd in the linked draft.

Eli Spitzer, Information security & System Management, Comsign

Jakob Bohm

unread,
Mar 22, 2016, 1:14:08 PM3/22/16
to mozilla-dev-s...@lists.mozilla.org
Just one minor typo issue:

On 22/03/2016 17:42, Eli Spitzer wrote:
> Hello,
> In response to the issues raised by Mr. Sleevi, we are making a number
> of changes in to ComSign's CPS.
>
> Some of the issues raised here will be addressed by the changes in the
> CPS, while others will remain the same because we feel that they do
> not represent problems with our compliance to the Mozilla Policy.
>
> Listed here are all of the replies in order of Mr. Sleevi's remarks
> (and with the division between 'Meh' and 'Bad').
>
> The draft of the revised CPS can be viewed in this address:
>
> http://www.comsign.co.uk/wp-content/uploads/Comsign CPS-EN-v312-Draft.pdf
>
> It includes most of the suggested changed (red-lined), but it still has
> the existing CPS structure. We are planning to change the structure and
> order of sections as well.
>
> Also, I would like to thank Mr. Sleevi, since this is an opportunity
> for us to improve our CPS and do some serious housekeeping, which we
> may not have done without his objections.
>
> ...
>> * Section 10.15.1 reserves ComSign the right to unilaterally employ
>> additional methods at ComSign's discretion. This seems to run counter to
>> the Mozilla Policy which obligates the CA to notify Mozilla of any
>> meaningful changes to the CP/CPS.
>
> This is a "General Statement of Conformity" section, which states that
> all of ComSign's methods of performing tasks related to certificate
> issuance will comply with the policies of the Certification Authority
> / Browser Forum ("CAB Forum").
>
> It also stated that "In case multiple or alternative methods or options
> are possible by the baseline requirements or guidelines ... ComSign
> reserves the right to choose any of the methods or options
> applicable". The methods themselves are listed and enumerated
> throw-out the CPS.
>
I think you mean through-out, which is something completely different.

> There is no mention in this section of the option to add additional
> methods, or to make any major or meaningful change to the CP/CPS. Of
> course ComSign is obligated and WILL notify Mozilla of any meaningful
> change in its CP/CPS, but this is not relevant to this section.
>


> ...
>
>
> Eli Spitzer, Information security & System Management, Comsign
>


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Andrew Whalley

unread,
Mar 29, 2016, 9:36:44 PM3/29/16
to mozilla-dev-s...@lists.mozilla.org
Hello Jesus,

Great points!

> Reviewing the BR audit report of Comsign Ltd I have a few doubts regarding the audits accepted by Mozilla and may someone can help me.
>
> The BR audit was conducted according to the WebTrust forCertification Authorites - SSL Baseline Requirements Audit Criteria version 1.1 and it's a point-of-time (as of April 26, 2015).
> Although this audit criteria is accepted according to the Mozilla CA Certificate Inclusion Policy 2.2, the BR audit version 1.1 was superseded by Webtrust SSL Baseline with Network Security version 2.0 (effective for audit periods starting on or after July 1, 2014).
>
> Webtrust audit criteria states that "The point-in-time readiness assessment shall be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and shall be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. (See SSL Baseline Requirements Section 17.4)". Should Mozilla expect a complete audit 90 days after the point-in-time BR audit report or after the first certificate (I don't know when was issued)?

Neither of the other audit reports I can find by Sharony - Shefler & Co, for "ComSign CA" (https://bugzilla.mozilla.org/attachment.cgi?id=868616) and "Comsign Secured CA" (https://bugzilla.mozilla.org/attachment.cgi?id=8686170), give an audit duration and only state a point in time.

Eli, please confirm when we can expect a period audit and what period it will cover.

> In addition and regarding the OCSP Responder certificate with Serial Number: 0e:2b:cd:a4:aa:4f:8f:80:da:16:94:4e:ba:33:35:33, the validity is 3 years. According the RFC 6960 "A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension SHALL be NULL. CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently." Which is the maximum acceptable lifetime for this type of certificates that contains the id-pkix-ocsp-nocheck extension?

Three years seems excessive, but doesn't appear to be uncommon:

http://ocsp.entrust.net
Not Before: Jun 4 19:15:34 2015 GMT
Not After : Jun 4 19:45:34 2017 GMT

http://crl.quovadisglobal.com/qvocag2.crl
Not Before: May 28 14:33:37 2014 GMT
Not After : May 28 14:33:37 2017 GMT

And there are some are valid for much longer:

http://root-c3-ca2-2009.ocsp.d-trust.net
Not Before: Jul 2 10:03:07 2013 GMT
Not After : Nov 5 08:35:58 2029 GMT

It sounds like limiting the validity period of OCSP signing certs would be an excellent topic to discuss generally, but I don't consider it a blocking issue for this application.

Andrew

Eli Spitzer

unread,
Mar 30, 2016, 3:20:25 AM3/30/16
to mozilla-dev-s...@lists.mozilla.org
Hello Andrew and Jesus,
As mentioned, the Audit reports that we have are only Point-in-Time reports. We haven't started issuing public certificates yet, and at the moment we are not planning to do so until the inclusion in the Mozilla Root program.
Once we finish the inclusion process and start issuing public certificates we will conduct a period audit as required by WebTrust BR
Eli

Andrew R. Whalley

unread,
Apr 4, 2016, 2:40:02 PM4/4/16
to Eli Spitzer, mozilla-dev-s...@lists.mozilla.org
It looks like https://fedir.comsign.co.il/test.html is trusted by OS X,
which for me meets the criteria for a Publicly‐Trusted Certificate. That
certificate was issued on 2nd Feb, so I presume the 90 day clock is ticking.





Andrew R. Whalley | Crypto Wrangler | Chrome Networking and Security | +1
415-736-7248

On Wed, Mar 30, 2016 at 12:20 AM, Eli Spitzer <elis....@gmail.com> wrote:

> On Wednesday, March 30, 2016 at 4:36:44 AM UTC+3, Andrew Whalley wrote:
> Hello Andrew and Jesus,
> As mentioned, the Audit reports that we have are only Point-in-Time
> reports. We haven't started issuing public certificates yet, and at the
> moment we are not planning to do so until the inclusion in the Mozilla Root
> program.
> Once we finish the inclusion process and start issuing public certificates
> we will conduct a period audit as required by WebTrust BR
> Eli
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Eli Spitzer

unread,
Apr 5, 2016, 10:20:21 AM4/5/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, April 4, 2016 at 9:40:02 PM UTC+3, Andrew R. Whalley wrote:
> It looks like https://fedir.comsign.co.il/test.html is trusted by OS X,
> which for me meets the criteria for a Publicly‐Trusted Certificate. That
> certificate was issued on 2nd Feb, so I presume the 90 day clock is ticking.
>
> >

Hello Andrew,

According to your interpretation, there should be no Point-In-Time readiness audits at all. At the very first moment of submitting an inclusion request there must already be some test certificates issued in order to comply with the BR – and this is the case with the certificate for fedir.comsign.co.il that you mentioned. Does is mean that issuing any test certificate immediately makes the CA a production system and requires a period audit?

Regarding the Inclusion in the Apple Root Certificate Program – whether or not a third party like Apple trusts this root is beside the point. This is not a correct interpretation of the term ‘issuing Publicly-Trusted Certificates’ as it is used by Mozilla.
Citing from the Mozilla Wiki - CA:BaselineRequirements (https://wiki.mozilla.org/CA:BaselineRequirements):

“if the root certificate is not yet in production and is not yet issuing certificates to customers, then a Point in Time Readiness Assessment of BR compliance (BR PITRA) may be used. In this case a BR PITRA prior to inclusion may be used, but the next annual audit after inclusion would need to be a full performance audit. Note: If the inclusion process spans more than one annual audit cycle, then more than one BR PITRA may be used, until the root certificate has been included or the root certificate is put into operation producing certificates for customers, whichever comes first.”

This is exactly the case with the ‘Comsign Global Root CA’ inclusion process – the initial inclusion request was submitted on July 2011, and since then there have been many delays. Some of these delays were entirely out of Comsign’s control, such as a waiting queue for the public discussion which took about four months.

Thanks,

Kathleen Wilson

unread,
Apr 6, 2016, 2:06:58 PM4/6/16
to mozilla-dev-s...@lists.mozilla.org
All,

Thank you to all of you who have been contributing to this discussion.

I do not yet feel comfortable with approving this request to include the 'ComSign Global Root CA' root certificate, and enable the Websites and Email trust bits.

My understanding is that this root certificate is included in both the Apple and Microsoft root stores and trusted for TLS, so regardless of what Mozilla's wiki pages say, it is a publicly trusted root certificate and should be meeting all of the requirements of the CA/Browser Forum's Baseline Requirements.

Therefore, my inclination is to put this discussion on hold until a full BR audit has been performed, and the audit statement provided.

Thanks,
Kathleen

Peter Bowen

unread,
Apr 6, 2016, 2:35:54 PM4/6/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Wed, Apr 6, 2016 at 10:58 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> My understanding is that this root certificate is included in both the Apple and Microsoft root stores and trusted for TLS, so regardless of what Mozilla's wiki pages say, it is a publicly trusted root certificate and should be meeting all of the requirements of the CA/Browser Forum's Baseline Requirements.
>
> Therefore, my inclination is to put this discussion on hold until a full BR audit has been performed, and the audit statement provided.

Kathleen,

Based on discussions I have had with auditors, there is not a clear
standard on what constitutes the "first certificate" for the purposes
of starting the 90 day period. I know that there is one
interpretation that certificates where the issuer, subject, and domain
registrant are the same entity are not adequate to demonstrate
exercise of controls. That being said,
https://crt.sh/?Identity=%25&iCAID=1632 clearly shows that a CA signed
by "ComSign Global Root CA" has issued certificates that do not appear
to be for domains controlled by ComSign. The earliest has a notBefore
date of 2014-10-26. Therefore it would seem that the first
examination period should have ended on or before 2015-01-26. Even
being extremely generous with time for the auditor to prepare an
attestation report, there should be a period of time report by now, a
year later.

I believe there is a requirement for an unbroken sequence of audit
periods. I would therefore hope that ComSign will provide audit
reports that document the period starting from when they generated or
acquired their CA keys to the end of the most recent examination
period. If this is not possible, I would hope that they will provide
a clear statement from their management as to why this is not possible
and an explanation of controls they had in place to ensure that the
keys were not misused from during the unaudited period.

Thanks,
Peter

Kathleen Wilson

unread,
Apr 7, 2016, 5:58:41 PM4/7/16
to mozilla-dev-s...@lists.mozilla.org
The status of this discussion is that we are waiting for the CA to provide the following:

1) Updated/restructured CPS (both in Hebrew and translated into English).

2) Full BR Audit statement.

3) An explanation of how the requirement for an unbroken sequence of audit periods has been met.

This discussion may continue as soon as the CA has provided the three items listed above.

Thanks,
Kathleen

Eli Spitzer

unread,
Apr 27, 2016, 12:19:35 PM4/27/16
to mozilla-dev-s...@lists.mozilla.org
I've added our latest WebTrust CA Audit report to the Root Inclusion Bug:
"https://bugzilla.mozilla.org/show_bug.cgi?id=675060"

Eli Spitzer

unread,
May 5, 2016, 9:36:54 AM5/5/16
to mozilla-dev-s...@lists.mozilla.org
On Friday, April 8, 2016 at 12:58:41 AM UTC+3, Kathleen Wilson wrote:
Hello,
I also added our latest WebTrust SSL BR audit report to the root inclusion bug:
"https://bugzilla.mozilla.org/attachment.cgi?id=8749173"
Both WebTrust CA and WebTrust SSL BR audit reports are full "period" reports.

Thanks,
Eli

Aaron Wu

unread,
Nov 21, 2017, 6:31:11 PM11/21/17
to mozilla-dev-s...@lists.mozilla.org
This discussion of this request was on-hold waiting for the CA to update/restructure their CPS (both in Hebrew and translated into English). The CA has updated their CPS as [1][2][3].

I have verified the following for the Comsign CA:

A. CP/CPS have been updated in English version [1] and corresponding repository [2][3]
B. BR Self Assessment has been updated [4], and the CA resolved all of the shortcomings that they noted in their previous version of BR Self Assessment
C. Current Audit Statements provided [5][6], which updated on 2017/4/26
D. Test websites work as expected [7]

We can restart the discussion and please review their updated documents and comment in this discussion if you have further questions or concerns about this request.

Thanks,
Aaron

[1] CPS v4.0: https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS-EN-v4.0.pdf
[2] Repository: https://www.comsign.co.il/repository/
[3] CPS: https://www.comsign.co.il/cps
[4] BR-Self Assessment: https://bugzilla.mozilla.org/attachment.cgi?id=8899375
[5] https://bug675060.bmoattachments.org/attachment.cgi?id=8872334
[6] https://bug675060.bmoattachments.org/attachment.cgi?id=8872335
[7] Test Websites
- Valid: https://fedir.comsign.co.il/test.html
- Revoked: https://revoked.comsign.co.uk/test.html
- Expired: https://expired.comsign.co.uk/test.html

wth...@mozilla.com

unread,
Dec 5, 2017, 1:43:44 PM12/5/17
to mozilla-dev-s...@lists.mozilla.org
> We can restart the discussion and please review their updated documents and comment in this discussion if you have further questions or concerns about this request.
>
After reviewing Comsign's updated CPS and related documents, I have the following comments:

== Good ==
- CPS follows RFC 3647 and includes a table of revisions
- CAA requirements are met
- Audit reports cover a full year
- Contact information for problem reporting is clearly stated in section 4.9.3
- Aside from what I’ve listed below, all of the issues reported earlier by Ryan Sleevi appear to have been addressed.

== Meh ==
- Fingerprints in the audit reports are SHA-1; should be SHA-256
- The CPS is located at https://www.comsign.co.il/CPS under the heading “CPS – in accordance with the Electronic Signature Law of Israel” but earlier discussions indicate that SSL certificates aren’t covered by this law, in which case it’s not clear what the difference is between this CPS and the one listed under “CPS – for - Certificates that are not under the Electronic Signature Law of Israel” on the same page.
- None of the subordinate CAs contain an EKU extension. [1]
- Section 3.1.3 states that “Comsign will not issue an Electronic Certificate bearing a nickname of the Subscriber or one that does not state the name of the Subscriber” but section 7.1.2.3(iv) shows a DV certificate profile that doesn’t name the Subscriber. If the term ‘Electronic Certificate’ is intended to only apply to non-SSL certificates, then the definition should be clarified.
- The domain validation methods specified in CPS section 3.2.2.4 are nearly cut-and-paste from the BRs, so this section provides little information that can be used to evaluate Comsign’s domain validation practices. [2]
- None of the four intermediates shown in the root hierarchy diagram [3] are disclosed in CCADB at this time (this isn’t required until the root is included). There are (at least) 3 different “ComSign Organizational CA” subordinate CA certificates with the same public key that should be disclosed.

== Bad ==
- The Hebrew version of the CPS at https://www.comsign.co.il/repository/ is version 3.1 while the English version on the same page is 4.0, so I assume that these are different documents. I see nothing in the English version stating that it takes precedence over the Hebrew version.
- Section 1 of the CPS doesn’t clearly state that Comsign adheres to the **latest** version of the BRs, nor that the BRs take precedence over the CPS (BR 2.2).
- The Creative Commons license is not listed in the CPS (Mozilla policy 3.3).
- Audit reports don’t list any intermediates covered by the audit (Mozilla policy 3.1.4).
- 3.2.2.4 states “All authentication and verification procedures in this sub-section shall be performed either directly by Comsign's personnel (RAs) or by Comsign's authorized representatives.”. There is no definition of who can be an ‘authorized representative’, but in this context it sounds like a Delegated Third Party, and CAs are not permitted to delegate domain validation (BR 1.3.2).
- CPS 3.2.2.4 states: “For issuing certificates to organizations requesting SSL certificates,Comsign performs domain name owners 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.” How does a WHOIS check or a human review effectively detect mixed scripts in a label? I don’t believe this is an effective safeguard against homograph spoofing.
- The audit reports supplied cover the period from 2015-04-27 to present. This doesn’t appear to satisfy the requirement for an unbroken sequence of audit periods back to the issuance of the first certificate on 2014-10-26 (refer to earlier discussion in this thread).

Wayne

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Usage_of_Appropriate_Constraints
[2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership
[3] https://bug675060.bmoattachments.org/attachment.cgi?id=8608692

YairE

unread,
Dec 11, 2017, 1:43:10 AM12/11/17
to mozilla-dev-s...@lists.mozilla.org
Thank you for your notes,
Here are the answers to your points.

all the "bad" points about the CPS were addressed:
Both CPS'es are changed to ver 4.1
section 1 states that we are addressing the *latest* BR
3.2.2.4 was corrected
the CPS'es in our site has been updated
I’m attaching the new CPS'es so you can review them

about the "creative commons license" it is indeed not listed and therefore according to Mozilla policy 3.3 will automatically be treated as CC-BY-ND 4.0.
I’m also attaching the audit for October 2014 as requested and recent audits who include the intermediate certificates.

Link to all the attachments:

https://drive.google.com/open?id=1VzrWqouZeda5bQkyhdboO_KvfBo9QV17
Message has been deleted

Wayne Thayer

unread,
Dec 18, 2017, 5:08:19 PM12/18/17
to YairE, mozilla-dev-security-policy
On Sun, Dec 10, 2017 at 9:15 AM, YairE via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Thank you for your notes,
> Here are the answers to your points.
>
> all the "bad" points about the CPS were addressed:
> Both CPS's are now changed to ver 4.1
>

Looks good, thank you.

section 1 states that we are addressing the latest BR
>

I am not convinced that section 1 of your CPS meets the requirements set
forth in BR 2.2. Your CPS states:

Comsign will develop, implement, enforce, and annually update these
Procedures in accordance with the requirements of the Law, the latest
requirements of the CA/Browser forum and any other relevant practices and
requirements.

The BRs state that you 'must include a link to the official version of
these Requirements'. Also, your CPS says that you will annually update your
procedures, while the BRs require the CA to commit to comply with the
latest public version at all times.

3.2.2.4 was corrected
>

My concern about delegated third parties was addressed (thank you), but my
concern about homograph spoofing was not.

Also, my final point about the audit report covering the period from
2014-10-26 to 2015-04-27 was not addressed.


> i'm also attaching the new CPS'es so you can review them
>
> About the "creative commons license" it is indeed not listed and therefore
> according to Mozilla policy 3.3 will automatically be treated as CC-BY-ND
> 4.0.
> I'm also attaching the audit for October 2014 as requested and recent
> audits who include the intermediate certificates.
>
> I do not think this is the intent of the policy, but I agree that this is
allowed. I've added an issue [1] to consider updating this requirement in
the next version of the policy.

[1] https://github.com/mozilla/pkipolicy/issues/110

YairE

unread,
Dec 19, 2017, 8:43:07 AM12/19/17
to mozilla-dev-s...@lists.mozilla.org
Thank you again,

On section 1 - we now added links to the current BR etc, and removed the "annual" update so we are bound to update anytime a new version is released.

About the homograph spoofing - we have changed the section so now it tells its only automatic (because as you have pointed, there is no way to validate manually)

the attachements again:
https://drive.google.com/open?id=1VzrWqouZeda5bQkyhdboO_KvfBo9QV17


Doug Beattie

unread,
Dec 19, 2017, 11:15:48 AM12/19/17
to wth...@mozilla.com, mozilla-dev-s...@lists.mozilla.org
Hi Wayne,

I noticed your comment on IDN validation. Is there a requirement that CAs establish an effective safeguard against homograph spoofing?

The reason I ask is that Let's Encrypt's CPS says this: "Regarding Internationalized Domain Names, ISRG will have no objection so long as the domain is resolvable via DNS. It is the CA’s position that homoglyph spoofing should be dealt with by registrars, and Web browsers should have sensible policies for when to display the punycode versions of names."

Doug

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Wayne Thayer via dev-security-policy
> Sent: Tuesday, December 5, 2017 1:44 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: ComSign Root Renewal Request
>
> > We can restart the discussion and please review their updated documents
> and comment in this discussion if you have further questions or concerns
> about this request.
> >

Wayne Thayer

unread,
Dec 20, 2017, 10:50:05 AM12/20/17
to Doug Beattie, mozilla-dev-s...@lists.mozilla.org
Doug,

I am not aware of any requirement for CAs to detect or prevent homograph
spoofing in the names contained in certificates they issue. Mozilla's
position is that this is something best handled by registries/registrars
just as stated in the CPS you quoted.

In the case of the ComSign CPS, my concerns were that the paragraph was
confusing and it described an ineffective process, so I asked for
clarification.

Wayne

On Tue, Dec 19, 2017 at 4:14 PM, Doug Beattie <doug.b...@globalsign.com>
wrote:

> Hi Wayne,
>
> I noticed your comment on IDN validation. Is there a requirement that CAs
> establish an effective safeguard against homograph spoofing?
>
> The reason I ask is that Let's Encrypt's CPS says this: "Regarding
> Internationalized Domain Names, ISRG will have no objection so long as the
> domain is resolvable via DNS. It is the CA’s position that homoglyph
> spoofing should be dealt with by registrars, and Web browsers should have
> sensible policies for when to display the punycode versions of names."
>
> Doug
>
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> > Wayne Thayer via dev-security-policy
> > Sent: Tuesday, December 5, 2017 1:44 PM
> > To: mozilla-dev-s...@lists.mozilla.org
> > Subject: Re: ComSign Root Renewal Request
> >
> > > We can restart the discussion and please review their updated documents
> > and comment in this discussion if you have further questions or concerns
> > about this request.
> > >

YairE

unread,
Dec 24, 2017, 4:46:03 AM12/24/17
to mozilla-dev-s...@lists.mozilla.org
Hi Wayne,

as requested i added the file with the certificates issued since 26/10/2014 until 31/03/2015 to the bug,

Back then it seems we didn’t have a WebTrust audit (I believe we started in 2015) but only external CPA and governmental audits as are attached already.
The reason we didn’t have a WebTrust audit is that we were already being audited by other auditors and the external WebTrust auditor was qualified only around that time.

wth...@mozilla.com

unread,
Jan 16, 2018, 4:06:02 PM1/16/18
to mozilla-dev-s...@lists.mozilla.org
To recap, we've established that this root was first BR audited on 26-April 2015 and has received clean period-of-time audits over the next two years. ComSign has disclosed 36 certificates issued by this root prior to the BR point-in-time audit, of which one remains unexpired. This does not meet the requirements of BR section 8.1 both because the point-in-time readiness assessment was not completed prior to issuing a publicly-trusted certificate, and because the first period-of-time audit was not completed within 90 days of issuing a publicly-trusted certificate. Mozilla policy, however, does not require a root to have maintained BR compliance over its entire lifetime to be included in the program. ComSign's current annual WebTrust for CAs and BR audits are enough to meet Mozilla's requirements.

The questions I raised have been addressed to my satisfaction. If anyone has further concerns, please raise them this week so that we can complete the public discussion period for this inclusion request.

- Wayne

Wayne Thayer

unread,
Jan 22, 2018, 2:32:13 PM1/22/18
to mozilla-dev-security-policy
Today I noticed the following ComSign response to question 6 [1] in
Mozilla's November 2017 CA Communication:

We are in the process of perfecting our CAA system. As far as I know we do
> not have a devoted mailbox for problem reporting in the root program, the
> mail for that should be mine – ya...@comda.co.il
>

<ya...@comda.co.il>
This first implies that ComSign is not yet performing CAA checking as
required by the BRs effective 8-Sept 2017.

While the BRs do not require problem reports to be accepted via email, they
do require CAs to "publicly disclose the instructions through a readily
accessible online means". The ComSign CPS includes two email addresses:
sup...@comsign.co.il and customer...@comsign.co.il. How has ComSign
met this requirement?

I will leave the discussion period open until ComSign has responded to
these concerns.

- Wayne

[1] https://ccadb-public.secure.force.com/mozillacommunications/
CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=
Q00042,Q00048

YairE

unread,
Jan 23, 2018, 8:56:07 AM1/23/18
to mozilla-dev-s...@lists.mozilla.org
On Monday, January 22, 2018 at 9:32:13 PM UTC+2, Wayne Thayer wrote:
> Today I noticed the following ComSign response to question 6 [1] in
> Mozilla's November 2017 CA Communication:
>
> We are in the process of perfecting our CAA system. As far as I know we do
> > not have a devoted mailbox for problem reporting in the root program, the mail for that should be mine – ya...@comda.co.il
>
> <ya...@comda.co.il>
> This first implies that ComSign is not yet performing CAA checking as
> required by the BRs effective 8-Sept 2017.

>>>while we answered the survey we were still working on improving our CAA checking, today we do perform the CAA checking as required.

> While the BRs do not require problem reports to be accepted via email, they do require CAs to "publicly disclose the instructions through a readily
> accessible online means". The ComSign CPS includes two email addresses:
> sup...@comsign.co.il and customer...@comsign.co.il. How has ComSign
> met this requirement?

>>> we added to our Hebrew site a contact us box devoted to report any problems (such as fraud,misuse,compromise etc) regarding the SSL certs.
in addition to a section in the Contact Us boxes, we are also adding it to our English site and it would be there by the end of today.

> I will leave the discussion period open until ComSign has responded to
> these concerns.

>>>I hope that we have taken care of all your concerns and we can move on

- Yair


Ryan Sleevi

unread,
Jan 24, 2018, 11:01:31 AM1/24/18
to Wayne Thayer, mozilla-dev-security-policy
For these, it may help to make sure the context is available on the thread
- https://bugzilla.mozilla.org/show_bug.cgi?id=675060 is the bug, and the
current CPS at time of writing is 4.1 (
https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf )

Section 1.3.2.5:
- It remains unclear whether or not DTPs can perform domain validation
(which is no longer permitted under the BRs). ComSign does employ DTPs as
RAs for other forms of information, such as organization information, and
does make it clear it supports Enterprise RAs (which are permitted under
the BRs, provided the domain namespace is scoped to something the CA
validated). Section 3.2.2.4 touches on this by stating it'll be performed
by their own staff, so I think this is just highlighting an ambiguous
inconsistency.

Section 3.2.2.4
- ComSign makes use of the (problematic) 3.2.2.4.1 method. This method is
presently permitted under the BRs, but worth highlighting as a concern,
given the attacks demonstrated in the CA/Browser Forum as to the
reliability of this method.
- ComSign makes use of the (problematic) 3.2.2.4.5 method. This method is
presently permitted under the BRs, but worth highlighting as a concern,
given the attacks demonstrated in the CA/Browser Forum as to the
reliability of this method.
- ComSign makes use of the (problematic) 3.2.2.4.9 method. This method is
presently permitted under the BRs, but worth highlighting as a concern,
given the attacks demonstrated in the CA/Browser Forum as to the
reliability of this method. ComSign has not yet disclosed to this list how
they use it, and whether their use of this method is affected by the same
vulnerabilities that affected GlobalSign and Let's Encrypt.

Section 3.2.2.8
- ComSign does not document ComSign's CAA identifier here or in Section
2.2. It is, however, documented in 4.2.1.1 (iv).

Section 3.4
- ComSign does not seem to permit revocation requests in the event of
misissuance, at least within this section. This means the domain holder of
a misissued certificate seemingly cannot request ComSign revoke that
certificate, nor can they request ComSign revoke pre-existing certificates
potentially obtained by prior domain holders. This seems supported by the
process in Section 4.9.2

Particularly Concerning:
This CP/CPS is the same set that ComSign uses for all of its issuance
practices. During the course of Chrome development and improving our
compliance checks to RFC5280 (which we require by policy and by virtue of
the BRs), we discovered that ComSign had issued "tens of thousands" of
misencoded client certificates [1]. The result was due to using RSA Keon
Certificate Authority [2]. These details were provided by someone
representing themselves as the CEO of ComSign [3].

As best we can tell, RSA was calling the product "Keon Certificate
Authority" at least as recent as 2007, based on CVE-2006-4991 [4], although
based on RSA's current information [5], it appears to have been rebranded
around that time to "RSA Certificate Manager" (no longer being called Keon
CA). The version known as "Keon CA" at least had vulnerabilities that
allowed for the overwriting of CA's audit logs

It's unclear if this means that ComSign is using CA software written in
2007, or whether they're using a more recent version. Based on the
documentation in [5], it does seem RSA Certificate Manager is reached End
of Product Support sometime in 2017, although it seems at least some
updates [6] were provided.

I think this demonstrates a violation of ComSign's commitment to RFC5280,
and to its CP/CPS regarding the use of names (c.f. Section 3.1.1), but also
raises deeper concerns about their commitment to quality in issuance, and
to past practices - particularly those outside of the audited window. Given
that ComSign has stated they plan to find new CA software [7], perhaps it
may be advisable to reject this request (and the key associated), and wait
until such a time as a new CA, with a new key, and an unblemished and
unquestioned audit sequence, can be established.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c3
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c4
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c29
[4] https://nvd.nist.gov/vuln/detail/CVE-2006-4991
[5] https://community.rsa.com/docs/DOC-73367
[6] https://community.rsa.com/docs/DOC-81493
[7] https://bugs.chromium.org/p/chromium/issues/detail?id=770323#c5

On Tue, Jan 16, 2018 at 4:05 PM, Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> To recap, we've established that this root was first BR audited on
> 26-April 2015 and has received clean period-of-time audits over the next
> two years. ComSign has disclosed 36 certificates issued by this root prior
> to the BR point-in-time audit, of which one remains unexpired. This does
> not meet the requirements of BR section 8.1 both because the point-in-time
> readiness assessment was not completed prior to issuing a publicly-trusted
> certificate, and because the first period-of-time audit was not completed
> within 90 days of issuing a publicly-trusted certificate. Mozilla policy,
> however, does not require a root to have maintained BR compliance over its
> entire lifetime to be included in the program. ComSign's current annual
> WebTrust for CAs and BR audits are enough to meet Mozilla's requirements.
>
> The questions I raised have been addressed to my satisfaction. If anyone
> has further concerns, please raise them this week so that we can complete
> the public discussion period for this inclusion request.
>
> - Wayne
>
> On Sunday, December 24, 2017 at 2:46:03 AM UTC-7, YairE wrote:

YairE

unread,
Jan 29, 2018, 10:43:30 AM1/29/18
to mozilla-dev-s...@lists.mozilla.org
Hi Ryan,

I noticed that your notes refer to a previous version of the CPS and not the current one
here is a link to the current version which is 4.1.
https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf

About the CA software – we are now under auditing for our new Microsoft CA and it will take at least 4-6 months until it will be approved for full usage.
We do understand that the Microsoft CA is much better and secure but we still ask of you to approve our root considering the fact we are at the last steps of implementing the Microsoft CA
We are under heavy pressure from customers that are using Mozilla to allow them SSL and we were waiting too much until we reached this point
Even if we receive that you acknowledged for 6 month to continue the current CA – it is good for us.

Yair

Wayne Thayer

unread,
Jan 29, 2018, 11:10:54 AM1/29/18
to YairE, mozilla-dev-security-policy
Yair,

Will you please provide a detailed response to each of Ryan's points? Also,
please provide the specific version of the RSA Certificate Manager in use
by ComSign.

Thanks,

Wayne

YairE

unread,
Feb 5, 2018, 10:23:29 AM2/5/18
to mozilla-dev-s...@lists.mozilla.org
Hi, thank you for pointing the above
Here is our response:

Section 1.3.2.5
We have corrected our CPS now that only limited actions could be performed by DTP's
And they cannot perform domain validation.

Section 3.2.2.4
We are aware of the problems with the methods that have been raised, we thought that as long as they are permitted in the BR we would keep them included on our CPS, of course that we prefer not to use them and will use the more secured methods like 3.2.4.4.2, 3.2.4.4.3 etc.
>After reviewing the January Communication we have removed the problematic methods from our CPS entirely.

Section 3.2.2.8
As Ryan mentioned Comsign’s CAA identifier is documented on section 4.2.1.1(v)
We also added it in section 3.2.2.8 now

Section 3.4
I do not understand why does Ryan claim that a domain holder cannot request a revocation in case of misissuance, it clearly states that any subscriber could revoke any certificate for any reason he seems fit as long as they are identified.

You can see all the updates on our CPS in our site repository:
https://www.comsign.co.il/repository/
on our UK site:
https://www.comsign.co.uk/?page_id=1282
and in this link as well:
https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf

Particularly Concerning
The software we are currently using is RSA CA 6.7 on Solaris.
As we mentioned we are now under audit on the new Microsoft CA and in the process of moving to that software instead of our old software.

Julien Cristau

unread,
Feb 5, 2018, 11:03:55 AM2/5/18
to YairE, mozilla-dev-s...@lists.mozilla.org
Re Section 3.4, you seem to assume the domain holder is a ComSign
subscriber. In case of misissuance, that may not be true.

Cheers,
Julien

YairE

unread,
Feb 6, 2018, 5:00:21 AM2/6/18
to mozilla-dev-s...@lists.mozilla.org
On Monday, February 5, 2018 at 6:03:55 PM UTC+2, Julien Cristau wrote:
> Re Section 3.4, you seem to assume the domain holder is a ComSign
> subscriber. In case of misissuance, that may not be true.
>>> I understand, for that we added on the CPS on section 3.4 the following:
"For the handling of revocation requests by other than the Subscriber or his/her representative, refer to Section ‎4.9 below."

Wayne Thayer

unread,
Feb 6, 2018, 6:34:46 PM2/6/18
to YairE, mozilla-dev-security-policy
Yair,

> Re Section 3.4, you seem to assume the domain holder is a ComSign
> > subscriber. In case of misissuance, that may not be true.
> >>> I understand, for that we added on the CPS on section 3.4 the
> following:
> "For the handling of revocation requests by other than the Subscriber or
> his/her representative, refer to Section ‎4.9 below."
>
> Could you please explain how section 4.9 resolves this concern? My
understanding of section 4.9 of your CPS is that only the Subscriber or an
authorized representative may request revocation.

> > >After reviewing the January Communication we have removed the
> problematic
> > > methods from our CPS entirely.
>

Thank you, this is a good change. However, it appears that you have made
multiple modifications to your CPS without updating the version number or
change log as required by Mozilla policy section 3.3. The latest version is
dated January 31, 2018 but is still at version 4.1 as it was back in
December.

The software we are currently using is RSA CA 6.7 on Solaris.
> As we mentioned we are now under audit on the new Microsoft CA and in the
> process of moving to that software instead of our old software.
>

According to the link Ryan provided [1], this version lost extended support
in July 2013. Is it correct that you have been using an unsupported version
of CA system software for the past 4 1/2 years?

Wayne

[1] https://community.rsa.com/docs/DOC-73367

YairE

unread,
Feb 7, 2018, 10:18:11 AM2/7/18
to mozilla-dev-s...@lists.mozilla.org
Hi Wyane,
resopnding to your notes:

Section 4.9 states that in any case that Comsign is notified about a misissuance (no matter if it was notified by a subscriber or in any other way) Comsign shall revoke the certificate.

It is true that we didn’t update the version number and we have corrected it. Along with updating the CPS version management table as well.

about the software we use for issuing certificate- As we commented on the January Communication we didn’t issue any SSL certificate in the last years at all – we do not plan to issue any SSL certificates in our current RSA software – only with our new one who is under audit now.
So, like we mentioned earlier we would like to be approved in advance so we could start issuing as soon as the new system will be in use.

Wayne Thayer

unread,
Feb 8, 2018, 5:37:18 PM2/8/18
to YairE, mozilla-dev-security-policy
On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Wyane,
> resopnding to your notes:
>
> Section 4.9 states that in any case that Comsign is notified about a
> misissuance (no matter if it was notified by a subscriber or in any other
> way) Comsign shall revoke the certificate.
>
> I have re-read section 4.9 of the ComSign CPS and I still do not agree
with your interpretation. However, I also believe that your current
language complies with Mozilla policy and the BR's.

It is true that we didn’t update the version number and we have corrected
> it. Along with updating the CPS version management table as well.
>
> about the software we use for issuing certificate- As we commented on the
> January Communication we didn’t issue any SSL certificate in the last years
> at all – we do not plan to issue any SSL certificates in our current RSA
> software – only with our new one who is under audit now.
>
> To recap, this inclusion request is for the ComSign Global Root CA that
was created in 2011[1]. This root was first BR audited on 26-April 2015,
but 36 end-entity certificates were issued prior to that time [2] (all but
one has since expired). We also have some evidence [3] that ComSign
received an ETSI 101 456 audit in 2012. ComSign stated “Back then it seems
we didn’t have a WebTrust audit (I believe we started in 2015) but only
external CPA and governmental audits as are attached already.” However, I
am unable to locate any additional audit documentation covering 2011-2015.

about the software we use for issuing certificate- As we commented on the
> January Communication we didn’t issue any SSL certificate in the last years
> at all – we do not plan to issue any SSL certificates in our current RSA
> software – only with our new one who is under audit now.
>

ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
issue certificates. This version has not been supported since July 2013
[4]. This implies that all 36 certificates were issued using unsupported CA
software.

I’ve discovered that ComSign recently issued two new unconstrained
subordinate CAs [5] from this root that contain a non-critical
basicConstraints extension in violation of BR 7.1.2.2. Another
unconstrained subordinate CA has been used to issue email certificates that
contain encoding errors [6].

In addition, numerous problems with ComSign’s CPS have been discussed in
this thread.

So, like we mentioned earlier we would like to be approved in advance so we
> could start issuing as soon as the new system will be in use.
>

While I appreciate ComSign’s efforts to resolve issues that have been
identified, new ones continue to be found. I am not at all comfortable
recommending that this request proceed at this time, and I have also lost
confidence that trust can ever be established for this root given its
history. I support Ryan’s recommendation that this request be denied and
that ComSign be asked to submit a new root containing a new key pair that
has not been used with their outdated CA system.

I would appreciate your comments on this course of action.

Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=675060
[2] https://bugzilla.mozilla.org/attachment.cgi?id=8938861
[3] https://bug675060.bmoattachments.org/attachment.cgi?id=615121
[4] https://community.rsa.com/docs/DOC-73367
[5] https://crt.sh/?cablint=680&iCAID=1631&minNotBefore=2017-01-01
[6] https://crt.sh/?caid=14449&opt=x509lint&minNotBefore=2014-01-01

YairE

unread,
Feb 12, 2018, 1:51:45 PM2/12/18
to mozilla-dev-s...@lists.mozilla.org
Hi Wayne,
Please realize our situation versus the Israeli market. We are the major certificate authority and we comply with every piece of local regulation, we are also members of international forums and trying to establish a CA in the UK with a new "international" root (Comsign International).This is our long term plan.
Meanwhile we are in a tough task to move from the RSA old and unsupported CA software to a new MS CA. It isn’t simple and involves many aspects, locally and internationally. On the same time, we try to be certified to eIDAS in order to be included in the European Trust list.
Mozilla is a mile stone that we MUST pass once and for all, as it prevents and holds us from supplying a lot of signing services to the Israeli market, especially the increasing requests for services over the mobile.
So, while we try to go "hand by hand" with you and with the BR, if you now send us back with the ROOT we have, it actually eliminates all the work we are doing to be complied with Mozilla for a long period of time, as you mentioned in your message. We can estimate that we will fully switch to MS within 6 months or so, mainly because we wait for the final audit and the approval of the Israeli Ministry of Justice, but if, as you suggest, you do not trust the ROOT (not only the CA software in which we are all on the same page with you), it is a much bigger problem, as you understand the meaning of such severe conclusion after all our efforts we did with Mozilla not to speak about the damage to our reputation that such a decision creates.

That was the background. For the essence:
1."ComSign Global Root CA that was created in 2011 was first BR audited on 26-April 2015, but 36 end-entity certificates were issued prior to that time, all but one has since expired)."
>>This one certificate expires at 3/2018 and we commit not to issue new SSL certificates until we are authorized with the new MS CA. However this point should not affect the integrity of the entire Root.

2."However, am unable to locate any additional audit documentation covering 2011-2015.".
>>We've asked the auditor (CPA Shefler which is approved by Webtrust from ~mid 2015) to send us all the audits reports. As is already disclosed this ROOT has passed many Webtrust audits over the last years and can be considered audited –we have already disclosed all the certificates that were issued prior to our first Webtrust as you have asked earlier on this thread.

3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to issue certificates. This version has not been supported since July 2013 [4]. This implies that all 36 certificates were issued using unsupported CA software."
>>Correct. Wrong decision of Comsign, which we apologized for. However, we still believe is should not affect the entire ROOT.

4."I’ve discovered that ComSign recently issued two new unconstrained
subordinate Cas [5] from this root that contain a non-critical basicConstraints extension in violation of BR 7.1.2.2.
>>While we appreciate your point here, these subCA's are not issuing SSL certificates at all but client certificates only. We cannot revoke these subordinates that serve hundreds of thousands of customers. However, if you approve our root – we commit to disclose the new SSL subCA before we issue new SSL certificates, while we keep the BR rules strictly of course.

5."Another unconstrained subordinate CA has been used to issue email certificates that contain encoding errors [6]."
>>That subCA does not issue SSL certificates as we mentioned above, the encoding error was corrected long ago and is linked to the RSA software that we are replacing in any case.

6."In addition, numerous problems with ComSign’s CPS have been discussed in this thread".
>>All these problems were corrected by us and approved by Mozilla representatives.

7."While I appreciate ComSign’s efforts to resolve issues that have been identified, new ones continue to be found. I am not at all comfortable
recommending that this request proceed at this time, and I have also lost confidence that trust can ever be established for this root given its history. I support Ryan’s recommendation that this request be denied and that ComSign be asked to submit a new root containing a new key pair that has not been used with their outdated CA system."
>>As we understand Ryan’s recommendation, after we accomplished almost all the points of rejection, is that Ryan recommends to wait for the new MS-CA, but Ryan did not express mistrust of the ROOT.
We fully understand the points that both you and Ryan made, but to throw the root back now, will be like starting everything from the beginning all over again and will take long precious time.
We suggest that we keep working on this root and fix all that still needs to be fixed.
As for the CPS, we should be totally compliant now.
As for the CA software we will enclose all the relevant details as soon as we finish our preparations and auditing.

We ask you to reconsider this ROOT approval request.

Ryan Sleevi

unread,
Feb 12, 2018, 2:06:45 PM2/12/18
to YairE, mozilla-dev-security-policy
> 1."ComSign Global Root CA that was created in 2011 was first BR audited on
> 26-April 2015, but 36 end-entity certificates were issued prior to that
> time, all but one has since expired)."
> >>This one certificate expires at 3/2018 and we commit not to issue new
> SSL certificates until we are authorized with the new MS CA. However this
> point should not affect the integrity of the entire Root.
>
> 2."However, am unable to locate any additional audit documentation
> covering 2011-2015.".
> >>We've asked the auditor (CPA Shefler which is approved by Webtrust from
> ~mid 2015) to send us all the audits reports. As is already disclosed this
> ROOT has passed many Webtrust audits over the last years and can be
> considered audited –we have already disclosed all the certificates that
> were issued prior to our first Webtrust as you have asked earlier on this
> thread.
>
> 3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
> issue certificates. This version has not been supported since July 2013
> [4]. This implies that all 36 certificates were issued using unsupported CA
> software."
> >>Correct. Wrong decision of Comsign, which we apologized for. However, we
> still believe is should not affect the entire ROOT.
>
> 4."I’ve discovered that ComSign recently issued two new unconstrained
> subordinate Cas [5] from this root that contain a non-critical
> basicConstraints extension in violation of BR 7.1.2.2.
> >>While we appreciate your point here, these subCA's are not issuing SSL
> certificates at all but client certificates only. We cannot revoke these
> subordinates that serve hundreds of thousands of customers. However, if you
> approve our root – we commit to disclose the new SSL subCA before we issue
> new SSL certificates, while we keep the BR rules strictly of course.
>
> 5."Another unconstrained subordinate CA has been used to issue email
> certificates that contain encoding errors [6]."
> >>That subCA does not issue SSL certificates as we mentioned above, the
> encoding error was corrected long ago and is linked to the RSA software
> that we are replacing in any case.
>
> 6."In addition, numerous problems with ComSign’s CPS have been discussed
> in this thread".
> >>All these problems were corrected by us and approved by Mozilla
> representatives.
>
> 7."While I appreciate ComSign’s efforts to resolve issues that have been
> identified, new ones continue to be found. I am not at all comfortable
> recommending that this request proceed at this time, and I have also lost
> confidence that trust can ever be established for this root given its
> history. I support Ryan’s recommendation that this request be denied and
> that ComSign be asked to submit a new root containing a new key pair that
> has not been used with their outdated CA system."
> >>As we understand Ryan’s recommendation, after we accomplished almost all
> the points of rejection, is that Ryan recommends to wait for the new MS-CA,
> but Ryan did not express mistrust of the ROOT.
> We fully understand the points that both you and Ryan made, but to throw
> the root back now, will be like starting everything from the beginning all
> over again and will take long precious time.
> We suggest that we keep working on this root and fix all that still needs
> to be fixed.
> As for the CPS, we should be totally compliant now.
> As for the CA software we will enclose all the relevant details as soon as
> we finish our preparations and auditing.
>
> We ask you to reconsider this ROOT approval request.
>

Note: On 2016-02-04, I recommended that new trust not be granted and that
all trust in ComSign be removed -
https://groups.google.com/d/msg/mozilla.dev.security.policy/uTBDhqO_IB0/bGWV7_lwBAAJ

While the inclusion request has continued, the nature of the issues and the
question about the provenance have me fully supporting Wayne's
recommendations.

That is, if any new ComSign root is to be trusted, then ComSign MUST
address the infrastructural issues discovered, must transition to a CA
fully compliant (and note that CAs running on Microsoft's Certificate
Services platform have, historically, failed to comply with industry
changes in sufficient time, so switching to MS does seem a potentially
risky change), and only when new keys are generated and a new hierarchy,
unblemished by the many issues discovered, should we consider trusting it.

This is entirely consistent with the advice given regarding other CAs
applying for inclusion or renewal that have had substantial issues, and for
existing CAs that have demonstrated patterns of issues.

YairE

unread,
Feb 12, 2018, 3:23:55 PM2/12/18
to mozilla-dev-s...@lists.mozilla.org
Dear Ryan, with all due respect and we do respect you, back in 2016 all the issues you mentioned were about the CPS and were corrected.
It took us a lot to create the documentation you've asked for.
There was no mentioning of any kind about our CA software or anything about the root itself.
We believe that by solving all the problems that you've rose - we have shown integrity and that we are trustworthy and we expected to hear a minor good word about accomplishing the correction you've asked for including creating a complete new CPS, which have costed us a lot of time.
We initiated out of our own integrity the new CA environment (nobody forced us to do so), and created already the new CA environment and one of our considerations was to use a trusted company like MS and not a relatively small vendor of CA. We knew they have some functionality disadvantages in their software but we hope they will correct it.
As mentioned – we do agree that we need to switch our CA software ASAP and we are doing so and make progress every day. We did all the corrections you've asked for. If not – please point them out.
You now, after we did everything you've asked for, put dark shadow, over our trust and we do not see why. The only real point now is that we've used and still are using a software that must be replaced ASAP.
Bear in mind please that we cannot switch in one day because we need the approval of the government to every step we plan.
In conclusion, we don’t see any trust problems regarding Comsign itself and\or this particular root.
We still ask that this root will be approved on the new MS-CA when we switch to it, and we see no need to decline our request as long as we continue to comply with the BR and issue on a trusted CA software.

Ryan Sleevi

unread,
Feb 12, 2018, 3:47:04 PM2/12/18
to YairE, mozilla-dev-security-policy
I hope you can understand that trust is not just based on the state of the
world 'today', but based on everything that key has ever done and every bit
of infrastructure that key has run on.

We know that key has been run on deficient infrastructure, with deficient
software, and done deficient things. The continued public examination has
continued to find and discover new issues since 2016. While remedying these
issues is a crucial minimum step towards trust, it only gets you to a point
where the current infrastructure might be suitable to be trusted going
forward.

Ensuring the creation of a new root, with new keys, which has never
certified any of the deficient infrastructure, is the only way the public
has to ensure they are not introducing additional risk to their users.
> continue to comply with the BR and issue on a trusted CA software.

Wayne Thayer

unread,
Feb 12, 2018, 7:32:57 PM2/12/18
to YairE, mozilla-dev-security-policy
Hi Yair,
> 1."ComSign Global Root CA that was created in 2011 was first BR audited on
> 26-April 2015, but 36 end-entity certificates were issued prior to that
> time, all but one has since expired)."
> >>This one certificate expires at 3/2018 and we commit not to issue new
> SSL certificates until we are authorized with the new MS CA. However this
> point should not affect the integrity of the entire Root.
>
> 2."However, am unable to locate any additional audit documentation
> covering 2011-2015.".
> >>We've asked the auditor (CPA Shefler which is approved by Webtrust from
> ~mid 2015) to send us all the audits reports. As is already disclosed this
> ROOT has passed many Webtrust audits over the last years and can be
> considered audited –we have already disclosed all the certificates that
> were issued prior to our first Webtrust as you have asked earlier on this
> thread.
>
> 3."ComSign stated that they are currently using “RSA CA 6.7 on Solaris” to
> issue certificates. This version has not been supported since July 2013
> [4]. This implies that all 36 certificates were issued using unsupported CA
> software."
> >>Correct. Wrong decision of Comsign, which we apologized for. However, we
> still believe is should not affect the entire ROOT.
>
> 4."I’ve discovered that ComSign recently issued two new unconstrained
> subordinate Cas [5] from this root that contain a non-critical
> basicConstraints extension in violation of BR 7.1.2.2.
> >>While we appreciate your point here, these subCA's are not issuing SSL
> certificates at all but client certificates only. We cannot revoke these
> subordinates that serve hundreds of thousands of customers. However, if you
> approve our root – we commit to disclose the new SSL subCA before we issue
> new SSL certificates, while we keep the BR rules strictly of course.
>
> This comment demonstrates a continued lack of knowledge of Mozilla
requirements. Specifically, section 1.1 places these intermediates in-scope
because they are capable of issuing SSL certificates, so they must comply
with the BRs.

5."Another unconstrained subordinate CA has been used to issue email
> certificates that contain encoding errors [6]."
> >>That subCA does not issue SSL certificates as we mentioned above, the
> encoding error was corrected long ago and is linked to the RSA software
> that we are replacing in any case.
>
> 6."In addition, numerous problems with ComSign’s CPS have been discussed
> in this thread".
> >>All these problems were corrected by us and approved by Mozilla
> representatives.
>
> Yes, these problems were corrected after being identified by Mozilla, but
that is not trustworthy behavior. How many problems remain that we haven't
identified? A CA earns trust by understanding and complying with
requirements without supervision.


> 7."While I appreciate ComSign’s efforts to resolve issues that have been
> identified, new ones continue to be found. I am not at all comfortable
> recommending that this request proceed at this time, and I have also lost
> confidence that trust can ever be established for this root given its
> history. I support Ryan’s recommendation that this request be denied and
> that ComSign be asked to submit a new root containing a new key pair that
> has not been used with their outdated CA system."
> >>As we understand Ryan’s recommendation, after we accomplished almost all
> the points of rejection, is that Ryan recommends to wait for the new MS-CA,
> but Ryan did not express mistrust of the ROOT.
> We fully understand the points that both you and Ryan made, but to throw
> the root back now, will be like starting everything from the beginning all
> over again and will take long precious time.
>

Why is it not possible to generate a new root in the 6 months that are
needed to get the new CA software fully operational? This new CA can be
cross-signed by the Global Root CA for compatibility with other root stores.

I do think we can place this request on hold and resume it once all
information for the new root has been provided, rather than starting over
again at the beginning of the process. I welcome input from others in the
community who may disagree with me on this point.

We suggest that we keep working on this root and fix all that still needs
> to be fixed.
> As for the CPS, we should be totally compliant now.
> As for the CA software we will enclose all the relevant details as soon as
> we finish our preparations and auditing.
>
> We ask you to reconsider this ROOT approval request.
>

Please understand that this is not just about fixing the problems that have
been identified. You are asking Mozilla to accept the risk created by the
past decisions ComSign made. If this root is included, that risk will be
transferred to Mozilla's users for many years to come, until this root is
retired.

YairE

unread,
Feb 14, 2018, 10:27:28 AM2/14/18
to mozilla-dev-s...@lists.mozilla.org
Dear Ryan

We need to refer to the points you have raised regarding the ROOT KEY – we must stress that the ROOT KEY and the ROOT CA are two different and separate entities.
Whilst the ROOT CA does have some history the ROOT KEY was never (and shouldn’t be) in question.

“I hope you can understand that trust is not just based on the state of the
world 'today', but based on everything that key has ever done and every bit of infrastructure that key has run on.”
>>>> You are now moving to discuss the root key. We have started a year ago speaking of the CPS, than on the certificate, and now the ROOT KEY itself.
Allow me to declare that the ROOT KEY is intact. It is kept on an FIPS140-2 Level 3 HSM from its creation and always in an offline state as should be.
You cannot put the key itself in any question.

“We know that key has been run on deficient infrastructure, with deficient software, and done deficient things.”
>>> deficient infrastructure? The HSM is the ONLY infrastructure of the ROOT KEY. The CA has nothing to do with the key itself. The KEY was NOT running on deficient infrastructure and\or software!

“The continued public examination has continued to find and discover new issues since 2016.
While remedying these issues is a crucial minimum step towards trust, it only gets you to a point where the current infrastructure might be suitable to be trusted going forward.
Ensuring the creation of a new root, with new keys, which has never certified any of the deficient infrastructure, is the only way the public
has to ensure they are not introducing additional risk to their users. “
>>>We strongly disagree with that statement that a new KEY should be generated – there’s never was any problem with the KEY therefore generating a new one would not affect the integrity of the root as a whole.
We think the discussion should remain on the ROOT CA which had its problems as discussed, and leave the KEY out of the discussion.
However, in order to come clean and regain your trust we would agree to start a brand new root with a new key pair running on the new CA software (and BR compliant of course) but before we do so, we would like to know for certain that this process will be satisfactory and accepted by you.

YairE

unread,
Feb 14, 2018, 10:29:15 AM2/14/18
to mozilla-dev-s...@lists.mozilla.org
Dear Wayne

We do understand the issues raised and instead of addressing each one separately we would give a shorter answer:
We do agree that mistakes were made with this rootCA and we understand your hesitation.
We also believe that our current CPS state is well and that we made a lot of progress and we are in a good position today with the CPS which is according to the BR.
We take your recommendation and we consider generating a brand new root with a new key pair that will run only on the new CA software – whilst providing all the audits and needed information as requested.
We need to know for certain before we initiate such a process that doing so would be accepted by you and Ryan, and that we could continue from this point, rather than starting over again at the beginning of the process.

Ryan Sleevi

unread,
Feb 14, 2018, 11:42:04 AM2/14/18
to YairE, mozilla-dev-security-policy
On Wed, Feb 14, 2018 at 10:27 AM, YairE via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Dear Ryan
>
> We need to refer to the points you have raised regarding the ROOT KEY – we
> must stress that the ROOT KEY and the ROOT CA are two different and
> separate entities.
> Whilst the ROOT CA does have some history the ROOT KEY was never (and
> shouldn’t be) in question.
>

I do not believe there is sufficient public evidence to make this
conclusion.


>
> “I hope you can understand that trust is not just based on the state of the
> world 'today', but based on everything that key has ever done and every
> bit of infrastructure that key has run on.”
> >>>> You are now moving to discuss the root key. We have started a year
> ago speaking of the CPS, than on the certificate, and now the ROOT KEY
> itself.
> Allow me to declare that the ROOT KEY is intact. It is kept on an
> FIPS140-2 Level 3 HSM from its creation and always in an offline state as
> should be.
> You cannot put the key itself in any question.
>

You have, by virtue of the failures demonstrated.


> “We know that key has been run on deficient infrastructure, with deficient
> software, and done deficient things.”
> >>> deficient infrastructure? The HSM is the ONLY infrastructure of the
> ROOT KEY. The CA has nothing to do with the key itself. The KEY was NOT
> running on deficient infrastructure and\or software!
>
> “The continued public examination has continued to find and discover new
> issues since 2016.
> While remedying these issues is a crucial minimum step towards trust, it
> only gets you to a point where the current infrastructure might be suitable
> to be trusted going forward.
> Ensuring the creation of a new root, with new keys, which has never
> certified any of the deficient infrastructure, is the only way the public
> has to ensure they are not introducing additional risk to their users. “
> >>>We strongly disagree with that statement that a new KEY should be
> generated – there’s never was any problem with the KEY therefore generating
> a new one would not affect the integrity of the root as a whole.
> We think the discussion should remain on the ROOT CA which had its
> problems as discussed, and leave the KEY out of the discussion.
> However, in order to come clean and regain your trust we would agree to
> start a brand new root with a new key pair running on the new CA software
> (and BR compliant of course) but before we do so, we would like to know for
> certain that this process will be satisfactory and accepted by you.


Public trust is based on the combination of the key and the name, not the
certificate itself. The semantic quibbles aside, there should be no
question that requiring a new "root certificate" is unquestionably the same
as requiring a new subject name, with new key, to be generated.

So regardless of your position about the existing key, I hope it's clear
that a new key and new certificate should be generated.

Ryan Sleevi

unread,
Feb 14, 2018, 11:46:11 AM2/14/18
to YairE, mozilla-dev-security-policy
On Wed, Feb 14, 2018 at 10:29 AM, YairE via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> We take your recommendation and we consider generating a brand new root
> with a new key pair that will run only on the new CA software – whilst
> providing all the audits and needed information as requested.
> We need to know for certain before we initiate such a process that doing
> so would be accepted by you and Ryan, and that we could continue from this
> point, rather than starting over again at the beginning of the process.


The Mozilla process does not guarantee trust as a pre-condition to taking
actions. Merely, in rejecting an application, it can give the reasons why
that application is rejected. Future submissions should therefore be
mindful to avoid repeating the same mistakes. That does not prevent new
mistakes from being made, thus new submissions should be mindful of the
Baseline Requirement, the Mozilla CA Policy, and the set of community
expectations and considerations that will be taken into account when
evaluating whether or not to trust any new certificates.

I do not believe it wise to accept this inclusion request, thus any new
inclusion request should avoid these issues as part of the design and
consideration - which would include ensuring that the infrastructure fully
complies with the Baseline Requirements and equivalent system controls. You
can always engage with an auditor or consultant to help design your system
in a way to ensure compliance, both prior to generating your keys and
certificate, and to ensure its continued compliance and responsiveness to
industry and policy changes over time.

zshe...@gmail.com

unread,
Feb 14, 2018, 1:55:33 PM2/14/18
to mozilla-dev-s...@lists.mozilla.org
Dear Ryan
You accuse our root status by saying:"We know that key has been run on deficient infrastructure, with deficient software, and done deficient things..."
As a matter of a fact the ROOT resides on a FIPS140-2 L3 HSM and kept all it life time in an offline status (in a robust SAFE) and was participated in 3 key ceremonies.
So why do you say that the infrastructure is deficient?
You can question the certificate issued to this key - but why do you question the key itself?
This is a very severe accusation.
the "deficient things" is creating 2 subca's that wasn't comply with ONE condition of the BR (critical/ not critical of a certain field, which may declared AFTER we created these SUB's). So the Comsign ROOT KEY IS INTACT even if is signed subca keys which its certificates are not 100% according to BR.
Can you agree?

YairE

unread,
Feb 19, 2018, 6:09:55 AM2/19/18
to mozilla-dev-s...@lists.mozilla.org
Dear Wayne,
What is the decision on our matter?
Can we start the new Root process (new Certificate with new KeyPair and the new CA software) and proceed the inclusion from this point later?
Our next steps will be to create all the above and disclose all the needed audits as required by Mozilla and the BR.

Looking forward to your reply.

Wayne Thayer

unread,
Feb 20, 2018, 12:30:25 PM2/20/18
to YairE, mozilla-dev-security-policy
Based on this discussion, Mozilla is denying the ComSign Global Root CA
inclusion request. I'd like to thank everyone for your constructive input
into the discussion, and I'd like to thank ComSign for their patience and
work to address issues as they have been discovered.

ComSign may submit a newly generated root and key-pair for inclusion, and
this submission can be made using the existing bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=675060)

For now, I am moving this request to an on-hold status. Mozilla will
require updated documentation, and that documentation will need to be
verified. This request will effectively need to go through the entire
process again, but may do so more quickly if ComSign's new submission
addresses all the issues that have already been identified.

- Wayne
0 new messages