DRAFT: Root Inclusion Considerations

[Kathleen Wilson]

All,

I will greatly appreciate your feedback on the following new wiki page.

https://wiki.mozilla.org/CA/Root_Inclusion_Considerations

As you all know, sometimes we have very difficult decisions to make in regards to new inclusion or continued inclusion of root certificates in Mozilla's root store. With this new wiki page I am hoping to make such difficult root inclusion decisions more deterministic. Hopefully it will help the next time we have a difficult discussion about a CA who is currently in Mozilla's program. And hopefully it will enable us to decline root inclusion requests before we even get to the public discussion phase when the CA has participated in unacceptable behavior or has a multitude of concerning behaviors.

Thanks in advance for your thoughtful and constructive consideration.

Kathleen

[Kurt Seifried]

Some immediate feedback:

network surveillance; or

What about security firms that also provide MSP/etc and do network surveillance for customers of customer networks?

Ditto for:

cyber espionage.

E.g. Verisign bought iDefense back in the day, iDefense did cyber espionage of bad people (dark web/boards/etc). I assume any of these security firms with "intelligence" or "dark web monitoring" are still doing this.

Also the following are fairly subjective:

The CA operator has done any of the following:
Mis-issued a large or unknown number of end-entity or intermediate certificates that they are not able to enumerate;

What if they miss issued 10 certs? Out of 20? Out of 20,000,000? Maybe some language around percentages?

One idea: why not require CA's to report every misssued certificate to the CCADB, that would give you some data to work of off, e.g. what is a normal amount of mistakes and who are the outliers, good and bad? Cn we maybe get some data from letsencrypt? They issue a lot of certs are apear to care about transparency and security. 

Deliberately violated Mozilla's Root Store Policy or other applicable policy; or
Lied, concealed, or failed to disclose the full extent of a problem.

This language is problematic. "We didn't lie, we misspoke". Maybe "appear to have" so we're dealing with what we saw happen, and we don't have to figure out intent.

This one:

The CA’s provided address is a mail drop, rather than an office.

Is hard to determine, maybe language like "an address shared with numerous other companiesentities" (e.g. shell corporate registry), but what about P.O. boxes?

I think this is a good one:

• The CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store.

Again problematic language/intent:

• The CA's representatives are evasive on matters such as legal domicile and ownership.

I would suggest "not fully transparent", put the onus on them to be honest, not for us to catch them being dishonest.

Also more detail:

The CA has physical, monetary, or business nexus to a government of a country that

E.g. what about owners/owning corporations? "The CA and owning entities, recursively until some end is encountered" I would also note that CA's shoudln't be hidden in/part of horribly complex legal/business structures, that's a red flag.

Ah I see later:

• The CA is owned or funded by an individual or government organization that is known to also own or fund a vendor that has provided software being used for network surveillance or cyber espionage.
• The CA uses a shell company, an acquisition, or other misdirection to divert attention away from their relationship with another organization or government.

I think "owning entities" is probably a better term as it's generic but I would suggest consulting a lawyer at this point for the correct term.

Also some definition of

• Has gaps between audit periods.

E.g. what constitutes a gap?

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b0e3c58a-26b1-430c-9aeb-7763bdda6345n%40mozilla.org.

--

Kurt Seifried (He/Him)
ku...@seifried.org

[John Han (hanyuwei70)]

> The CA operator is in a global region that cannot use the CCADB, or is not capable of entering into a contractual agreement with a US-based company.
Is this means US government can control whether any CA  is in Mozilla root store?

> Mis-issued a large or unknown number of end-entity or intermediate certificates that they are not able to enumerate;

I agree with Kurt Seifried, we can require CA to report all mis-issued cert to determine a baseline for current CAs. So we can have a better understand about mis-issurance.

About network surveillance and cyber espionage, these need to be more specific. For example, police or other security agencies will use cameras to defend possible attacks. we could consult CA operators to have better understanding.

[Kurt Seifried]

On Wed, Feb 1, 2023 at 9:42 AM John Han (hanyuwei70) <hanyu...@gmail.com> wrote:

> The CA operator is in a global region that cannot use the CCADB, or is not capable of entering into a contractual agreement with a US-based company.
Is this means US government can control whether any CA  is in Mozilla root store?

I would assume if they are listed on https://sanctionssearch.ofac.treas.gov/ for example then yes, Mozilla and friends can't be doing business with them (and putting them into the root CA ... yow). I'm trying to think of a legitimate corner case where a company can't do business with a US entity legally but is still somehow trustworthy enough to be a root CA, and nothing comes to mind.

 

[John Han (hanyuwei70)]

I understand that. Perhaps we could use "with a US-based or EU-based company." to address neutrality or it is impossible in legal?

[Kurt Seifried]

Correct me if I'm wrong but AFAIK all the main participants that consume what the CCADB creates are all US based (Mozilla/Microsoft/Google/Apple/Oracle/Adobe). 

Also if you really want "neutrality" then you'll need to define what you mean exactly. And probably include include Africa, Asia and South America at a minimum. I don't think this makes any sense.

[Filippo Valsorda]

I want to thank Mozilla for producing this. It's never easy to summarize, formalize, and enumerate what boils down to values.

I'm happy to see a stark stance on any surveillance activity. Different people with different values and from different cultures will disagree on who are the people that are ok to surveil: maybe you think surveilling police targets is good, maybe you think surveilling the police is good; maybe you think children must be protected from the Internet, maybe you think children have a right to privacy. The WebPKI serves everyone, and its universal trust requirements are simply incompatible with entities involved in any kind of monitoring or surveillance of people, regardless of how socially necessary or positive it might be considered.

[Robert Lee]

Generally I think this is a great step and it's going to be a good thing for WebPKI and the community in/around it.

Some general thoughts:
1. As already suggested by others, I wonder if it would help to better clarify what is meant by network surveillance.  I think a strong stance is good but perhaps precision is needed to distinguish between actors engaged in spying and vendors of network monitoring tools as the latter could be argued to be the former.

2. "Mis-issued a large or unknown number of ... certificates".  I wonder if stating it's a large number is an unhelpful distinction, large or unknown is definitely bad but repeated small volume mis-issuance may be more concerning than a single incident.  It may be covered by other rules elsewhere but on the page under draft I didn't see anything that would describe a CA who was coming to the mailing list every month or so with their latest problem as in that case the number of certificates might be low.

3. This may be more subjective and less precise than the tone you're going for but is there value in having some sort of comment about how CA representatives are to engage with the community via this mailing list?  Maybe not Unacceptable or Concerning Behaviour but at the Warning Sign level it could fit.  Naming no names, it seems to me as if some of the recently excluded CAs have responded extremely unpleasantly to reasonable questioning/criticism from members of the community so I wonder if a requirement to behave might not be a bad thing.  As I say, it's a bit subjective, but as Filippo rightly says this page is trying to right down values expected so if Mozilla policy is going to demand transparency over ownership and operations then adding respectful interaction with the community might not be totally unreasonable.

Best Regards,

Rob

[Wayne Thayer]

Thank you for compiling this Kathleen. I do think it will help in assessing future inclusion requests, but of course it won't cover every possible situation. It is implied in the MRSP, but might be worth making explicit here that inclusion requests may be denied for reasons/behaviors not [yet] listed on this wiki page. Additional comments:

- The bullet on a large volume of mis-issuance makes sense from the perspective of not including a root that has misissued a bunch of certs (instead make the CA submit a new "clean" root)

- However, in line with a previous comment, I have more concern with repeated mis-issuance than the number of misissued certs. This might be more broadly stated as repeated incidents.

- The CA's response to mis-issuance/incidents is important. Did the CA self-report or wait for the community to raise the issue? Did they revoke promptly? Identify and remediate the root cause?

