[Cscwg-public] Final Minutes of CSCWG meeting Feb 25, 2021

Thu Mar 25 16:52:17 UTC 2021

Final Minutes of CSCWG meeting Feb 25, 2021

1.	Attendees: Dean Coclin, Daniela Hood, Atsushi Inaba, Bruce Morton, Corey Bonnell, Dimitris Zacharopoulos, Ian McMillan, Inigo Barreira, Karthik Ramasamy, Mario Vukson (Guest Speaker), Mike Reilly, Sebastian Schulz, Tim Crawford, Tim Hollebeek, Tomas Gustavsson
2.	Minute taker: Daniela Hood
3.	AntiTrust statement was read by Dean
4.	Minutes from prior call: Bruce sent the minutes the day prior the meeting. Nobody had comments or corrections. The minutes for February 11th, 2021 meeting were approved and will be sent to public list.
5.	Guest-Speaker Introduction by Ian: Mario Vukson is the Co-Founder and CEO ReversingLabs. His company and his partner, Co-Founder Tomislav Pericin, have spent a lot of time looking into and researching about Code Signing, even blogging about how CAs have been abused and victimized by attackers, as well as how subscribers to Code Signing certificates have been abused. He was invited to the meeting to present his company and what they do, and talk on how his company could help our group on making the information sharing among CAs thrive, and injecting threat data on how attacks are leveraging Code Signing Certificates in abusive ways.
6.	Guest-Speaker Presentation by Mario Vukson: ReversingLabs has been founded for about 12 years, and historically has been positioned on the blue zone of response of attacks and helping security centers on profiling and understanding threats. 

The company has vast resources for vulnerability researchers, software risk and SOC teams, to understand file threat reputation. They are the largest serving of global repository with information in goodware and malware. 

This is important to assist security companies in assuring the quality of their products and to assist enterprise companies with tools to assess trustworthiness of content. The company’s focus is in any software that can be installed, patched, and updated, and providing a deep analysis of malicious components that could have been introduced but that allegedly has a valid signature. 

Within this process they have built a unique cross platform, that works for any system and understands and profile the applications for their malicious content, while extracting complex data. ReverseLabs has a set of services and feeds, that helps customer to understand malformation, proper validation, and the use of digital certificates applied to software. 

The company also pulls indicators form their database to help threat hunters in complex searches, that utilize different keywords but that is focused on proper parsing and sorting of the data to identify profile signers, and verify, the validity of the application, the certificate status applied to the product and flag any different, unintentional or deliberate downgrading of crypto, in order to provide a historical behavior view of these certificates. 

As they evaluate the characteristics of the certificate, some of their APIs could be interesting to identify fraudulent issuance attempts.

Ian mentioned that it would be interesting to understand the malicious application and the certificate that was used in signing it, and what was the fact that caused the issue. E.g. private key being stolen, takeover, was the attacker in possession of the private key or was there an exploitation of the signing schema itself. He also mentioned the cases for Authenticode and the peak off binaries exploited and SolarWinds takeover. The goal is to help the CA community in its totality to have access to any cases of abuse, from big corporations to small business, in a way that it can be consistently shared and communicated across the group.

Mario replied that the problem could be solved with automation, as ReverseLabs processes 8 million unique files daily, and although not all are digitally signed, there could be created an alerting system that would go off whenever there is malware applied to a certificate, prompting an investigation or revocation of the certificate, or even be an indicator that the company should switch from a regular to EV certificate as their risk profile is higher. 

They also track broken signing attacks, where people impersonate companies that they believe the end user will likely trust, which could also be an indicative that the organization needs to strengthen their certificate.

He also mentioned that is possible to have an early alert for when an organization attempts and fails a certificate request, or if they get the certificate and use to sign malware and trying to repeat the same process with a different vendor. In this case the organization would be notified that their risk level needs to be increased.

Ian then mentioned about the High-Risk Applicants and the possibility to enable the CA collective, to have any customer that choose to identify themselves as high risk and be treat accordingly. And he questioned if it is feasible and if the data share APIs could do something alike. 

Mario started by mentioning that the data of signed software is discoverable, and information such as who has a certificate, have they signed anything with the certificate, and what kind of software they are signing. It is possible to do it so per platform, and type and verify the validity of the signature, if it was done by mistake, or if they deliberately sabotaged the process; and the information can be retrieved using automation. He also mentioned that the process would facilitate recognizing valid applications of smaller, not well-known organizations.

Inigo questioned Mario if he was familiar with the CAA process for SSL certificates, and how in this process customers can flag which CA they want to issue their certificates. He also mentioned that for Code Signing it would be great if companies could have access to data sharing API, in a way that they could set themselves to be notified if a file or a signature it is impersonating the company. He then proceeded to ask Mario if such is feasible with what ReverseLabs is doing at the moment.

