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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Fri May 29 00:29:06 MST 2020



On 2020-05-29 9:32 π.μ., Pedro FUENTES via Servercert-wg 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.

Why do you think it's a bad practice? A well-audited CA can generate a 
CA key in a much more controlled environment than an 
externally-unaudited environment (if we are talking about a 
Technically-Constrained subCA per 7.1.5 of the BRs) operated by another 
organization. Perhaps you are not capturing all use cases. We (HARICA) 
don't do it either but that doesn't mean it's unreasonable for some use 
cases that need this process. Perhaps if we had such a use case, we 
would also follow this practice and we would probably prefer generating 
the key at a RootCA (organization) level and transfer it, than trust an 
external organization for doing this CA key generation process 
correctly, even with this being witnessed by an Auditor.

My interpretation of the requirement to have an auditor witness the key 
generation ceremony outside the controlled environment of the "Root CA", 
is to ensure that the minimum security conditions are met and the key is 
generated and protected securely. Without this assurance, the RootCA 
doesn't know about the quality of the key and might sign a subCA 
Certificate that could possibly be compromised.

In my understanding we have two cases for externally-operated subCAs:

 1. Technically-constrained subCAs: As Ryan said, there are no
    requirements in the BRs that this TCSC must be fully audited so the
    Root CA needs some basic assurance about the key generation and
    protection. This is currently the "minimum" bar.
 2. Unconstrained subCA: The BRs require a full audit according to
    section 8.4 so the Root CA has some assurance about the controls and
    the externally-operated subCA's environment. Since this subCA is
    already audited, getting a keygen audit attestation doesn't seem
    excessive.

If a Root CA generates a CA keypair, without being witnessed by an 
auditor, and transferring the CA private key securely to another 
organization, we have two sub-categories:

 1. If the CA key corresponds to a TCSC, then the *transfer *is
    currently allowed without requiring an external auditor process,
    since the recipient subCA is not required to be audited
 2. If the CA key corresponds to an unconstrained subCA, then the
    *transfer *must be audited according to the audit standards. Of
    course the recipient subCA must already have a successful audit to
    securely receive the CA key and maintain its protection constantly.

IMO, the current requirements are reasonable but could use some 
additional clarifications.


Dimitris.
>
>> 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
> 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/ca3046e9/attachment-0001.html>


More information about the Servercert-wg mailing list