Email requirements to speak on behalf of a CA on the list

[Kurt Seifried]

I think at a bare minimum we need to start requiring CA's to use their work email addresses and not throw-away Gmail addresses when talking on behalf of the CA.  Otherwise, we'll have random @gmail.com addresses joining the list and claiming to be the CA and potentially causing problems. 

Does anyone object to this?

--

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

[Ben Wilson]

All,

Besides this, I think there might be a misunderstanding with some people that they have to use a Gmail account for the list because it is hosted using Google Groups.

I hope we can get the word out that any email address should be able to subscribe to this list.

Ben

[Kurt Seifried]

On Wed, Dec 14, 2022 at 9:34 AM Ben Wilson <bwi...@mozilla.com> wrote:

All,

Besides this, I think there might be a misunderstanding with some people that they have to use a Gmail account for the list because it is hosted using Google Groups.

I hope we can get the word out that any email address should be able to subscribe to this list.

Ben

One thing that might help:

1) Any email can join a google group and get/send emails to the group

2) If you want to use the google group for calendar invites/sharing docs/etc, then accounts on the group need to either be google hosted, or enabled (https://accounts.google.com/, "create account", "Use my current email address instead"), there is, as far as I know, no calendar/document sharing/etc happening through this list, ergo it's not needed and any email account can be used.

I don't know if telling people #2 will help or muddy the waters but I think it would make sense to implement a policy of "you must use your work account to signup for the list if you are here as a representative of your company, especially if it's a CA asking for inclusion.

Again is there any objection to this from anyone?

 

On Tuesday, December 13, 2022 at 12:11:21 PM UTC-7 ku...@seifried.org wrote:

I think at a bare minimum we need to start requiring CA's to use their work email addresses and not throw-away Gmail addresses when talking on behalf of the CA.  Otherwise, we'll have random @gmail.com addresses joining the list and claiming to be the CA and potentially causing problems. 

Does anyone object to this?

--

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

[Amir Omidi (aaomidi)]

Full disclosure - I'm an engineer on Google Trust Services. This email is on my personal capacity.

I'm not a huge fan of changing/adding policies due to just a few examples. Participating in mailing lists is difficult to begin with, having email requirements might make it more complicated to participate in these discussions even with the aforementioned clarifications. I don't believe we've seen this problem often enough to warrant a change.

Cheers!

Amir (he/them)

[Kurt Seifried]

On Wed, Dec 14, 2022 at 1:21 PM Amir Omidi (aaomidi) <am...@aaomidi.com> wrote:

Full disclosure - I'm an engineer on Google Trust Services. This email is on my personal capacity.

I'm not a huge fan of changing/adding policies due to just a few examples. Participating in mailing lists is difficult to begin with, having email requirements might make it more complicated to participate in these discussions even with the aforementioned clarifications. I don't believe we've seen this problem often enough to warrant a change.

Can you clarify what the difficulties are? 

 

Cheers!

Amir (he/them)

[Matthew Hardeman]

I have an altogether different opinion on this matter.

This is, ostensibly, a place in which information security professionals and other interested parties communicate.

To the extent that the apparent source email address of a message published in a Google Group causes you to accord more deference or strength of attribution related to that communication, why is that?

There are certainly mechanisms for verifying that a statement made in a public group can be confirmed or denied by the relevant person or organization, and these mostly involve communication in the reverse direction - reaching out to known / published / indexed points of contact for verification of the questioned message.

Why would security professionals even implicitly advance the notion or practice of utilizing "sender email address/envelope address/from address" on a received communication as a basis for forming an opinion on the actual sender or their affiliations?

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa3_RS3EC1%2BMHTwJsQtxNSb3UOPam2No%2Bp1mL5xNV_g%3DuqA%40mail.gmail.com.

[Kurt Seifried]

On Wed, Dec 14, 2022 at 1:52 PM Matthew Hardeman <mhar...@gmail.com> wrote:

I have an altogether different opinion on this matter.

This is, ostensibly, a place in which information security professionals and other interested parties communicate.

To the extent that the apparent source email address of a message published in a Google Group causes you to accord more deference or strength of attribution related to that communication, why is that?

There are certainly mechanisms for verifying that a statement made in a public group can be confirmed or denied by the relevant person or organization, and these mostly involve communication in the reverse direction - reaching out to known / published / indexed points of contact for verification of the questioned message.

Why would security professionals even implicitly advance the notion or practice of utilizing "sender email address/envelope address/from address" on a received communication as a basis for forming an opinion on the actual sender or their affiliations?

Because hopefully Google is bouncing bad SPF/DKIM emails from the lists and people are using email addresses with domains that have SPF/DKIM/DMARC setup.

Are we saying the alternative is to give up and just allow anonymous throwaway email addresses with no verification at all?

Aren't CA's supposed to be able to demonstrate that they are trustworthy?

 

On Tue, Dec 13, 2022 at 1:11 PM 'Kurt Seifried' via public <pub...@ccadb.org> wrote:

I think at a bare minimum we need to start requiring CA's to use their work email addresses and not throw-away Gmail addresses when talking on behalf of the CA.  Otherwise, we'll have random @gmail.com addresses joining the list and claiming to be the CA and potentially causing problems. 

Does anyone object to this?

--

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

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa3_RS3EC1%2BMHTwJsQtxNSb3UOPam2No%2Bp1mL5xNV_g%3DuqA%40mail.gmail.com.

[notthep...@whitehouse.gov]

I don't know what you mean Matthew. My sender email is obviously legitimate! Surely no one would do sender spoofing in email...

[Kurt Seifried]

In this case it's pretty obvious that Google is misconfigured. 

Can someone please describe a good reason to NOT require their work email address? 

On Wed, Dec 14, 2022 at 2:35 PM <notthep...@whitehouse.gov> wrote:

I don't know what you mean Matthew. My sender email is obviously legitimate! Surely no one would do sender spoofing in email...

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/20221214213205.14E42304020D%40server.germancoding.com.

[Kurt Seifried]

Oh and also it does show the details if you click show original:

SPF:	FAIL with IP 209.85.220.69 Learn more
DKIM:	'PASS' with domain ccadb-org.20210112.gappssmtp.com Learn more
DMARC:	'FAIL' Learn more

But why it's letting failed SPF in is beyond me.

On Wed, Dec 14, 2022 at 2:35 PM <notthep...@whitehouse.gov> wrote:

I don't know what you mean Matthew. My sender email is obviously legitimate! Surely no one would do sender spoofing in email...

--
You received this message because you are subscribed to the Google Groups "public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/20221214213205.14E42304020D%40server.germancoding.com.

[Matthew Hardeman]

I wonder, Mr. NotThePresident, as you clearly hail from the WhiteHouse, if you can assist me with reaching out to someone with whom I can discuss the Federal PKI as regards a confidential matter?

[Matthew Hardeman]

Because the state of email administration is garbage and they want things to work for users who have no agency or control over that brokenness, a rather pragmatic position.

But never actually trust it without verifying.

[Kurt Seifried]

On Wed, Dec 14, 2022 at 3:08 PM Ryan Hurst <ryan....@gmail.com> wrote:

Full disclosure - I also Google Trust Services. This email is in my personal capacity.

There are a few reasons I personally think it's not a useful change, some of which include:

1. Reliance on the "work email" domain to signal the author is authorized to speak on behalf of the organization would be problematic. Maybe it is the janitor and not someone in an administrative or technical role associated with the CA.

2. If one was to make this a requirement it seems it would be natural to go even further and say the address should be under the domain used for CAA, which of course does not work in many cases, which then limits the value (see #1).

3. There are people who work in a CA that are in fact affiliated with the operations of the associated CA but are neither authorized to speak on the behalf of the organization nor have the context to effectively answer questions on behalf of the CA.

4. The root programs would not take action against a CA on the basis of an email or email address alone and have registered contacts that they engage with for administrative issues and questions and this could not replace this.

5. The people representing a CA change over time and anchoring on individuals rather than an organization is problematic as a result.

6. This forum is most useful when it is a place where anyone can come and answer questions even if not associated with a CA, or if they are associated with a CA and seeking clarifications on ambiguity.

I agree. There should be strong identity and authorization requirements. These are people that are ultimately being trusted GLOBALLY by billions of people.

What's fascinating to me is that to get a BIMI logo for email there are much more stringent identity verification requirements than for the root CA's getting into the root CA program. 

E.g. BIMI: https://bimigroup.org/resources/VMC_Requirements_latest.pdf

I've actually done this process, it's actually really easy if you're operating properly, e.g. trademark registered, have someone sufficiently empowered do the process (e.g. a C level exec) or they authorize someone lower (e.g. me), the C level or myself goes to a public notary choosen by the BIMI provider to sign the docs, and the notary sends it in (I've been through the process). So there is strong proof that

1) the company signing up for BIMI has the legal right to the trademark

