HN user
[ my public key: https://keybase.io/rmhrisk; my proof: https://keybase.io/rmhrisk/sigs/QgT79a4qutJ477eR5cf2ZdpYH6kJ3Jv2i8lOyeuZ1rg ]
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.
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.
Cool, I would love to see the source.
I believe for CT to "work" all CAs on the public internet need to participate.
I also believe that certificate transparency by itself is insufficient and the other items I mentioned are also needed.
Marsh, I understand your concern and I share it though I don't agree with the conclusion (re sticking head in the ground).
With that said GlobalSign has committed to implementing CT and we hope all other CAs agree to do the same as Adam points out earlier in this thread its the way to bring the desired transperancy.
That said it alone inst enough either, to start we also need TACK (and/or HSTS pinning), CAA, robust revocation checking and Name Constraints.
And while conversations like this are uncomfortable (certainly for me being on the receiving end) I think they help too.
They need to meet the same criteria we do, here are some starting points but its far from exaustive:
http://www.mozilla.org/projects/security/certs/policy/
http://social.technet.microsoft.com/wiki/contents/articles/3...
Just look at the root program members in the Mozilla program, look at EFF data or the great notary.icsi.berkeley.edu/trust-tree/
As for disclosing all CAs have agreed to disclose -- no secret here at all.
And clearly from this thread I am being very open :)
The root programs all allow for technical and procedural controls to meet the this criteria. There are technical controls beyond name constraints as well.
Again GlobalSign's policies do not allow the use of certificates that chain to our roots to be used for MiTM purposes (or other malicious use cases for that matter) and we have controls in place that protect against such things occurring.
I of course feel a little singled out here but as has been called out by Adam many (if not all) trusted roots have this same offering.
It is allowed by all the root programs.
The practices (both technological and procedural) we put around our program are some of the best in the industry, we take this responsibility very seriously.
More over we very rarely do it and instead work with customers to utilize our managed PKI offerings where we operate the infrastructure on behalf of the customer.
Lifetime varies, but yes the goal is to re-issue them once criticality is viable -- customers are contractually obligated to support that migration also.
Said migration would ave no cost from us on the customer, I can't speak to what the other CAs do.
It does not.