On 15/12/2017 22:33, Ryan Hurst wrote:
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.
Please reread my message above.
I was talking about the protections of the semi-offline HSM holding the
issuing CA key getting in the way of a procedure that delivers the
private key, erases the private key, then signs the certificate all in a
matter of seconds as the subscriber (who is presumable not smart enough
to create a CSR locally) waits impatiently.
PKCS#12 encrypted with a certificate is unlikely to be useful to any
first time not-terribly-smart end user. As that would
- Work on a tiny minority of end user systems (password based PKCS#12 is
the commonly implemented and tested case).
- A user needing such a service, especially for first time issuance or
post-expiry issuance, is unlikely to have the training and tools to set
up a certificate (and associated private key) just to decrypt the CA
generated private key.
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
