[Cscwg-public] Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Nov 11 18:42:02 UTC 2021
Hello Ian,
I noticed that you have not set an effective date for all these changes.
It would be best if the ballot itself contained updates to the table in
section 1.3. With that said, section 16.2 probably needs an effective
date because it requires signing services to use at least FIPS 140-2
level 2, or Common Criteria EAL 4+ for ALL Code Signing Certificates (it
used to apply only for EV CS Certificates).
When you say "conforming to *at least* FIPS 140-2 level 2, or Common
Criteria EAL 4+", does the "at least" apply only for the first part
(FIPS 140-2 level 2) or does it also extend to the second part (Common
Criteria EAL 4+)? I'm not 100% sure how it is used in the English
language and since it is possible to have non-native English speakers
interpreting these requirements (CAs and auditors), I thought it's best
to ask for clarifications.
While still on section 16.2, I believe the introduction of the term
"cloud-base*d*" (please correct the typo), "subscription and usage
pattern" needs to be defined and/or clarified. Similarly for the "cloud
solution" in 2a. We may need some assistance from providers offering
cloud key management services to reach good language for this. We can
certainly try ourselves and see what happens :-)
In 16.3.1, under the new numbered item 1.,
"1. Subscriber hosts a hardware crypto module meeting the specified
requirement; "
does not mean that the key will be protected in that hardware crypto
module. As written, a subscriber could just present that they own a
compliant device and would meet the requirement without the need for
them to actually use it.
Following similar language as 2. and 3., I would recommend changing this to:
"1. Subscriber uses a hosted hardware crypto module meeting the
specified requirements;"
I have some concerns about 2. which are related to the
definition/clarifications described above for "cloud-based" key
management solutions. In my opinion these are not any different from
"signing services", which are entities that manage keys on behalf of the
Subscribers. Having two similar terms for similar things is a bit confusing.
Section 16.3 should be more about Private Key *generation**, use* and
protection. The "verification" part sounds a bit strange for me. 16.3.2
is more about the subscriber key generation part, and assurances that
the key generation is done properly according to the specified requirements.
Finally, some small recommendations for 16.3.2.
"1. The CA ships a suitable hardware crypto module, with a
preinstalled key pair" could be changed to:
"1. The CA ships a suitable hardware crypto module, with one or more
pre-generated key pairs that the CA has generated using those crypto
modules"
"2. The Subscriber counter-signs certificate requests that can be
verified by using a manufacturer’s certificate indicating that the key
is managed in a suitable hardware module; " to
"2. The Subscriber counter-signs certificate requests that can be
verified by using a manufacturer’s certificate indicating that the key
was generated in a suitable hardware module in a non-exportable way;"
I thought we agreed to remove option 4. (a suitable IT audit indicating
a FIPS 140-2 level 2 or equivalent) because we didn't hear auditors or
CAs using that option and it is very ambiguous and risky. I would love
to see this go and I believe September 2022 is a reasonable timeframe to
deprecate this practice.
For 6., the "cloud-based" again sounds confusing to me because they are
effectively "signing services". They generate and protect the subscriber
keys on their behalf.
"8. Any other method the CA uses satisfy this requirement SHALL be
specified in the CPS and must be proposed to the CA/Browser Forum for
inclusion into these requirements within a 6-month period." to
"8. Any other method the CA uses to satisfy this requirement. The CA
SHALL specify and describe in detail those other methods in its
Certificate Policy or Certification Practice Statement, and SHALL
propose those methods to the CA/Browser Forum Code Signing Working Group
for inclusion into these requirements until April 1, 2022, using the
questions at cabforum.org mailing list. After that date, the Code Signing
Working Group will discuss the removal of this "any other method" and
allow only CA/Browser Forum approved methods."
I hope that was not too painful for you to read :-)
Dimitris.
On 11/11/2021 3:36 μ.μ., Ian McMillan via Cscwg-public wrote:
>
> Hi Folks,
>
> After a brief side conversation with Bruce, I’ve made some further
> edits to the redline draft to include the CA prescribed CSP and
> suitable hardware crypto module scenario raised in the last call.
>
> Please review the attached redline now and let me know if you have any
> feedback and if you are willing to endorse this ballot.
>
> Thanks,
>
> Ian
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of
> *Ian McMillan via Cscwg-public
> *Sent:* Tuesday, November 9, 2021 8:35 AM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>; cscwg-public at cabforum.org
> *Subject:* [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed Ballot
> CSC-6: Update to Subscriber Private Key Protection Requirements
>
> Thanks Bruce!
>
> Really appreciate the help with the new redline draft. I’ve added the
> effective date of September 1, 2022 for this change to private key
> protection requirements. That seems reasonable and better than placing
> a date closer to major events in the calendar year (e.g. end of year
> holiday season).
>
> The other thing that isn’t sitting well with me is the Signing Service
> requirements section 16.2, so I added the cloud-based key protection
> to the list of techniques that MAY be used for protecting the private
> keys of subscribers in a Signing Service. I know this section will
> have considerable overhauling in the very near future, so I only would
> like to add this minor update.
>
> For everyone, please see that new attached redline now. Also please
> let me know if you are willing to endorse the ballot.
>
> Thanks,
>
> Ian
>
> *From:* Bruce Morton <Bruce.Morton at entrust.com>
> *Sent:* Thursday, November 4, 2021 3:00 PM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>;
> cscwg-public at cabforum.org; Ian McMillan <ianmcm at microsoft.com>
> *Subject:* [EXTERNAL] RE: Discussion: Proposed Ballot CSC-6: Update to
> Subscriber Private Key Protection Requirements
>
> Hi Ian,
>
> Great meeting. Looks like we are making progress now. It will be nice
> to get this behind us.
>
> Since the change will impact the CAs, we need the ballot to have an
> effectivity date. As such, we need to keep the current requirements as
> is with no change. We will also add in the new requirements and have
> them be effective on a future date. It is understood that the CAs may
> implement the requirement before that date.
>
> Attached is a draft with the idea. I used the latest version of the
> CSBRs and captured most of the changes.
>
> It would be great, if the CAs could provide some feedback on an
> effective date.
>
> Thanks, Bruce.
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of
> *Bruce Morton via Cscwg-public
> *Sent:* Wednesday, November 3, 2021 1:21 PM
> *To:* Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org
> *Subject:* [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed Ballot
> CSC-6: Update to Subscriber Private Key Protection Requirements
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know
> the content is safe.
>
> ------------------------------------------------------------------------
>
> Hi Ian,
>
> Thanks for the proposal. Please find your document with some edits. I
> wanted to state that the subscriber could use a Signing Service to
> protect the private key. In addition I tried to reduce the number of
> “FIPS 140-2 Level 2 or Common Criteria EAL 4+” call outs as I am sure
> they will not remain consistent.
>
> Looking forward to the discussion tomorrow.
>
> Thanks again, Bruce.
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org> *On Behalf Of
> *Ian McMillan via Cscwg-public
> *Sent:* Wednesday, November 3, 2021 10:58 AM
> *To:* cscwg-public at cabforum.org
> *Subject:* [EXTERNAL] [Cscwg-public] Discussion: Proposed Ballot
> CSC-6: Update to Subscriber Private Key Protection Requirements
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know
> the content is safe.
>
> ------------------------------------------------------------------------
>
> Hi Folks,
>
> I’ve found the time to write up the subscriber private key protection
> update under a proposed Ballot CSC-6. Please review the attached
> redline doc and provide feedback. Also, please let me know if you are
> willing to endorse this ballot.
>
> cscwg:csc_6_-_update_to_subscriber_private_key_protection_requirements
> [CAB Forum Wiki]
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwiki.cabforum.org%2Fcscwg%2Fcsc_6_-_update_to_subscriber_private_key_protection_requirements__%3B!!FJ-Y8qCqXTj2!JFXFBvuicNpp5JGeK1TvRJ-6eotM5fhSRjTUe2CUTty2HljPYkdltIcLdAbGX374fBk%24&data=04%7C01%7Cianmcm%40microsoft.com%7Ccc354d4529b4414011a408d9a385cb2d%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637720617753249627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9TMurjkZZoqTbBZgq20%2Bc1Y5qv%2FmOUOhb%2FJ8x6iyzvY%3D&reserved=0>
>
> Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
>
> Purpose of this ballot: Update the subscriber private key protection
> requirements in the Baseline Requirement for the Issuance and
> Management of Publicly-Trusted Code Signing Certificates v2.5. The
> following motion has been proposed by Ian McMillan of Microsoft, and
> endorsed by <Name + Org> and <Name + Org>.
>
> — MOTION BEGINS — This ballot updates the “Baseline Requirements for
> the Issuance and Management of Publicly‐Trusted Code Signing
> Certificates“ version 2.5 according to the attached redline which
> includes:
>
> * Update section 16.3 “Subscriber Private Key Protection” to
> “Subscriber Private Key Protection and Verification”
> * Update section 16.3 “Subscriber Private Key Protection” to include
> sub-sections “16.3.1 Subscriber Private Key Protection” and
> “16.3.2 Subscriber Private Key Verification”
> * Update section 16.3 under new sub-section 16.3.1 to remove
> allowance of TPM key generation and software protected private key
> protection, and remove private key protection requirement
> differences between EV and non-EV Code Signing Certificates
> * Update section 16.3 under new sub-section 16.3.1 to include the
> allowance of key generation and protection using a cloud-based key
> protection solution providing key generation and protection in a
> hardware crypto module that conforms to at least FIPS 140-2 Level
> 2 or Common Criteria EAL 4+
> * Update section 16.3 under new sub-section 16.3.2 to include
> verification for Code Signing Certificates' private key generation
> and storage in a crypto module that meets or exceeds the
> requirements of FIPS 140-2 level 2 or Common Criteria EAL 4+ by
> the CAs. Include additional acceptable methods for verification
> including cloud-based key generation and protection solutions and
> a stimpulation for CAs to satisfy this verification requirement
> with additional means specified in their CPS. Any additional means
> specified by a CA in their CPS, must be proposed to the CA/Browser
> Forum for inclusion into the acceptable methods for section 16.3.2
> within 6 months of inclusion in their CPS.
>
> — MOTION ENDS —
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7 days) Start Time: TBD End Time: TBD
>
> Vote for approval (7 days) Start Time: TBD End Time: TBD
>
> Thanks,
>
> Ian
>
> /Any email and files/attachments transmitted with it are confidential
> and are intended solely for the use of the individual or entity to
> whom they are addressed. If this message has been sent to you in
> error, you must not copy, distribute or disclose of the information it
> contains. _Please notify Entrust immediately_ and delete the message
> from your system./
>
>
> _______________________________________________
> 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/20211111/b11c09b5/attachment-0001.html>
More information about the Cscwg-public
mailing list