Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Ramiro Muñoz via dev-security-policy 
El martes, 19 de enero de 2021 a las 14:32:19 UTC+1, paul.leo@gmail.com 
escribió:
> On Tuesday, January 19, 2021 at 11:01:15 AM UTC+1, Ramiro Muñoz wrote: 
> 
> > Finally, I’d like to ask you, based on which article of Mozilla Root Store 
> > Policy, you are sentencing a removal from the Mozilla store.
> Oh, I know this one: It is in the Mozilla Root Store Policy, 7.3: "Mozilla 
> MAY, at its sole discretion, decide to disable (partially or fully) or remove 
> a certificate at any time and for any reason." (You might really want to 
> start to read the Mozilla Root Store Policy and BR before posting here or in 
> incident reports.) 
> 
> But please note that Matt is not sentencing anyone but merely providing 
> arguments for the module peers/owner, who, by Mozilla's decision-making 
> process, will call the shots in the end (by their sole discretion possibly 
> based or not based on arguments in this thread). 
> 
> Also, your whataboutisms might not serve you well. If you think that other 
> CAs have handled incidents inadequately, your questions in the respective 
> incident report bugs would surely have been much appreciated. 
> 
> On the subject, since the start of this thread, things have actually got 
> worse. Camerfirma evidently got under pressure, which, for a functioning CA, 
> would result in better incident handling and an opportunity to show their 
> solid foundation as a CA. Instead, Camerfirma, besides engaging in absurd 
> argumentation in this thread, has started to request bugs clearly not fully 
> remediated be closed 
> (, 
> ). Recently, we 
> have also learned that Camerfirma does not even have an understanding (or 
> process) about the BR's revocation timelines 
> (). 
> 
> There cannot be such a thing as a "last chance" ("Let's see how things work 
> out"/"Camerfirma gets removed with the next incident") as this would put even 
> more pressure on Camerfirma. It would also come with a massive incentive for 
> Camerfirma to not report any more incidents. For Mozilla and their users, 
> this would come with the risk of unreported incidents but also the need for 
> an emergency release of Firefox and other relying software in case Camerfirma 
> has to be removed in an unorderly way. Thus, orderly (pre-announced) distrust 
> in one of the next Firefox release is the only way forward.

Paul,
Thanks for your contribution.

Yes, we know art. 7.3 of the Mozilla Root Store Policy and we are aware that 
Mozilla may remove a certificate at any time and for any reason. 
Of course in the event such decision be taken, we would respect it but, for 
sake of a proper governance of our community the reasons for such a traumatic 
decision should be clearly communicate to all community members. And the reason 
should be as objective as possible, bearing in  mind – again - that Camerfirma 
is not the member with the highest number of incidents nor the member with the 
most severe ones. 

>Camerfirma, besides engaging in absurd argumentation in this thread, has 
>started to request bugs clearly not fully remediated be closed 
>(, 
>).
 
Paul it was a mistake when we try to close all those open bugs when the answers 
from our side ware already sent. This wasn't  the case in this bug, in fact we 
keep on adding new information to it.   

> Recently, we have also learned that Camerfirma does not even have an 
> understanding (or process) about the BR's revocation timelines 
> ().

We have already published an answers in this bug and expaling the timeling 
considered.



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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread paul.leo....--- via dev-security-policy 
On Tuesday, January 19, 2021 at 11:01:15 AM UTC+1, Ramiro Muñoz wrote:

> Finally, I’d like to ask you, based on which article of Mozilla Root Store 
> Policy, you are sentencing a removal from the Mozilla store. 

Oh, I know this one: It is in the Mozilla Root Store Policy, 7.3: "Mozilla MAY, 
at its sole discretion, decide to disable (partially or fully) or remove a 
certificate at any time and for any reason." (You might really want to start to 
read the Mozilla Root Store Policy and BR before posting here or in incident 
reports.)

