[Cscwg-public] Minutes of F2F CSCWG February 24, 2022

[Dean Coclin]

Code Signing Working Group

Speaker: Bruce Morton 
Minute Taker: Corey Bonnell 

Member attendees: Andrea Holland (SecureTrust), Bruce Morton (Entrust),
Chris Kemmerer (SSL.com), Corey Bonnell (Digicert), Dean Coclin (Digicert),
Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Eva
Vansteenberge (GlobalSign), Inaba Atsushi (GlobalSign), Joanna Fox (TrustCor
Systems), Jos Purvis (Cisco Systems), Karina Sirota (Microsoft), Leo Grove
(SSL.com), Li-Chun Chen (Chunghwa Telecom), Martijn Katerbarg (Sectigo),
Nick France (Sectigo), Rich Smith (Digicert), Stephen Davidson (Digicert),
Tim Callan (Sectigo), Tim Crawford (CPA Canada/WebTrust), Tim Hollebeek
(Digicert), Tsung-Min Kuo (Chunghwa Telecom), Yamian Quintero (Microsoft) 

Non-member attendees: Branca Martin (Amazon), Georgy Sebastian (Amazon),
Mike Agenius Kushner (Interested Party), Tadahiko Ito (SECOM), Yoshiro
Yoneya (JPRS) 

Dean read the antitrust statement. 

Minutes for the January 27th and February 10th minutes were approved. 

Bruce presented the Goals presentation (attached). 

Signing Service Discussion 

Bruce suggested we should identify high-level goals before making any
changes to the CSBR document. He also suggested that if the Signing Service
is not performing a RA function, then it should not be considered to be a
DTP. Ian agreed. 

Ian mentioned that another primary goal of defining Signing Service
requirements is to define parameters around access control. 

Ian suggested that another goal is to define requirements around
timestamping. Bruce said that he views providing timestamping services as CA
responsibility but not the Signing Service. Ian agreed that it is more
secure for CAs to host TSA as opposed to third parties. 

Bruce said that the primary goal of a Signing Service is to mitigate against
key compromise. Dean suggested that it also opens the possibility for using
ephemeral keys (one certificate/key per signing operation). Ian agreed. 

Dimitris added that for "providing code signing signature", we discussed two
models. Either the hash is sent, or the full document (binary) is sent.
Also, for timestamping, Dimitris noted that the TSA must be audited in all
cases. Nick added that Microsoft clarified privately that TSAs must be
audited. Tim mentioned that we now require CABF policy OIDs in timestamp
certs for code signing, so Relying Party software knows whether a given TSA
certificate is being audited for use in the code signing ecosystem. 

On the bullet point "Not a Subscriber", Ian agreed that the Signing Service
is not the identity; the Signing Service is not the software publisher.
Bruce raised Dimitris's previous point about whether the Signing Service
receives just the hash or the full binary from the Subscriber for signing
and said that the Signing Service should not have to take on the
responsibility for scanning for malware. Ian agreed. Dimitris added that the
CSBRs currently require notification to the CA if Suspect Code is found. He
also added that it would be an improvement if we define requirements around
scanning for Suspect Code. Tim said that it may be challenging to define
explicit requirements in this area to achieve the security goals. 

Ian brought up the current requirement for Signing Services to being running
antivirus software. He said that it would be an improvement for the
requirements to state that the Signing Service must be hardened. 

Ian said that service availability should not be covered under the
requirements. Dean added that is a product feature and thus out of scope for
this working group. 

Bruce said that currently there are requirements for Signing Services but
none for Cloud Services. However, it is difficult to differentiate between
the two services. Bruce added that to clarify, the Signing Service could be
operated by the CA. Tim suggested that if the different types of services
have different security properties, then the certificates and signatures can
contain a flag to denote the type of service that is managing the keys.
Bruce said that keys managed directly by the subscriber may have drastically
different levels of protection depending on the controls in place by the
Subscriber. Ian added that he's been brainstorming adding a flag to denote
the type of key protection and will consider further. 

Bruce asked Ian why he considers such a flag to be valuable. Ian said that
although he doesn't see software consuming such a flag in the near term,
requiring such a flag sets the groundwork for using it in the future. Such a
flag can also be used to see what type of service is being abused the most
to sign Suspect Code. 

Bruce said we should revisit the high-level goals to ensure that we're not
making the requirements for Signing Services to be very high compared to the
other types of key protection. Tim and Ian agreed. 

Bruce suggested that after the RFC 3647 migration is complete, the group can
go through the document and markup the areas that define requirements for
Signing Services. The next step may be to remove all these requirements and
start from scratch since the current requirements are currently haphazard. 

Tim added that we should look into existing implementations to gauge
existing practices and see what needs to be amended. Ian said that he'll
look into providing details about how their internal signing service is
implemented. 

Tim said that RFC 3647 reformat may help with comparing the requirements for
each key protection type. Doug suggested that the Signing Service
requirements could be a different specification since the requirements are
so different. It was agreed that we should use a modular approach to the
requirements to allow for different entities to perform different aspects of
the services covered under the document. Dimitris added that ETSI standards
for key management may be useful to compare against and potentially use for
these requirement. Tim mentioned that some amendments may need to be
required to account for different countries (e.g. in US, states are
sovereign). The goal may be to make the standards compatible but not
necessarily identical. 

Next meeting is March 10. 

 

 

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