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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
