Re: ComSign Root Renewal Request

[Wayne Thayer via 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

On Mon, Feb 19, 2018 at 4:09 AM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[zshetach--- via dev-security-policy]

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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Ryan Sleevi via dev-security-policy]

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 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Ryan Sleevi via dev-security-policy]

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.
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

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 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.
>
> 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 

Re: ComSign Root Renewal Request

[Ryan Sleevi via 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.

On Mon, Feb 12, 2018 at 3:23 PM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Ryan Sleevi via dev-security-policy]

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 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 

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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 

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

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
> 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=1631=2017-01-01
[6] https://crt.sh/?caid=14449=x509lint=2014-01-01
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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."

> 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 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.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Julien Cristau via dev-security-policy]

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 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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via 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

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 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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
> 
> 
> 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:
> supp...@comsign.co.il and customer_servi...@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 


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via 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
>


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:
supp...@comsign.co.il and customer_servi...@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=a051J3mogw7=
Q00042,Q00048

On Tue, Jan 16, 2018 at 2:05 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

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:
> 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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

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.beat...@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=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 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.

RE: ComSign Root Renewal Request

[Doug Beattie via dev-security-policy]

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=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 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
> homograp

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

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.

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

>
> Link to all the attachments:
>
> https://drive.google.com/open?id=1VzrWqouZeda5bQkyhdboO_KvfBo9QV17
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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 "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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[YairE via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Aaron Wu via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

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 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

I've added our latest WebTrust CA Audit report to the Root Inclusion Bug:
"https://bugzilla.mozilla.org/show_bug.cgi?id=675060;
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

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,

Eli Spitzer, Information security & System Management, Comsign

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Andrew R. Whalley]

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  wrote:

> 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 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
>
> 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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

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 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

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Andrew Whalley]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Jakob Bohm]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

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 

Re: ComSign Root Renewal Request

[Eli Spitzer]

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 

Re: ComSign Root Renewal Request

[Eli Spitzer]

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 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 

Re: ComSign Root Renewal Request

[Jesus F]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Peter Bowen]

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 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Peter Kurrasch]

  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 WilsonSent: Wednesday, January 20, 2016 5:46 PM‎On 12/10/15 12:01 PM, Kathleen Wilson wrote:> This request is to include the "ComSign Global Root CA" root> certificate, and enable the Websites and Email trust bits. This root> will eventually replace the "ComSign CA" root certificate that is> currently included in NSS, and was approved in bug #420705.>> ComSign is owned by Comda, Ltd., and was appointed by the Justice> Ministry as a CA in Israel in 

Re: ComSign Root Renewal Request

[Kathleen Wilson]

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

This request is to include the "ComSign Global Root CA" root
certificate, and enable the Websites and Email trust bits. This root
will eventually replace the "ComSign CA" root certificate that is
currently included in NSS, and was approved in bug #420705.

ComSign is owned by Comda, Ltd., and was appointed by the Justice
Ministry as a CA in Israel in accordance with the Electronic Signature
Law 5761-2001. ComSign has issued electronic signatures to thousands of
business people in Israel.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=675060

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8697333

Noteworthy points:

* The primary documents are the CP and CPS, provided in Hebrew and
English. Only the Hebrew version of the CPS was approved by the Israeli
CA Registrar. The English version of the CPS adds procedures dealing
with SSL certificates, which are not regulated under Israel's Elctronic
Signature Law.

Document Repository: https://www.comsign.co.il/
Document Repository (English): https://www.comsign.co.uk/?page_id=1282
CPS:
http://www.comsign.co.uk/wp-content/uploads/Comsign%20CPS-EN-v%20311.pdf

* CA Hierarchy: This root has internally-operated subordinate CAs:
ComSign ISA Global CA, ComSign Corporation CA, ComSign Professionals CA,
and ComSign Organizational CA.
CA Hierarchy Diagram:
https://bugzilla.mozilla.org/attachment.cgi?id=8608692

* This request is to enable the Websites and Email trust bits. ComSign
is not requesting EV treatment at this time.

** Note: The English version of the CPS adds procedures dealing with SSL
certificates, which are not regulated under Israel's Electronic
Signature Law. So, the SSL verification procedures are only part of the
English version of the CPS.

