[Cscwg-public] Timestamp Certificate and SubCA updates
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Mon Mar 11 08:48:29 UTC 2024
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 <cscwg-public-bounces at cabforum.org> on behalf of
> Dimitris Zacharopoulos (HARICA) via Cscwg-public
> <cscwg-public at cabforum.org>
> *Date: *Sunday, 10 March 2024 at 10:30
> *To: *cscwg-public at cabforum.org <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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F34&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C5e8ff97a46964cd97d6f08dc40e4b919%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638456598304253222%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jt5w8Oh%2BJS%2FZ%2FFyU%2BGCERgmT7hq6frpyLwiKUhEVRFw%3D&reserved=0>
>
> 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 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C5e8ff97a46964cd97d6f08dc40e4b919%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638456598304262389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PKc6BBon3Qd4VpovT%2FWFINg69tG6ltUfhyIMe77pwAY%3D&reserved=0>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240311/618b32d7/attachment-0001.html>
More information about the Cscwg-public
mailing list