- I'd also suggest adding something about not providing prompt and detailed responses to Mozilla inquiries as a concerning behavior or warning sign.

- The bullet on CAB Forum membership is slightly problematic because CAB Forum membership requires the CAs roots to be recognized in at least one browser, and Mozilla is often the first.  Adding "or interested party" or changing "member" to "participant" would solve this.

Thanks,

Wayne

[Kathleen Wilson]

Thank you all for your feedback so far. I am sure it will take a couple iterations to get this all correct and usable, so I will continue to appreciate your feedback on this draft page.

https://wiki.mozilla.org/CA/Root_Inclusion_Considerations

I have incorporated your feedback as follows.

- Changed network surveillance bullet point to:
network surveillance that collects information about a person or organization and sends it to another entity in a way that endangers the privacy or device security of the person or organization

- Changed the cyber espionage bullet point to:
cyber espionage that aims to obtain information from a person or organization without the knowledge or permission of the person or organization for personal, economic, political or military advantage.

- Changed the “The CA operator has done any of the following:” bullet and sub-bullet points to:
The CA operator appears to have:
– Deliberately violated Mozilla's Root Store Policy or other applicable policy; or

– Lied, concealed, or failed to disclose the full extent of a problem.

- Moved the “Mis-issued a large or unknown number of…” sub-bullet point to:
The CA operator has:
– Repeated incidents of certificate mis-issuance that the CA operator previously claimed to have resolved;
– Failed to identify and remediate the root cause of their incident of certificate mis-issuance; or
– Demonstrated insufficient quality or competence in their CA’s operations by frequently mis-issuing certificates, especially when such mis-issuance would be prevented by pre-issuance lint testing.

- Added “Mozilla may deny a root inclusion request for reasons or behaviors not listed on this page.”

- Changed “The CA’s provided address is a mail drop, rather than an office.” to:
The CA’s provided address is a P.O. box, mail drop, or an address shared with numerous other companies/entities. (e.g. shell corporate registry)

- Changed “The CA's representatives are evasive…” to:
The CA's representatives are not fully transparent on matters such as legal domicile and ownership.

- For the “This CA is associated / owned…” bullet points, added:
(or the CA’s owning entities are)

- Changed CABF bullet point to:
“Is not a voting member, associate member, or interested party participating in the CA/Browser Forum (CABF) Server Certificate Working Group (when applying for the Websites trust bit) or the CABF S/MIME Certificate Working Group (when applying for the Email trust bit).”

- Changed “Has gaps between audit periods.” to:
Has non-contiguous audit periods

- Added Warning Signs:
– Fails to provide prompt and detailed responses to Mozilla inquiries about their CA operations, root inclusion requests, policy documents, audit statements, and incidents.
- Demonstrates unacceptable behavior in Mozilla's dev-security-policy discussion forum, as per Mozilla’s Community Participation Guidelines.
- Fails to follow the CCADB Public Code of Conduct when posting in the CCADB Public discussion forum.

Thanks!
Kathleen

[Kurt Seifried]

On Tue, Feb 7, 2023 at 6:10 PM Kathleen Wilson <kwi...@mozilla.com> wrote:

Thank you all for your feedback so far. I am sure it will take a couple iterations to get this all correct and usable, so I will continue to appreciate your feedback on this draft page.

https://wiki.mozilla.org/CA/Root_Inclusion_Considerations

I have incorporated your feedback as follows.

- Changed network surveillance bullet point to:
network surveillance that collects information about a person or organization and sends it to another entity in a way that endangers the privacy or device security of the person or organization

I think network surveillance might need a bit of definition here, e.g. are we talking just packet sniffing/dns/bgp/etc redirection? Or for example, as a root CA I could potentially also issue client authentication certificates and use them to log into a site (e.g. with auth locked to a specific domain unless you pin to a specific cert/key...). 

 

- Changed the cyber espionage bullet point to:
cyber espionage that aims to obtain information from a person or organization without the knowledge or permission of the person or organization for personal, economic, political or military advantage.

This definitely covers things like Atos monitoring the darkweb and being paid to do so (see CCADB public forum discussion about this). 

 

- Changed the “The CA operator has done any of the following:” bullet and sub-bullet points to:
The CA operator appears to have:
– Deliberately violated Mozilla's Root Store Policy or other applicable policy; or

Which version? Current versions? Past versions? E.g. if a CA did something that wasn't previously banned, and is then later banned what exactly happens?

 

– Lied, concealed, or failed to disclose the full extent of a problem.

One thought: post-mortems sometimes take time, I worry that this might incentivize companies not to look as deeply, and hope that they can get away with it, especially since external investigations into this are almost impossible without full cooperation of the organization being investigated (witness Trustcor).

 

- Changed “Has gaps between audit periods.” to:
Has non-contiguous audit periods

This might unintentionally punish an organization that shortens its audit cycle (which is probably a good thing). 

 

- Added Warning Signs:
– Fails to provide prompt and detailed responses to Mozilla inquiries about their CA operations, root inclusion requests, policy documents, audit statements, and incidents.

Can we add something to ensure this is done publicly and transparently? E.g. Is Mozilla asking these things in public, in private, in both? I assume these are all public asks, but it's not stated clearly as such (or I could be wrong and you're asking for tons of things in private?). 

 

- Demonstrates unacceptable behavior in Mozilla's dev-security-policy discussion forum, as per Mozilla’s Community Participation Guidelines.
- Fails to follow the CCADB Public Code of Conduct when posting in the CCADB Public discussion forum.

Thanks!
Kathleen

[Roman Fischer]

Dear Kathleen,

 

I think your suggestions absolutely go in the right direction.

 

I would only comment on the “network monitoring” as my understanding is that things like collecting information in the sense of Threat Intelligence / OSINT should be allowed (we want to know what’s being said about us on the web – dark and light alike) and things like intercepting / manipulating traffic should be not allowed (unless it goes into the “lawfull interception” category, which would be a bit strange for a CA to be involved in… but alas. 😉). I’m not English native speaking so I don’t dare to suggest concrete wording but hope this helps to clarify the thought behind this requirement a bit.

 

Thanks
Roman

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa3-5ot2bc1L_mtigtLnN4h2Xt2p6EV6Hey_qABgAhd8t%3DA%40mail.gmail.com.

[Kathleen Wilson]

I appreciate your patience and continued feedback as we work together to get this all correct and usable.

https://wiki.mozilla.org/CA/Root_Inclusion_Considerations

I have incorporated recent feedback as follows.

- Changed “network surveillance…” to:
network surveillance that intercepts/manipulates traffic or collects private information about a person or organization and sends it to another entity without the permission of the person or organization, or in a way that endangers the privacy or device security of the person or organization

- Changed “cyber espionage …” to:
cyber espionage that aims to obtain private information from a person or organization without the knowledge or permission of the person or organization for personal, economic, political or military advantage.

- Changed “Deliberately violated Mozilla's Root Store Policy …” to:
Deliberately violated the version of Mozilla's Root Store Policy or other applicable policy that was in effect at the time that the violation occurred

- Under “The CA operator appears to have:” added:
Made intentionally deceptive or recklessly misleading claims relating to operation of the CA or the use of its certificates

- Changed “The CA's representatives are not fully transparent on matters such as legal domicile and ownership.” to:
The CA's representatives are not fully transparent on matters such as legal domicile and Control.
-- "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%.

- Changed “Fails to provide prompt and detailed responses to Mozilla inquiries…” to:
Fails to provide prompt, detailed, public, and transparent responses to Mozilla inquiries about their CA operations, root inclusion requests, policy documents, audit statements, and incidents.