2) the person applying is authorized on behalf of the company

3) the person applying is actually the person applying

4) a trusted third party (a public notary) is used to reduce the chances of shenanigans (e.g. signing paperwork, notarizing it, the notary sends it in so there's less chance for me to go alter the paper work and then send it in)

Looking at the root CA requirement there is nothing here, in fact:

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

the word "identity" only occurs once, and there's no mention of validating the identity or authorization of the people involved in the process. Quit the opposite, I see several people in the community arguing in favour of throw away Gmail addresses.

 

It does seem reasonable to expect people to disclose affiliations and make it clear if they are speaking on behalf of their organizations though.

Agreed, it would also be a good idea for them to also prove they work for those organizations that they claim to represent (easily done via email if you have SPF/DKIM/DMARC setup, and these are CA's, they should be able to do security, right?), and are authorized to do so (ideally they should have some public reference that makes it clear that they're not just some random intern or the janitor).

 

Ryan Hurst

[Matthew Hardeman]

I again reiterate my opinion -- an opinion which I believe is broadly shared in the infosec community -- that email and email based processes should never be presented to users as trustworthy as to confidentiality or as to integrity, with the possible exception of some entirely intra-organization endorsed mechanisms.

The mere normalization of according trust in a communication indexed upon an email address is the very kind of implicit experiential training that leads to the category of attacks known as business email compromise.

I believe that every attempt to make incremental but non-universal improvements to such schemes is merely training users toward bad practice.

[Kurt Seifried]

Fair enough, then what do you suggest we do to improve the security of this process and actually ensure that e.g. ran...@gmail.com is indeed SERPRO or BJCA.cn? 

[Matthew Hardeman]

There are at least two easily available mechanisms to ensure this:

1.  As active participants in the discussion, one should presume that representatives of a given CA are actively watching discussions which involve them and that they themselves would call attention to any unauthorized statements purported to have been made by them.

2.  In the presence of extraordinary claims at any point, one could always reach out to their official contact points to confirm the legitimacy and content of assertions made in their name.  In addition, at the end of the discussion, it's perfectly reasonable to send a summary to the official contact points for confirmation.

[Kurt Seifried]

On Thu, Dec 15, 2022 at 12:36 PM Matthew Hardeman <mhar...@gmail.com> wrote:

There are at least two easily available mechanisms to ensure this:

1.  As active participants in the discussion, one should presume that representatives of a given CA are actively watching discussions which involve them and that they themselves would call attention to any unauthorized statements purported to have been made by them.

That's a dangerous presumption to make.

It looks like 6% of the email addresses listed at https://ccadb-public.secure.force.com/ccadb/AllProblemReportingMechanismsReport are broken.

Can we confirm that all 100+ CA's are on this mailing list? 

 

2.  In the presence of extraordinary claims at any point, one could always reach out to their official contact points to confirm the legitimacy and content of assertions made in their name.  In addition, at the end of the discussion, it's perfectly reasonable to send a summary to the official contact points for confirmation.

That would be fine if they had working reporting mechanisms. Many have broken email, and at least one put the wrong data in:

5463283B6793FF55277CEDE39098E80422F912F7 Certicámara

So you're assuming they'll all be actively listening to this list, AND that they all have valid reporting mechanisms. Well 1 proovably has no mechanism listed and many have non working email addresses listed. 

And we have no proof that any are on the list and listening in large numbers, so unless you can show proof of this I don't think it's a valid claim to make (aka I have a teapot near Neptune). 

Ben Wilson: can you confirm that ALL the root CA's are on this list? Barring that can you tell us the total number of subscribers?

 

On Thursday, December 15, 2022 at 12:19:22 PM UTC-6 ku...@seifried.org wrote:

Fair enough, then what do you suggest we do to improve the security of this process and actually ensure that e.g. ran...@gmail.com is indeed SERPRO or BJCA.cn? 

[Kurt Seifried]

Ah one bit of good news, at least one of the emails that probed as bad actually seem to work when sent an email, so hopefully the list of broken emails is actually 0 and they just have overly aggressive SMTP blocking/greylisting or something.