On Tue, 4 Dec 2018 07:56:12 +0100 Jakob Bohm via dev-security-policy <[email protected]> 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. > 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. > 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. 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. > 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." 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. 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. > 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. [ 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. > 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 ] > 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. > 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 ? Nick. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
