<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@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:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
span.EmailStyle22
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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-GB" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hello All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Attempting to send this again, as the previous E-Mail didn’t seem to display the message body. The below has been discussed on the meeting of June 3<sup>rd</sup>. There no immediate action that could be taken but a comment is warranted
 nevertheless. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">With the current state of technology, certificate issuers have no visibility of the later use of CodeSigning certificates so that authorization checks when signing code cannot be performed by certificate issuers. However, the working group
 acknowledges that in addition to guaranteeing the authenticity and integrity of code with digital signatures a guarantee that the signer is an authorized party would contribute to the security of the whole ecosystem. The working group would like to encourage
 any certificate consumer or even third party who intends to address this problem to present their approach.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There’s a special case for certificate issuer operated signing services, where certificate issuers have visibility of the code that is being signed. Such signing services will be discussed and addressed by the working group in greater detail
 during the coming months. The authorization of an entity to sign certain software/applications/code will not be a primary concern but definitely receive some attention during the discussion as well.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kind regards,<o:p></o:p></p>
<p class="MsoNormal">Seb<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-family:"Arial",sans-serif;color:#666666">Sebastian Schulz</span></b><span lang="EN-US" style="color:#1F497D"><br>
</span><i><span style="font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:EN-GB">Product Manager Client Certificates</span></i><span lang="EN-US"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="mso-fareast-language:EN-GB">From:</span></b><span lang="EN-US" style="mso-fareast-language:EN-GB"> Sebastian Schulz
<br>
<b>Sent:</b> 04 June 2021 09:53<br>
<b>To:</b> cscwg-public@cabforum.org<br>
<b>Subject:</b> Signature authorization checks for signed code (SBOM)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hello All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I wanted to bring something to your attention that a partner of ours has shared with us. In short, in securing software supply chains there’s some concern about tools for the validation of code signing signatures (e.g. SignTool) not taking
 into account whether the signer is actually <i>authorized </i>to sign that software package. As a suggestion to resolving this problem, a system similar to DNS CAA is being suggested (while being well aware that it could not work the exact same way).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Full message below:<o:p></o:p></p>