- Changed “Has non-contiguous audit periods” to:
Has non-contiguous audit periods; meaning that there is one day or more between consecutive audit periods.

Thanks,
Kathleen

[Kathleen Wilson]

Would it be reasonable to add the following as a Concerning Behavior?

- The CA does not publish annual accounts or financial statements that have been independently audited or examined.

This has been suggested to me via email, but I am not versed in this area.

Thanks,

Kathleen

[Matthew Hardeman]

As a rule, you tend to have to be a pretty significant business operation to have accounts / financial statements that are "independently audited or examined."

Even many small businesses have their financials and tax accounting reviewed and prepared by accounting professionals.  But that's different from a formal assertion of "independently audited or examined."

In the US, publicly traded corporations would be.  But many private entities would not.  It can add a significant time investment and significant expenditure to go that extra step and get an assertion from the accountant that the financials represented in the report do materially reflect the state of the business.

Without expressing a particular opinion on the matter, I believe that you should contemplate whether any risk mitigation value of imposing such burdens outweighs the costs to the CA / prospective CA.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/54e67648-e742-4995-865d-b5221fe3ef07n%40mozilla.org.

[Jeremy Rowley]

Which CAs are even publicly traded at this point – Google, Amazon, Entrust?  Plus, do government CAs qualify as having independently and publicly available audited financial statements? What about services like Let’s Encrypt? They publish a report on their finances but I think that report is written by Let’s Encrypt, not independent auditors?  I’d venture most of the CAs in the root program don’t meet both the independent and publicly available statements. 

 

I don’t like this requirement because it means only small subsidiaries of very large organizations can be a CA.

 

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Matthew Hardeman
Sent: Thursday, February 9, 2023 11:11 AM
To: Kathleen Wilson <kwi...@mozilla.com>
Cc: dev-secur...@mozilla.org
Subject: Re: DRAFT: Root Inclusion Considerations

 

As a rule, you tend to have to be a pretty significant business operation to have accounts / financial statements that are "independently audited or examined."

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPAx59EgVZ5rNUJgei2x14yUfany4kNCpDUu1m61tJWMKgGLtg%40mail.gmail.com.

[Ryan Hurst]

I agree with Jeremy.

Ryan Hurst

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BYAPR14MB26007E1B8E86C2DB615C54388ED99%40BYAPR14MB2600.namprd14.prod.outlook.com.

[Moudrick M. Dadashov]

Makes sense for multi-homed (delegated) CAs operations.

Thanks,

M.D.

Sent from my Galaxy

-------- Original message --------

From: Kathleen Wilson <kwi...@mozilla.com>

Date: 2/9/23 19:54 (GMT+02:00)

To: dev-secur...@mozilla.org

Subject: Re: DRAFT: Root Inclusion Considerations

[Dennis Jackson]

On Thursday, February 9, 2023 at 6:28:19 PM UTC Jeremy Rowley wrote:

Which CAs are even publicly traded at this point – Google, Amazon, Entrust?  Plus, do government CAs qualify as having independently and publicly available audited financial statements? What about services like Let’s Encrypt? They publish a report on their finances but I think that report is written by Let’s Encrypt, not independent auditors?  I’d venture most of the CAs in the root program don’t meet both the independent and publicly available statements. 

I don’t like this requirement because it means only small subsidiaries of very large organizations can be a CA.

Matthew Hardeman wrote:

As a rule, you tend to have to be a pretty significant business operation to have accounts / financial statements that are "independently audited or examined."

 Even many small businesses have their financials and tax accounting reviewed and prepared by accounting professionals.  But that's different from a formal assertion of "independently audited or examined."

 In the US, publicly traded corporations would be.  But many private entities would not.  It can add a significant time investment and significant expenditure to go that extra step and get an assertion from the accountant that the financials represented in the report do materially reflect the state of the business.

I am not aware of the situation in the USA, but the EU has much stronger financial transparency requirements. Every EU business with limited liability (public or privately held) must publish an annual balance sheet at the very least. All businesses except those defined as small (<50 employees and <$10 million revenue) must also have a full independent audit. As an example, you can lookup LuxTrust in the EU wide business register which will direct you to the Luxembourg register of accounts which provides their annual statements for free to users who solve a CAPTCHA. I've attached their 2021 statement, including an independent auditor's report from Ernst and Young.

Stronger requirements are imposed upon charities and non-profits. For example, here are the independently examined financial reports for a randomly selected small UK charity (yearly revenue <$400k) which are also available for free online via a government provided service. Further, in the USA many organisations choose to or are required to publish audits of their accounts. e.g. the Tor Project publish an audit of their annual accounts as a non-profit (turnover $8 million in 2021), showing that this is practical even for small concerns.

So I'd expect nearly every EU based CA is already compliant with these rules and clearly even relatively small non-profits like Tor in the USA are able to have their accounts audited as a yearly obligation. Put another way, why shouldn't we hold all CAs to the same standard of financial reporting as that required of small charities? 

Best,

Dennis

 

 

From: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> On Behalf Of Matthew Hardeman
Sent: Thursday, February 9, 2023 11:11 AM
To: Kathleen Wilson <kwi...@mozilla.com>
Cc: dev-security-policy@mozilla.org
Subject: Re: DRAFT: Root Inclusion Considerations

 

 

On Thu, Feb 9, 2023 at 11:54 AM Kathleen Wilson <kwi...@mozilla.com> wrote:

Would it be reasonable to add the following as a Concerning Behavior?

 

- The CA does not publish annual accounts or financial statements that have been independently audited or examined.

 

This has been suggested to me via email, but I am not versed in this area.

 

Thanks,

Kathleen

 

 

--
You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsub...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/54e67648-e742-4995-865d-b5221fe3ef07n%40mozilla.org.

--
You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsub...@mozilla.org.

[Kurt Seifried]

On Wed, Feb 8, 2023 at 1:42 PM Kathleen Wilson <kwi...@mozilla.com> wrote:

I appreciate your patience and continued feedback as we work together to get this all correct and usable.

https://wiki.mozilla.org/CA/Root_Inclusion_Considerations

I have incorporated recent feedback as follows.

- Changed “network surveillance…” to:
network surveillance that intercepts/manipulates traffic or collects private information about a person or organization and sends it to another entity without the permission of the person or organization, or in a way that endangers the privacy or device security of the person or organization

Another wrinkle that just came up: In the ATOS root certificate discussion it turns out ATOS also makes a Data Loss Prevention (DLP) product, so obviously having a root cert to MitM that would be hugely helpful, and probably not something we want to be done with root certificates.

Maybe adding some language around "if digital certificates are issued for domains the issuer MUST establish control/consent with the owner/controller of the domain" which would basically negate the whole man-in-the-middle (MitM) usage of these certificates even in "legitimate" products.

[Peter Bowen]

Entrust is, to my knowledge, privately owned.

I believe that Amazon Trust Services LLC, Certainly LLC, Google Trust
Services LLC, and Starfield Technologies LLC are all privately held
companies that are owned by publicly traded companies. I'd be
surprised if any of these CA operators (as defined in their WebTrust
audit reports) has financial reporting equivalent to a company that
has securities registered with the US SEC.

On Thu, Feb 9, 2023 at 10:28 AM 'Jeremy Rowley' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:
>

[Kurt Seifried]

FYI at least one person is being blocked from posting to the list properly for reasons unknown.

On Fri, Feb 10, 2023 at 11:04 AM Steve Keller <kelle...@proton.me> wrote:

Unfortunately it won't let me post. I don't see why it would be harmful to ask the community to double-check my work to make sure that I'm not misunderstanding the new requirements?

As far as I can tell, there's a number of CAs currently rooted that are already engaging in Concerning Behavior, but maybe I'm misunderstanding something or Mozilla doesn't like that question?

