[Cscwg-public] [External Sender] Re: Timestamp Certificate and SubCA updates
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu Apr 4 06:36:04 UTC 2024
+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 <cscwg-public-bounces at cabforum.org> *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)
> <dzacharo at harica.gr>
> *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)
> <mailto:dzacharo at harica.gr> 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 <cscwg-public-bounces at cabforum.org> on behalf of
> Martijn Katerbarg via Cscwg-public <cscwg-public at cabforum.org>
> *Date: *Monday, 11 March 2024 at 09:51
> *To: *Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>,
> 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.
>
> Works for me on both fronts. I’ll leave the discussion open for a bit
> so others can add on.
>
> *From: *Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Date: *Monday, 11 March 2024 at 09:48
> *To: *Martijn Katerbarg <martijn.katerbarg at sectigo.com>,
> 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.
>
> 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>
> <mailto:cscwg-public-bounces at cabforum.org> on behalf of Dimitris
> Zacharopoulos (HARICA) via Cscwg-public
> <cscwg-public at cabforum.org> <mailto:cscwg-public at cabforum.org>
> *Date: *Sunday, 10 March 2024 at 10:30
> *To: *cscwg-public at cabforum.org <cscwg-public at cabforum.org>
> <mailto: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: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240404/0e668ac8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240404/0e668ac8/attachment-0001.p7s>
More information about the Cscwg-public
mailing list