But please note that Matt is not sentencing anyone but merely providing 
arguments for the module peers/owner, who, by Mozilla's decision-making 
process, will call the shots in the end (by their sole discretion possibly 
based or not based on arguments in this thread).

Also, your whataboutisms might not serve you well. If you think that other CAs 
have handled incidents inadequately, your questions in the respective incident 
report bugs would surely have been much appreciated.

On the subject, since the start of this thread, things have actually got worse. 
Camerfirma evidently got under pressure, which, for a functioning CA, would 
result in better incident handling and an opportunity to show their solid 
foundation as a CA. Instead, Camerfirma, besides engaging in absurd 
argumentation in this thread, has started to request bugs clearly not fully 
remediated be closed 
(, 
). Recently, we have 
also learned that Camerfirma does not even have an understanding (or process) 
about the BR's revocation timelines 
().

There cannot be such a thing as a "last chance" ("Let's see how things work 
out"/"Camerfirma gets removed with the next incident") as this would put even 
more pressure on Camerfirma. It would also come with a massive incentive for 
Camerfirma to not report any more incidents. For Mozilla and their users, this 
would come with the risk of unreported incidents but also the need for an 
emergency release of Firefox and other relying software in case Camerfirma has 
to be removed in an unorderly way. Thus, orderly (pre-announced) distrust in 
one of the next Firefox release is the only way forward.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Kurt Roeckx via dev-security-policy 

On 2021-01-19 11:02, Ramiro Muñoz wrote:

El martes, 19 de enero de 2021 a las 0:49:42 UTC+1, Matt Palmer escribió:

On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via dev-security-policy 
wrote:

We don’t ask the community to disregard the data, on the contrary we ask
the community to analyze the data thoroughly including the impacts
produced.

OK, I'll bite. As a member of the community, I've analyzed the data
thoroughly, and I'm not impressed. Camerfirma does not appear to grasp the
fact that "nothing bad has happened yet" is a *bad take*. "Nothing bad has
happened yet" is how every CA starts its life. It is not something to be
proud of, it's the absolute bare minimum. The volume of incidents that
Camerfirma has had is troubling, but it's the repetition of the nature of
the incidents, and the lacklustre way in which they have been responded to,
that causes me to think that Camerfirma has no place in the Mozilla trust
store.

- Matt


Dear Matt,

Thanks for your input, we really appreciate your time in contributing to this 
discussion.

We are trying to make this discussion as objective as possible, and talking 
about objectivity I’d like to ask you where does the ‘bare minimum’ threshold 
stands according  to Mozilla Root Store Policy. And why you are positioning 
Camerfirma below such a ‘bare minimum’ bar considering that Camerfirma, 
according to the public data, is not the member with the highest number of 
incidents nor the member with the most severe ones.


I think you misunderstand Matt's mail.

If "something bad has happened" was the case, this would be a much 
different discussion. As far as we know, you're still meeting the bare 
minimum. But the bare minimum is not good enough.



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

Re: Audit Reminder Email Summary

2021-01-19 Thread Kathleen Wilson via dev-security-policy 

 Forwarded Message 
Subject: Summary of January 2021 Audit Reminder Emails
Date: Tue, 19 Jan 2021 20:00:30 + (GMT)

Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238854

Standard Audit Period End Date: 2019-12-18
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238855

BR Audit Period End Date: 2019-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 3
Standard Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238797

Standard Audit Period End Date: 2019-12-31
BR Audit: 
https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=238798

BR Audit Period End Date: 2019-12-31
EV Audit: https://www.ecert.gov.hk/ev/Webtrust_EVSSL_2019.pdf
EV Audit Period End Date: 2019-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA**
   Buypass Class 3 Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

Standard Audit Period End Date: 2019-10-31
BR Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

BR Audit Period End Date: 2019-10-31
EV Audit: 
https://www.buypass.com/the-company/certification/_/attachment/download/413dca90-da68-483e-80e4-3978e33a8e98:76247c1b8cacd26f80531a2929c2a739db2b5159/ETS%20018.pdf

EV Audit Period End Date: 2019-10-31
CA Comments: null



Mozilla: Overdue Audit Statements
CA Owner: Dhimyotis / Certigna
Root Certificates:
   Certigna Root CA**
   Certigna**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://lsti-certification.fr/images/23_1377_AT_V10__LSTI_-_Attestation_letter_2020.pdf

Standard Audit Period End Date: 2019-10-18
BR Audit: 
https://lsti-certification.fr/images/23_1377_AT_V10__LSTI_-_Attestation_letter_2020.pdf

BR Audit Period End Date: 2019-10-18
CA Comments: null




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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Andrew Ayer via dev-security-policy 
On Sun, 17 Jan 2021 00:51:29 -0800 (PST)
Ramiro Mu__oz via dev-security-policy
 wrote:

> Some certificates may have been syntactically
> incorrect due to misinterpretation, but we have never compromised any
> vetting, identification or information validation.

This is false, as shown by incidents like
https://bugzilla.mozilla.org/show_bug.cgi?id=1672423
(issuing for a non-existent domain) and
https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 (not checking CAA),
not to mention the validation failures by sub-CAs for which Camerfirma
is ultimately responsible.  And even misissuances that are just
"syntactically incorrect" are concerning because they show a disregard
for the policies that exist to prevent harm to innocent parties.

It's troubling that even at this stage, Camerfirma still doesn't seem
to grasp the seriousness of their compliance problems. Today,
they are arguing that there was no security threat from a certificate
issued for a domain without authorization because the subdomain
in the certificate "does not exist": 
https://bugzilla.mozilla.org/show_bug.cgi?id=1672409#c8

Camerfirma was warned in 2018 that trust in their CA was in jeopardy,
yet compliance problems continued.  There is no reason to believe
Camerfirma will improve, and there are many indications that they won't.
Mozilla's users deserve CAs that take security more seriously than this.
It's time to take action to protect Mozilla's users by distrusting
Camerfirma.

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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Paul Kehrer via dev-security-policy 
On Tue, Jan 19, 2021 at 6:37 PM Jonathan Rudenberg via
dev-security-policy  wrote:
>
> On Tue, Jan 19, 2021, at 12:01, Andrew Ayer via dev-security-policy wrote:
> > Camerfirma was warned in 2018 that trust in their CA was in jeopardy,
> > yet compliance problems continued.  There is no reason to believe
> > Camerfirma will improve, and there are many indications that they won't.
> > Mozilla's users deserve CAs that take security more seriously than this.
> > It's time to take action to protect Mozilla's users by distrusting
> > Camerfirma.
>
> I strongly agree. The consistent pattern of documented failures and 
> insufficient remediation is deeply problematic, and reflects a level of 
> danger to Mozilla users that can only be mitigated by distrusting the CA.
>
> Jonathan

I also agree with this sentiment. Camerafirma's extensively documented
issues (https://wiki.mozilla.org/CA:Camerfirma_Issues) and the
responses in this thread reveal a CA which cannot responsibly handle
the burden of being a publicly trusted authority.

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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Jonathan Rudenberg via dev-security-policy 
On Tue, Jan 19, 2021, at 12:01, Andrew Ayer via dev-security-policy wrote:
> Camerfirma was warned in 2018 that trust in their CA was in jeopardy,
> yet compliance problems continued.  There is no reason to believe
> Camerfirma will improve, and there are many indications that they won't.
> Mozilla's users deserve CAs that take security more seriously than this.
> It's time to take action to protect Mozilla's users by distrusting
> Camerfirma.

I strongly agree. The consistent pattern of documented failures and 
insufficient remediation is deeply problematic, and reflects a level of danger 
to Mozilla users that can only be mitigated by distrusting the CA.

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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Matt Palmer via dev-security-policy 
On Tue, Jan 19, 2021 at 07:28:17AM -0800, Ramiro Muñoz via dev-security-policy 
wrote:
> Camerfirma is not the member with the highest number of
> incidents nor the member with the most severe ones.

No, but Camerfirma's got a pretty shocking history of poor incident
response, over an extended period, with no substantive evidence of
improvement.  *That* makes me not want to trust Camerfirma, because I have
no confidence that problems are being handled in a manner befitting a
globally-trusted CA.  Further, Camerfirma's continued insistence that "it's
all better now", in the face of all the contrary evidence, does not inspire
confidence that there will be future improvement.

- Matt

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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Ramiro Muñoz via dev-security-policy 
El martes, 19 de enero de 2021 a las 0:49:42 UTC+1, Matt Palmer escribió:
> On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via 
> dev-security-policy wrote: 
> > We don’t ask the community to disregard the data, on the contrary we ask 
> > the community to analyze the data thoroughly including the impacts 
> > produced.
> OK, I'll bite. As a member of the community, I've analyzed the data 
> thoroughly, and I'm not impressed. Camerfirma does not appear to grasp the 
> fact that "nothing bad has happened yet" is a *bad take*. "Nothing bad has 
> happened yet" is how every CA starts its life. It is not something to be 
> proud of, it's the absolute bare minimum. The volume of incidents that 
> Camerfirma has had is troubling, but it's the repetition of the nature of 
> the incidents, and the lacklustre way in which they have been responded to, 
> that causes me to think that Camerfirma has no place in the Mozilla trust 
> store. 
> 
> - Matt

Dear Matt,

Thanks for your input, we really appreciate your time in contributing to this 
discussion.

We are trying to make this discussion as objective as possible, and talking 
about objectivity I’d like to ask you where does the ‘bare minimum’ threshold 
stands according  to Mozilla Root Store Policy. And why you are positioning 
Camerfirma below such a ‘bare minimum’ bar considering that Camerfirma, 
according to the public data, is not the member with the highest number of 
incidents nor the member with the most severe ones.

Finally, I’d like to ask you, based on which article of Mozilla Root Store 
Policy, you are sentencing a removal from the Mozilla store.

Again we appreciate your time and input in contributing to this discussion.

-Ramiro


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

Re: Summary of Camerfirma's Compliance Issues

2021-01-19 Thread Ramiro Muñoz via dev-security-policy 
El martes, 19 de enero de 2021 a las 0:49:42 UTC+1, Matt Palmer escribió:
> On Sun, Jan 17, 2021 at 12:51:29AM -0800, Ramiro Muñoz via 
> dev-security-policy wrote: 
> > We don’t ask the community to disregard the data, on the contrary we ask 
> > the community to analyze the data thoroughly including the impacts 
> > produced.
> OK, I'll bite. As a member of the community, I've analyzed the data 
> thoroughly, and I'm not impressed. Camerfirma does not appear to grasp the 
> fact that "nothing bad has happened yet" is a *bad take*. "Nothing bad has 
> happened yet" is how every CA starts its life. It is not something to be 
> proud of, it's the absolute bare minimum. The volume of incidents that 
> Camerfirma has had is troubling, but it's the repetition of the nature of 
> the incidents, and the lacklustre way in which they have been responded to, 
> that causes me to think that Camerfirma has no place in the Mozilla trust 
> store. 
> 
> - Matt

Dear Matt,

Thanks for your input, we really appreciate your time in contributing to this 
discussion.

We are trying to make this discussion as objective as possible, and talking 
about objectivity I’d like to ask you where does the ‘bare minimum’ threshold 
stands according  to Mozilla Root Store Policy. And why you are positioning 
Camerfirma below such a ‘bare minimum’ bar considering that Camerfirma, 
according to the public data, is not the member with the highest number of 
incidents nor the member with the most severe ones.

Finally, I’d like to ask you, based on which article of Mozilla Root Store 
Policy, you are sentencing a removal from the Mozilla store.

Again we appreciate your time and input in contributing to this discussion.

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