------- Original Message -------
On Tuesday, February 7th, 2023 at 9:52 PM, Steve Keller <kelle...@proton.me> wrote:

My apologies, for some reason its not posting my response. I will try again.

Thanks,

Steve

------- Original Message -------
On Tuesday, February 7th, 2023 at 9:06 PM, Kurt Seifried <ku...@seifried.org> wrote:

You need to reply to the list.

-Kurt

On Feb 7, 2023, at 1:35 PM, Steve Keller <kelle...@proton.me> wrote:



What happens to the CAs engaging in "Concerning Behavior" that currently have their root certificates in Mozilla's root store?

Mozilla states:

>  If the CA operator currently has root certificates in Mozilla's root store, then Mozilla may remove those root certificates or set them to be distrusted after a specified date.

How much Concerning Behavior would a CA need to engage in before their root certificates were removed?

Just a quick review of all the currently included CAs in Mozilla's root store and it seems that these CAs are already engaging in Concerning Behavior according to the recently announced considerations:

1. Agence Nationale de Certification Electronique - Corruption Perceptions Index Score less than 50 (score = 40)

2. certSIGN - Corruption Perceptions Index Score less than 50 (score = 46)

3. China Financial Certification Authority (CFCA) - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

4. E-Tugra - Internet Freedom Score less than 50 (score = 32), Corruption Perceptions Index Score less than 50 (score = 36)

5. eMudhra Technologies Limited - Corruption Perceptions Index Score less than 50 (score = 40)

6. Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA)) - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

7. Government of Hong Kong (SAR), Hongkong Post, Certizen aka "Hongkong Post" - Internet Freedom Score less than 50, Corruption Perceptions Index Score less than 50

8. Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) aka "TUBITAK" - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45), CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

9. iTrusChina Co., Ltd. - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

10. Microsec Ltd. - Corruption Perceptions Index Score less than 50 (score = 42), CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

11. Netlock - Corruption Perceptions Index Score less than 50 (score = 42), CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

12. Shanghai Electronic Certification Authority Co., Ltd. aka "UniTrust" - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

13. Actalis - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

14. Atos Trustcenter - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

15. Buypass - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

16. Chunghwa Telecom - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

17. Disig, a.s. - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

18. e-commerce monitoring GmbH - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

19. HARICA - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

20. SwissSign AG - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

------- Original Message -------

-- 

Kurt Seifried (He/Him)
ku...@seifried.org

-- 

Kurt Seifried (He/Him)

ku...@seifried.org

-- 

[Kathleen Wilson]

On Friday, February 10, 2023 at 12:29:54 PM UTC-8 ku...@seifried.org wrote:

FYI at least one person is being blocked from posting to the list properly for reasons unknown.

On Fri, Feb 10, 2023 at 11:04 AM Steve Keller <kelle...@proton.me> wrote:

Unfortunately it won't let me post. I don't see why it would be harmful to ask the community to double-check my work to make sure that I'm not misunderstanding the new requirements?

As far as I can tell, there's a number of CAs currently rooted that are already engaging in Concerning Behavior, but maybe I'm misunderstanding something or Mozilla doesn't like that question?

Steve will need to:

"Subscribe by sending email to: dev-security-policy+subscribe@mozilla.org. Membership requests must provide context for your interest in joining the group. Requests without this information will be rejected."

Only members can post to this group, otherwise this group would receive a lot of spam.



What happens to the CAs engaging in "Concerning Behavior" that currently have their root certificates in Mozilla's root store?

Concerning Behavior: "The following situations are concerning and in aggregate..."

So concern would be raised when a collection (several) of the main bullet points happen.

 

Mozilla states:

>  If the CA operator currently has root certificates in Mozilla's root store, then Mozilla may remove those root certificates or set them to be distrusted after a specified date.

How much Concerning Behavior would a CA need to engage in before their root certificates were removed?

When several of the concerning behaviors exist, then we need to look more closely at the CA and do a risk versus value assessment of the CA.

 

Just a quick review of all the currently included CAs in Mozilla's root store and it seems that these CAs are already engaging in Concerning Behavior according to the recently announced considerations:

1. Agence Nationale de Certification Electronique - Corruption Perceptions Index Score less than 50 (score = 40)

2. certSIGN - Corruption Perceptions Index Score less than 50 (score = 46)

3. China Financial Certification Authority (CFCA) - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

4. E-Tugra - Internet Freedom Score less than 50 (score = 32), Corruption Perceptions Index Score less than 50 (score = 36)

5. eMudhra Technologies Limited - Corruption Perceptions Index Score less than 50 (score = 40)

6. Global Digital Cybersecurity Authority Co., Ltd. (Formerly Guang Dong Certificate Authority (GDCA)) - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

7. Government of Hong Kong (SAR), Hongkong Post, Certizen aka "Hongkong Post" - Internet Freedom Score less than 50, Corruption Perceptions Index Score less than 50

8. Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) aka "TUBITAK" - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45), CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

9. iTrusChina Co., Ltd. - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

10. Microsec Ltd. - Corruption Perceptions Index Score less than 50 (score = 42), CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

11. Netlock - Corruption Perceptions Index Score less than 50 (score = 42), CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

12. Shanghai Electronic Certification Authority Co., Ltd. aka "UniTrust" - Internet Freedom Score less than 50 (score = 10), Corruption Perceptions Index Score less than 50 (score = 45)

I am interested in feedback on using the Internet Freedom Score and Corruption Perceptions Index when considering CAs...

Is this check useful?

How much should it impact our decisions?

Is it only useful when the CA is also closely aligned with a government organization?

 

13. Actalis - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

14. Atos Trustcenter - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

15. Buypass - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

16. Chunghwa Telecom - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

17. Disig, a.s. - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

18. e-commerce monitoring GmbH - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

19. HARICA - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

20. SwissSign AG - CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store

I think this concern about auditor only auditing one CA means that we might need to do more due diligence in regards to verifying that auditor's qualifications. Especially when any other items in the Concerning Behaviors list apply to the CA.

These are all good questions, and I am very interested to hear feedback from CAs who are currently in Mozilla's program and may be impacted by this list.

Thanks,

Kathleen

[Roman Fischer]

Dear all,

 

Regarding „CA's auditor has not audited other CAs whose root certificates are already included in Mozilla’s Root store”, I’d like to point out that we need to make sure that we have a common understanding what “CA’S auditor” means. Is it a person, a company? Is that entity just currently not auditing other public trusted CAs but did so in the past (how long ago) or did the auditors maybe work for a different audit company that -did- audits on other public trusted CAs… ?

 

The current wording would also exclude new auditors from ever doing their first audit of a public trusted CA… 😉

 

I think what we all want and expect is that the auditors are experienced, know the regulations they have to audit against and have some understanding of what “good practice” as CA must show.

 

Kind regards
Roman

 

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Kathleen Wilson
Sent: Montag, 13. Februar 2023 19:59
To: dev-secur...@mozilla.org
Cc: ku...@seifried.org <ku...@seifried.org>; Steve Keller <kelle...@proton.me>
Subject: Re: DRAFT: Root Inclusion Considerations

 

On Friday, February 10, 2023 at 12:29:54 PM UTC-8 ku...@seifried.org wrote:

FYI at least one person is being blocked from posting to the list properly for reasons unknown.

 

On Fri, Feb 10, 2023 at 11:04 AM Steve Keller <kelle...@proton.me> wrote:

Unfortunately it won't let me post. I don't see why it would be harmful to ask the community to double-check my work to make sure that I'm not misunderstanding the new requirements?

As far as I can tell, there's a number of CAs currently rooted that are already engaging in Concerning Behavior, but maybe I'm misunderstanding something or Mozilla doesn't like that question?

 

