[Cscwg-public] Final F2F CSCWG minutes

Thu Apr 6 16:25:37 UTC 2023

Final F2F Minutes February 28, 2023

Attendees: Enrico Entschew (D-Trust), Ben Dewberry (Keyfactor), Alison Titus (Entrust), Tadahiko Ito (SECOM Trust Systems), Lisa Marie Barlow (Entrust), Brianca Martin (Amazon), Vijay Kumar (eMudhra), Chris Kemmerer (SSL.com), Nikolaos Soumelidis (QMSCERT/ACAB-C), Thomas Zermeno (SSL.com), Corey Bonnell (DigiCert), Marcelo Silva (Visa), Aaron Poulsen (Amazon), Janet Hines (VikingCloud), Matthias Wiedenhorst (ACAB/C), George Fergadis (HARICA), Christophe Bonjean (GlobalSign), Eva Van Steenberge (GlobalSign), Nargin Mannan (VikingCloud), Rebecca Kelley (Apple), Martijn Katerbarg (Sectigo), Rob Stradling (Sectigo), Brittany Randall (GoDaddy), Clemens Wanko (ACAB/C), Ilona Jones (Entrust), Inigo Barreira (Sectigo), Dimitris Zacharopoulos (HARICAO), J.P. Hamilton (Cisco), Ben Wilson (Mozilla), Daryn Wright (GoDaddy), Bruce Morton (Entrust), Ian McMillan (Microsoft), Nick France (Sectigo), Paul van Brouwershaven (Entrust), Elaine Bronsther (Sectigo), Ellie Lu (TrustAsia Technologies), Atsushi Inaba (GlobalSign), Adam Jones (Microsoft), Trevoli Ponds-White (Amazon), Dough Beattie (GlobalSign)

1.	Assign Minute taker (start recording)

a.	Martijn is taking minutes

2.	Antitrust Statement

a.	Bruce read the antitrust statement

3.	Agenda

a.	Don added a question on the interrelationship between Code Signing and NetSec:

                                                               i.      Don: We didn’t see any clear reference in the CSCBRs to the Network Security requirements and has asked to add the same language as the SMBR and BRs use.  Bruce stated that will be addressed.

4.	Approval of prior meeting minutes

a.	January 26th minutes are not yet available.
b.	February 9th minutes are approved.

5.	Ballot Status

a.	Malware ballot: Looking to redraft and expand to the complete revocation section. Set to have a draft ready by the March 23rd meeting.
b.	Signing Service ballot: To be change to Subscriber Key Protection Service. No progress on this yet since the last call. Tim has gone through and added comments which we need to work through.
c.	Remove BR References ballot: Dimitris has added more items after feedback over the last two meetings. We will need to discuss on which bits we need to import for certain sections.
There was a discussion on why we currently reference a specific BR version, yet “the latest” Network Security requirements. 

6.	Code Signing Ecosystem Status

a.	Microsoft to provide Code Signing ecosystem issues from Root program, Windows and Azure perspective

                                                               i.      Ian gave a presentation on the challenges in Code Signing. 

                                                             ii.      A question was raised on the subject of State Threat Actors: Is there an estimate on the percentage of signed malware from state actors?

1.	Ian: We don’t have a clear estimate on that in terms of a percentage, but expect it is a small percentage

                                                           iii.      Leo raises the issue of customers still being hesitant on using signing services and wanting to keep using the certificate using “the old fashioned” way. It’s a heavy lift to get people to change their mindset.

1.	Ian: We do contribute to open source projects that enable and offer easier use of signing services.

                                                           iv.      Trevoli: For developers, certificates and keys is something they want to spend as little time as possible on. As such they will keep resisting changes unless it leads to both less time spent and more security.

                                                             v.      Dimitris: I’d like to know what Ian’s visions are in regards to Certificate Transparency.

1.	Ian: There’s a big opportunity to solving the CA hopping by malicious actors due the identities listed in CT. CAs and other parties can perform further investigations before issuing a certificate.
2.	The point is raised that this is not a proactive method, but it would help by “burning” a malicious actor’s identity which they may have built up over a longer period of time.