<div style="border:none;border-bottom:solid windowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm">
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US">Copied from <a href="https://energycentral.com/c/ec/we-cannot-secure-software-supply-chain-without-sbom">
https://energycentral.com/c/ec/we-cannot-secure-software-supply-chain-without-sbom</a>
<o:p></o:p></span></p>
<p><span lang="EN-US">A <a href="https://ntia.gov/sbom" target="_blank">Software Bill of Materials (SBOM)</a> has received considerable attention since the
<a href="https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/" target="_blank">
Cybersecurity Executive order was released on May 12, 2021</a> calling on government agencies to require SBOM’s from software vendors,
<em><span style="font-family:"Calibri",sans-serif">“(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website</span></em>”
<o:p></o:p></span></p>
<p><span lang="EN-US">The Executive Order goes on to describe an SBOM, with an emphasis on it’s component inventory capabilities,
<em><span style="font-family:"Calibri",sans-serif">“Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software</span></em>”, “<em><span style="font-family:"Calibri",sans-serif">It
 is analogous to a list of ingredients on food packaging.</span></em>”<o:p></o:p></span></p>
<p><span lang="EN-US">All of these claims are indeed accurate, however there is another essential and critically important element that SBOM’s provide, which is essential to secure the software supply chain; The identity of the software source supplier that
 produced and licensed the software, which can be verified using digital signing keys issued by trustworthy Certificate Authorities.
<o:p></o:p></span></p>
<p><span lang="EN-US">Current practices used in the software supply chain do not require identification of the actual software supplier and licensor of a software package. Some practices require that software packages be digitally signed, however there is no
 verification or validation that the signer of a software package and the supplier/licensor are related, or that the supplier/licensor has authorized a given party to sign a software object on their behalf. This creates a false sense of security when parties
 rely on tools such as Microsoft’s signtool to validate a digital signature. Signtool does not validate that a digital signature belongs to a party authorized to sign a software product on behalf of the original source supplier/licensor – it has no way of verifying
 that a given signer is authorized to digitally sign a software package. Signtool will report a valid signature if the cryptographic verifications and trust chain reports produce successful results, which do not verify the authorization of a signing party and
 supplier arrangement. This issue is similar to a past scenario where Certificate Authorities were issuing SSL certificates to domains without authorization to do so, which resulted in the implementation of DNS CAA (<a href="https://datatracker.ietf.org/doc/html/rfc6844" target="_blank">IETF
 RFC 6844</a>) records to identify authorized parties to issue SSL certificates. A similar authorization scheme may be appropriate to authorize the issuance of digital certificates and signing keys to parties that have been authorized by a software supplier/licensor
 to sign software objects on their behalf.<o:p></o:p></span></p>
<p><span lang="EN-US">The ability to determine trustworthiness is the key to securing the software supply chain. SBOM is the foundation for establishing this trust by specifying the identification of the actual source supplier/licensor of a software product.
 This supplier information can then be used to validate a digital signature applied to a software object by verifying the relationship of the software supplier and software signer using a trusted method to verify this relationship. A solution similar to DNS
 CAA, ref: “DNS Certification Authority Authorization (CAA) Resource Record”, <a href="https://datatracker.ietf.org/doc/html/rfc6844" target="_blank">
IETF RFC 6844</a> may be worth exploring to address this need.<o:p></o:p></span></p>
<p><span lang="EN-US">There is no doubt that securing the software supply chain requires a software consumer to verify the identity of a software source supplier and licensor of a software object. SBOM is a critical requirement in this process due to its standard
 method for identifying a software supplier/licensor of a software object. Having this SBOM supplier identifier will enable a software consumer to verify this party using digital signatures based on digital certificates issued by trusted Certificate Authorities.
  What is missing today is a means to verify the authorization of a signing party by the software source supplier/licensor using trusted mechanisms, similar to RFC 6844. Perhaps, one day, we may see a DNS Digital Signature Authorization (DSA) record to meet
 this need. <o:p></o:p></span></p>
<p><span lang="EN-US">Everyone in the Energy industry really needs to follow this wise guidance provided by NIST:<o:p></o:p></span></p>
<p><span lang="EN-US">SP 800-161 R1: <a href="https://doi.org/10.6028/NIST.SP.800-161r1-draft" target="_blank">
https://doi.org/10.6028/NIST.SP.800-161r1-draft</a>  <o:p></o:p></span></p>
<p><em><span lang="EN-US" style="font-family:"Calibri",sans-serif">SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | CODE AUTHENTICATION
</span></em><span lang="EN-US"><o:p></o:p></span></p>
<p><em><span lang="EN-US" style="font-family:"Calibri",sans-serif">Supplemental C-SCRM Guidance: The organization should ensure that code authentication mechanisms such as digital signatures are implemented to assure the integrity of software, firmware, and
 information.</span></em><span lang="EN-US"><o:p></o:p></span></p>
<div style="border:none;border-bottom:solid windowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm">
<p><span lang="EN-US">This NIST guidance, combined with Software Supplier Identification information contained in a digitally signed SBOM will go a long way to addressing software supply chain issues.<o:p></o:p></span></p>
</div>
<p class="MsoNormal">Best,<br>
Seb<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr>
<td width="387" valign="top" style="width:290.2pt;padding:0cm 5.4pt 0cm 5.4pt">
<p class="MsoNormal" style="line-height:11.55pt"><b><span style="font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:EN-GB">Sebastian Schulz</span></b><span style="color:#1F497D;mso-fareast-language:EN-GB"><br>
</span><i><span style="font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:EN-GB">Product Manager Client Certificates</span></i><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td width="387" valign="top" style="width:290.2pt;padding:0cm 5.4pt 0cm 5.4pt">
<p class="MsoNormal"><a href="http://www.globalsign.com/" title="http://www.globalsign.com/"><span style="color:#17375E;mso-fareast-language:EN-GB;text-decoration:none"><img border="0" width="191" height="41" style="width:1.9895in;height:.427in" id="Picture_x0020_6" src="cid:image001.png@01D76102.A1D5EF20" alt="signature_517036358"></span></a><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="353" style="width:264.45pt">
<tbody>
<tr style="height:23.3pt">
<td valign="top" style="padding:0cm 0cm 0cm 0cm;height:23.3pt">
<p class="MsoNormal" style="line-height:11.55pt"><span lang="DE" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#666666;mso-fareast-language:EN-GB">Diestseveest 14, 3000 Leuven, Belgium<br>
<b>T</b> +32 1652 0000 <b>ext </b>5955 |  <br>
<b>Email:</b> </span><span lang="DE" style="font-size:9.0pt;font-family:"Arial",sans-serif;mso-fareast-language:EN-GB"><a href="mailto:masebastian.schulz@globalsign.comrk.freeman@globalsign.com">sebastian.schulz@globalsign.com</a><span style="color:#005EAE"> </span></span><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
</td>
</tr>
<tr style="height:8.8pt">
<td valign="top" style="padding:0cm 0cm 0cm 0cm;height:8.8pt">
<p class="MsoNormal" style="line-height:11.55pt"><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;mso-fareast-language:EN-GB"><a href="https://www.linkedin.com/in/sebschulz/">Connect on LinkedIn</a></span></b><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:11.55pt"><i><span style="font-size:10.0pt;mso-fareast-language:EN-GB"><a href="https://downloads.globalsign.com/acton/media/2674/preference-center-login" title="https://downloads.globalsign.com/acton/media/2674/preference-center-login">Sign
 up to receive news and content from GlobalSign</a></span></i><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
</td>
</tr>
<tr style="height:2.8pt">
<td style="padding:0cm 0cm 0cm 0cm;height:2.8pt"></td>
</tr>
<tr style="height:4.85pt">
<td valign="top" style="padding:.75pt 0cm 0cm 0cm;height:4.85pt">
<p class="MsoNormal" style="line-height:11.55pt"><a href="https://twitter.com/globalsign"><span style="mso-fareast-language:EN-GB;text-decoration:none"><img border="0" width="22" height="22" style="width:.2291in;height:.2291in" id="Picture_x0020_5" src="cid:image002.png@01D76102.A1D5EF20" alt="signature_1478717044"></span></a><span style="color:#1F497D;mso-fareast-language:EN-GB"> </span><a href="http://www.linkedin.com/company/globalsign" target="_blank"><span style="mso-fareast-language:EN-GB;text-decoration:none"><img border="0" width="22" height="22" style="width:.2291in;height:.2291in" id="Picture_x0020_4" src="cid:image003.png@01D76102.A1D5EF20" alt="signature_1457613119"></span></a><span style="color:#1F497D;mso-fareast-language:EN-GB"> </span><a href="http://www.facebook.com/globalsignssl"><span style="mso-fareast-language:EN-GB;text-decoration:none"><img border="0" width="22" height="22" style="width:.2291in;height:.2291in" id="Picture_x0020_3" src="cid:image004.png@01D76102.A1D5EF20" alt="signature_1657600325"></span></a><span style="color:#1F497D;mso-fareast-language:EN-GB"> </span><a href="https://www.instagram.com/globalsign/"><span style="mso-fareast-language:EN-GB;text-decoration:none"><img border="0" width="22" height="22" style="width:.2291in;height:.2291in" id="Picture_x0020_2" src="cid:image005.png@01D76102.A1D5EF20" alt="signature_529620044"></span></a><span style="color:#1F497D;mso-fareast-language:EN-GB"> </span><a href="https://www.youtube.com/channel/UC8sZHRv5heWZpckgTAMBuJg"><span style="mso-fareast-language:EN-GB;text-decoration:none"><img border="0" width="20" height="20" style="width:.2083in;height:.2083in" id="Picture_x0020_1" src="cid:image006.png@01D76102.A1D5EF20" alt="signature_1719033113"></span></a><span style="font-size:12.0pt;mso-fareast-language:EN-GB"><o:p></o:p></span></p>
</td>
</tr>
<tr style="height:.25pt">
<td width="353" valign="top" style="width:264.45pt;padding:6.0pt 0cm 0cm 0cm;height:.25pt">
<p class="MsoNormal" style="text-align:justify;line-height:11.55pt"><span style="font-size:7.0pt;font-family:"Helvetica",sans-serif;color:#1F497D;mso-fareast-language:EN-GB">This e-mail message, including any attachments, is for the sole use of the intended
 recipient(s) and may include trade secrets or privileged or otherwise confidential information. Any unauthorized review, use, forwarding, printing, copying, disclosure or distribution is strictly prohibited. If you received this message in error, or have reason
 to believe you are not authorized to receive it, please promptly delete this message, destroy all copies, and notify the sender by e-mail.</span><span style="mso-fareast-language:EN-GB"><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>