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 new
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 a
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
On Wed, Feb 14, 2018 at 10:29 AM, YairE via dev-security-policy <
dev-security-policy@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
On Wed, Feb 14, 2018 at 10:27 AM, YairE via dev-security-policy <
dev-security-policy@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.
> Wh
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
progr
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 understan
Hi Yair,
On Mon, Feb 12, 2018 at 11:50 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
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 thing
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 be
On Mon, Feb 12, 2018 at 1:50 PM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> 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
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).
On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy <
dev-security-policy@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
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
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
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 r
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
On Mon, Feb 5, 2018 at 4:23 PM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi, thank you for pointing the above
> Here
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 thoug
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
On Mon, Jan 29, 2018 at 8:43 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
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
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 whethe
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 p
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..
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
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
ug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> > Wayne Thayer via dev-security-policy
> > Sent: Tuesday, December 5, 2017 1:44 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: ComSign Root Renewal Request
> >
> > > We ca
olicy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Wayne Thayer via dev-security-policy
> Sent: Tuesday, December 5, 2017 1:44 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: ComSign Root Renewal Request
>
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, ther
On Sun, Dec 10, 2017 at 9:15 AM, YairE via dev-security-policy <
dev-security-policy@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.
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
section 1 states that we are addressing the latest BR
3.2.2.4 was corrected
i'm also attaching the new CPS'es so you can review them
About the "
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
> 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
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 corre
On Friday, April 8, 2016 at 12:58:41 AM UTC+3, Kathleen Wilson wrote:
> 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
On Friday, April 8, 2016 at 12:58:41 AM UTC+3, Kathleen Wilson wrote:
> 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
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
On Wed, Apr 6, 2016 at 10:58 AM, Kathleen Wilson 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 mee
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 includ
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.
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
On Wednesday, March 30, 2016 at 4:36:44 AM UTC+3, Andrew Whalley wrote:
> 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
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 Criteri
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
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 t
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 t
On Thursday, February 4, 2016 at 10:57:54 PM UTC+2, Ryan Sleevi wrote:
> 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
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
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
On Monday, February 1, 2016 at 1:17:10 PM UTC+2, Erwann Abalea wrote:
> 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
> > w
On Saturday, January 30, 2016 at 3:03:21 AM UTC+2, David Keeler wrote:
> On 12/10/2015 12:01 PM, Kathleen Wilson wrote:
> ...
> > * Test Website: https://fedir.comsign.co.il/test.html
>
> The certificate presented by the test website specifies "ISRAEL" in the
> Country field of the Subject DN, whe
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 incl
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 pa
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 ownershi
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 wrote:
> * There is a BR from CABF that covers code signing. I must admit
On 12/10/2015 12:01 PM, Kathleen Wilson wrote:
...
> * Test Website: https://fedir.comsign.co.il/test.html
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 mechani
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 "electroni
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 t
On 12/10/15 12:01 PM, Kathleen Wilson wrote:
This request is to include the "ComSign Global Root CA" root
certificate, and enable the Websites and Email trust bits. This root
will eventually replace the "ComSign CA" root certificate that is
currently included in NSS, and was approved in bug #4207
On 12/14/15 1:17 PM, Charles Reiss wrote:
On 12/14/15 19:56, Eli Spitzer wrote:
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
On 12/14/15 19:56, Eli Spitzer wrote:
> 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 onl
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 certificat
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 mome
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 acti
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
64 matches
Mail list logo