From martijn.katerbarg at sectigo.com Tue Apr 2 19:59:48 2024 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Tue, 2 Apr 2024 19:59:48 +0000 Subject: [Cscwg-public] [Discussion Period Begins] CSC-24: Timestamping Private Key Protection Message-ID: ?Purpose of the Ballot This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? version 3.7 in order to clarify language regarding Timestamp Authority Private Key Protection. The main goals of this ballot are to: 1. Require Timestamp Authority Subordinate CA Private Keys to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests The following motion has been proposed by Martijn Katerbarg of Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. MOTION BEGINS This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? ("Code Signing Baseline Requirements") based on version 3.7. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683 MOTION ENDS The procedure for this ballot is as follows: Discussion (7 days) * Start Time: 2024-04-02 21:00 UTC * End Time: Not before 2024-04-09 21:00 UTC Vote for approval (7 days) * Start Time: TBD * End Time: TBD -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From dean.coclin at digicert.com Tue Apr 2 20:42:33 2024 From: dean.coclin at digicert.com (Dean Coclin) Date: Tue, 2 Apr 2024 20:42:33 +0000 Subject: [Cscwg-public] CSCWG Agenda April 4, 2024 In-Reply-To: <0100018e4d4a525c-23867691-4eb0-434a-9c68-da3b957c3a6f-000000@email.amazonses.com> References: <0100018b8241390e-52081729-55be-42aa-872a-4f0dd6107fe7-000000@email.amazonses.com> <0100018bcb5415a2-87d4f969-b882-4524-b4da-6ea74c0efcd4-000000@email.amazonses.com> <0100018c1630a242-eecafec3-ce5d-426a-a2d6-f2a9400fdc11-000000@email.amazonses.com> <0100018c5f26d101-09e6c2ed-74ec-431c-8b13-643a41e6c388-000000@email.amazonses.com> <0100018ce9e9039d-7d33d66a-7bb5-4423-a45b-c4d073297413-000000@email.amazonses.com> <0100018ceffa249b-b44f3930-a6f2-4270-b9b5-268629b6dae0-000000@email.amazonses.com> <0100018d319ae3ff-c2f9c7b8-833d-421f-9d59-0d02a981ad58-000000@email.amazonses.com> <0100018d7ac562d1-58c20c48-594f-4d6e-9aa9-7eaa01fd98fa-000000@email.amazonses.com> <0100018e4d4a525c-23867691-4eb0-434a-9c68-da3b957c3a6f-000000@email.amazonses.com> Message-ID: Here's the draft agenda for this week's call: MINUTE TAKER: NEED A VOLUNTEER, START RECORDING 1. Roll Call 2. Antitrust reminder 3. Approve prior meeting minutes - F2F (awaiting draft from Andrea), March 21st (Brianca) 4. Ballot status: Marking the EV CS guidelines obsolete (CSC-23). Do we need an IPR review? 5. Proposed ballots: Remove EV Guideline References 6. Proposed ballot for Time-stamp Requirements update; CSC-24 7. Continued discussion on Application for Associate Member status from Keyfactor 8. Interested Party application from Wangmo Tenzing (as an individual) 9. Other business 10. Next meeting - April 18th 11. Adjourn Dean Coclin CSCWG Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5217 bytes Desc: not available URL: From mohit.kumar at globalsign.com Thu Apr 4 02:19:48 2024 From: mohit.kumar at globalsign.com (Mohit Kumar) Date: Thu, 4 Apr 2024 02:19:48 +0000 Subject: [Cscwg-public] Timestamp Certificate and SubCA updates In-Reply-To: <0100018e55f44b58-11354952-ba0a-4c48-9e43-16c7ce498d7c-000000@email.amazonses.com> References: <0100018e13a9bd97-d838febe-f003-42df-94c9-2f7301aff0d0-000000@email.amazonses.com> <0100018e27b2ff0f-a2ace85a-dad8-4885-b0ba-1f192552a1a3-000000@email.amazonses.com> <849c65b3-cdbc-4afb-a860-760d0de0f3b9@harica.gr> <0100018e2cb58c86-fde096c6-96f6-458f-b6eb-ef1434e01f3c-000000@email.amazonses.com> <0100018e55f44b58-11354952-ba0a-4c48-9e43-16c7ce498d7c-000000@email.amazonses.com> Message-ID: Hi Martijn, 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. 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 ?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, 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.? Thanks Mohit From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Tuesday, March 19, 2024 5:04 AM To: cscwg-public at cabforum.org; Dimitris Zacharopoulos (HARICA) Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates The language (https://github.com/cabforum/code-signing/pull/34 ) has been further updated (https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683) based on the below. @Dimitris Zacharopoulos (HARICA) I replaced ?deleted? with ?destroyed? in your proposal, as I believe it would fit better in that section. Are there any further comments? If not I will start the official discussion period in the next few days. Regards, Martijn From: Cscwg-public on behalf of Martijn Katerbarg via Cscwg-public Date: Monday, 11 March 2024 at 09:51 To: Dimitris Zacharopoulos (HARICA) , cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Works for me on both fronts. I?ll leave the discussion open for a bit so others can add on. From: Dimitris Zacharopoulos (HARICA) Date: Monday, 11 March 2024 at 09:48 To: Martijn Katerbarg , cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. On 11/3/2024 10:32 ?.?., Martijn Katerbarg wrote: Thanks Dimitris, I?ve reviewed and accepted the suggestions. > 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). TBH, I?m not sure why it couldn?t be two persons of the same Trusted Role? 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. > 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. > 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! 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. But your point on an HSM restoring an entire partition and that violating the requirement, is valid. For reference, the current proposed language is: 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. What about we once more use the NSR language and state: 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. Thoughts? 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: Modify 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. to 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 deletion ceremony performed by the CA and witnessed and signed-off by at least two Trusted Role members. The CA MAY also perform a key destruction ceremony, 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. Thanks, Dimitris. 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 From: Cscwg-public on behalf of Dimitris Zacharopoulos (HARICA) via Cscwg-public Date: Sunday, 10 March 2024 at 10:30 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Hi Martijn, Two suggestions submitted on GitHub. 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. 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. Let me restate the intent of this requirement as discussed all this time, and please correct me if I'm wrong. IMO, the goal is to put the keys associated with Timestamp Certificates out of use, 15 months after the notBefore of the Timestamp Certificate. 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 notBefore 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). 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! Thoughts? Dimitris. On 6/3/2024 2:07 ?.?., Martijn Katerbarg via Cscwg-public wrote: All, 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 https://github.com/cabforum/code-signing/pull/34 I?ve made changes this morning to add 3 effective dates, these are: * For the removal of private keys associated with timestamp certificates, effective June 1st, 2024, CAs will need to properly log the removal of said key. * 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 * Effective April 15, 2025, private keys associated with SubCAs containing the ?Time Stamping? EKU will need to be placed in offline HSMs. * I believe a roughly one year effective date is appropriate here, since CAs may need to move keys from one HSM to another. * 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. * 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. I?ll start a ballot on this early next week, unless there is concern with the above. Regards, Martijn _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8402 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Thu Apr 4 06:36:04 2024 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Thu, 4 Apr 2024 08:36:04 +0200 Subject: [Cscwg-public] [External Sender] Re: Timestamp Certificate and SubCA updates In-Reply-To: <0100018ea6e7fed5-9c74bfdc-c982-4414-8dc1-1f8657dc9a1e-000000@email.amazonses.com> References: <0100018e13a9bd97-d838febe-f003-42df-94c9-2f7301aff0d0-000000@email.amazonses.com> <0100018e27b2ff0f-a2ace85a-dad8-4885-b0ba-1f192552a1a3-000000@email.amazonses.com> <849c65b3-cdbc-4afb-a860-760d0de0f3b9@harica.gr> <0100018e2cb58c86-fde096c6-96f6-458f-b6eb-ef1434e01f3c-000000@email.amazonses.com> <0100018e55f44b58-11354952-ba0a-4c48-9e43-16c7ce498d7c-000000@email.amazonses.com> <0100018ea6e7fed5-9c74bfdc-c982-4414-8dc1-1f8657dc9a1e-000000@email.amazonses.com> Message-ID: <8218195e-6f63-451e-b5bc-424f368f3eb2@staff.aruba.it> +1 Il 04/04/2024 04:20, Mohit Kumar via Cscwg-public ha scritto: > > Hi Martijn, > > 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. > > 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 > > ?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, 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.? > > Thanks > > Mohit > > *From:*Cscwg-public *On Behalf Of > *Martijn Katerbarg via Cscwg-public > *Sent:* Tuesday, March 19, 2024 5:04 AM > *To:* cscwg-public at cabforum.org; Dimitris Zacharopoulos (HARICA) > > *Subject:* Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > The language (https://github.com/cabforum/code-signing/pull/34 ) has > been further updated > (https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683) > based on the below. @Dimitris Zacharopoulos (HARICA) > I replaced ?deleted? with ?destroyed? in > your proposal, as I believe it would fit better in that section. > > Are there any further comments? If not I will start the official > discussion period in the next few days. > > Regards, > > Martijn > > *From: *Cscwg-public on behalf of > Martijn Katerbarg via Cscwg-public > *Date: *Monday, 11 March 2024 at 09:51 > *To: *Dimitris Zacharopoulos (HARICA) , > cscwg-public at cabforum.org > *Subject: *Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > 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. > > Works for me on both fronts. I?ll leave the discussion open for a bit > so others can add on. > > *From: *Dimitris Zacharopoulos (HARICA) > *Date: *Monday, 11 March 2024 at 09:48 > *To: *Martijn Katerbarg , > cscwg-public at cabforum.org > *Subject: *Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > 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. > > On 11/3/2024 10:32 ?.?., Martijn Katerbarg wrote: > > Thanks Dimitris, I?ve reviewed and accepted the suggestions. > > > 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). > > TBH, I?m not sure why it couldn?t be two persons of the same > Trusted Role? > > > 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. > > > 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. > > > 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! > > 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. > > But your point on an HSM restoring an entire partition and that > violating the requirement, is valid. > > For reference, the current proposed language is: > > /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./ > > // > > What about we once more use the NSR language and state: > > /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./ > > // > > Thoughts? > > > 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: > > Modify > > /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./ > > > to > > /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 deletion ceremony performed > by the CA and witnessed and signed-off by at least two Trusted > Role members. The CA MAY also perform a key destruction ceremony, > /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. > > > Thanks, > Dimitris. > > // > > 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 > > *From: *Cscwg-public > on behalf of Dimitris > Zacharopoulos (HARICA) via Cscwg-public > > *Date: *Sunday, 10 March 2024 at 10:30 > *To: *cscwg-public at cabforum.org > > *Subject: *Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > 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. > > Hi Martijn, > > Two suggestions submitted on GitHub. > > 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. > > 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. > > Let me restate the intent of this requirement as discussed all > this time, and please correct me if I'm wrong. > > IMO, the goal is to put the keys associated with Timestamp > Certificates out of use, 15 months after the /notBefore /of the > Timestamp Certificate. > > 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 > /notBefore /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). > > 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! > > Thoughts? > > Dimitris. > > On 6/3/2024 2:07 ?.?., Martijn Katerbarg via Cscwg-public wrote: > > All, > > 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 > https://github.com/cabforum/code-signing/pull/34 > > I?ve made changes this morning to add 3 effective dates, these > are: > > * For the removal of private keys associated with timestamp > certificates, effective June 1^st , 2024, CAs will need to > properly log the removal of said key. > > o 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 > > * Effective April 15, 2025, private keys associated with > SubCAs containing the ?Time Stamping? EKU will need to be > placed in offline HSMs. > > o I believe a roughly one year effective date is > appropriate here, since CAs may need to move keys from > one HSM to another. > > * 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. > > o 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. > > I?ll start a ballot on this early next week, unless there is > concern with the above. > > Regards, > > Martijn > > _______________________________________________ > > Cscwg-public mailing list > > Cscwg-public at cabforum.org > > https://lists.cabforum.org/mailman/listinfo/cscwg-public > > > _______________________________________________ > Cscwg-public mailing list > Cscwg-public at cabforum.org > https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From martijn.katerbarg at sectigo.com Thu Apr 4 10:06:19 2024 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Thu, 4 Apr 2024 10:06:19 +0000 Subject: [Cscwg-public] Timestamp Certificate and SubCA updates In-Reply-To: References: <0100018e13a9bd97-d838febe-f003-42df-94c9-2f7301aff0d0-000000@email.amazonses.com> <0100018e27b2ff0f-a2ace85a-dad8-4885-b0ba-1f192552a1a3-000000@email.amazonses.com> <849c65b3-cdbc-4afb-a860-760d0de0f3b9@harica.gr> <0100018e2cb58c86-fde096c6-96f6-458f-b6eb-ef1434e01f3c-000000@email.amazonses.com> <0100018e55f44b58-11354952-ba0a-4c48-9e43-16c7ce498d7c-000000@email.amazonses.com> Message-ID: ?Hi Mohit, > 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. 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. 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. 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. (I won?t be able to make todays call, but please feel free to discuss and let me know the outcome) > 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 Correct. I would expect Section 1.2 already makes clear that only TS certificates with this OID, assert compliance with the CSBRs. 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. Regards, Martijn From: Mohit Kumar Date: Thursday, 4 April 2024 at 04:19 To: Martijn Katerbarg , cscwg-public at cabforum.org Subject: RE: [Cscwg-public] Timestamp Certificate and SubCA updates Hi Martijn, 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. 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 ?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, 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.? Thanks Mohit From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Tuesday, March 19, 2024 5:04 AM To: cscwg-public at cabforum.org; Dimitris Zacharopoulos (HARICA) Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates The language (https://github.com/cabforum/code-signing/pull/34 ) has been further updated (https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683 ) based on the below. @Dimitris Zacharopoulos (HARICA) I replaced ?deleted? with ?destroyed? in your proposal, as I believe it would fit better in that section. Are there any further comments? If not I will start the official discussion period in the next few days. Regards, Martijn From: Cscwg-public on behalf of Martijn Katerbarg via Cscwg-public Date: Monday, 11 March 2024 at 09:51 To: Dimitris Zacharopoulos (HARICA) , cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Works for me on both fronts. I?ll leave the discussion open for a bit so others can add on. From: Dimitris Zacharopoulos (HARICA) Date: Monday, 11 March 2024 at 09:48 To: Martijn Katerbarg , cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. On 11/3/2024 10:32 ?.?., Martijn Katerbarg wrote: Thanks Dimitris, I?ve reviewed and accepted the suggestions. > 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). TBH, I?m not sure why it couldn?t be two persons of the same Trusted Role? 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. > 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. > 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! 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. But your point on an HSM restoring an entire partition and that violating the requirement, is valid. For reference, the current proposed language is: 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. What about we once more use the NSR language and state: 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. Thoughts? 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: Modify 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. to 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 deletion ceremony performed by the CA and witnessed and signed-off by at least two Trusted Role members. The CA MAY also perform a key destruction ceremony, 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. Thanks, Dimitris. 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 From: Cscwg-public on behalf of Dimitris Zacharopoulos (HARICA) via Cscwg-public Date: Sunday, 10 March 2024 at 10:30 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Hi Martijn, Two suggestions submitted on GitHub. 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. 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. Let me restate the intent of this requirement as discussed all this time, and please correct me if I'm wrong. IMO, the goal is to put the keys associated with Timestamp Certificates out of use, 15 months after the notBefore of the Timestamp Certificate. 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 notBefore 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). 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! Thoughts? Dimitris. On 6/3/2024 2:07 ?.?., Martijn Katerbarg via Cscwg-public wrote: All, 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 https://github.com/cabforum/code-signing/pull/34 I?ve made changes this morning to add 3 effective dates, these are: 1. For the removal of private keys associated with timestamp certificates, effective June 1st, 2024, CAs will need to properly log the removal of said key. 1. 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 1. Effective April 15, 2025, private keys associated with SubCAs containing the ?Time Stamping? EKU will need to be placed in offline HSMs. 1. I believe a roughly one year effective date is appropriate here, since CAs may need to move keys from one HSM to another. 1. 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. 1. 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. I?ll start a ballot on this early next week, unless there is concern with the above. Regards, Martijn _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From ianmcm at microsoft.com Thu Apr 4 17:54:33 2024 From: ianmcm at microsoft.com (Ian McMillan) Date: Thu, 4 Apr 2024 17:54:33 +0000 Subject: [Cscwg-public] Timestamp Certificate and SubCA updates In-Reply-To: <0100018ea89317ae-d527adcc-052e-4b76-94ff-6cbf80e97a5f-000000@email.amazonses.com> References: <0100018e13a9bd97-d838febe-f003-42df-94c9-2f7301aff0d0-000000@email.amazonses.com> <0100018e27b2ff0f-a2ace85a-dad8-4885-b0ba-1f192552a1a3-000000@email.amazonses.com> <849c65b3-cdbc-4afb-a860-760d0de0f3b9@harica.gr> <0100018e2cb58c86-fde096c6-96f6-458f-b6eb-ef1434e01f3c-000000@email.amazonses.com> <0100018e55f44b58-11354952-ba0a-4c48-9e43-16c7ce498d7c-000000@email.amazonses.com> <0100018ea89317ae-d527adcc-052e-4b76-94ff-6cbf80e97a5f-000000@email.amazonses.com> Message-ID: Hi Martijn and all, 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... "'Effective April 15, 2025, a Timestamp Authority MUST protect all Private Keys associated with its Root CA certificates and new Subordinate CA certificates with a validity period of greater than 72 months 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.' What my intent for this to mean is that all new subCAs issuing time stamp certificates will fall into two buckets.... * SubCA Certificate validity greater than 72 months MUST/SHALL be secured offline * SubCA Certificate validity less than 72 months MAY be secured online (or 'SHOULD be secured offline') 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. Thanks, Ian From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Thursday, April 4, 2024 6:07 AM To: Mohit Kumar ; cscwg-public at cabforum.org Subject: [EXTERNAL] Re: [Cscwg-public] Timestamp Certificate and SubCA updates Hi Mohit, > 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. 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. 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. 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. (I won't be able to make todays call, but please feel free to discuss and let me know the outcome) > 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 Correct. I would expect Section 1.2 already makes clear that only TS certificates with this OID, assert compliance with the CSBRs. 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. Regards, Martijn From: Mohit Kumar > Date: Thursday, 4 April 2024 at 04:19 To: Martijn Katerbarg >, cscwg-public at cabforum.org > Subject: RE: [Cscwg-public] Timestamp Certificate and SubCA updates Hi Martijn, 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. 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 '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, 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.' Thanks Mohit From: Cscwg-public > On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Tuesday, March 19, 2024 5:04 AM To: cscwg-public at cabforum.org; Dimitris Zacharopoulos (HARICA) > Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates The language (https://github.com/cabforum/code-signing/pull/34 ) has been further updated (https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683) based on the below. @Dimitris Zacharopoulos (HARICA) I replaced "deleted" with "destroyed" in your proposal, as I believe it would fit better in that section. Are there any further comments? If not I will start the official discussion period in the next few days. Regards, Martijn From: Cscwg-public > on behalf of Martijn Katerbarg via Cscwg-public > Date: Monday, 11 March 2024 at 09:51 To: Dimitris Zacharopoulos (HARICA) >, cscwg-public at cabforum.org > Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Works for me on both fronts. I'll leave the discussion open for a bit so others can add on. From: Dimitris Zacharopoulos (HARICA) > Date: Monday, 11 March 2024 at 09:48 To: Martijn Katerbarg >, cscwg-public at cabforum.org > Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. On 11/3/2024 10:32 ?.?., Martijn Katerbarg wrote: Thanks Dimitris, I've reviewed and accepted the suggestions. > 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). TBH, I'm not sure why it couldn't be two persons of the same Trusted Role? 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. > 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. > 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! 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. But your point on an HSM restoring an entire partition and that violating the requirement, is valid. For reference, the current proposed language is: 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. What about we once more use the NSR language and state: 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. Thoughts? 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: Modify 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. to 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 deletion ceremony performed by the CA and witnessed and signed-off by at least two Trusted Role members. The CA MAY also perform a key destruction ceremony, 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. Thanks, Dimitris. 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 From: Cscwg-public on behalf of Dimitris Zacharopoulos (HARICA) via Cscwg-public Date: Sunday, 10 March 2024 at 10:30 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Hi Martijn, Two suggestions submitted on GitHub. 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. 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. Let me restate the intent of this requirement as discussed all this time, and please correct me if I'm wrong. IMO, the goal is to put the keys associated with Timestamp Certificates out of use, 15 months after the notBefore of the Timestamp Certificate. 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 notBefore 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). 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! Thoughts? Dimitris. On 6/3/2024 2:07 ?.?., Martijn Katerbarg via Cscwg-public wrote: All, 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 https://github.com/cabforum/code-signing/pull/34 I've made changes this morning to add 3 effective dates, these are: 1. For the removal of private keys associated with timestamp certificates, effective June 1st, 2024, CAs will need to properly log the removal of said key. * 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 1. Effective April 15, 2025, private keys associated with SubCAs containing the "Time Stamping" EKU will need to be placed in offline HSMs. * I believe a roughly one year effective date is appropriate here, since CAs may need to move keys from one HSM to another. 1. 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. * 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. I'll start a ballot on this early next week, unless there is concern with the above. Regards, Martijn _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijn.katerbarg at sectigo.com Thu Apr 4 18:59:39 2024 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Thu, 4 Apr 2024 18:59:39 +0000 Subject: [Cscwg-public] Timestamp Certificate and SubCA updates In-Reply-To: References: <0100018e13a9bd97-d838febe-f003-42df-94c9-2f7301aff0d0-000000@email.amazonses.com> <0100018e27b2ff0f-a2ace85a-dad8-4885-b0ba-1f192552a1a3-000000@email.amazonses.com> <849c65b3-cdbc-4afb-a860-760d0de0f3b9@harica.gr> <0100018e2cb58c86-fde096c6-96f6-458f-b6eb-ef1434e01f3c-000000@email.amazonses.com> <0100018e55f44b58-11354952-ba0a-4c48-9e43-16c7ce498d7c-000000@email.amazonses.com> <0100018ea89317ae-d527adcc-052e-4b76-94ff-6cbf80e97a5f-000000@email.amazonses.com> Message-ID: ?Hi Ian, I like that proposal. Perhaps a minor nit is that I?d suggest we replace ?new? with ?newly issued Subordinate CA certificates after that date with a validity??. I?ll leave this open for discussion a few more days, and restart the discussion period sometime next week, unless there is further feedback. Regards, Martijn From: Ian McMillan Date: Thursday, 4 April 2024 at 19:54 To: Martijn Katerbarg , cscwg-public at cabforum.org , Mohit Kumar Subject: RE: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Hi Martijn and all, 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? ??Effective April 15, 2025, a Timestamp Authority MUST protect all Private Keys associated with its Root CA certificates and new Subordinate CA certificates with a validity period of greater than 72 months 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.? What my intent for this to mean is that all new subCAs issuing time stamp certificates will fall into two buckets?. * SubCA Certificate validity greater than 72 months MUST/SHALL be secured offline * SubCA Certificate validity less than 72 months MAY be secured online (or ?SHOULD be secured offline?) 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. Thanks, Ian From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Thursday, April 4, 2024 6:07 AM To: Mohit Kumar ; cscwg-public at cabforum.org Subject: [EXTERNAL] Re: [Cscwg-public] Timestamp Certificate and SubCA updates Hi Mohit, > 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. 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. 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. 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. (I won?t be able to make todays call, but please feel free to discuss and let me know the outcome) > 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 Correct. I would expect Section 1.2 already makes clear that only TS certificates with this OID, assert compliance with the CSBRs. 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. Regards, Martijn From: Mohit Kumar > Date: Thursday, 4 April 2024 at 04:19 To: Martijn Katerbarg >, cscwg-public at cabforum.org > Subject: RE: [Cscwg-public] Timestamp Certificate and SubCA updates Hi Martijn, 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. 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 ?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, 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.? Thanks Mohit From: Cscwg-public > On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Tuesday, March 19, 2024 5:04 AM To: cscwg-public at cabforum.org ; Dimitris Zacharopoulos (HARICA) > Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates The language (https://github.com/cabforum/code-signing/pull/34 ) has been further updated (https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683 ) based on the below. @Dimitris Zacharopoulos (HARICA) I replaced ?deleted? with ?destroyed? in your proposal, as I believe it would fit better in that section. Are there any further comments? If not I will start the official discussion period in the next few days. Regards, Martijn From: Cscwg-public > on behalf of Martijn Katerbarg via Cscwg-public > Date: Monday, 11 March 2024 at 09:51 To: Dimitris Zacharopoulos (HARICA) >, cscwg-public at cabforum.org > Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Works for me on both fronts. I?ll leave the discussion open for a bit so others can add on. From: Dimitris Zacharopoulos (HARICA) > Date: Monday, 11 March 2024 at 09:48 To: Martijn Katerbarg >, cscwg-public at cabforum.org > Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. On 11/3/2024 10:32 ?.?., Martijn Katerbarg wrote: Thanks Dimitris, I?ve reviewed and accepted the suggestions. > 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). TBH, I?m not sure why it couldn?t be two persons of the same Trusted Role? 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. > 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. > 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! 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. But your point on an HSM restoring an entire partition and that violating the requirement, is valid. For reference, the current proposed language is: 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. What about we once more use the NSR language and state: 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. Thoughts? 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: Modify 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. to 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 deletion ceremony performed by the CA and witnessed and signed-off by at least two Trusted Role members. The CA MAY also perform a key destruction ceremony, 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. Thanks, Dimitris. 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 From: Cscwg-public on behalf of Dimitris Zacharopoulos (HARICA) via Cscwg-public Date: Sunday, 10 March 2024 at 10:30 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] Timestamp Certificate and SubCA updates 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. Hi Martijn, Two suggestions submitted on GitHub. 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. 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. Let me restate the intent of this requirement as discussed all this time, and please correct me if I'm wrong. IMO, the goal is to put the keys associated with Timestamp Certificates out of use, 15 months after the notBefore of the Timestamp Certificate. 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 notBefore 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). 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! Thoughts? Dimitris. On 6/3/2024 2:07 ?.?., Martijn Katerbarg via Cscwg-public wrote: All, 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 https://github.com/cabforum/code-signing/pull/34 I?ve made changes this morning to add 3 effective dates, these are: 1. For the removal of private keys associated with timestamp certificates, effective June 1st, 2024, CAs will need to properly log the removal of said key. 1. 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 1. Effective April 15, 2025, private keys associated with SubCAs containing the ?Time Stamping? EKU will need to be placed in offline HSMs. 1. I believe a roughly one year effective date is appropriate here, since CAs may need to move keys from one HSM to another. 1. 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. 1. 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. I?ll start a ballot on this early next week, unless there is concern with the above. Regards, Martijn _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Fri Apr 5 06:53:20 2024 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Fri, 5 Apr 2024 08:53:20 +0200 Subject: [Cscwg-public] [External Sender] Re: Timestamp Certificate and SubCA updates In-Reply-To: <0100018eaa7b6d69-e9ea4d7e-77d0-4dc8-aecd-677a3d6104d6-000000@email.amazonses.com> References: <0100018e13a9bd97-d838febe-f003-42df-94c9-2f7301aff0d0-000000@email.amazonses.com> <0100018e27b2ff0f-a2ace85a-dad8-4885-b0ba-1f192552a1a3-000000@email.amazonses.com> <849c65b3-cdbc-4afb-a860-760d0de0f3b9@harica.gr> <0100018e2cb58c86-fde096c6-96f6-458f-b6eb-ef1434e01f3c-000000@email.amazonses.com> <0100018e55f44b58-11354952-ba0a-4c48-9e43-16c7ce498d7c-000000@email.amazonses.com> <0100018ea89317ae-d527adcc-052e-4b76-94ff-6cbf80e97a5f-000000@email.amazonses.com> <0100018eaa7b6d69-e9ea4d7e-77d0-4dc8-aecd-677a3d6104d6-000000@email.amazonses.com> Message-ID: I also agree with the proposal, but I am not clear where does this "magic number" of 72 (months) come from... Adriano Il 04/04/2024 20:59, Martijn Katerbarg via Cscwg-public ha scritto: > > Hi Ian, > > > I like that proposal. Perhaps a minor nit is that I?d suggest we > replace ?new? with ?newly issued Subordinate CA certificates after > that date with a validity??. > > I?ll leave this open for discussion a few more days, and restart the > discussion period sometime next week, unless there is further feedback. > > Regards, > > Martijn > > *From: *Ian McMillan > *Date: *Thursday, 4 April 2024 at 19:54 > *To: *Martijn Katerbarg , > cscwg-public at cabforum.org , Mohit Kumar > > *Subject: *RE: [Cscwg-public] Timestamp Certificate and SubCA updates > > 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. > > Hi Martijn and all, > > 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? > > ??Effective April 15, 2025, a Timestamp Authority MUST protect all > Private Keys associated with its Root CA certificates and new > Subordinate CA certificates with a validity period of greater than 72 > months 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.? > > What my intent for this to mean is that all new subCAs issuing time > stamp certificates will fall into two buckets?. > > * SubCA Certificate validity greater than 72 months MUST/SHALL be > secured offline > * SubCA Certificate validity less than 72 months MAY be secured > online (or ?SHOULD be secured offline?) > > 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. > > Thanks, > Ian > > *From:*Cscwg-public *On Behalf Of > *Martijn Katerbarg via Cscwg-public > *Sent:* Thursday, April 4, 2024 6:07 AM > *To:* Mohit Kumar ; cscwg-public at cabforum.org > *Subject:* [EXTERNAL] Re: [Cscwg-public] Timestamp Certificate and > SubCA updates > > Hi Mohit, > > >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. > > 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. > > 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. > > 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. > > > (I won?t be able to make todays call, but please feel free to discuss > and let me know the outcome) > > >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 > > Correct. I would expect Section 1.2 already makes clear that only TS > certificates with this OID, assert compliance with the CSBRs. > > 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. > > Regards, > > Martijn > > *From: *Mohit Kumar > > *Date: *Thursday, 4 April 2024 at 04:19 > *To: *Martijn Katerbarg >, cscwg-public at cabforum.org > > > *Subject: *RE: [Cscwg-public] Timestamp Certificate and SubCA updates > > Hi Martijn, > > 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. > > 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 > > ?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, 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.? > > Thanks > > Mohit > > *From:*Cscwg-public > *On Behalf Of *Martijn > Katerbarg via Cscwg-public > *Sent:* Tuesday, March 19, 2024 5:04 AM > *To:* cscwg-public at cabforum.org ; > Dimitris Zacharopoulos (HARICA) > > *Subject:* Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > The language (https://github.com/cabforum/code-signing/pull/34 > ) > has been further updated > (https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683 > ) > based on the below. @Dimitris Zacharopoulos (HARICA) > I replaced ?deleted? with ?destroyed? in > your proposal, as I believe it would fit better in that section. > > Are there any further comments? If not I will start the official > discussion period in the next few days. > > Regards, > > Martijn > > *From: *Cscwg-public > on behalf of Martijn > Katerbarg via Cscwg-public > > *Date: *Monday, 11 March 2024 at 09:51 > *To: *Dimitris Zacharopoulos (HARICA) >, cscwg-public at cabforum.org > > > *Subject: *Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > 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. > > Works for me on both fronts. I?ll leave the discussion open for a bit > so others can add on. > > *From: *Dimitris Zacharopoulos (HARICA) > > *Date: *Monday, 11 March 2024 at 09:48 > *To: *Martijn Katerbarg >, cscwg-public at cabforum.org > > > *Subject: *Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > 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. > > On 11/3/2024 10:32 ?.?., Martijn Katerbarg wrote: > > Thanks Dimitris, I?ve reviewed and accepted the suggestions. > > > 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). > > TBH, I?m not sure why it couldn?t be two persons of the same > Trusted Role? > > > 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. > > > 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. > > > 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! > > 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. > > But your point on an HSM restoring an entire partition and that > violating the requirement, is valid. > > For reference, the current proposed language is: > > /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./ > > // > > What about we once more use the NSR language and state: > > /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./ > > // > > Thoughts? > > > 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: > > Modify > > /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./ > > > to > > /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 deletion ceremony performed > by the CA and witnessed and signed-off by at least two Trusted > Role members. The CA MAY also perform a key destruction ceremony, > /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. > > > Thanks, > Dimitris. > > // > > 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 > > *From: *Cscwg-public > on behalf of Dimitris > Zacharopoulos (HARICA) via Cscwg-public > > *Date: *Sunday, 10 March 2024 at 10:30 > *To: *cscwg-public at cabforum.org > > > *Subject: *Re: [Cscwg-public] Timestamp Certificate and SubCA updates > > 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. > > Hi Martijn, > > Two suggestions submitted on GitHub. > > 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. > > 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. > > Let me restate the intent of this requirement as discussed all > this time, and please correct me if I'm wrong. > > IMO, the goal is to put the keys associated with Timestamp > Certificates out of use, 15 months after the /notBefore /of the > Timestamp Certificate. > > 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 > /notBefore /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). > > 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! > > Thoughts? > > Dimitris. > > On 6/3/2024 2:07 ?.?., Martijn Katerbarg via Cscwg-public wrote: > > All, > > 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 > https://github.com/cabforum/code-signing/pull/34 > > > I?ve made changes this morning to add 3 effective dates, these > are: > > 1. For the removal of private keys associated with timestamp > certificates, effective June 1^st , 2024, CAs will need to > properly log the removal of said key. > > 1. 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 > > 1. Effective April 15, 2025, private keys associated with > SubCAs containing the ?Time Stamping? EKU will need to be > placed in offline HSMs. > > 1. I believe a roughly one year effective date is > appropriate here, since CAs may need to move keys from > one HSM to another. > > 1. 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. > > 1. 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. > > I?ll start a ballot on this early next week, unless there is > concern with the above. > > Regards, > > Martijn > > _______________________________________________ > > Cscwg-public mailing list > > Cscwg-public at cabforum.org > > https://lists.cabforum.org/mailman/listinfo/cscwg-public > > > > _______________________________________________ > Cscwg-public mailing list > Cscwg-public at cabforum.org > https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From martijn.katerbarg at sectigo.com Mon Apr 8 07:31:20 2024 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Mon, 8 Apr 2024 07:31:20 +0000 Subject: [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection Message-ID: ?Purpose of the Ballot This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? version 3.7 in order to clarify language regarding Timestamp Authority Private Key Protection. The main goals of this ballot are to: 1. Require newly issued Timestamp Authority Subordinate CA Private Keys to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests The following motion has been proposed by Martijn Katerbarg of Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. MOTION BEGINS This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? ("Code Signing Baseline Requirements") based on version 3.7. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 MOTION ENDS The procedure for this ballot is as follows: Discussion (7 days) * Start Time: 2024-04-08 09:00 UTC * End Time: Not before 2024-04-15 17:00 UTC Vote for approval (7 days) * Start Time: TBD * End Time: TBD -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Mon Apr 8 07:47:51 2024 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Mon, 8 Apr 2024 09:47:51 +0200 Subject: [Cscwg-public] [External Sender] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection In-Reply-To: <0100018ebc9e8f18-2fe265de-6f26-4721-922d-fb77683047bf-000000@email.amazonses.com> References: <0100018ebc9e8f18-2fe265de-6f26-4721-922d-fb77683047bf-000000@email.amazonses.com> Message-ID: Hi, wouldn't it have been a little kinder to wait for an answer to the question I asked on Friday 5? It may be that the answer was obvious, but it remains unclear to me where that 72 months comes from..... Adriano Il 08/04/2024 09:31, Martijn Katerbarg via Cscwg-public ha scritto: > > *Purpose of the Ballot* > > This ballot updates the ?Baseline Requirements for the Issuance and > Management of Publicly?Trusted Code Signing Certificates? version 3.7 > in order to clarify language regarding Timestamp Authority Private Key > Protection. The main goals of this ballot are to: > > 1. Require newly issued Timestamp Authority Subordinate CA Private > Keys to be stored in offline HSMs > 2. Add a requirement to remove Private Keys associated with Timestamp > Certificates after a 18 months > 3. Add a requirement to reject SHA-1 timestamp requests > > The following motion has been proposed by Martijn Katerbarg of Sectigo > and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. > > *MOTION BEGINS* > > This ballot updates the ?Baseline Requirements for the Issuance and > Management of Publicly?Trusted Code Signing Certificates? ("Code > Signing Baseline Requirements") based on version 3.7. MODIFY the Code > Signing Baseline Requirements as specified in the following > redline:https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 > > *MOTION ENDS* > > The procedure for this ballot is as follows: > > Discussion (7 days) > > * Start Time: 2024-04-08 09:00 UTC > * End Time: Not before 2024-04-15 17:00 UTC > > Vote for approval (7 days) > > * Start Time: TBD > * End Time: TBD > > > _______________________________________________ > Cscwg-public mailing list > Cscwg-public at cabforum.org > https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From martijn.katerbarg at sectigo.com Mon Apr 8 08:08:14 2024 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Mon, 8 Apr 2024 08:08:14 +0000 Subject: [Cscwg-public] [External Sender] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection In-Reply-To: References: <0100018ebc9e8f18-2fe265de-6f26-4721-922d-fb77683047bf-000000@email.amazonses.com> Message-ID: ?Hi Adriano, My apologies! It was in the past discussed about limiting timestamping to 72 or 75 months alltogether, then not requiring the SubCAs to be offline. The compromise here still allows up to 135 month timestamp certificates, if the SubCAs are offline. Mind you there?s no current limit to SubCA validity periods yet, but I would like to limit this to in a future ballot as well Regards, Martijn From: Adriano Santoni Date: Monday, 8 April 2024 at 09:47 To: cscwg-public at cabforum.org , Martijn Katerbarg Subject: Re: [External Sender] [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection Hi, wouldn't it have been a little kinder to wait for an answer to the question I asked on Friday 5? It may be that the answer was obvious, but it remains unclear to me where that 72 months comes from..... Adriano Il 08/04/2024 09:31, Martijn Katerbarg via Cscwg-public ha scritto: Purpose of the Ballot This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? version 3.7 in order to clarify language regarding Timestamp Authority Private Key Protection. The main goals of this ballot are to: 1. Require newly issued Timestamp Authority Subordinate CA Private Keys to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests The following motion has been proposed by Martijn Katerbarg of Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. MOTION BEGINS This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? ("Code Signing Baseline Requirements") based on version 3.7. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 MOTION ENDS The procedure for this ballot is as follows: Discussion (7 days) 1. Start Time: 2024-04-08 09:00 UTC 2. End Time: Not before 2024-04-15 17:00 UTC Vote for approval (7 days) 1. Start Time: TBD 2. End Time: TBD _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Mon Apr 8 08:35:47 2024 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Mon, 8 Apr 2024 10:35:47 +0200 Subject: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection In-Reply-To: References: <0100018ebc9e8f18-2fe265de-6f26-4721-922d-fb77683047bf-000000@email.amazonses.com> Message-ID: <8cad3c8f-b469-481a-b8a0-c206ee845ef4@staff.aruba.it> Hi Martijn, I can't find (in the call minutes) a past discussion about that, however I assume it's fine for everyone since I haven't seen any objections. Adriano Il 08/04/2024 10:08, Martijn Katerbarg ha scritto: > > Hi Adriano, > > My apologies! It was in the past discussed about limiting timestamping > to 72 or 75 months alltogether, then not requiring the SubCAs to be > offline. The compromise here still allows up to 135 month timestamp > certificates, if the SubCAs are offline. > > Mind you there?s no current limit to SubCA validity periods yet, but I > would like to limit this to in a future ballot as well > > Regards, > > Martijn > > *From: *Adriano Santoni > *Date: *Monday, 8 April 2024 at 09:47 > *To: *cscwg-public at cabforum.org , Martijn > Katerbarg > *Subject: *Re: [External Sender] [Cscwg-public] [Discussion Period > Begins] CSC-24 (v2): Timestamping Private Key Protection > > Hi, > > wouldn't it have been a little kinder to wait for an answer to the > question I asked on Friday 5? > > It may be that the answer was obvious, but it remains unclear to me > where that 72 months comes from..... > > Adriano > > Il 08/04/2024 09:31, Martijn Katerbarg via Cscwg-public ha scritto: > > *Purpose of the Ballot* > > This ballot updates the ?Baseline Requirements for the Issuance > and Management of Publicly?Trusted Code Signing Certificates? > version 3.7 in order to clarify language regarding Timestamp > Authority Private Key Protection. The main goals of this ballot > are to: > > 1. Require newly issued Timestamp Authority Subordinate CA > Private Keys to be stored in offline HSMs > 2. Add a requirement to remove Private Keys associated with > Timestamp Certificates after a 18 months > 3. Add a requirement to reject SHA-1 timestamp requests > > The following motion has been proposed by Martijn Katerbarg of > Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan > of Microsoft. > > *MOTION BEGINS* > > This ballot updates the ?Baseline Requirements for the Issuance > and Management of Publicly?Trusted Code Signing Certificates? > ("Code Signing Baseline Requirements") based on version 3.7. > MODIFY the Code Signing Baseline Requirements as specified in the > following > redline:https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 > > *MOTION ENDS* > > The procedure for this ballot is as follows: > > Discussion (7 days) > > 1. Start Time: 2024-04-08 09:00 UTC > 2. End Time: Not before 2024-04-15 17:00 UTC > > Vote for approval (7 days) > > 1. Start Time: TBD > 2. End Time: TBD > > > > _______________________________________________ > > Cscwg-public mailing list > > Cscwg-public at cabforum.org > > https://lists.cabforum.org/mailman/listinfo/cscwg-public > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From christophe.bonjean at globalsign.com Fri Apr 12 14:30:18 2024 From: christophe.bonjean at globalsign.com (Christophe Bonjean) Date: Fri, 12 Apr 2024 14:30:18 +0000 Subject: [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection In-Reply-To: <0100018ebc9e8ae2-3753523a-e207-4add-9eb8-c25f92268c9a-000000@email.amazonses.com> References: <0100018ebc9e8ae2-3753523a-e207-4add-9eb8-c25f92268c9a-000000@email.amazonses.com> Message-ID: Hi Martijn, Looking at the purpose of the ballot, the goal is to require newly issued [..] Private Keys to be stored in offline HSMs. The proposed change scopes this change to [keys related to] Root CA certificates and new Subordinate CA certificates I would recommend to scope this change to Private Keys generated after the effective date, instead of linking it to the issuing date of the Subordinate CA Certificate for those keys. For example if a CA issues a new Subordinate CA Certificate after this date, with an existing Private Key, then the related Private Key would need to be moved to an offline state. I think the intention is only for new keys to follow this requirement. Christophe From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Monday, April 8, 2024 9:32 AM To: cscwg-public at cabforum.org Subject: [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection Purpose of the Ballot This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? version 3.7 in order to clarify language regarding Timestamp Authority Private Key Protection. The main goals of this ballot are to: 1. Require newly issued Timestamp Authority Subordinate CA Private Keys to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests The following motion has been proposed by Martijn Katerbarg of Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. MOTION BEGINS This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? ("Code Signing Baseline Requirements") based on version 3.7. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 MOTION ENDS The procedure for this ballot is as follows: Discussion (7 days) * Start Time: 2024-04-08 09:00 UTC * End Time: Not before 2024-04-15 17:00 UTC Vote for approval (7 days) * Start Time: TBD * End Time: TBD -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8477 bytes Desc: not available URL: From adriano.santoni at staff.aruba.it Tue Apr 16 06:35:24 2024 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Tue, 16 Apr 2024 08:35:24 +0200 Subject: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection In-Reply-To: <0100018ed2b7a3a7-bb41b7eb-05bf-4351-80ac-75a84995dedf-000000@email.amazonses.com> References: <0100018ebc9e8ae2-3753523a-e207-4add-9eb8-c25f92268c9a-000000@email.amazonses.com> <0100018ed2b7a3a7-bb41b7eb-05bf-4351-80ac-75a84995dedf-000000@email.amazonses.com> Message-ID: <6e8192f4-352b-4700-b3e1-646b1328de58@staff.aruba.it> I concur with Christophe. Adriano Il 12/04/2024 16:30, Christophe Bonjean via Cscwg-public ha scritto: > > Hi Martijn, > > Looking at the purpose of the ballot, the goal is to require *newly > issued* [..] *Private Keys *to be stored in offline HSMs*.* > > ** > > The proposed change scopes this change to [keys related to] Root CA > certificates and *new Subordinate CA certificates* > > I would recommend to scope this change to Private Keys generated after > the effective date, instead of linking it to the issuing date of the > Subordinate CA Certificate for those keys. > > For example if a CA issues a new Subordinate CA Certificate after this > date, with an existing Private Key, then the related Private Key would > need to be moved to an offline state. I think the intention is only > for new keys to follow this requirement. > > Christophe > > *From:*Cscwg-public *On Behalf Of > *Martijn Katerbarg via Cscwg-public > *Sent:* Monday, April 8, 2024 9:32 AM > *To:* cscwg-public at cabforum.org > *Subject:* [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): > Timestamping Private Key Protection > > *Purpose of the Ballot* > > This ballot updates the ?Baseline Requirements for the Issuance and > Management of Publicly?Trusted Code Signing Certificates? version 3.7 > in order to clarify language regarding Timestamp Authority Private Key > Protection. The main goals of this ballot are to: > > 1. Require newly issued Timestamp Authority Subordinate CA Private > Keys to be stored in offline HSMs > 2. Add a requirement to remove Private Keys associated with Timestamp > Certificates after a 18 months > 3. Add a requirement to reject SHA-1 timestamp requests > > The following motion has been proposed by Martijn Katerbarg of Sectigo > and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. > > *MOTION BEGINS* > > This ballot updates the ?Baseline Requirements for the Issuance and > Management of Publicly?Trusted Code Signing Certificates? ("Code > Signing Baseline Requirements") based on version 3.7. MODIFY the Code > Signing Baseline Requirements as specified in the following > redline:https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 > > *MOTION ENDS* > > The procedure for this ballot is as follows: > > Discussion (7 days) > > * Start Time: 2024-04-08 09:00 UTC > * End Time: Not before 2024-04-15 17:00 UTC > > Vote for approval (7 days) > > * Start Time: TBD > * End Time: TBD > > > _______________________________________________ > Cscwg-public mailing list > Cscwg-public at cabforum.org > https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4620 bytes Desc: Firma crittografica S/MIME URL: From martijn.katerbarg at sectigo.com Tue Apr 16 10:06:36 2024 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Tue, 16 Apr 2024 10:06:36 +0000 Subject: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection In-Reply-To: <0100018ee59e3968-3fdfeedf-0ebd-4b54-8c21-9eed8b1bf0c9-000000@email.amazonses.com> References: <0100018ebc9e8ae2-3753523a-e207-4add-9eb8-c25f92268c9a-000000@email.amazonses.com> <0100018ed2b7a3a7-bb41b7eb-05bf-4351-80ac-75a84995dedf-000000@email.amazonses.com> <0100018ee59e3968-3fdfeedf-0ebd-4b54-8c21-9eed8b1bf0c9-000000@email.amazonses.com> Message-ID: ?Hi Christophe, Adriano, Thank you for the comments. I kind of think this may be a slight mismatch between what?s listed as the purpose of the ballot, vs the language included in the redline. However, I?m not sure I agree with your solution: > I would recommend to scope this change to Private Keys generated after the effective date, instead of linking it to the issuing date of the Subordinate CA Certificate for those keys. > For example if a CA issues a new Subordinate CA Certificate after this date, with an existing Private Key, then the related Private Key would need to be moved to an offline state. I think the intention is only for new keys to follow this requirement. Am I understanding correctly that you?re proposing that if CAs issue a new SubCA after the effective date using a key already in existance, you want them to keep using that CA in an online state? If so, that kindof defeats the purpose of this ballot. CA?s may have loads of parked private keys in their online HSMs, meaning if we scope it to when a key was generated, they could keep issuing new SubCAs for timestamping for many years to come in an online state. Instead, I think we could restate the purpose of the ballot to make it a bit more clear if we feel that may help, as: 1. Require Private Keys associated with newly issued Timestamp Authority Subordinate CA to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests Thoughts? (If so, I wonder, since the redline doesn?t change, only the ballot description, does it need a new ballot version?) Regards, Martijn From: Cscwg-public on behalf of Adriano Santoni via Cscwg-public Date: Tuesday, 16 April 2024 at 08:35 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection 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. I concur with Christophe. Adriano Il 12/04/2024 16:30, Christophe Bonjean via Cscwg-public ha scritto: Hi Martijn, Looking at the purpose of the ballot, the goal is to require newly issued [..] Private Keys to be stored in offline HSMs. The proposed change scopes this change to [keys related to] Root CA certificates and new Subordinate CA certificates I would recommend to scope this change to Private Keys generated after the effective date, instead of linking it to the issuing date of the Subordinate CA Certificate for those keys. For example if a CA issues a new Subordinate CA Certificate after this date, with an existing Private Key, then the related Private Key would need to be moved to an offline state. I think the intention is only for new keys to follow this requirement. Christophe From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Monday, April 8, 2024 9:32 AM To: cscwg-public at cabforum.org Subject: [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection Purpose of the Ballot This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? version 3.7 in order to clarify language regarding Timestamp Authority Private Key Protection. The main goals of this ballot are to: 1. Require newly issued Timestamp Authority Subordinate CA Private Keys to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests The following motion has been proposed by Martijn Katerbarg of Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. MOTION BEGINS This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? ("Code Signing Baseline Requirements") based on version 3.7. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 MOTION ENDS The procedure for this ballot is as follows: Discussion (7 days) * Start Time: 2024-04-08 09:00 UTC * End Time: Not before 2024-04-15 17:00 UTC Vote for approval (7 days) * Start Time: TBD * End Time: TBD _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From dean.coclin at digicert.com Tue Apr 16 13:55:32 2024 From: dean.coclin at digicert.com (Dean Coclin) Date: Tue, 16 Apr 2024 13:55:32 +0000 Subject: [Cscwg-public] CSCWG Agenda April 18, 2024 Message-ID: MINUTE TAKER: NEED A VOLUNTEER, START RECORDING Bruce will run the meeting as I have a conflict this week 1. Roll Call 2. Antitrust reminder 3. Approve prior meeting minutes - F2F (Andrea), March 21st (Brianca), April 4th (Scott) 4. Proposed ballots: Remove EV Guideline References 5. Proposed ballot for Time-stamp Requirements update; CSC-24 6. Other business 7. Next meeting - May 2nd 8. Adjourn Dean Coclin CSCWG Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5217 bytes Desc: not available URL: From dean.coclin at digicert.com Thu Apr 18 19:13:02 2024 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 18 Apr 2024 19:13:02 +0000 Subject: [Cscwg-public] Final minutes of CSCWG March 21, 2024 In-Reply-To: <0100018ecd77b8f9-bbdc86f2-3017-4848-b9a9-e79df27e95bb-000000@email.amazonses.com> References: <0100018ecd77b8f9-bbdc86f2-3017-4848-b9a9-e79df27e95bb-000000@email.amazonses.com> Message-ID: Minutes for CSCWG Call 21 Mar 2024 Agenda: 1. Roll Call 2. Antitrust reminder 3. Minutes 4. Ballots 5. Membership 6. Other business 7. Next meeting - April 4th 8. Adjourn Attendees: Dean Coclin (DigiCert), Martijn Katerbarg (Sectigo), Brianca Martin (Amazon), Tim Crawford (CPA Canada/WebTrust), Thomas Zermeno (SSL.com), Mohit Kumar (GlobalSign), Scott Rea (eMudhra, Mohit Kumar (GlobalSign), Dimitris Zacharopoulos (HARICA), Atsushi INABA (GlobalSign), Inigo Barreira (Sectigo) Minutes: Dean Coclin read the Antitrust policy. Meeting minutes - No minutes to approve. Andrea Holland working on minutes from F2F-New Delhi. Ballots * CSC-23, Marking the EV Code Signing Guidelines Obsolete, in the voting period, ends next week. Needs vote from Microsoft (only CA in the group). * Removing EV guidelines references (in discussion) - imported the latest changes from the CS BR's, ballot is ready, looking for 2 endorsers. EV will not be removed, will likely enhance the validation methods of the existing OV level. * Noted that a file on the wiki hasn't been changed in years. Not included in the guidelines, needs chair approval to remove it. * Timestamping Private Key Protection - Incorporated feedback, ready to start discussion period. Membership * Identrust - Current associate member, requesting transition to full membership in the CSWG. Server Cert Working Group (SCWG) approved them to be a full member. Each working group needs to approve their status, membership level can be different across groups. Ian (Microsoft) confirmed they have the appropriate root in Windows and the appropriate audit (link provided in the application). Request approved without objection. Dean to send confirmation to Marco. * Keyfactor - Request to upgrade to become an associate member in the CSWG. Noted for information that the request was approved by the SCWG. Status has traditionally been used for groups like FederalPKI, Webtrust, Etsy and companies that are in the process of applying for a root certificate in a browser. This would be the 1st time for the CSWG that a particular company would be given associate member status. It was noted that they run a CA platform that several CA/B forum members use, may not specifically be related to code signing. Discussion on Keyfactor was held at the forum level during the F2F meeting. Concern was raised about setting a bad precedent. Dean to discuss with Tim. Approval postponed to the next meeting. Other Business: None Meeting adjourned. Next meeting April 4th. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5217 bytes Desc: not available URL: From dean.coclin at digicert.com Thu Apr 18 19:13:33 2024 From: dean.coclin at digicert.com (Dean Coclin) Date: Thu, 18 Apr 2024 19:13:33 +0000 Subject: [Cscwg-public] Final CSCWG Minutes April 4, 2024 In-Reply-To: <0100018ec42bb398-07a13368-1dc2-4e2c-86ce-651cea16471b-000000@email.amazonses.com> References: <0100018ec42bb398-07a13368-1dc2-4e2c-86ce-651cea16471b-000000@email.amazonses.com> Message-ID: Minutes for CSCWG Call 4 Apr 2024 Agenda: 1. Roll Call 2. Antitrust reminder 3. Approve prior meeting minutes - F2F (awaiting draft from Andrea), March 21st (Brianca) 4. Ballot status: Marking the EV CS guidelines obsolete (CSC-23). Do we need an IPR review? 5. Proposed ballots: Remove EV Guideline References 6. Proposed ballot for Time-stamp Requirements update; CSC-24 7. Continued discussion on Application for Associate Member status from Keyfactor 8. Interested Party application from Wangmo Tenzing (as an individual) 9. Other business 10. Next meeting - April 18th 11. Adjourn Attendees: Brian Winters (Identrust), Bruce Morton (Entrust), Corey Bonnell (DigiCert), Dean Coclin (DigiCert), Ian McMillan (Microsoft), Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Marco Schambach - (IdenTrust), Mohit Kumar (GlobalSign), Nome Huang - (TrustAsia), Rollin Yu - (TrustAsia), Scott Rea (eMudhra), Tim Crawford - (CPA Canada/WebTrust), Trevoli Ponds-White - (Amazon), Minutes: Dean read the note well. Meeting minutes for F2F-New Delhi (Andrea Holland) yet to be posted. Meeting minutes for March 21, 2024 Meeting (Brianca Martin) yet to be posted. Ballot CSC-23 Marking the EV Code Signing Guidelines SUPERCEDED (Dean) This ballot passed, but the question has arisen whether there is need for an IPR review since all we are doing is marking these obsolete? (Bruce) there is nothing to present to lawyers, so what is there to review? Consensus on call is that IPR Review is not necessary in this case as agreed in WG call. Removing EVG references in CSBRs No recent update or status from Dimitris for removing references to EVGs. Since Dimitris is not on current call, this will be deferred to next meeting. Ballot CSC-24 Timestamping Private Key Protection Ballot was posted for discussion on 2 Apr 2024. Bruce raised concern that potential re-word was required because of NOT catering to Online CAs already in use. Mohit asked for clarification as to whether this only applied to future NEW CAs or whether it anticipated existing CAs to also be covered by the guideline. It is expected that some amendments will be applied to address the above, and a restart to the discussion period will apply. Individual Joiner Request Wangmo Tenzing from Lawrence Livermore National Lab originally sent IPR Agreement representing the Lab but clarified that this was rather meant to be an individual Interested Party and not as the Lab's representative. IPRA was withdrawn, and request resubmitted as an individual Interested Party. No objections from WG to accept Wangmo as individual Interested Party. Associate Member Application Follow on from previous meeting (and F2F meeting) where discussion was held regarding Key Factor's application to become an Associated Member. No objections from WG to accept Key Factor as Associate Members. Other Business: EV vs OV for Code Signing Request Microsoft to clarify their treatment of OV vs EV CS certs and where there is differentiation. (Ian) The only place of differentiation is on-boarding for the Hardware Developer Centre Partner Program, which makes a requirement for EV. There are no other current differentiation anywhere. Question from Bruce on how this is validated? (Ian) We are not looking at the OID in the cert, we are more looking at the issuing CA, since its only on application to the program. Microsoft is currently reviewing with the Hardware Developer Centre folks to work out how this will be dealt with in future. Clarification requested from Bruce on whether its the case that EV no longer helps with Reputation? (Ian) It is not the signer's reputation that is paramount rather than the credentials they are using. Clarification from Bruce as to whether Microsoft values SubjectInfo in EV certs? (Ian) There is not a focus to put any value on EV-specific fields. Clarification from Mohit as to whether that implies a move to OV in future? (Ian) Microsoft is evaluating the bar between OV and EV and looking to strike a balance between EV rigor and the effort for organizations around the world to get it. We are trying to make it as simple as possible for the ecosystem. So we are evaluating if an EV uplift is worth the value. Suggestion from Bruce: take current BRs, and remove all EV related content and see if it makes sense or whether the extra EV stuff is actually still needed? (Ian) The biggest challenge is how to provide clear communications to developers about which certificate is required. (Bruce) Perhaps the better approach is to decide where to go with this, and then just work towards that. Some discussion ensued about current validation of Organizations across all the CABF working groups, and Bruce pointed out we already have 3 ways today, and surely there was little value introducing a 4th specific to CS. To have further discussion at the next F2F. Meeting adjourned. Next meeting April 18th. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5217 bytes Desc: not available URL: From dzacharo at harica.gr Sun Apr 21 10:32:03 2024 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Sun, 21 Apr 2024 13:32:03 +0300 Subject: [Cscwg-public] Code Signing Baseline Requirements references to the EV Guidelines In-Reply-To: <0100018e2e505af0-23236d24-8375-4d3f-a137-58c870087851-000000@email.amazonses.com> References: <0100018ce92e4788-bc2dabd5-a686-4268-bbd8-8355a7c2877e-000000@email.amazonses.com> <684cfe16-3378-4e39-ab80-a38f3bac86f9@harica.gr> <0100018e2e505af0-23236d24-8375-4d3f-a137-58c870087851-000000@email.amazonses.com> Message-ID: On 11/3/2024 6:20 ?.?., Dimitris Zacharopoulos (HARICA) via Cscwg-public wrote: > > All, > > I re-based the importEVG branch to the latest CSBR (3.7.0). You can > see the ballot redline in > https://github.com/cabforum/code-signing/pull/38. Feel free to start a > review within the PR or reply to this thread with comments. > > Importing the EV Guidelines into the CSBRs ballot requires time to > review so I plan to give at least 2 weeks discussion period for > Members to check before starting the voting period. > > I have one remaining task which is to import the changes introduced by > Ballot SC68 . Other > than that, we should be good to go. I would like to ask for 2 > endorsers to reserve a ballot number. I added the language of Ballot SC68, fixed some numbering issues and reformatted the tables. Everything seems to be all set. Martijn and Corey have kindly offered to review the PR and hopefully they will also be able to endorse the ballot. You can also download the artifacts (.docx, .pdf, redline pdf) produced based on the latest commit. Please let me know if you have any questions or concerns. Best regards, Dimitris. > > > Thank you, > Dimitris. > > On 2/2/2024 1:59 ?.?., Dimitris Zacharopoulos (HARICA) wrote: >> Dear Members, >> >> Apologies for sending this late. Here is the mapping document for the >> import of the EV Guidelines into the CS Baseline Requirements. >> >> The process started from sections of the CSBRs that point to sections >> of the EV Guidelines. In some cases, the referenced EVG section, >> contained additional references within the EVG. The spreadsheet tried >> to capture and follow all those references to ensure we didn't miss >> anything. >> >> I hope this document will help the review process so we can proceed >> with a ballot. Before we do the ballot, we will have to rebase to the >> latest CSBR version and resolve any conflicts that may be caused by >> the last 2 ballots. My goal is to get this ready for a ballot after >> the next F2F meeting. >> >> >> Thank you, >> Dimitris. >> >> On 8/1/2024 3:06 ?.?., Dimitris Zacharopoulos (HARICA) via >> Cscwg-public wrote: >>> Dear Members, >>> >>> Following up on the work of importing the references to the EV >>> Guidelines and specifically the latest version (1.8.0) with the >>> exception of the CA/B Forum organization identifier extension as >>> agreed in previous meetings, the resulting redline (based on CSBR >>> version 3.4.0) is available in the following link: >>> >>> * https://github.com/cabforum/code-signing/compare/main...importEVG >>> >>> We can easily rebase to version 3.5.0 which is the latest CSBR >>> version, but the focus should be more on the import of the existing >>> EV references. >>> >>> The redline contains several formatting improvements as well, like >>> removal of double spaces and tabs that break the conversion. >>> >>> Here are my notes from the conversion: >>> >>> >>> - CSBR section 3.2.2.2 points to EV Guidelines >>> ? - Section 10.1.2 for specific roles (done) >>> ? - Section 11.2 for Legal Existence and Identity (done) >>> ? - Section 11.3 for Assumed Name (done) >>> ? - Section 11.4 for Physical Existence (done) >>> ? - Section 11.5 for Method of Communication (done) >>> ? - Section 11.6 for Operational Existence (done) >>> ? - Section 11.8 for Name, Title and Authority of Contract Signer >>> and Certificate Approver (done) >>> ? - Section 11.9 for Signature on Subscriber Agreement and EV CS >>> Certificate Requests (done) >>> ? - Section 11.10 for Approval of EV CS Certificate Request (done) >>> ? - Section 11.11 for Certain Information Sources (done) >>> ? - Section 11.12.3 for Parent/Subsidiary/Affiliate Relationship (done) >>> - CSBR section 4.1.1 points to EV Guidelines section 11.12.2 for >>> "suspicious" certificate requests (done new section 3.2.8) >>> - CSBR section 4.2.1 points to EV Guidelines >>> ?? - section 11.13 for the "due diligence" verification (done new >>> section 3.2.9) >>> ?? - section 11.14 for the usage periods of documents, data and >>> previous validations performed per section 3.2. (done with new >>> section 4.2.1.1) >>> - CSBR section 5.2.4 points to EV Guidelines section 11.13 for the >>> Final Cross-Correlation and Due Diligence steps (done by pointing to >>> the new section 3.2.9) >>> - CSBR section 5.3.3 points to EV Guidelines in general for the >>> Validation Specialist training and internal examination (done) >>> - CSBR section 7.1.4.2.4 points to EV Guidelines sections 9.2.1 >>> (done), 9.2.3 (done), 9.2.4 (done, section 11.1.3 disclosure of >>> verification sources migrated to 3.2.10), 9.2.5 (done), 9.2.6 >>> (done), 9.2.8 (done updated reference to 9.2.4 to 7.1.4.2.4 (c)) for >>> subject information >>> - CSBR section 9.2.1 points to EV Guidelines section 8.4 for >>> insurance coverage (done) >>> >>> >>> 9.8.2 --> Do not import >>> 11.11.1 --> 3.2.2.2.10.1 >>> 11.11.4 --> 3.2.2.2.12 >>> 11.13 --> 3.2.9 >>> 14.1.1, 14.1.2 --> 5.3 (Training and background checks) >>> 14.1.3 --> 5.2.4 (separation of duties) >>> 14.2 --> 1.3.2.1 (new section) >>> >>> We still need to do a thorough check for the import of the proper >>> definitions and acronyms and remove the ones that are not use in the >>> CSBRs with the first letter capitalized. >>> >>> I have not completed a full mapping of the import of the EVGs into >>> the CSBRs but that's my next target. Please note that some >>> destination sections are different from what Inigo has decided for >>> the conversion of the EVGs into the RFC 3647 format >>> . >>> We can compare notes with Inigo after we get some initial feedback >>> by Members. >>> >>> >>> Best regards, >>> Dimitris. >>> >>> On 2/10/2023 11:56 ?.?., Dimitris Zacharopoulos (HARICA) wrote: >>>> >>>> Dear Members, >>>> >>>> At a previous Teleconference I volunteered to search the CSBRs and >>>> find references to the EV Guidelines that could be discussed at the >>>> upcoming F2F. We can then decide if we want to import all or some >>>> of them to the CSBRs. >>>> >>>> The EV Guidelines that is -supposed to be- referenced is version 1.7.1. >>>> >>>> * CSBR section 3.2.2.2 points to EV Guideline: >>>> o Section 10.1.2 for specific roles >>>> o Section 11.2 for Legal Existence and Identity >>>> o Section 11.3 for Assumed Name >>>> o Section 11.4 for Physical Existence >>>> o Section 11.5 for Method of Communication >>>> o Section 11.6 for Operational Existence >>>> o Section 11.8 for Name, Title and Authority of Contract >>>> Signer and Certificate Approver >>>> o Section 11.9 for Signature on Subscriber Agreement and EV >>>> CS Certificate Requests >>>> o Section 11.10 for Approval of EV CS Certificate Request >>>> o Section 11.11 for Certain Information Sources >>>> o Section 11.12.3 for Parent/Subsidiary/Affiliate Relationship >>>> * CSBR section 4.1.1 points to EV Guidelines section 11.12.2 for >>>> "suspicious" certificate requests >>>> * CSBR section 4.2.1 points to EV Guidelines: >>>> o section 11.13 for the "due diligence" verification >>>> o section 11.14 for the usage periods of documents, data and >>>> previous validations performed per section 3.2 >>>> * CSBR section 5.2.4 points to EV Guidelines section 11.13 for >>>> the Final Cross-Correlation and Due Diligence steps >>>> * CSBR section 5.3.3 points to EV Guidelines in general for the >>>> Validation Specialist training and internal examination >>>> * CSBR section 7.1.4.2.4 points to EV Guidelines sections 9.2.1, >>>> 9.2.3, 9.2.4, 9.2.5, 9.2.6 for subject information >>>> * CSBR section 9.2.1 points to EV Guidelines section 8.4 for >>>> insurance coverage >>>> >>>> During this process, I also noticed that we have a capitalized term >>>> "EV Process" without a corresponding definition. I will add an >>>> issue on GitHub for the next cleanup ballot. >>>> >>>> I would appreciate a second review in case I missed something. >>>> >>>> >>>> Thank you, >>>> >>>> Dimitris. >>>> >>> >>> >>> _______________________________________________ >>> Cscwg-public mailing list >>> Cscwg-public at cabforum.org >>> https://lists.cabforum.org/mailman/listinfo/cscwg-public >> > > > _______________________________________________ > Cscwg-public mailing list > Cscwg-public at cabforum.org > https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijn.katerbarg at sectigo.com Mon Apr 22 08:17:58 2024 From: martijn.katerbarg at sectigo.com (Martijn Katerbarg) Date: Mon, 22 Apr 2024 08:17:58 +0000 Subject: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection In-Reply-To: <0100018ee65fa00c-9ae2ed16-cc78-4e25-b063-585cb93382f6-000000@email.amazonses.com> References: <0100018ebc9e8ae2-3753523a-e207-4add-9eb8-c25f92268c9a-000000@email.amazonses.com> <0100018ed2b7a3a7-bb41b7eb-05bf-4351-80ac-75a84995dedf-000000@email.amazonses.com> <0100018ee59e3968-3fdfeedf-0ebd-4b54-8c21-9eed8b1bf0c9-000000@email.amazonses.com> <0100018ee65fa00c-9ae2ed16-cc78-4e25-b063-585cb93382f6-000000@email.amazonses.com> Message-ID: ?All, Based on our discussion from last week, I?ve updated the proposed language. Please review the new commit, located at https://github.com/cabforum/code-signing/pull/34/commits/61d9426e9025d448a13eb56fa75b9651b2136548 and let me know if there are any further concerns blocking this ballot from moving forward. From: Cscwg-public on behalf of Martijn Katerbarg via Cscwg-public Date: Tuesday, 16 April 2024 at 12:06 To: Adriano Santoni , cscwg-public at cabforum.org , Christophe Bonjean Subject: Re: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection 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. Hi Christophe, Adriano, Thank you for the comments. I kind of think this may be a slight mismatch between what?s listed as the purpose of the ballot, vs the language included in the redline. However, I?m not sure I agree with your solution: > I would recommend to scope this change to Private Keys generated after the effective date, instead of linking it to the issuing date of the Subordinate CA Certificate for those keys. > For example if a CA issues a new Subordinate CA Certificate after this date, with an existing Private Key, then the related Private Key would need to be moved to an offline state. I think the intention is only for new keys to follow this requirement. Am I understanding correctly that you?re proposing that if CAs issue a new SubCA after the effective date using a key already in existance, you want them to keep using that CA in an online state? If so, that kindof defeats the purpose of this ballot. CA?s may have loads of parked private keys in their online HSMs, meaning if we scope it to when a key was generated, they could keep issuing new SubCAs for timestamping for many years to come in an online state. Instead, I think we could restate the purpose of the ballot to make it a bit more clear if we feel that may help, as: 1. Require Private Keys associated with newly issued Timestamp Authority Subordinate CA to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests Thoughts? (If so, I wonder, since the redline doesn?t change, only the ballot description, does it need a new ballot version?) Regards, Martijn From: Cscwg-public on behalf of Adriano Santoni via Cscwg-public Date: Tuesday, 16 April 2024 at 08:35 To: cscwg-public at cabforum.org Subject: Re: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection 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. I concur with Christophe. Adriano Il 12/04/2024 16:30, Christophe Bonjean via Cscwg-public ha scritto: Hi Martijn, Looking at the purpose of the ballot, the goal is to require newly issued [..] Private Keys to be stored in offline HSMs. The proposed change scopes this change to [keys related to] Root CA certificates and new Subordinate CA certificates I would recommend to scope this change to Private Keys generated after the effective date, instead of linking it to the issuing date of the Subordinate CA Certificate for those keys. For example if a CA issues a new Subordinate CA Certificate after this date, with an existing Private Key, then the related Private Key would need to be moved to an offline state. I think the intention is only for new keys to follow this requirement. Christophe From: Cscwg-public On Behalf Of Martijn Katerbarg via Cscwg-public Sent: Monday, April 8, 2024 9:32 AM To: cscwg-public at cabforum.org Subject: [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection Purpose of the Ballot This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? version 3.7 in order to clarify language regarding Timestamp Authority Private Key Protection. The main goals of this ballot are to: 1. Require newly issued Timestamp Authority Subordinate CA Private Keys to be stored in offline HSMs 2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 3. Add a requirement to reject SHA-1 timestamp requests The following motion has been proposed by Martijn Katerbarg of Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. MOTION BEGINS This ballot updates the ?Baseline Requirements for the Issuance and Management of Publicly?Trusted Code Signing Certificates? ("Code Signing Baseline Requirements") based on version 3.7. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 MOTION ENDS The procedure for this ballot is as follows: Discussion (7 days) * Start Time: 2024-04-08 09:00 UTC * End Time: Not before 2024-04-15 17:00 UTC Vote for approval (7 days) * Start Time: TBD * End Time: TBD _______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org https://lists.cabforum.org/mailman/listinfo/cscwg-public -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 8254 bytes Desc: not available URL: From dean.coclin at digicert.com Tue Apr 30 20:21:06 2024 From: dean.coclin at digicert.com (Dean Coclin) Date: Tue, 30 Apr 2024 20:21:06 +0000 Subject: [Cscwg-public] CSCWG Agenda May 2, 2024 In-Reply-To: References: <0100018ee7311c62-c29acc48-63bd-4046-ae95-3739ce164d40-000000@email.amazonses.com> Message-ID: MINUTE TAKER: NEED A VOLUNTEER, START RECORDING 1. Roll Call 2. Antitrust reminder 3. Approve prior meeting minutes - F2F (Andrea), April 18th (Corey) 4. Proposed ballots: Remove EV Guideline References 5. Proposed ballot for Time-stamp Requirements update; CSC-24 6. Discuss F2F Agenda 7. Other business 8. Next meeting - May 16th 9. Adjourn Dean Coclin CSCWG Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5227 bytes Desc: not available URL: