[Servercert-wg] Subscriber key pair generation by the CA
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri May 29 10:31:24 MST 2020
Ryan,
My response to Pedro was specific to his comment about 6.1.1.1 and was
related only to subCA keys, not Subscriber keys. If we want to discuss
6.1.1.1 further, perhaps it would be best to start a new thread.
Thanks,
Dimitris.
On 2020-05-29 6:59 μ.μ., Ryan Sleevi via Servercert-wg wrote:
> 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
> <http://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
> <mailto: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 <mailto: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 <mailto:sleevi at google.com>>
>> *Sent:* Thursday, May 28, 2020 7:47:24 PM
>> *To:* Jeremy Rowley <jeremy.rowley at digicert.com
>> <mailto:jeremy.rowley at digicert.com>>
>> *Cc:* Clint Wilson <clintw at apple.com <mailto:clintw at apple.com>>;
>> CA/B Forum Server Certificate WG Public Discussion List
>> <servercert-wg at cabforum.org <mailto: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 <mailto: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
>> <mailto:servercert-wg-bounces at cabforum.org>> on behalf of
>> Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org
>> <mailto:servercert-wg at cabforum.org>>
>> *Sent:* Thursday, May 28, 2020 4:03:31 PM
>> *To:* Clint Wilson <clintw at apple.com <mailto:clintw at apple.com>>
>> *Cc:* CA/B Forum Server Certificate WG Public Discussion List
>> <servercert-wg at cabforum.org <mailto: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 <mailto: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 <mailto: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
>>> <mailto: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
>>> <mailto:Servercert-wg at cabforum.org>
>>> http://cabforum.org/mailman/listinfo/servercert-wg
>>>
>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org <mailto: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 <tel:+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.
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200529/0b62c8e4/attachment-0001.html>
More information about the Servercert-wg
mailing list