Steve will need to:

"Subscribe by sending email to: dev-security-p...@mozilla.org. Membership requests must provide context for your interest in joining the group. Requests without this information will be rejected."

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b9407f23-c174-4d75-8d4d-1e439408164dn%40mozilla.org.

[Kathleen Wilson]

I have made the following changes to

https://wiki.mozilla.org/CA/Root_Inclusion_Considerations#Concerning_Behavior

1) Clarified the intent of this section in the first paragraph:

The following situations are concerning in aggregate; meaning that a concern would be raised when a collection (several) of the main bullet points below happen. These concerns in aggregate may lead to Mozilla denying the CA operator's root inclusion request. If the CA operator currently has root certificates in Mozilla's root store and these concerns in aggregate apply, then Mozilla should perform a risk versus value assessment, and may remove those root certificates or set them to be distrusted after a specified date.

2) Clarified what is meant by "auditor":

The CA's auditor (i.e. the third-party auditing organization) has not audited other CAs whose root certificates are already included in Mozilla’s Root store.

Hope that helps with the recent feedback.

Thanks to all of you, and looking forward to more feedback on this draft.

Kathleen

[Kathleen Wilson]

I continue to receive feedback/concerns about the auditor bullet point in the "Concerning Behavior" section, so I am attempting to resolve those concerns with the following version of that bullet point:

• The CA is using an auditing organization (ETSI, WebTrust) that has not audited other publicly trusted CAs whose root certificates are included in browser root store programs, and the Auditor Qualifications indicate that the audit team is inexperienced in auditing CA operations, public key infrastructure, trust services or similar information systems.
  • New auditors are allowed under the condition that the CA ensures that the Audit Team is lead by third-party specialists or affiliate audit firms who are experienced in auditing publicly trusted CAs, and this information must be provided as part of the Auditor Qualifications.

I will appreciate feedback and suggestions on this new text. Does it address your concerns?

Also, I am no longer receiving feedback on the rest of the wiki page, https://wiki.mozilla.org/CA/Root_Inclusion_Considerations, so I am assuming that the rest of the page is solid (i.e. ready to remove the "DRAFT" at the top of the page).

Thanks,

Kathleen

[Ryan Hurst]

Kathleen/Ben,

I have been thinking about the new Concerning Behavior language being proposed for the Mozilla Root Store Policy and I wanted to share my thoughts relative to this policy and censorship.

When discussing CA inclusions, a topic that commonly comes up is the risk of the applicant violating the privacy of Mozilla's users by enabling MiTMs. However, there are other concerning behaviors that are not often discussed, such as the use of certificate issuance and denial as tools for censorship, community exclusion, and enabling misinformation. 

These behaviors can have far-reaching impacts on Mozilla's customers and are not aligned with the objectives of Mozilla as I understand them.

In 2015, Let's Encrypt wrote a blog post on why CAs make poor content watchdogs. I believe the points raised in this post are still relevant today, and it may make sense to add some language to the Concerning Behavior section of the Root Store Policy to make Mozilla's position on these topics clear. 

For example, we could consider adding the following bullets to the warning signs section:

• CA operators who attempt to act as a content watchdog beyond what is required by other root programs or governing legal jurisdictions should be seen as a warning sign of behavior that could lead to censorship and be incompatible with Mozilas objectives for the root program and its principles overall.
• CA operators who attempt to act as content watchdogs by denying the issuance of Internationalized Domain Names (IDNs) for reasons beyond legal jurisdictional requirements, what is required by other root programs, or the technical limitations of their certificate issuance systems should be seen as a warning sign of behavior that could lead to censorship which would be incompatible with Mozilas objectives for the root program and its principles overall as it limits access to the internet for non-English speaking users and may be used as a tool for political or cultural control.

While this is probably not the exact right wording something similar to this has the potential to make it clear what Mozilla's position on these topics is and as a result, strongly discourage CAs from leveraging their position to support these activities.

Best regards,

Ryan Hurst

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/164d74b3-2371-4d79-815c-2bcd466ace00n%40mozilla.org.

[Jeremy Rowley]

I think this approach is dangerous too though. Is it censorship if a CA won’t issue to Russian entities? What about to other government entities? If Mozilla goes down this route, the policy should include some standard where a ca can exclude entities where there is there is a risk of potentially facilitating of legally questionable activity.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Ryan Hurst <ryan....@gmail.com>
Sent: Wednesday, March 1, 2023 7:54:31 PM
To: Kathleen Wilson <kwi...@mozilla.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Re: DRAFT: Root Inclusion Considerations

 

Kathleen/Ben,

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwY_j1foAGnqW0atHEx%3DMLLZdPXgx-K5aWXyMFvAMnW-2w%40mail.gmail.com.

[Kurt Seifried]

On Wed, Mar 1, 2023 at 7:54 PM Ryan Hurst <ryan....@gmail.com> wrote:

Kathleen/Ben,

I have been thinking about the new Concerning Behavior language being proposed for the Mozilla Root Store Policy and I wanted to share my thoughts relative to this policy and censorship.

When discussing CA inclusions, a topic that commonly comes up is the risk of the applicant violating the privacy of Mozilla's users by enabling MiTMs. However, there are other concerning behaviors that are not often discussed, such as the use of certificate issuance and denial as tools for censorship, community exclusion, and enabling misinformation. 

These behaviors can have far-reaching impacts on Mozilla's customers and are not aligned with the objectives of Mozilla as I understand them.

In 2015, Let's Encrypt wrote a blog post on why CAs make poor content watchdogs. I believe the points raised in this post are still relevant today, and it may make sense to add some language to the Concerning Behavior section of the Root Store Policy to make Mozilla's position on these topics clear. 

For example, we could consider adding the following bullets to the warning signs section:

• CA operators who attempt to act as a content watchdog beyond what is required by other root programs or governing legal jurisdictions should be seen as a warning sign of behavior that could lead to censorship and be incompatible with Mozilas objectives for the root program and its principles overall.
• CA operators who attempt to act as content watchdogs by denying the issuance of Internationalized Domain Names (IDNs) for reasons beyond legal jurisdictional requirements, what is required by other root programs, or the technical limitations of their certificate issuance systems should be seen as a warning sign of behavior that could lead to censorship which would be incompatible with Mozilas objectives for the root program and its principles overall as it limits access to the internet for non-English speaking users and may be used as a tool for political or cultural control.

Silly question but why isn't there more usage of certificate restrictions, e.g. if a CA from a country has some concerns (like SERPRO) it would be much less damaging if they were more limited (e.g. to *.br). 

 

While this is probably not the exact right wording something similar to this has the potential to make it clear what Mozilla's position on these topics is and as a result, strongly discourage CAs from leveraging their position to support these activities.

Best regards,

Ryan Hurst

On Wed, Mar 1, 2023 at 4:46 PM Kathleen Wilson <kwi...@mozilla.com> wrote:

I continue to receive feedback/concerns about the auditor bullet point in the "Concerning Behavior" section, so I am attempting to resolve those concerns with the following version of that bullet point:

• The CA is using an auditing organization (ETSI, WebTrust) that has not audited other publicly trusted CAs whose root certificates are included in browser root store programs, and the Auditor Qualifications indicate that the audit team is inexperienced in auditing CA operations, public key infrastructure, trust services or similar information systems.
  • New auditors are allowed under the condition that the CA ensures that the Audit Team is lead by third-party specialists or affiliate audit firms who are experienced in auditing publicly trusted CAs, and this information must be provided as part of the Auditor Qualifications.

I will appreciate feedback and suggestions on this new text. Does it address your concerns?

