[Servercert-wg] Subscriber key pair generation by the CA

Ryan Sleevi sleevi at google.com
Fri May 29 08:59:49 MST 2020


I'm not sure I follow Dimitris' reply, and I think he may be looking at it
differently, but I would say that the primary difference between these
scenarios is tied to audits and key protection.

If the Root generates a key for a Subordinate, and they later transfer
control of that Subordinate key*, there's both BR policy and Root Policy
regarding the continual protection, both physical and logical, of that key
material, there is supporting audit evidence regarding that, and there are
additional Root Store specific policies about ensuring the continuity and
reporting.

It's certainly possible to envisage a system where we allowed CAs to
generate keys for Subscribers, but that would require far more attention to
what the CA can and cannot do. For example, explicitly prohibiting escrow
by the CA (with the Root/Subordinate CA case already does, by virtue of the
audit regime), coupled strong normative requirements regarding key
protection and delivery. You can see that already semi-reflected in the
6.1.2 ("communicated to an unauthorized person or an organization not
affiliated with the Subscriber"); however, that section would need to be
replaced and, in line with the approach done to 3.2.2.4, enumerate explicit
methods that are permitted for key transport/delivery and the validation of
authorization and** affiliation.

This doesn't close all the loopholes. The most obvious one is that this
prohibits CAs from generating the key, but does not prohibit Affiliates of
the CA from generating the key. That is a necessary loophole, for better or
worse, because it's what permits providers like Amazon or GoDaddy to
provide hosting services, and avoids even messier interactions where the
Subscriber is an Affiliate of the CA, and they generate the key themselves,
but would violate such a requirement if it existed, which is why it doesn't.

>From our point of view, one of the big reasons we think CAs shouldn't
generate Subscriber Keys is that it creates a risk for Subscribers that
Subscribers themselves cannot (meaningfully) manage. When we delegate the
trust our users place in us to a CA, by trusting that CA in our products,
we grant them a position of privilege when compared to other CAs that we do
not trust and delegate the security of our users to. For a variety of
technical reasons due the necessary complexity of interoperability, and by
necessity of security, the number of CAs a Subscriber can work with and
interoperate with both our products and other products is limited. Without
this prohibition, it's not inconceivable to see CAs attempting to REQUIRE
that they generate the Key for the Subscriber, which may allow the CA, or
anyone the CA chooses, to compromise the security of our users in ways that
are not detectable to our users or to the Subscriber. That's not acceptable
for us, and so we want to ensure that the CA is not a party to the key
generation, in order to ensure the Subscriber has full control over
managing their risk and key protection.

Subordinate CAs, and Root CAs, are different, in that we address the risks
to our users and Subscribers through supervision and audits. While that
scales for intermediate CAs, it simply is not viable to suggest for all
Subscribers with server certificates.


* Note: I phrased it like this to distinguish from "generated for an
externally operated subordinate" because that implies an intent at key
generation, where I'm talking about control transfers during the lifetime
of the key, which ignores 'intent'.

** Note 2: This is "and", not the current "or" or an "and/or", because
communicating a private key to an Affiliate of the Subscriber doesn't mean
the Affiliate is authorized; e.g. giving a key to google.com to a Waymo
employee would still be a Very Bad Thing, and is in line with things like
CAA and the list of Authorized Applicants in writing (Section 3.2.5,
paragraph 3) as a loophole to close.

On Fri, May 29, 2020 at 2:32 AM Pedro FUENTES <pfuentes at wisekey.com> wrote:

> I just wonder what are the implications on the parallel discussion on
> 6.1.1.1
>
> Why should it be allowed then that a Root generates the key for an
> externally-operated subordinate? We don’t do it and I personally think is a
> bad practice.
>
> On 29 May 2020, at 03:57, Jeremy Rowley via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> I only deal in edge cases. :)
>
> Okay, the follow up to that. What obligation does the ca have to check
> that a key isn't being used for tls that they generate for smime or client
> auth? We've been looking at key reuse (in connection with revocation) and
> there does seem to be some sharing of keys between certs.
> ------------------------------
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Thursday, May 28, 2020 7:47:24 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* Clint Wilson <clintw at apple.com>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Subscriber key pair generation by the CA
>
> Always with the edge cases ;) It's good to be thinking about that, though!
>
> As worded, the definitions for CA say:
> Certification Authority: An organization that is responsible for the
> creation, issuance, revocation, and management of Certificates. The term
> applies equally to both Roots CAs and Subordinate CAs.
>
> So the question is which organization is generating the key. If I generate
> key on my MacBook Pro, using an Apple-provided copy of BoringSSL, would it
> be reasonable to say that Apple generated my Key Pair? I don't think so, so
> I think you'd be fine.
>
> If your software makes a webservice call to some DigiCert endpoint, and
> this DigiCert endpoint generates a key pair and returns it, I would say
> yes, DigiCert did generate the key pair then.
>
> On Thu, May 28, 2020 at 9:07 PM Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
> Question. Would this be violated if the CA had software that was on prem
> at the client that incorporated a key gen tool? Technically it's the tool
> generating the key, but it is software provided by the CA. Is that
> considered a violation?
> ------------------------------
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org>
> *Sent:* Thursday, May 28, 2020 4:03:31 PM
> *To:* Clint Wilson <clintw at apple.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Subscriber key pair generation by the CA
>
> https://github.com/sleevi/cabforum-docs/pull/25
>
> On Thu, May 28, 2020 at 5:06 PM Clint Wilson <clintw at apple.com> wrote:
>
> We’re supportive of incorporating this into the browser alignment ballot.
> Thanks for spotting and raising this, Adriano!
>
> On May 27, 2020, at 7:04 AM, Ryan Sleevi <sleevi at google.com> wrote:
>
> This seems like something easy to add to the Browser Alignment draft
> ballot, and something Google would support.
>
> Mike, Clint: Do you have opinions here on behalf of Microsoft and Apple?
> I'm loathe to add additional requirements after y'all already reviewed, but
> this does seem worth tackling.
>
> On Wed, May 27, 2020 at 9:37 AM Adriano Santoni via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> All,
>
> tt seems to me there's an inconsistency between §5.2 of Mozilla Root
> Policy, which very clearly prohibits CAs from generating Subscribers' key
> pairs for SSL Server certs, and §6.1.2 of the BR which seemingly allows
> that. It would seem logical, and should not harm any CAs, if it was
> clarified in the BR that subscriber key pair generation by the CA is not
> allowed, in line with the requirement set forth in Mozilla Root Policy.
>
> What do the people here think?
>
> Adriano
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
>
>
>
> *WISeKey SA*
>
> *Pedro Fuentes*CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00 <+41%2022%20594%2030%2000>
> Mobile: + 41 (0) 791 274 790
> Address: 29, Rte de Pré-Bois - CP 853 | Geneva 1215 CH - Switzerland
>
> *Stay connected with WISeKey <http://www.wisekey.com>*
> *THIS IS A TRUSTED MAIL*: This message is digitally signed with a WISeKey
> identity. If you get a mail from WISeKey please check the signature to
> avoid security risks
>
> *CONFIDENTIALITY: *This email and any files transmitted with it can be
> confidential and it’s intended solely for the use of the individual or
> entity to which they are addressed. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. If you have
> received this email in error please notify the sender
>
> *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of
> this message and does not accept any liability for any errors or
> omissions herein as this message has been transmitted over a public
> network. Internet communications cannot be guaranteed to be secure or
> error-free as information may be intercepted, corrupted, or contain
> viruses. Attachments to this e-mail are checked for viruses; however, we do
> not accept any liability for any damage sustained by viruses and therefore
> you are kindly requested to check for viruses upon receipt.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200529/b2737218/attachment-0001.html>


More information about the Servercert-wg mailing list