<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:13.5pt'>Code Signing Working Group<o:p></o:p></span></b></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>Speaker</b>: Bruce Morton <br><b>Minute Taker</b>: Corey Bonnell <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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) <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Non-member attendees: Branca Martin (Amazon), Georgy Sebastian (Amazon), Mike Agenius Kushner (Interested Party), Tadahiko Ito (SECOM), Yoshiro Yoneya (JPRS) <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Dean read the antitrust statement. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Minutes for the January 27th and February 10th minutes were approved. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Bruce presented the Goals presentation (attached). <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Signing Service Discussion <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Ian mentioned that another primary goal of defining Signing Service requirements is to define parameters around access control. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Next meeting is March 10. <o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>