Also, I am no longer receiving feedback on the rest of the wiki page, https://wiki.mozilla.org/CA/Root_Inclusion_Considerations, so I am assuming that the rest of the page is solid (i.e. ready to remove the "DRAFT" at the top of the page).

Thanks,

Kathleen

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/164d74b3-2371-4d79-815c-2bcd466ace00n%40mozilla.org.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwY_j1foAGnqW0atHEx%3DMLLZdPXgx-K5aWXyMFvAMnW-2w%40mail.gmail.com.

[Ryan Hurst]

I do believe it’s appropriate for there to be language to accommodate what is required by law. Such language would accomate legal obligations like sanctions should they be relevant. The langauge like you propose leaves it to the CA to determine if it’s questionable. This is very problematic given the realities of this ecosystem.

The purpose of the WebPKI is to facilitate delegated TOFU not content or name policing. CAs do not have access to the content served to the relying party and Mozilla use safe browsing and other motivations focused on content and names.

Expanding the scope to more than that without a clear mandate or standard is too dangerous given the global and distributed nature of this ecosystem.

Ryan Hurst

[Kurt Seifried]

On Wed, Mar 1, 2023 at 9:10 PM 'Jeremy Rowley' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

I think this approach is dangerous too though. Is it censorship if a CA won’t issue to Russian entities? What about to other government entities? If Mozilla goes down this route, the policy should include some standard where a ca can exclude entities where there is there is a risk of potentially facilitating of legally questionable activity.

So some concerns:

1) CA's have to abide by legal restrictions in their jurisdiction (e.g. US sanctions) and often in other jurisdictions (e.g. US sanctions, if you use US banks.. yeah)

2) Please define censorship, if you mean "not willing to issue a certificate" then there are many gay areas, e.g. let's pick on Russia. What if the CA says "look, we get a ton of spam/abuse/bad behavior from Russia, so we're simply declining to take those risks, it's not worth it"? Are we now going to force people to deal with everyone and not allow them to be somewhat selective in their clientele?

3) "the policy should include some standard where a ca can exclude entities where there is there is a risk of potentially facilitating of legally questionable activity."

Please define "legally questionable", please define which jurisdictions come into play (the CA? the client? the US where Mozilla resides? anything else?) and so on. This is hugely problematic language.

I'm inclined to aks the question:

Sort of devil's advocate: Why is it a problem if a CA refuses to provide certificates to someone/some entity, assuming it's legal (e.g. a US CA  refusing certificates to protected classes of people would likely not be legal, but refusing to service an entire state would likely be legal)?

 

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BYAPR14MB26000622195C610DB2107B7F8EB29%40BYAPR14MB2600.namprd14.prod.outlook.com.

[Kurt Seifried]

GRAY AREAS. dangit.

[Jeremy Rowley]

It is a little bit up the CA to determine. They know the laws of their jurisdiction and their tolerance for legal risk. If something is questionable legally, thrnCA probably shouldn't issue. 

---

From: Ryan Hurst <ryan....@gmail.com>
Sent: Wednesday, March 1, 2023 9:16:38 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Kathleen Wilson <kwi...@mozilla.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>

[Jeremy Rowley]

1) CA's have to abide by legal restrictions in their jurisdiction (e.g. US sanctions) and often in other jurisdictions (e.g. US sanctions, if you use US banks.. yeah)

[JR] Yeah – but what if its not exactly 100% sanctioned? For example, assume the US decides to sanction a country and France doesn’t. If the CA in France decides not to issue because the entity is on the sanctions list, then what? Did they censure it? Or what if the CA is tired of a country being put on and taken off the US list every month and just stops allowing issuance to that domain. Its okay to issue there some months, but not others.

 

2) Please define censorship, if you mean "not willing to issue a certificate" then there are many gay areas, e.g. let's pick on Russia. What if the CA says "look, we get a ton of spam/abuse/bad behavior from Russia, so we're simply declining to take those risks, it's not worth it"? Are we now going to force people to deal with everyone and not allow them to be somewhat selective in their clientele?

[JR] This is the crux of the issue. Appropriate vs. inappropriate censorship or what is a good definition of censorship? Is not wanting to issue to Dark Matter censorship after Mozilla booted them? What about sites that are espousing hate crimes? Although there’s nothing that says a CA needs to verify the contents of a site, there’s also nothing saying the CA can’t vet the content of a website. One of my big worries with the original DMCA was being a contributory infringer for copyright violation. If I refuse issuance to Warez sites, is that censorship? A definition would be good.

 

3) "the policy should include some standard where a ca can exclude entities where there is there is a risk of potentially facilitating of legally questionable activity."

 

Please define "legally questionable", please define which jurisdictions come into play (the CA? the client? the US where Mozilla resides? anything else?) and so on. This is hugely problematic language.

[JR] That wasn’t proposed language. That was pointing out a flaw in saying “No censorship is allowed”.

 

Sort of devil's advocate: Why is it a problem if a CA refuses to provide certificates to someone/some entity, assuming it's legal (e.g. a US CA  refusing certificates to protected classes of people would likely not be legal, but refusing to service an entire state would likely be legal)?

[JR] I think there’s years of court cases that try to answer this question, and answer it better than I could. But I think Mozilla has an interest in making sure CAs are providing services to the community as a whole (for example, not issuing only to themselves) while allowing CAs to manage their own risk profile.

 

 

From: 'Kurt Seifried' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Sent: Wednesday, March 1, 2023 9:21 PM
To: Jeremy Rowley <jeremy...@digicert.com>

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa382qwgB%3DC0jMjDWNVWu_2NQRBEVDcsMw88%2B3%3D5zf2Jp7Q%40mail.gmail.com.

[Kurt Seifried]

Also is there any mechanism for an entity to report a CA refusing to service them? Can I suggest it might be better to:

1) Create some sort of reporting mechanism (bugzilla?)

2) Create some sort of process, e.g. where the CA is questioned and has to explain why they refused it

Because then we'd actually have some facts upon which to figure out what happens next.

E.g. Do we even know how often this happens at all? Like is this even a problem?

[Jeremy Rowley]

I like the reporting mechanism. And Bugzilla is even better because it’s public. If someone complains, the CA can respond there. I know I wouldn’t have a problem saying on Bugzilla that we didn’t issue X cert because they are in X country or were found involved in Y criminal activity.

 

As for the scope of the problem, no idea. I know the scenarios I gave are real, but I’m unaware of any CA that refuses to issue certs to communities Mozilla might want to protect.

[Ryan Hurst]

I think that is the wrong question. If we go to first principles, Mozilla Root Policy exists to support Mozilla's mission:

Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe, and independent.

With that context, I believe the question becomes how giving WebPKI CAs room to be content watchdogs supports that vision, and does doing so conflict with that mission? I would argue that it does not support the mission and accommodating it conflicts with that vision. 

More concretely, I would argue that the fact the objective of ensuring the internet is a "global public resource" that is "open and accessible to all" directly speaks to the organization's position on this class of problem. Furthermore, the mission's focus on empowering individuals to "shape their own experiences" suggests that the user or their agent should protect them from maliciousness, not some third party they have never heard of.

As a technologist, if I put aside the mission of the organization and ask myself at which layer of the stack should be used to protect users from malicious content, the first question I would ask is at what layer in the stack can we see the content that the user is going to interact with. 

The answer to that question would exclude doing so at the naming layer, which is what both DNS and the WebPKI represent, as they don't see the same content the user does, and content changes far more often than certificates expire. 

Furthermore, since a browser's technological objective is to provide a uniform experience for its users, I would posit the objective of the root program is to deliver a uniform experience for those that rely on HTTPS within the browser since it is HTTPS that demands the existence of the root program. This precludes accommodating subjectivity; after all, there are nearly 100 members of the root program, and many of these organizations operate in countries with different concepts of appropriateness. 

