On 04/12/2018 13:36, Nick Lamb wrote:
On Tue, 4 Dec 2018 07:56:12 +0100
Jakob Bohm via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
Which systems?
As far as I'm aware, any of the automated certificate issuance
technologies can be used here, ACME is the one I'm most familiar with
because it is going through IETF standardisation and so we get to see
not only the finished system but all the process and discussion.
Oh, so you meant "CA issuance systems and protocols with explicit
automation features" (as opposed to e.g. web server systems or operating
systems or site specific subscriber automation systems). That's why I
asked.
And note that this situation started with an OV certificate, not a DV
certificate. So more than domain ownership needs to be validated.
I prefer not to experiment with live certificates. Anyway, this was
never intended to focus on the specifics of ACME, since OC issuance
isn't ACME anyway.
The direction of the thread was: Excuses for why a subscriber can't
manage to replace certificates in a timely fashion. Your contribution
was a claim that automated deployment has poor operational security
because:
"it necessarily grants read/write access to the certificate data
(including private key) to an automated, online, unsupervised system."
I've cleanly refuted that, showing that in a real, widely used system
neither read nor write access to the private key is needed to perform
automated certificate deployment. You do not need to like this, but to
insist that something false is "necessarily" true is ludicrous.
You have shown that ONE system, which you happen to like, can avoid that
weakness, IF you ignore some other issues. You have not shown that
requiring subscribers to do this for any and all combinations of
validation systems and TLS server systems they encounter won't have this
weakness.
So returning to the typical, as-specified-in-the-BRs validation
challenges. Those generally either do not include the CSR in the
challenge, or do so in a manner that would involve active checking
rather than just trivial concatenation. These are the kind of
challenges that require the site owner to consider IF they are in a
certificate request process before responding.
I _think_ this means you still didn't grasp how ACME works, or even how
one would in general approach this problem. The CSR needs to go from
the would-be subscriber to the CA, it binds the SANs to the key pair,
proving that someone who knows the private key wanted a certificate for
these names. ACME wants to bind the names back to the would-be
subscriber, proving that whoever this is controls those names, and so
is entitled to such a certificate. It uses _different_ keys for that
precisely so that it doesn't need the TLS private key.
It means ACME is of very little relevance to OV and EV certificates from
most/all current OV and EV CAs.
But most centrally the Baseline Requirements aren't called the "Ideal
Goals" but only the "Baseline Requirements" for a reason. If a CA
approaches them as a target to be aimed for, rather than as a bare
minimum to be exceeded, we're going to have a problem. Accordingly the
Ten Blessed Methods aren't suggestions for how an ideal CA should
validate control of names, they're the very minimum you must do to
validate control of names. ACME does more, frankly any CA should be
aiming to do more.
I made no such claim. I was saying that your hypothetical that all/most
validation systems have the properties of ACME and that all/most TLS
servers allow certificate replacement without access to the private key
storage represents an idealized scenario different from practical
reality.
See for example NIST SP 1800-16B Prelim Draft 1, Section 5.1.4 which
has this to say:
"... It is possible to renew a certificate with the same public and
private keys (i.e., not rekeying during the renewal process).
However, this is only recommended when the private key is contained
with a hardware security module (HSM) validated to Federal
Information Processing Standards (FIPS) Publication 140-2 Level 2 or
above"
Just before that sentence the current draft says:
"It is important to note that the validity period of a certificate is
different than the cryptoperiod of the public key contained in the
certificate and the corresponding private key."
And the paragraph I quoted says to not do that unless you are using a
HSM, which very few subscribers do.
Quite so. Thus, the only reason to change both at the same time is as I
said, a convenience of scheduling, NIST does not claim that creating
certificates has any actual impact on the cryptoperiod, they just want
organisations to change their keys frequently and "on renewal" is a
convenient time to schedule such a change.
It is not a convenience of scheduling. It is a security best practice,
called out (as the first example found) in that particular NIST
document.
Moreover, this is (a draft of) Volume B of NIST's guidance. There is an
entire volume, Volume C, about the use of automation, to be published
later. I have no idea what that will say, but I doubt it will begin by
insisting that you need read-write access to private keys to do
something people are already doing today without such access.
Which has absolutely no bearing on the rule that keys stored outside an
HSM should (as a best practice) be changed on every reissue. It would
be contradictory if part B says not to reuse keys, and part C then
prescribes an automation method violating that.
I am referring to the very real facts that:
- Many "config GUI only" systems request certificate import as
PKCS#12 files or similar.
This is a real phenomenon, and encourages a lot of bad practices we've
discussed previously on m.d.s.policy. It even manages to make the
already confusing (for lay persons) question of what's "secret" and what
is not yet more puzzling, with IMNSHO minimal gains to show for it. Use
of PKCS#12 in this way can't be deprecated quickly enough for my liking.
So it is real.
[ This is also related to the Windows ecosystem in which there's a
pretence kept up that private keys aren't accessible once imported,
which of course isn't mechanically true since those keys are needed by
the system for it to work. So bad guys can ignore the documentation
saying its impossible and just read the keys out of RAM with a trivial
program, but good guys can't get back their own private keys.
A true masterpiece of security engineering, presumably from the same
people who invented the LANMAN password hash. ]
- Many open source TLS servers require supplying the private key as
an unencrypted PKCS#8 PEM key file, either appended to the PEM file
with the certificate chain or as a matching file with same file name.
Either of those require private key access to change the certificate
(for the parallel key file case, only if following the recommendation
to rekey on each renewal).
This just imports the pretence that NIST's recommendation aimed at
ensuring keys get changed _at all_ implies all new certificates must
have new keys from above and isn't a separate idea.
No, I am stating that:
- For systems that want the certificate as a PKCS#12 file only,
certificate import requires private key import and thus private key
write access.
- For systems that append the private key pem file to the certificate
chain PEM file, certificate import requires write access to the file
storing the private key.
- For systems that put the key and certificate chain in parallel PEM
files (such as Apache HTTPD), granting write access to the certificate
but not the private key is potentially possible, though not
necessarily. For example, typical Apache HTTPD configurations place
the certificate and key files in the same POSIX disk directory, where
write access would be granted to the operator installing new
certificates.
The risk of forgetting to do the renewal (a self-inflicted risk that
occurs only at the time when this should have been in your calendar)
is substantially different than the risk of someone from the outside
suddenly demanding doing the procedure as a rush job at a completely
different time.
Today many large organisations struggle to do the first of these
things, adoption of automation would enable them to easily do both. In
practice what's happening is that they adopt "Cloud" technologies that
throw in the certificate automation for free.
[ e.g. Amazon will charge you cash money for a service that mints
certificates for internal use and manages their keys. But if you want
TLS certificates for the Web PKI those are free when Amazon hosts your
web site and will just happen automatically ]
This assumes that granting a big global cloud provider easy access to
your organization's private keys is considered an acceptable risk, which
is not at all a given.
For a non-US government entity (as was the case with the malformed
D-TRUST certificate), there may very well be hard requirements against
that. In particular given their decision to use a national CA instead
of a global CA like Comodo.
I also explained, that ACME wasn't the target, and any mitigations
specific to ACME are of little relevance.
Ensuring that the entity making the issuance request is also behind the
proof-of-control responses is a common sense feature, it just happens
to exceed what is mandated by the Baseline Requirements. This behaviour
would have mitigated a considerable number of goofs we've seen in the
last few years where CAs weren't actually achieving what they thought
they had in their validation methods.
It also isn't central to my argument since the key protected here is
not the TLS private key.
And again you are arguing as if ACME is a typical case.
Again, this is only for your chosen ACME example, while I was
referring to traditional challenges closely matching what the BRs say
should be done.
I've read the ACME documentation. I see there is at least some
documentation for Sectigo/ Comodo's solution in this area but it
doesn't appear to cover the actual protocol itself. Who else has a
publicly documented automation protocol ?
And there you assume that automation is the norm. Which I am arguing it
is not.
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
