[Cscwg-public] Question about "Certificates transported outside of a Signing Service"

[Bruce Morton]

This is precisely why we need to review and update Signing Service.

I thought the premise of the Signing Service was for a service to both generate the key and permit activation of the key.

So I don't recall the background and agree that it doesn't make sense. Hopefully our work on the Signing Service will fix these issues.


Bruce.

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Corey Bonnell via Cscwg-public
Sent: Friday, August 13, 2021 1:52 PM
To: cscwg-public at cabforum.org
Subject: [EXTERNAL] [Cscwg-public] Question about "Certificates transported outside of a Signing Service"

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Hello,
I'm currently working through the CSBRs and moving the content into RFC 3647 format and I encountered a requirement that is unclear. Section 10.2.4 (Subscriber Private key) states:

"For Certificates transported outside of a Signing Service's secure infrastructure, the CA or Signing
Service MUST require, by contract, each Subscriber to generate their own Private Key and protect
the Private Key in accordance with Section 16.2 ("Private Key Protection")."

Certificates are bundled with signed binaries, so they by necessity will be "transported outside a Signing Service's secure infrastructure". So I believe this requirement, as written, doesn't make a lot of sense. It may be speaking to Private keys instead of Certificates, which may make more sense, but still isn't clear. If the Subscriber is required to generate a key pair after migrating their private key out of a Signing Service, they won't be able to use their current Certificate for future signing operations (since they key pair will have changed). The net result of this reading is that key export from a Signing Service would not be allowed.

It appears this language has been around for some time (it exists as-is in v1.2). Does anyone have any insight into what this requirement is attempting to convey?

Thanks,
Corey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210813/57d89b3d/attachment.html>