To me, this means that for Mozilla to allow for censoring for reasons outside some narrowly defined scope that is well defined, such as legal obligations and conflicts with other root program requirements it must provide a definition for what is acceptable if it wants them to do this. Otherwise, from the perspective of the web, Mozilla's behavior is non-deterministic.

I say this because CAs in the WebPKI serve at the behest of browsers (which are the user’s agents) as they facilitate the browsers to provide authenticated and encrypted sessions for them. In the case of Mozilla, they achieve this goal by using their software and associated community to advance its broader mission, which includes this scope, which is why the root program exists.

Ryan Hurst

[Ryan Hurst]

Jeremy,

[JR] Yeah – but what if it's not exactly 100% sanctioned? For example, assume the US decides to sanction a country and France doesn’t. If the CA in France decides not to issue because the entity is on the sanctions list, then what? Did they censure it? Or what if the CA is tired of a country being put on and taken off the US list every month and just stops allowing issuance to that domain? It's okay to issue there some months, but not others.

To the best of my honoring sanctions is something that is legally required of a CA and as such in your initial example, I would imagine they would meet those legal obligations and not issue that certificate. 

The Oxford Dictionary defines censorship  as: 

the suppression or prohibition of any parts of books, films, news, etc. that are considered obscene, politically unacceptable, or a threat to security.

I would say that based on that definition this scenario does qualify as censorship but it would be allowed given the language I proposed because accommodates legal obligations.

The issue arises when the CAs get to apply subjectivity to this practice. As I stated in my earlier response if there are approaching 100 organizations with their own policies on what content they are OK with being on the internet how does that support Mozillas objective?

There is also the larger question of sustainability of accommodating such subjectivity also. I am proud to have known you now for around 20 years. I trust you and I believe as long as you are at DigiCert you would use your influence to make principled decisions even if it was uncomfortable to do so. 

But would a CA that issues a few thousand certificates a year do the same? Do they even understand the impact of their decisions sufficiently to adequately asses this question? 

I suppose that takes you to the earlier question that Kurt raised. Why does it matter if CAs censor?

Though we often forget this in the west the world is much larger than the English-speaking world. One reason that 2000 certificate issuing CA WebPKI exists is that the internet is a “global public resource” and that local CA is able to support users in that country in a way that the larger CAs are not able to do.

Then there is the question of what happens when Jeremy Rowley retires? Who are the individuals within  DigiCert that get to decide such cases? Will they apply the same critical thinking and principled approaches to this problem?

For me, this all comes back to what will it take for the Mozilla Root Program to support its organization's mission and do so in a consistent and sustainable way that is not dependent on goodwill, expertise, and blind faith.

Ryan Hurst

[Ryan Hurst]

Jeremy,

I wanted to respond to your other two comments.

[JR] That wasn’t proposed language. That was pointing out a flaw in saying “No censorship is allowed”.

To be clear, my proposed language did not say “no censorship is allowed”. Suggesting so would be what I think most would consider a straw man argument. What I did say, in essence, is that said censorship only when served the legal obligations of the CA or requirements of other root programs. 

This in essence says if a government says we want you to censor people here is the definition we want you to follow. If a root program wants you to censor here is the standard we want you to follow and Mozilla respects their right to do so.

Basically, there needs to be a clear standard so it is applied uniformly.

[JR] This is the crux of the issue. Appropriate vs. inappropriate censorship or what is a good definition of censorship? Is not wanting to issue to Dark Matter censorship after Mozilla booted them? What about sites that are espousing hate crimes? Although there’s nothing that says a CA needs to verify the contents of a site, there’s also nothing saying the CA can’t vet the content of a website. One of my big worries with the original DMCA was being a contributory infringer for copyright violation. If I refuse issuance to Warez sites, is that censorship? A definition would be good.

Let's take the topic of hate speech. As the agent of the user Mozilla provides a number of capabilities. This includes all the supporting technology and the associated ecosystem that enables it to authenticate domain names and provide TLS.

It also supports technologies to protect its users from content and malicious names, one example being its support for Safe Browsing (I think it might be called Phishing Protection now). If Mozilla wants those it delegates verification of domain control to also protect users from malicious or hateful content it should specify what standard to apply.

Absent that CAs should be put on notice that applying opaque and subjective “good censorship” is something to be considered when they evaluate if a CA should be a member of the root program.

Ryan Hurst

On Wednesday, March 1, 2023 at 8:36:25 PM UTC-8 Jeremy Rowley wrote:

[Moudrick M. Dadashov]

Kathleen, 

do the auditors that failed to notice surrogate (eIDAS/GDPR non-compliant) QESCs (Qualified electronic signature certificate)  fall under this definition?

Thanks,

M.D.

Sent from my Galaxy

-------- Original message --------

From: Kathleen Wilson <kwi...@mozilla.com>

Date: 3/2/23 02:46 (GMT+02:00)

To: dev-secur...@mozilla.org

Subject: Re: DRAFT: Root Inclusion Considerations

[Watson Ladd]

On Wed, Mar 1, 2023 at 9:57 PM Ryan Hurst <ryan....@gmail.com> wrote:
>
> Jeremy,
>
> I wanted to respond to your other two comments.
>
> [JR] That wasn’t proposed language. That was pointing out a flaw in saying “No censorship is allowed”.
>
> To be clear, my proposed language did not say “no censorship is allowed”. Suggesting so would be what I think most would consider a straw man argument. What I did say, in essence, is that said censorship only when served the legal obligations of the CA or requirements of other root programs.
>
> This in essence says if a government says we want you to censor people here is the definition we want you to follow. If a root program wants you to censor here is the standard we want you to follow and Mozilla respects their right to do so.
>
> Basically, there needs to be a clear standard so it is applied uniformly.

I'd like to suggest a more generalized approach to the issue. First
off we should require that the CPS cover in detail who the CA issues
for, and what will lead to non-issuance. That information is important
for evaluating the risk vs. reward of adding a CA. Secondly we should
say that content based restrictions are inappropriate vs. e.g. "we
only serve educational institutions", "we only serve *.ir domains",
etc.

Otherwise I think we'll end up debating the merits of a particular
decision endlessly vs. separating into the CPS and whether it was
followed.

The other point I want to raise is that if CAs broadly have limited
sets of issuance, we might be in a situation where some websites could
not transition in case of distrust. That would be problematic for the
health of the ecosystem, and is a reason we need to evaluate who CAs
will and will not serve.

Sincerely,
Watson

[Ryan Hurst]

I concur that censorship should be carried out transparently, with comprehensive policies documented in their CPS and any applications of that policy be published in a discoverable manner. For instance, when censorship is the reason for an order being rejected, detailed errors should be published, and possibly a CENSORED.TXT file could be published in a well-known location, similar to how SECURITY.TXT is used to identify security contacts.

I also believe that when a CA serves only a narrow or specific community, its CPS should explicitly state this. This raises questions about whether such entities should be included in the Mozilla root program, which is designed to serve the broader Mozilla community. However, that is a separate discussion.

Regardless of the outcome of this discussion, I think it is appropriate to document Mozilla's stance. This could involve adding text on Concerning Behavior, Recommending Best Practices, or updating the root program requirements themselves. Given the various gray areas that exist in this topic, It was my belief the non-binding nature of"Concerning Behavior" was appropriate which is why I mentioned it here. This is because my understanding is that this is a section of "considerations" not "prohibitions".

Ryan Hurst

[Kurt Seifried]

On Thu, Mar 2, 2023 at 5:49 PM Ryan Hurst <ryan....@gmail.com> wrote:

