rmhrisk

If a root/admin user installs a root there is no prompt, if a user does, it is scoped to the individual user profile and a prompt is displayed. No prompt as root would be meaningful because the root/admin user could just update the configuration without using the API. Long story short, don't give root/admin to applications you don't trust.

With the recent GCP Cloud Certificate Manager release the global propagation time is minutes. (I should note I was a PM for this feature)

No, GCP has had arguably a superior TLS story for years.

For example they do managed TLS for their workloads like AWS but they operate their own CA rather than outsourcing to Digicert for certificate issuance which gives them a better SLA.

They have a global load balancer offering that enables TLS to terminate everywhere GCP is without having to manage a bunch of discrete load balancers, this also supports managed TLS.

They now support a very large number of certificates in the global load balancer product which allows SaaS products like hosting services to leverage the global load balancer rather than deploying a load balancer per 25 certificates (the limit per AWS LB).

And now let you enroll for certificates from the same CA they use even if you terminate TLS rather than having them do it for you. They do this via a standard API (ACME) which lets you have uniform and agile device compatibility regardless of how you deploy TLS. AWS doesn't let you do this at all.

(I should note I was the PM for most of these releases and am still the PM for Google Trust Services the CA used for this ACME release)

There is no origin limitation. It works on premise or cross cloud.

We hear you, while I can't speak to future products and features I can say we understand there is room to improve the SSL provisioning and lifecycle management story in our products and we are making investments in that area.

That is effectively how both the Mozilla and Microsoft programs root store programs works.

Some PKI-related services can not, due to user agent behaviors and, do SSL, for example, consider OCSP; if to fetch an OCSP request you need to do an SSL connection and the library doing SSL does an OCSP check to verify the SSL cert you can end up in an infinite loop.

While it would be ideal for that not to be the case, one has to build out infrastructure that supports the way UAs behave today.

Disclosure: I am the author of that post and Product Manager for this project as well as other related work like Certificate Transparency and Key Transparency.

While I can not say what Google will do in the future, I can say we are very supportive of Let's Encrypt. We have provided them funding and I personally act as an advisor to Let's Encrypt.

In short, we love what Let's Encrypt is doing.

Google has announced an effort to move all CAs to Certificate Transparency, here is a Threatpost piece on the topic - https://threatpost.com/google-to-make-certificate-transparen....

They will already log their public certificates to CT and this will continue given their push for CT.

It's actually quite common, another example is Amazon who operates its own root for its SSL certificate needs. Additionally, there is minimal risk profile differences to an unconstrained subordinate CA (like GIAG2 or the equivalent Microsoft subordinate) and a root. One could argue the risk is in fact reduced for a large issuer to be independent because of fewer entities can negativly impact operations.

There are numerous, Microsoft has its own subordinate CA that they operate for their own certificates. Amazon has its own root CA https://www.amazontrust.com/repository/. There are more as well.

This article from TechCrunch does a good job explaining Key Transparency - https://techcrunch.com/2017/01/12/googles-key-transparency-p...

No.

First, like CT you want an ecosystem of logs.

Second, you have caching and in-band exchanges as means to mitigate some of that.

To understand the technical approach to the solution this is a good resource - https://github.com/google/key-transparency/blob/master/docs/...

This is also useful for understanding some of the core differences between CONIKS and Key Transparency - https://github.com/google/key-transparency/blob/master/docs/...

One of the differences between Key Transparency and other solutions is the role of certifying and logging have been separated. In other words, being in the directory does not mean the identity has been verified. The verification of control of an email address is the role of the certifier. Your requirements of the certifier are an application specific decision.

Is this something more than a public key server? Unlike a simple public key server, this provides privacy protecting elements. The project utilizes Zero Knowlege Proofs (ZKP) to limit your access to keys associated with users you already know.

How is this different than KeyBase? It is similar. Some differences include the use of ZKP, it is a generic key store designed (could be used for PGP or E2E messaging), it is designed to scale to trillions of entries, anyone can run a log, and architecturally it should scale significantly better. KeyBase is doing great work, though.

thanks, fixed everything but the quotes.

see: https://publicsuffix.org/

My post responding to this - https://unmitigatedrisk.com/?p=552

There are a bunch of good tools like https://www.ssllabs.com/ and https://mozilla.github.io/server-side-tls/ssl-config-generat... for getting your SSL configuration right. That said generating the certificate request with various tools can be a pain. We try to address that pain with this tool.