[Cscwg-public] [External Sender] Re: Timestamp Certificate and SubCA updates
Adriano Santoni
adriano.santoni at staff.aruba.it
Fri Apr 5 06:53:20 UTC 2024
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 <ianmcm at microsoft.com>
> *Date: *Thursday, 4 April 2024 at 19:54
> *To: *Martijn Katerbarg <martijn.katerbarg at sectigo.com>,
> cscwg-public at cabforum.org <cscwg-public at cabforum.org>, Mohit Kumar
> <mohit.kumar at globalsign.com>
> *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 <cscwg-public-bounces at cabforum.org> *On Behalf Of
> *Martijn Katerbarg via Cscwg-public
> *Sent:* Thursday, April 4, 2024 6:07 AM
> *To:* Mohit Kumar <mohit.kumar at globalsign.com>; 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 <mohit.kumar at globalsign.com
> <mailto:mohit.kumar at globalsign.com>>
> *Date: *Thursday, 4 April 2024 at 04:19
> *To: *Martijn Katerbarg <martijn.katerbarg at sectigo.com
> <mailto:martijn.katerbarg at sectigo.com>>, cscwg-public at cabforum.org
> <mailto: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
>
> 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
> <mailto: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 <mailto:cscwg-public at cabforum.org>;
> Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr
> <mailto:dzacharo at harica.gr>>
> *Subject:* Re: [Cscwg-public] Timestamp Certificate and SubCA updates
>
> The language (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%7C6b3466de38b944c4e95508dc54d04b7f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638478500818433702%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bvH%2B3sXZ2FajBydG%2BKx%2FPq2IGaDyaMUBjpE%2FI5tOw3A%3D&reserved=0>)
> has been further updated
> (https://github.com/cabforum/code-signing/pull/34/commits/9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F34%2Fcommits%2F9288f7ec376b4bbd139dcb596bcb2d1bf9bd7683&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C6b3466de38b944c4e95508dc54d04b7f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638478500818443934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=gijk9MMkc%2FBgJ1ixouYmXL%2B6ELmREaVwDy%2BlvODTNb0%3D&reserved=0>)
> 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
> <mailto:cscwg-public-bounces at cabforum.org>> on behalf of Martijn
> Katerbarg via Cscwg-public <cscwg-public at cabforum.org
> <mailto:cscwg-public at cabforum.org>>
> *Date: *Monday, 11 March 2024 at 09:51
> *To: *Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr
> <mailto:dzacharo at harica.gr>>, cscwg-public at cabforum.org
> <mailto: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.
>
> 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
> <mailto:dzacharo at harica.gr>>
> *Date: *Monday, 11 March 2024 at 09:48
> *To: *Martijn Katerbarg <martijn.katerbarg at sectigo.com
> <mailto:martijn.katerbarg at sectigo.com>>, cscwg-public at cabforum.org
> <mailto: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.
>
> 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
> <mailto: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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fpull%2F34&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C6b3466de38b944c4e95508dc54d04b7f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638478500818451355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xFI1fEshQ6bVGbv7Fkhiq50yu3aQVtlnHsItYzjbHnc%3D&reserved=0>
>
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C6b3466de38b944c4e95508dc54d04b7f%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638478500818457689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=auRwiJgcdQwhLAicHeqXhVIawOMAwJkM6odGMr%2BRYOY%3D&reserved=0>
>
>
> _______________________________________________
> 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/20240405/77595b30/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/20240405/77595b30/attachment-0001.p7s>
More information about the Cscwg-public
mailing list