I concur that censorship should be carried out transparently, with comprehensive policies documented in their CPS and any applications of that policy be published in a discoverable manner. For instance, when censorship is the reason for an order being rejected, detailed errors should be published, and possibly a CENSORED.TXT file could be published in a well-known location, similar to how SECURITY.TXT is used to identify security contacts.

I feel like transparency is key here, but I would suggest instead of scattering these all over the web, shouldn't root CA's tell Mozilla what their issuing/censorship/etc policy(s) are and have it as part of their document set with Mozilla? And if it changes they should update Mozilla.

I feel like there is far too much "I got audited once, sure things change, maybe significantly (hey we bought a spyware company!), but I don't have to tell you. I just have to pass my next audit"

 

I also believe that when a CA serves only a narrow or specific community, its CPS should explicitly state this. This raises questions about whether such entities should be included in the Mozilla root program, which is designed to serve the broader Mozilla community. However, that is a separate discussion.

Has anyone taken the certificate transparency logs for root CA's and generated any stats? E.g. here's the ~140 root CA's, here's how many certs they issued for unique websites/code signing/email (we only have web data right?) in 2022, here's how many intermediate CA's they support, roughly how many certs they issued.

I'm reminded of the CVE program where roughly one quarter of the CVE Numbering Authorities that ever existed have done <10 CVE ID's in their entire existence and another quarter have done 10-50. Out of 242,000 CVEs assigned (reserved/rejected/public). 

Do we really need root CA's that only issue a handful of certificates? I suspect for some, especially those run by governments, it is "cheaper" to become a root CA (and pay for audits which can be justified) than an intermediate CA (where you also have to pay a root CA). 

 

Regardless of the outcome of this discussion, I think it is appropriate to document Mozilla's stance. This could involve adding text on Concerning Behavior, Recommending Best Practices, or updating the root program requirements themselves. Given the various gray areas that exist in this topic, It was my belief the non-binding nature of"Concerning Behavior" was appropriate which is why I mentioned it here. This is because my understanding is that this is a section of "considerations" not "prohibitions".

I feel like we need to shine a light on a lot of this. I've been into SSL/TLS for over 2 decades (https://it.slashdot.org/story/00/12/18/0759236/attacks-against-ssh-1-and-ssl was a good one, I miss the old days) and root CA's for over a decade (see list archives) and I can confidently say "I know barely anything and specific CA's? Less than barely anything".

 

Ryan Hurst

[Ryan Hurst]

Kurt,

As for why transparency information should be published in a place that is under the CAs control, there are arguments to be made for both ways but I believe that doing so would make it practical for real-time data, or near real-time data to be represented and would allow for the data to be machine readable which would enable the data to be used for analyzing the CAs. Mozilla already requires CAs to publish URLs to CRLs and other objects so it seems that this is consistent with that practice as well. With that said I would argue as Mozilla has made no statement on this topic it's too early to discuss implementation details though.

Regarding the question of if we need CAs that issue a few certificates, I do think that is a good question but I think it is outside the scope of the topic of this thread. I will say that I believe there are cases for local CAs and emerging CAs so this is not as cut and dry as some might think.

I also do not think that this thread is the right place to learn about the size, shape, and nature of the webPKI and it is most appropriate to stay focused on its topic, namely the concerning behavior, and possibly move the discussion to other efforts like Recommended Best practices or updating the root program requirements. That said here are a few resources that might help you understand the space better:

• CCADB.org aggregates a lot of useful data that helps one understand the size and shape of the WebPKI. There are also sites that index CT logs to provide useful information, you can learn more about Certificate Transparency and some of the projects that do use this information at certificate.transparency.dev. Censys is one of the most flexible and complete.
• CCADB.org also contains a list of all root and intermediate certificates. I do not have a count of certificates as I don't see much use in it as the security domains they operate in (aka the policies and practices of the organizations) is really the important thing. In many respects, more CAs are better as it suggests the possibility of many security domains in use (reduced surface area).
• One that is not listed as a monitor that used to be a great reliable resource is Merkle.Town, which has a few issues right now and I believe they will be fixed but it is still useful. In particular, it is interesting to know that the WebPKI currently operates at about 71 certificates per second and certificates expire at about 66 certificates per second.
• I also use both CT and CCADB data to produce a quick market analysis Google Sheets. It helps me keep an eye on how the CA market is changing. I also published a blog post with the methodology I use. As I am referring to this earlier I mentioned the number of CAs off the top of my head I tried to generalize it (approaching 100) the actual number is around 85 based on the Microsoft Root Program as per the related CCADB.org dataset.

If you have more questions on the size, nature, and monitoring of the ecosystem I think it would be best to start a new thread. 

With that said I would say there the WebPKI is more transparent than it has ever been for those that care to look. That is why I wanted to call out this one area where there is clearly a lack of transparency on a practice that is in use today that is clearly not aligned with Mozillas mission, which the Mozilla root program should be squarely supporting via its requirements and guidance to participants in this ecosystem.

Ryan

[Cristian Garabet]

Hello all!

I am speaking in behalf of certSIGN. Regarding the bullet "The CA has physical, monetary, or business nexus to a government of a country that[...] has a score less than 50 on the Corruption Perceptions Index", is correct our understanding that this bullet touches on any company that has a branch in a country that has a score less than 50 on the CPI? For example, all global big tech companies have branches in Romania (R&D, Support, Call Center, Sales etc). Our opinion is that if a CA is in this situation, but it proves to implement anti-corruption mechanisms, for example is ISO37001 certified, this criterion should not be applicable in this case. 

Cristian

[Kathleen Wilson]

I have updated the 4th bullet point in

https://wiki.mozilla.org/CA/Root_Inclusion_Considerations#Concerning_Behavior

to say:

The CA's representative is unable to demonstrate that the CA has implemented anti-corruption mechanisms (e.g. ISO 37001 certification) and the CA has physical, monetary, or business nexus to a government of a country that

• has an Internet Freedom Score less than 50; or

• has a score less than 50 on the Corruption Perceptions Index

And I have removed the "{{draft}}" notice from the page, because I believe this page is ready to be put into use.

Of course, I will always appreciate thoughtful and constructive feedback on this page and our other wiki pages.

Thanks,

Kathleen

 

[Moudrick M. Dadashov]

Not only "business nexus to a country..." but also to CA's problematic shareholders.

Thanks,

M.D.

Sent from my Galaxy

-------- Original message --------

From: Kathleen Wilson <kwi...@mozilla.com>

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/e15b213c-cb1f-4423-acce-444e48bba88bn%40mozilla.org.

[Prof. Reardon]

Hello all:

I want add my support for these inclusion considerations, these are excellent.

I had some thoughts about the auditors aspect. Perhaps one of the warning signs
or troubling behaviour could be not rotating auditors. Granted that having the
same group repeatedly visit will probably result in better audits over time, and
in some jurisdictions there may not be a wealth of eligible auditors, it may

still be worth spelling out that, where possible, not rotating after 5/10 years

is considered a warning sign / troubling behaviour.

Another thing that may be worth including as a troubling behaviour would be
using an auditor that is not professionally licensed as an auditor in the
jurisdiction. This may seem bizarre to spell out but it is the case that Webtrust
had such an auditor on their list of approved practitioners. When I informed
Webtrust about this, the auditor was unceremoniously removed as a practitioner
soon after and when I received a reply there was no explanation as to why the
auditor was removed. That is, I do not know if it was a result of my disclosure
or the timing was a coincidence, e.g., the auditor left voluntarily or its

membership expired. I was also not given an answer to whether being a

professionally licensed auditor is a requirement for Webtrust---but it can be

made a requirement for Mozilla CAs. If it is a requirement for Webtrust,

there is evidence that it is not enforced, because the auditor did audit a

CA's operations under the auspices of Webtrust during the time which

it was not a licensed auditing firm.

Joel