b.	CAs to contribute problem issues based on whatever including incidents, implementation, clarification, audit perspective

                                                               i.      Bruce raised the issue of “High Risk” language in the CSCBRs. There appears to be no common thing between CAs on how it should be done. It’s pointed out that the High Risk region section is also empty.

                                                             ii.      Dimitris: Maybe as a group we should agree on which sources for company registrations we should be using. By this we could set which sources are considered good, and have all CAs share the same base.  

1.	Bruce: The problem there may be that there could only be one source for a specific region. Maybe the source is not that good, but if it is the only one, there is no alternative.
2.	Chris added that maybe in those cases we should look at requesting more details such as having a bank account.
3.	Ian states that malicious actors will wait 3 years or more before purchasing the certificates, just to have their company registration build up a status. They’re willing to play the long game.

                                                           iii.      Dimitris: I believe CT is the wrong tool to lower the amount of signed malware. Microsoft could play a key role into this however. MS is already consuming all those certificates and knows when malicious code has been signed. If there’s a way to communicate that to CAs, that also removes any legal issues CA’s might have because it will be the Certificate Consumer for which we have a contract with. Chris seconds this.

1.	Ian agrees, but cannot currently give any details on what the root program will and can legally do about this.

b.	Whiteboard ideas and approaches which could be implemented to address discuss issues

                                                               i.      Shorter maximum certificate validity period

1.	Leo raises the question about if very short validity periods are offered, such as just 1 day, would there be an option to soften the requirement on using FIPS devices?

a.	Ian stated that no, that would not be an option is his opinion.

                                                             ii.      Certificate Transparency

                                                           iii.      Stop constant reports of suspect code

1.	Corey raises that historically there have also been reports of suspect code that were used, weaponized, against companies in order to have a certificate revoked. It is hard for CAs to determine when something is suspect code or not.
2.	Bruce suggests maybe CAs should use something like Virustotal by adding software there and see the outcome
3.	Martijn adds that even that is not waterproof as it does have false positives and varies from hour to hour. CA’s are not malware specialists. If even the experts have false positives, how are we supposed to have it 100% correct.
4.	Eva adds that they also run into the same issues. However sometimes it seems like this is more about a Subscriber and investigating them or get in touch with them. Several times when we’ve done a revocation, malicious actors will ask us why we revoked, instead of asking what has happened. It seems actors are trying to figure out how we detected them.

                                                           iv.      Post suspect code in the same repository

                                                             v.      CAA

                                                           vi.      Verification escalation to EV or F2F

1.	Bruce brings up the possibility of adding F2F checks or more EV like validation for all certificates in order to reduce the amount of malware signed.
2.	Martijn adds that, how much do we expect this to help if threat actors are willing to wait 3-5 years. Potentially it’s part of several improvements that all together make it harder. There doesn’t appear to be one single solution.
3.	Corey adds a notion of requiring something like a notary public, however that would also increase the burden on any legitimate company.
4.	Ian: Maybe we should be looking ad Identity verification solutions, such as TrueID.
5.	Corey: That would also add to automation of identity checking.

                                                          vii.      Simplify EV verification

1.	Ian: The CSCBRs currently have a requirement for a second reviewer for EV certificates. This struck me as an option to exploit corruption. Automation instead would be a much more safe practice.
2.	Bruce: Should we be using more automation such as LEIs for vetting? I think EV probably needs to be more streamlined as a lot of the language is probably about 15 years old by now, and very much built on a legal framework.
3.	Trevoli: I don’t think the issue is perse how many people are involved, but more about how could we be using tooling.

6.	Other Items

a.	Bruce was asked to give a presentation on the CA/B Forum Code Signing WG in Toronto. Does anyone have any objections to this? (There are none).
b.	Chris: Question for Ian, is there any estimate on the size of the malware community?

                                                               i.      Ian: Recently through data from Reversing Labs, we’ve seen about 20K code signing certificates used in malware. That’s less than 1 percent of all code signing certificate, but still a large number. 

8.	Next Meeting

a.	March 9th, 2023.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230406/a57219ba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230406/a57219ba/attachment-0001.p7s>