<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:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 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=iso-8859-7">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@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:0in;
font-size:10.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:0in;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:10.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;
mso-ligatures:none;
mso-fareast-language:EN-GB;}
span.EmailStyle21
{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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:306476385;
mso-list-template-ids:-1192361176;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:863903334;
mso-list-template-ids:-1435343104;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:1405682490;
mso-list-template-ids:-741859574;}
@list l2:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:1538272648;
mso-list-template-ids:-618353580;}
@list l3:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4
{mso-list-id:1951738788;
mso-list-template-ids:-1168080936;}
@list l4:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5
{mso-list-id:2083680138;
mso-list-type:hybrid;
mso-list-template-ids:723573266 609101426 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l5:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Aptos",sans-serif;
mso-fareast-font-family:Aptos;
mso-bidi-font-family:"Times New Roman";}
@list l5:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l5:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l5:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l5:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l5:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l6
{mso-list-id:2138376636;
mso-list-template-ids:644793364;}
@list l6:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="#467886" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Martijn and all,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thinking more about this requirement and the way folks are operating today and I can see with this requirement CA may be constrained when they encounter a need for greater agility to scale out. I’d like to
propose a means to keep issuing CAs for time stamping end-entity certificates online when they are shorter-lived certificates (less than 72 months in validity). I agree that we need wording to say existing CAs are not required to adhere to these clarified
requirements, but all new subCAs must meet the requirements. Here is my proposal…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">“‘Effective April 15, 2025, a Timestamp Authority MUST protect all Private Keys associated with its Root CA certificates and
<span style="color:red">new</span> Subordinate CA certificates <span style="color:red">
with a validity period of greater than 72 months</span> containing the `id-kp-timeStamping` KeyPurposeId in the `extKeyUsage` extension (per section 7.1.2.2 g) and that issued Timestamp Certificates with the policyidentifier 2.23.140.1.4.2, in a Hardware Crypto
Module conforming to the requirements specified in [Section 6.2.7.1](#6271-private-key-storage-for-CA-keys), maintained in a High Security Zone and in an offline state or air-gapped from all other networks.’<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">What my intent for this to mean is that all new subCAs issuing time stamp certificates will fall into two buckets….<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo1"><span style="font-size:11.0pt">SubCA Certificate validity greater than 72 months MUST/SHALL be secured offline<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l5 level1 lfo1"><span style="font-size:11.0pt">SubCA Certificate validity less than 72 months MAY be secured online (or ‘SHOULD be secured offline’)<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This is similar to a policy we’ve operated under internally with the risk of online issuing CAs where we need greater agility to scale out as the business needs for certificate issuance/fulfillment have higher
volumes and latency requirements that offline CAs just cannot effectively meet. <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<br>
Ian <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Cscwg-public <cscwg-public-bounces@cabforum.org>
<b>On Behalf Of </b>Martijn Katerbarg via Cscwg-public<br>
<b>Sent:</b> Thursday, April 4, 2024 6:07 AM<br>
<b>To:</b> Mohit Kumar <mohit.kumar@globalsign.com>; cscwg-public@cabforum.org<br>
<b>Subject:</b> [EXTERNAL] Re: [Cscwg-public] Timestamp Certificate and SubCA updates<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Mohit,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">></span> <span style="font-size:11.0pt">
Can I confirm that the proposal to protect private keys of Subordinate CAs in an offline state is applicable to only private keys generated for Roots/Subordinate CAs created after the effective date.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">You’re touching on a good point here. The way the requirement is written, can be interpreted as such that the CA would need to do this for existing SubCAs as well. I’m leaving out Root CAs here, since these
even now, already are required to be in an offline state.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">But, making this a requirement for existing SubCAs may be an issue… while CAs may be able to migrate keys to an offline HSM, that’s not always a given. If that’s not an option, then key destruction would also
not be an option, cause even if the CA wouldn’t use the SubCA is issue new timestamp certificates anymore, they would still need use the key for signing CRLs.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I think it makes sense to make the requirement to be for any SubCA still used for the issuance of timestamp certificates going forward. If there’s no objection to that approach, I can update the ballot.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
(I won’t be able to make todays call, but please feel free to discuss and let me know the outcome)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">></span> <span style="font-size:11.0pt">
Also, per my understanding, the scope of the proposal is limited to only Root/Subordinate CAs issuing Timestamp Certificates for Code Signing (i.e. with the OID 2.23.140.1.4.2). If yes, may be it would be better to clarify the same with the following language
update<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Correct. I would expect Section 1.2 already makes clear that only TS certificates with this OID, assert compliance with the CSBRs.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">As far from a root store standpoint, it seems the the MS Root store policy requires the Policy OID to be included for TLS and Non-EV code signing, but there is no mentioning there about Timestamping certificates
specifically.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Regards,<br>
<br>
Martijn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><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 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Mohit Kumar <</span><a href="mailto:mohit.kumar@globalsign.com"><span style="font-size:12.0pt">mohit.kumar@globalsign.com</span></a><span style="font-size:12.0pt;color:black">><br>
<b>Date: </b>Thursday, 4 April 2024 at 04:19<br>
<b>To: </b>Martijn Katerbarg <</span><a href="mailto:martijn.katerbarg@sectigo.com"><span style="font-size:12.0pt">martijn.katerbarg@sectigo.com</span></a><span style="font-size:12.0pt;color:black">>,
</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:12.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:12.0pt;color:black"> <</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:12.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:12.0pt;color:black">><br>
<b>Subject: </b>RE: [Cscwg-public] Timestamp Certificate and SubCA updates<o:p></o:p></span></p>
</div>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
Hi Martijn,<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
Can I confirm that the proposal to protect private keys of Subordinate CAs in an offline state is applicable to only private keys generated for Roots/Subordinate CAs created after the effective date.<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
Also, per my understanding, the scope of the proposal is limited to only Root/Subordinate CAs issuing Timestamp Certificates for Code Signing (i.e. with the OID 2.23.140.1.4.2). If yes, may be it would be better to clarify the same with the following language
update<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
‘Effective April 15, 2025, a Timestamp Authority MUST protect Private Keys associated with its Root CA certificates and Subordinate CA certificates containing the `id-kp-timeStamping` KeyPurposeId in the `extKeyUsage` extension (per section 7.1.2.2 g) and that
issued Timestamp Certificates with the policyidentifier 2.23.140.1.4.2<span style="color:#CD5937">, </span>in a Hardware Crypto Module conforming to the requirements specified in [Section 6.2.7.1](#6271-private-key-storage-for-CA-keys), maintained in a High
Security Zone and in an offline state or air-gapped from all other networks.’<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
<o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
Thanks <o:p></o:p></p>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:30.0pt">
Mohit<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Cscwg-public <</span><a href="mailto:cscwg-public-bounces@cabforum.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">cscwg-public-bounces@cabforum.org</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>
<b>On Behalf Of </b>Martijn Katerbarg via Cscwg-public<br>
<b>Sent:</b> Tuesday, March 19, 2024 5:04 AM<br>
<b>To:</b> </span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">cscwg-public@cabforum.org</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">; Dimitris Zacharopoulos (HARICA)
<</span><a href="mailto:dzacharo@harica.gr"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">dzacharo@harica.gr</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">><br>
<b>Subject:</b> Re: [Cscwg-public] Timestamp Certificate and SubCA updates</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The language (</span><a href="https://github.com/cabforum/code-signing/pull/34"><span style="font-size:11.0pt">https://github.com/cabforum/code-signing/pull/34</span></a><span style="font-size:11.0pt"> ) has
been further updated (</span><a href="https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683"><span style="font-size:11.0pt">https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683</span></a><span style="font-size:11.0pt">)
based on the below. </span><a id="OWAAM1110A1362D438B4BADD95FD51E9651CD" href="mailto:dzacharo@harica.gr"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif;text-decoration:none">@Dimitris Zacharopoulos (HARICA)</span></a><span style="font-size:11.0pt">
I replaced “deleted” with “destroyed” in your proposal, as I believe it would fit better in that section.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Are there any further comments? If not I will start the official discussion period in the next few days.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Regards,<br>
<br>
Martijn</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Cscwg-public <</span><a href="mailto:cscwg-public-bounces@cabforum.org"><span style="font-size:12.0pt">cscwg-public-bounces@cabforum.org</span></a><span style="font-size:12.0pt;color:black">> on behalf of
Martijn Katerbarg via Cscwg-public <</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:12.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:12.0pt;color:black">><br>
<b>Date: </b>Monday, 11 March 2024 at 09:51<br>
<b>To: </b>Dimitris Zacharopoulos (HARICA) <</span><a href="mailto:dzacharo@harica.gr"><span style="font-size:12.0pt">dzacharo@harica.gr</span></a><span style="font-size:12.0pt;color:black">>,
</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:12.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:12.0pt;color:black"> <</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:12.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:12.0pt;color:black">><br>
<b>Subject: </b>Re: [Cscwg-public] Timestamp Certificate and SubCA updates</span><o:p></o:p></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-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.</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Works for me on both fronts. I’ll leave the discussion open for a bit so others can add on.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:11.0pt;color:black">From:
</span></b><span style="font-size:11.0pt;color:black">Dimitris Zacharopoulos (HARICA) <</span><a href="mailto:dzacharo@harica.gr"><span style="font-size:11.0pt">dzacharo@harica.gr</span></a><span style="font-size:11.0pt;color:black">><br>
<b>Date: </b>Monday, 11 March 2024 at 09:48<br>
<b>To: </b>Martijn Katerbarg <</span><a href="mailto:martijn.katerbarg@sectigo.com"><span style="font-size:11.0pt">martijn.katerbarg@sectigo.com</span></a><span style="font-size:11.0pt;color:black">>,
</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:11.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:11.0pt;color:black"> <</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:11.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:11.0pt;color:black">><br>
<b>Subject: </b>Re: [Cscwg-public] Timestamp Certificate and SubCA updates</span><o:p></o:p></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-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.</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 11/3/2024 10:32 ð.ì., Martijn Katerbarg wrote:</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks Dimitris, I’ve reviewed and accepted the suggestions.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> 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).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">TBH, I’m not sure why it couldn’t be two persons of the same Trusted Role?</span><o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt"><br>
I'm not a native English speaker but I think "Roles" (plural) points to the different types of Roles, while "Trusted Role members" would point to different Members in any Trusted Role. If the intent is to have a 4-eye principle control from any Trusted Role,
we can make it clearer by using the "Trusted Role members" phrase.</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> 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.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">> 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!</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">But your point on an HSM restoring an entire partition and that violating the requirement, is valid.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">For reference, the current proposed language is:</span><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">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.</span></i><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt"> </span></i><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">What about we once more use the NSR language and state:</span><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">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.</span></i><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt"> </span></i><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thoughts? </span><o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt"><br>
If we want to allow the existence of a key in a backup, IMHO we should avoid using the "key destruction" language. How about the following:<br>
<br>
Modify</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><i><span style="font-size:12.0pt">For Timestamp Certificates issued on or after June 1, 2024, the CA SHALL log the removal of the Private Key from the Hardware Crypto Module through means of a key destruction ceremony performed by the CA
and witnessed and signed-off by at least two Trusted Roles.</span></i><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt"><br>
to</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><i><span style="font-size:12.0pt">For Timestamp Certificates issued on or after June 1, 2024, the CA SHALL log the removal of the Private Key from the Hardware Crypto Module through means of a key
<span style="color:blue">deletion </span>ceremony performed by the CA and witnessed and signed-off by at least two
<span style="color:blue">Trusted Role members</span>. <span style="color:blue">The CA MAY also perform a key destruction ceremony,
</span></span></i><span style="font-size:12.0pt;color:blue">meaning that all copies of that private key are unequivocally/securely deleted (i.e. without a way to recover the key), including any instance of the key as part of a backup, to satisfy this requirement</span><span style="font-size:12.0pt">.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt"><br>
Thanks,<br>
Dimitris.</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><i><span style="font-size:11.0pt"> </span></i><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:11.0pt;color:black">From:
</span></b><span style="font-size:11.0pt;color:black">Cscwg-public </span><a href="mailto:cscwg-public-bounces@cabforum.org"><span style="font-size:11.0pt"><cscwg-public-bounces@cabforum.org></span></a><span style="font-size:11.0pt;color:black"> on behalf of
Dimitris Zacharopoulos (HARICA) via Cscwg-public </span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:11.0pt"><cscwg-public@cabforum.org></span></a><span style="font-size:11.0pt;color:black"><br>
<b>Date: </b>Sunday, 10 March 2024 at 10:30<br>
<b>To: </b></span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:11.0pt">cscwg-public@cabforum.org</span></a><span style="font-size:11.0pt;color:black">
</span><a href="mailto:cscwg-public@cabforum.org"><span style="font-size:11.0pt"><cscwg-public@cabforum.org></span></a><span style="font-size:11.0pt;color:black"><br>
<b>Subject: </b>Re: [Cscwg-public] Timestamp Certificate and SubCA updates</span><o:p></o:p></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-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.</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.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.</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 6/3/2024 2:07 ì.ì., Martijn Katerbarg via Cscwg-public wrote:</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">All,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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
</span><a href="https://github.com/cabforum/code-signing/pull/34"><span style="font-size:11.0pt">https://github.com/cabforum/code-signing/pull/34</span></a><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I’ve made changes this morning to add 3 effective dates, these are:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l6 level1 lfo2"><span style="font-size:11.0pt">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></ol>
<ol style="margin-top:0in" start="1" type="1">
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level2 lfo3"><span style="font-size:11.0pt">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></ol>
</ol>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo4"><span style="font-size:11.0pt">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></ol>
<ol style="margin-top:0in" start="1" type="1">
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l4 level2 lfo5"><span style="font-size:11.0pt">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></ol>
</ol>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo6"><span style="font-size:11.0pt">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></ol>
<ol style="margin-top:0in" start="1" type="1">
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level2 lfo7"><span style="font-size:11.0pt">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></ol>
</ol>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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 style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Regards,<br>
<br>
Martijn</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt"> </span><o:p></o:p></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://lists.cabforum.org/mailman/listinfo/cscwg-public">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>