Mario mentioned that it could be done in scale as they process millions of new files daily, and have a portfolio of 20 billion unique files, in which 1 billion of those are digitally signed files. Specially because they have a lot of different information other than the reputation of the certs. Mentioning that it would be totally feasible, and that the company would be excited to work with that, as they feel strong about certificates being a way to fortify systems and avoid abuse.

At the end of the presentation it was decided that Mario and his partner would be back on March 11th to provide more content.

Mario dropped after the presentation.

7.	OCSP and Time Stamping: After looking into the requirements Ian got to the conclusion that he would like to discuss the possibility of removing OCSP for time stamping first and then Code Signing. His reasoning was that the 135 month max for a time stamping certificate is beyond of what they would like to see for any key pair, and although he was taking in account that the requirements require a key rotation at least every 15 months, and when it comes to their platform it does not look at the validity period when it comes to the time stamping certificate, but he questioned if the signature truly expires, answering that it actually does not. 

He then mentioned that all the certs Microsoft issues for its products, the certificates are typically 12 or 15 months valid. He also mentioned that Microsoft does not use OCSP and that is done purposefully, as to not carry OCSP responses specially ones with SHA1. He proceeded to explain that in terms of the time stamping responder with SHA1 TSAs, they do not intent to carry OCSP responses as they wanted that deprecated long ago. When issuing a Time Stamping certificate, the same will carry 11 ¼ years with the 135-month max validity, and once that expires the OCSP response has to retained for 10 years. Bruce and Dimitris both questioned why they will need to keep going with the OCSP for 10 years. Ian explained that the way they interpreted the CSBR, OCSP responses must be carry on 10 years post the expiring of the certificate. Both, Bruce and Dimitris, mentioned that they believed this was only applied for Code Signing Certificates. Tim Hollebeek mentioned that was the reason TSAs are longer, to outlive the code signing by 10 years. Ian commented that he understands but the way the CSBR is written it does not imply that, and that this issue was brought up before. Tim H. commented that the requirements around this area are badly written and do not translate what the group wants. He agrees with Ian that Time Stamping Certificate lifetime should be only the time that the Time Stamping Service is active and that the certificate should not live on for another 10 years. Ian mentioned that OCSP is not needed for time stamping and don’t need a 11 ¼ certificate when the key only lives for 15 months. He suggested to limit on the requirement for code signing certificates and keys a max validity period of 15 months, as it works well for the certificate consumer and their platform. Corey asked if OCSP delegated responder would be considered where no response is required or would be CRL based? And if that would only be for the validity period of the time stamping certificate. Ian answered that it would be CRL based and it would only be valid through the validity period of the certificate with no obligation post expiration. Karthik asked if that rule applies even if the private key live in HSM and the private key is rotated every 15 months. Ian responded with a yes. Dimitris mentioned that limiting Time Stamping to 15 months would require a different treatment, as most CAs use an offline system for their Time Stamping Issuing CA. It was also discussed the conflict that Time Stamping would create when used in other platforms, and how code signing certificates can be abused and there is no assurance of time alignment or private key security as these platforms would not be auditing this certificates against the CSBRs. To solve the issued it was suggested the creation of a Policy OID, that would clarify that the certificate complies with CSBR to distinguish code signing time stamping from doc signing time stamping or any other time stamping. After further discussion on the time stamping value, and changing the max validity period, it was decided to start with a change that would make OCSP optional but nor forbid it, with changing the language on the CSBR to “Shall be CRL and may not be OCSP”. Ian will work on a ballot based on this discussion

8.	Intel: Intel provided an IPR agreement to join the CS group, however before members are able to give an opinion about it, the full application was requested.
9.	Key Protection and Tokens: A concern with section 16.3.6 was brought up as the section leads to the understanding that it is possible to substitute of a full FIPS certification, by demonstrating an operating environment equivalent to FIPS level. Dimitris mentioned that his concerned with the risk of the requirement and the difficulty to audit if the same has been followed.  Tim H. mentioned that the biggest issue with this subject is that the language is not finished and so it is difficult on direct people on how they comply to the key protection bit. Ian clarified that would be the FIPs 140-2 level 2, ILA 4+ common criteria, which does not make sense without the protection profile, and that they are specifying the protection profile that was chosen. It was proposed to divide the issue in 2 stages 1- the implementation of ILA 4+ now, 2- follow up with the protection profile. While drafting the ballot the format of 16.3 will be fixed. It was agreed that two separate ballots should be created 1- key protection and 2- time stamping, and those ballots should be against the version that is in IPR.
10.	F2F: Meeting was set to be half an hour, with a presentation of Bruce that would look through the e-mail from last month of topics of interest, make a small agenda for our working group on Tuesday.
11.	Next Meeting: F2F Tuesday, March 2nd. Followed by our regular meetings back on March 11th.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210325/70a5a766/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/20210325/70a5a766/attachment-0001.p7s>