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-boun...@cabforum.org> on behalf of
Dimitris Zacharopoulos (HARICA) via Cscwg-public
<cscwg-public@cabforum.org>
*Date: *Sunday, 10 March 2024 at 10:30
*To: *cscwg-public@cabforum.org <cscwg-public@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@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>
_______________________________________________
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public
