<html 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=utf-8"><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;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:11.0pt;
font-family:"Aptos",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1401363;
mso-list-template-ids:-2097770136;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style></head><body lang=en-SE link="#467886" vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Thanks Dimitris, I’ve reviewed and accepted the suggestions. <o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>></span> witnessed by members of two different Trusted Roles (not by two Trusted Role Members, i.e. you can't use two persons of the same Trusted Role).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>TBH, I’m not sure why it couldn’t be two persons of the same Trusted Role?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>></span> In general, a "key destruction" ceremony includes the deletion of all copies of the key, including copies that reside in backups. If we require a "key destruction" ceremony, the "restore key" case is nonsensical. We probably need to work on this some more so that we all have the same understanding and expectations.<o:p></o:p></p><p class=MsoNormal>> It's ok to keep the keys in backups but if you happen to restore them in an HSM, you must not use them to sign anything. If a CA/TSA can also "destroy" the key, meaning that all copies of that private key can be unequivocally/securely deleted (i.e. without a way to recover the key), including any instance of the key as part of a backup, the better!<br><br><span style='mso-fareast-language:EN-US'><o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Agreed in general regarding the Key Destruction ceremony. However having to also destroy the backup of the key, and do this again for any next key every 18 months, can be a lengthy procedure, specially if backups are stored securely and offline in different places around the world. That’s why for this case we specifically call out that backups don’t need to be destroyed. <o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>But your point on an HSM restoring an entire partition and that violating the requirement, is valid. <o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>For reference, the current proposed language is:<o:p></o:p></span></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-US'>The CA MAY maintain existing backup sets containing the Private Key corresponding to a Timestamp Certificate. The CA MUST NOT restore the Private Key corresponding to a Timestamp Certificate contained within the backup if the Timestamp Certificate was issued more than 15 months prior to restoration of the backup.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></i></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>What about we once more use the NSR language and state:<o:p></o:p></span></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-US'>The CA MAY maintain existing backup sets containing the Private Key corresponding to a Timestamp Certificate. The CA SHOULD NOT restore the Private Key corresponding to a Timestamp Certificate contained within the backup if the Timestamp Certificate was issued more than 15 months prior to restoration of the backup. If the CA does restore such a Private Key, the CA SHALL only restore the Private Key in a suitable HSM while it’s maintained in a High Security Zone and in an offline state or air-gapped from all other networks and perform a new key destruction ceremony prior to the HSM being brought to an online state.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></i></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Thoughts? <o:p></o:p></span></p><p class=MsoNormal><i><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></i></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>As a side-note, I wonder if there’s a task for the NSWG (or Definitions WG once it’s setup) to define terms for online and offline HSMs<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><div id=mail-editor-reference-message-container><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='color:black'>From: </span></b><span style='color:black'>Cscwg-public <cscwg-public-bounces@cabforum.org> on behalf of Dimitris Zacharopoulos (HARICA) via Cscwg-public <cscwg-public@cabforum.org><br><b>Date: </b>Sunday, 10 March 2024 at 10:30<br><b>To: </b>cscwg-public@cabforum.org <cscwg-public@cabforum.org><br><b>Subject: </b>Re: [Cscwg-public] Timestamp Certificate and SubCA updates</span><span style='font-size:12.0pt;color:black'><o:p></o:p></span></p></div><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:black'>CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>Hi Martijn,<br><br>Two suggestions submitted on GitHub.<br><br>Regarding the prohibition of restoring a private key of a Timestamp Certificate, I'm not sure how universal this can be because some HSMs restore an entire slot/partition, which might contain Private Keys associated with obsolete Timestamp Certificates. As the ballot is written, such an action would be a violation.<br><br>In general, a "key destruction" ceremony includes the deletion of all copies of the key, including copies that reside in backups. If we require a "key destruction" ceremony, the "restore key" case is nonsensical. We probably need to work on this some more so that we all have the same understanding and expectations.<br><br>Let me restate the intent of this requirement as discussed all this time, and please correct me if I'm wrong.<br><br>IMO, the goal is to put the keys associated with Timestamp Certificates out of use, 15 months after the <i>notBefore </i>of the Timestamp Certificate. <br><br>In order to achieve some level of assurance for this action, the proposal is to delete the keys from the HSM 18 months after the <i>notBefore </i>of the Timestamp Certificate, in an audited way, witnessed by members of two different Trusted Roles (not by two Trusted Role Members, i.e. you can't use two persons of the same Trusted Role). <br><br>It's ok to keep the keys in backups but if you happen to restore them in an HSM, you must not use them to sign anything. If a CA/TSA can also "destroy" the key, meaning that all copies of that private key can be unequivocally/securely deleted (i.e. without a way to recover the key), including any instance of the key as part of a backup, the better!<br><br>Thoughts?<br><br>Dimitris.<br><br><o:p></o:p></p><div><p class=MsoNormal>On 6/3/2024 2:07 μ.μ., Martijn Katerbarg via Cscwg-public wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal><span lang=EN-US>All,</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>As discussed last week, I’d send out the draft language for this ballot once more before starting the discussion period. The latest version can be found in <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F34&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C5e8ff97a46964cd97d6f08dc40e4b919%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638456598304253222%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jt5w8Oh%2BJS%2FZ%2FFyU%2BGCERgmT7hq6frpyLwiKUhEVRFw%3D&reserved=0">https://github.com/cabforum/code-signing/pull/34</a></span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>I’ve made changes this morning to add 3 effective dates, these are:</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><ul style='margin-top:0cm' type=disc><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'><span lang=EN-US>For the removal of private keys associated with timestamp certificates, effective June 1<sup>st</sup>, 2024, CAs will need to properly log the removal of said key. </span><o:p></o:p></li></ul><ul style='margin-top:0cm' type=disc><ul style='margin-top:0cm' type=circle><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level2 lfo1'><span lang=EN-US>While I expect CAs to already properly log this for audit purposes even now, there may be exceptions for when this has not been done, for example a private key or timestamp certificate that was signed maybe 20 years ago. This language is added to avoid any confusion on from what point there needs to be an audit trail</span><o:p></o:p></li></ul></ul><ul style='margin-top:0cm' type=disc><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'><span lang=EN-US>Effective April 15, 2025, private keys associated with SubCAs containing the “Time Stamping” EKU will need to be placed in offline HSMs.</span><o:p></o:p></li></ul><ul style='margin-top:0cm' type=disc><ul style='margin-top:0cm' type=circle><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level2 lfo1'><span lang=EN-US>I believe a roughly one year effective date is appropriate here, since CAs may need to move keys from one HSM to another.</span><o:p></o:p></li></ul></ul><ul style='margin-top:0cm' type=disc><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo1'><span lang=EN-US>For private keys associated with timestamp certificates that were issued for greater than 15 months, CAs will need to remove the private keys 18 months after certificate issuance, starting April 15, 2025.</span><o:p></o:p></li></ul><ul style='margin-top:0cm' type=disc><ul style='margin-top:0cm' type=circle><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level2 lfo1'><span lang=EN-US>Likewise, I feel like anything involving HSM process changes, should have a longer effective date, and it makes sense to align this with the effective date above.</span><o:p></o:p></li></ul></ul><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>I’ll start a ballot on this early next week, unless there is concern with the above. </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US>Regards,<br><br>Martijn</span><o:p></o:p></p></div><p class=MsoNormal><span style='font-size:12.0pt'><br><br><o:p></o:p></span></p><pre>_______________________________________________<o:p></o:p></pre><pre>Cscwg-public mailing list<o:p></o:p></pre><pre><a href="mailto:Cscwg-public@cabforum.org">Cscwg-public@cabforum.org</a><o:p></o:p></pre><pre><a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C5e8ff97a46964cd97d6f08dc40e4b919%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638456598304262389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PKc6BBon3Qd4VpovT%2FWFINg69tG6ltUfhyIMe77pwAY%3D&reserved=0">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></pre></blockquote><p class=MsoNormal><span style='font-size:12.0pt'><o:p> </o:p></span></p></div></div></div></div></body></html>