** CPS section 3.2.7.1: As part of the identification process, a unique
secret code (the "Secret Code" will be mailed by Comsign to the
Applicant's e-mail address. The Secret Code will be mailed during the
coordination stage preceding the Applicant's personal appearance for the
identification process. The Applicant will provide the Secret Code to
the coordination clerk during the telephone conversation coordinating
the Applicant's personal appearance. If the provided Secret Code is
correct, the coordination clerk will transfer it to the identification
clerk together with all other data pertaining to the applicant
(including the applicant's e-mail address).

** CPS section 3.2.7.2: In the event of a non-coordinated visit to
Comsign offices (as well as in any other event) the identification clerk
will mail the Secret Code during the identification process (Comsign
will provide the Applicant with internet access).

** CPS section 3.2.7.3. The Applicant must provide the Secret Code in
the application form. The identification clerk will verify the matching
of the Secret Code in the application form with the one reported by the
coordination clerk (or by the applicant himself in a non-coordinated
visit to Comsign offices) as well as the matching of the e-mail address
in the application form with the address reported by the coordination
clerk. Alternatively, the identification clerk will verify the matching
of the Secret Code in the application form to the one mailed by the
identification clerk to the e-mail address provided by the Applicant in
the application form.

** CPS section 3.2.7.4: Only the e-mail address to which the verified
Secret Code was mailed will appear in the electronic certificate issued
by Comsign to the Applicant.

** CPS section 3.2.8.1: For issuing certificates to organizations
requesting SSL certificates, Comsign performs domain name owner
verification to detect cases of homographic spoofing of IDNs. Comsign
employs an automated or manual process that searches various ‘whois’
services to find the owner of a particular domain. A search failure
result is flagged and the RA rejects the Certificate Request.
Additionally, the RA rejects any domain name that visually appears to be
made up of multiple scripts within one hostname label.
Note: Orders for major corporations, well known trademarks and financial
institutions may be queued for further security reviews prior to issuance.
In the event an order is queued for review the administrative contact
must be a full time employee of the company for successful issuance. A
verification telephone call with the administrative contact may be
required.
- Verification methods include one of the following:
*** 3.2.8.1.1 EMail-based DCV
An email is sent to an administrative contact for the required domain.
The email will contain a unique validation code and link. Clicking the
link and entering the code will prove domain control.
Valid email addresses are: Any email address listed in the "whois"
records. The following generic admin type email addresses AT 

Re: ComSign Root Renewal Request

[Kathleen Wilson]

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 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.


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".




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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

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.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Charles Reiss]

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?

> 
> 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
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

ComSign Root Renewal Request

[Kathleen Wilson]

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 

Re: ComSign Root Renewal Request

[Charles Reiss]

On 12/10/15 20:01, Kathleen Wilson wrote:
> This request is to include the "ComSign Global Root CA" root certificate, and
> enable the Websites and Email trust bits. This root will eventually replace 
> the
> "ComSign CA" root certificate that is currently included in NSS, and was
> approved in bug #420705.
> 
> ComSign is owned by Comda, Ltd., and was appointed by the Justice Ministry as 
> a
> CA in Israel in accordance with the Electronic Signature Law 5761-2001. 
> ComSign
> has issued electronic signatures to thousands of business people in Israel.
[snip]

> * CA Hierarchy: This root has internally-operated subordinate CAs: ComSign ISA
> Global CA, ComSign Corporation CA, ComSign Professionals CA, and ComSign
> Organizational CA.
> CA Hierarchy Diagram: https://bugzilla.mozilla.org/attachment.cgi?id=8608692

Via Censys.io, I noticed a subCA with CN "Comsign EV SSL CA" whose subCA cert is
reproduced below.

-BEGIN CERTIFICATE-
MIIG1zCCBL+gAwIBAgIQcybbitmPn4IXQtwZX2fD8DANBgkqhkiG9w0BAQsFADBF
MR8wHQYDVQQDExZDb21TaWduIEdsb2JhbCBSb290IENBMRUwEwYDVQQKEwxDb21T
aWduIEx0ZC4xCzAJBgNVBAYTAklMMB4XDTE1MDkyNDExMTgyM1oXDTI1MTAyMjE5
MDAwMFowUzELMAkGA1UEBhMCSUwxETAPBgNVBAcTCFRlbCBBdml2MRUwEwYDVQQK
EwxDb21zaWduIEx0ZC4xGjAYBgNVBAMTEUNvbXNpZ24gRVYgU1NMIENBMIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA9802wpU9bUwRopTfxwDsjugmljHX
MVMt4stqAZuCZO2EbHAvFVdT9vGnzQ2AxbHEpTPTlJZdBpYsUKZPZW56MEs17a9R
SYIDJWRs2GrmQIFoSxqIkjkHCpfzzAA6UM4PvqTYuCkvmaUEV3GtK3RvVfSqYlCQ
Kszcj+BLq5q9lvfQh4ygN8Cgj+O7s8svh+D08ho7LHyf23Ng+lrYea+zlJosn+9C
f97DpkK+Ceg1wgjmFPWE6vKil1euayyf69NLlufkbd99Dej0JUX0hPkewNEbPXc9
wANWQBC/HAu/QR4cLmMIU+MbSFPVBZmUIyZKQnEe4AVcnpk4rL7HV7xOb/Q1JGOE
wkyoXWMHh+qaxzmYxA27360LTvQ+ik6cOruCZhFIT/3G9bF9vx0D0wn7MTJuiaoI
MMjT8ayBGsqB3U31omLHo2AXLwpBC1thj4aYSMFio/vIRfglslny/cQM6RXt1Xk6
qC/b1JUK1boUnjFgxjClG/dmSdjJrK0T/zr11oKaxEkdZ2FjHXwBgsF2/MVGCqvK
Kv6hAgmptEl4kvrgk+O5RGDfceNE28OpJJ89Ew/UnAHhaRqVzo1yT6MHD2Pw5Rnx
sau7cVblH7iGu+GXOLBH6QjjrQs5Ul9jXQQ0waFQOE2B0i2lZicP9t05bh+445dH
EUU8BojywPEbNn8CAwEAAaOCAbMwggGvMIGCBggrBgEFBQcBAQR2MHQwKwYIKwYB
BQUHMAGGH2h0dHA6Ly9vY3NwMS5jb21zaWduLmNvLmlsL29jc3AwRQYIKwYBBQUH
MAKGOWh0dHA6Ly9mZWRpci5jb21zaWduLmNvLmlsL2NhY2VydC9Db21TaWduR2xv
YmFsUm9vdENBLmNydDAfBgNVHSMEGDAWgBQCRZPYDUhirGm6rgZbPvuqJpFQsTAS
BgNVHRMBAf8ECDAGAQH/AgEAMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUF
BwIBFhxodHRwOi8vd3d3LmNvbXNpZ24uY28uaWwvQ1BTMIGEBgNVHR8EfTB7MDyg
OqA4hjZodHRwOi8vZmVkaXIuY29tc2lnbi5jby5pbC9jcmwvQ29tU2lnbkdsb2Jh
bFJvb3RDQS5jcmwwO6A5oDeGNWh0dHA6Ly9jcmwxLmNvbXNpZ24uY28uaWwvY3Js
L0NvbVNpZ25HbG9iYWxSb290Q0EuY3JsMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E
FgQU7fGGKZqDjBRnn7pjoL3PRHlkAdIwDQYJKoZIhvcNAQELBQADggIBAHxBbq2k
jzKZVcI6kL++GGAfojlBv/x2ci6q0c7LOois6Mu+QiD3QhplSuZtAY5GZ7rLdN28
3cI4ufh+roNGmZDuh6E4ZMQG1Kd+DbfpCsEKo8tq5nmXCjdp2f4+eK2LAuXb0Z38
fsodqjnsGfMJuVg1F4ofRzX/WnfY2vgVV5Fo7ng5hwdVzIsywxgTd4JBCrfZJsRE
Ci+mxfIu5kEZiSftciaoFjqWkI+HUYE3H+Fsmq0K59sMg5oYZpwo/LFBKfRIBunC
IBKNCODFTVIwXjtrY3xkAYPac6XmTDTNqwu7sLscZ9K4psBJokhe4HVFrVarXpXi
khFSTlkD4ZTgJSnikmmgBzlPieMUqeGfu7vWymVIhU+2bbS/orDrX8Sm5QIMw3xz
WMuPmGwB3FVzBc9TdqjNdw1+iHgCIEpvuBiLIMsIAkRQzaxifYcrTv6zFx5xRKuQ
MWKLgyGeTG+WZscOtP7eWxwvzhGMmAAahUqSgCvp01lk5rtOzYF4kYM4fvQRnkJB
MmgZ0gEbUtjxPI8JiOc9sI6I73M8IC7LqrqI3NXQoVyri0smRD5elgIHfksBrOS1
Yl6zC5ekM0GDkatfX7l29OteGtVHVaUj4Ti+esT/D8CuBL9bHqIMjrJePzuE29+Z
GgiV55sP/5iWAHIhoqvHBmswvEEHBozrAh6I
-END CERTIFICATE-


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy