On Tuesday, December 12, 2017 at 1:08:24 PM UTC-8, Jakob Bohm wrote: > On 12/12/2017 21:39, Wayne Thayer wrote: > > On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 12/12/2017 19:39, Wayne Thayer wrote: > >> > >>> The outcome to be avoided is a CA that holds in escrow thousands of > >>> private keys used for TLS. I don’t think that a policy permitting a CA to > >>> generate the key pair is bad as long as the CA doesn’t hold on to the key > >>> (unless the certificate was issued to the CA or the CA is hosting the > >>> site). > >>> > >>> What if the policy were to allow CA key generation but require the CA to > >>> deliver the private key to the Subscriber and destroy the CA’s copy prior > >>> to issuing a certificate? Would that make key generation easier? Tim, some > >>> examples describing how this might be used would be helpful here. > >>> > >>> > >> That would conflict with delivery in PKCS#12 format or any other format > >> that delivers the key and certificate together, as users of such > >> services commonly expect. > >> > >> Yes, it would. But it's a clear policy. If the requirement is to deliver > > the key at the same time as the certificate, then how long can the CA hold > > the private key? > > > > > > Point is that many end systems (including Windows IIS) are designed to > either import certificates from PKCS#12 or use a specific CSR generation > procedure. If the CA delivered the key and cert separately, then the > user (who is apparently not sophisticated enough to generate their own > CSR) will have a hard time importing the key+cert into their system. > > > > >> It would also conflict with keeping the issuing CA key far removed from > >> public web interfaces, such as the interface used by users to pick up > >> their key and certificate, even if separate, as it would not be fun to > >> have to log in twice with 1 hour in between (once to pick up key, then > >> once again to pick up certificate). > >> > >> I don't think I understand this use case, or how the proposed policy > > relates to the issuing CA. > > > > If the issuing CA HSM is kept away from online systems and processes > vetted issuance requests only in a batched offline manner, then a user > responding to a message saying "your application has been accepted, > please log in with your temporary password to retrieve your key and > certificate" would have to download the key, after which the CA can > delete key and queue the actual issuance to the offline CA system, and > only after that can the user actually download their certificate. > > Another thing with similar effect is the BR requirement that all the > OCSP responders must know about issued certificates, which means that > both the serial number and a hash of the signed certificate must be > replicated to all the OCSP machines before the certificate is delivered. > (One of the good OCSP extensions is to include a hash of the valid > certificate in the OCSP response, thus allowing the relying party > software to check that a "valid" response is actually for the > certificate at hand). > > > > > > > >> It would only really work with a CSR+key generation service where the > >> user receives the key at application time, then the cert after vetting. > >> And many end systems cannot easily import that. > >> > >> Many commercial CAs could accommodate a workflow where they deliver the > > private key at application time. Maybe you are thinking of IOT scenarios? > > Again, some use cases describing the problem would be helpful. > > > > One major such use case is IIS or Exchange at the subscriber end. > Importing the key and cert at different times is just not a feature of > Windows server. > > > > >> A policy allowing CAs to generate key pairs should also include provisions > >>> for: > >>> - The CA must generate the key in accordance with technical best practices > >>> - While in possession of the private key, the CA must store it securely > >>> > >>> Wayne > >>> > >>> > >> > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded
I agree that the "right way(tm)" is to have the keys generated in a HSM, the keys exported in ciphertext and for this to be done in a way that the CA can not decrypt the keys. Technically the PKCS#12 format would allow for such a model as you can encrypt the keybag to a public key (in a certificate. You could, for example generate a key in a HSM, export it encrypted to a public key, and the CA would never see the key. This has several issues, the first is, of course, you must trust the CA not to use a different key; this could be addressed by requiring the code performing this logic to be made public, and that it utilize some transparent logging mechanism (ex: merkle trees, etc) that could be audited against the HSM logs in some way. The second is once you use such a mechanism you now have produced PKCS#12 files that cannot be opened by OpenSSL or Windows. Another approach would be to write an applet that would do all of this on the HSM (some HSMs contain a TEE) and this would be more auditable as you wouldnt have a soft linkage between HSM logs and the outer logs; that said you are still trusting the CA to pass in the right key. I think you would want this log mechanism to be publicly verifiable also. Regardless you end up in a situation where you enable this use case but do so in a way the files are not consumable by the applications that need to use the keys. This may be appropriate for cases like IOT where custom code could be relied upon on the client but would probably fail to meet business requirements that folks are trying to achieve here. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
