Tag Archives: Security

Why crawling is not an adequate measurement methodology for the WebPKI

The answer is simple — It’s an incomplete view of the use of the WebPKI.

There are a number of different methodologies a web crawler-based approach might take in measuring the size of the WebPKI. The most naive approach would be to simply scan all IPv4 address space and log all of the certificates you see during this scan.

The problem is that this only shows a small fraction of the certificates that are out there. When you connect to an IP address and the associated web server doesn’t know what host you are trying to connect to it will return its “default” website and use the associated certificate.

That same IP address may literally be responsible for serving millions of sites based on the client’s indicated hostname. With this IP-based enumeration approach at best you would get one certificate from that host, at worse you wouldn’t even get that because some servers are not configured with a default site. This is just one problem with this approach there are many more.

Though most WebPKI market share reports do not document their methodology anecdotally it appears most work on this crawler approach and at least historically some have taken periodic drops from CAs to make their view “more complete”.

Today though the only way to measure CA market share that should be used is by relying on the pre-certificate counts in Certificate Transparency logs.

Evolution of privacy governance and how cryptographic controls can help

Unfortunately, most organizations do not have a formal strategy for privacy, and those that do usually design and manage them similarly to their existing compliance programs.

This is not ideal for several reasons which I will try to explore in this post but more importantly, I want to explore how the adoption of End-To-End encryption and Client-Side encryption is changing this compliance-focused model of privacy to one backed by proper technical controls based on modern cryptographic patterns. 

If we look at compliance programs they usually evolve from something ad-hock and largely aspirational (usually greatly overselling what they deliver) and over time move to a more structured process-oriented approach that is backed with some minimum level of technical controls to ensure each process is followed. 

What is usually missing in this compliance journey is an assessment of sufficiency beyond “I completed the audit gauntlet without a finding”. This is because compliance is largely focused on one objective — proving conformance to third-party expectations rather than achieving a set of contextually relevant security or privacy objectives – This is the root of why you hear security professionals say “Compliance is not Security”.

If you watch tech news as I do, you have surely seen news articles calling the cybersecurity market “the new lemon market “, and while I do agree this is largely true I also believe there is a larger underlying issue — an overreliance on compliance programs to achieve security and privacy objectives.

To be clear, the point here is not that compliance programs for privacy are not necessary, instead, what I am saying is they need to be structured differently than general-purpose compliance programs, as the objectives are different. These differences lend themself to misuse resistant design and the use of cryptographic controls as an excellent way to achieve those objectives.

Misuse resistance is a concept from cryptography where we design algorithms to make implementation failures harder. This is in recognition of the fact that almost all cryptographic attacks are caused by implementation flaws and not fundamental breaks in the cryptographic algorithms themselves. 

Similarly, in the case of privacy, most companies will not say “we intend to share your data with anyone who asks”. Instead, they talk of their intent to keep your information confidential — the problem is that in the long run everyone experiences some sort of failure and those failures can make it impossible to live up to that intent.

So back to this compliance-focused approach to privacy — it is problematic in several cases, including:

  • Where insiders [1,2,3] are abusing their position within an organization,
  • When configuration mistakes result in leakage of sensitive data [4,5,6], 
  • When service providers fail to live up to customers’ expectations on data handling [7,8], 
  • When technical controls around data segmentation fail [9],
  • and of course when service providers fail to live up to their marketing promises for government access requests for your sensitive information [10,11].

If we move to a model where we approach these problems using engineering principles rather than process and manual controls we end can end up in a world where the data and access to it are inherently misused resistant and hopefully verifiable.

This is exactly what we see in the design patterns that have been adopted by Signal, namely they gather only the minimal level of data to deliver the service, and the data they do gather they encrypt in such a way to limit what they can do with it.

They are not the only ones though can see the similar approaches from Android and how they handle encrypted backups as well as in Apple in how they handle device pin recovery

Another great example is how payment providers like Stripe leverage client-side encryption to reduce exposure of payment details to intermediaries or how Square uses client-side encryption in the Cash App to limit adversaries’ access to the data.

While today these patterns are only being applied by the largest and most technically advanced organizations the reality is that as Alexander Pope once said “to err is human” and if we are to truly solve for privacy and security we have to move to models that rely less on humans doing the right thing and for privacy, this means extensive use of cryptographic patterns like those outlined above.

It could be argued that of the reasons we do not see these patterns applied more is security the nihilist’s argument that client-side encryption and cryptographic transparency are exercises of re-arranging deck chairs on a sinking ship.

While there is some truth to that argument you can both limit the amount of trust you have to place in these providers (limiting the amount of trust delegated is the essence of security after all!) and make elements of what the provider does verifiable which again furthers this misuse resistant objective.

If that is the case then why is it that only the largest providers do this today? I would argue it’s just too darn hard right now. For example, when you start applying client-side encryption and cryptographic controls to systems there is still a substantial lift, especially when compared to the blind trust paradigm most systems operate within.

There are a few reasons, but one of the largest in the case of client-side encryption is that you end up having to build the associated key management frameworks yourself and that takes time, and expertise that many projects simply do not have access to.

With that said just like modern systems have moved from self-hosted monoliths to microservices that are globally scaled thanks to solutions like Kubernetes which in turn gives them node to node compartmentalization and other by default security controls, I believe we will see a similar move for sensitive data handling where these cryptographic controls and usage policies become a key tool in the developer’s toolbox.

More work is needed to make it so the smaller organizations can adopt these patterns but, unquestionably, this is where we end up long term. When we do get here, to borrow an over-used marketing term, we end up what might be called Zero Trust Data Protection in today’s market.

Risk variance and managing risk

One of my favorite security sayings is “My threat model is not your threat model”. We broadly accept there are different perspectives for every problem — the same is true with security.

Consider an Enterprises IT organization where you are chartered to support and secure a business. You need to meet this charter with a fairly fixed set of resources but the business requirements you must support are always changing. To deliver a reasonable level of service enterprises standardize on a core set of ways that certain issues (user and access management, compute, etc.) will be provided and force business units down the path of adopting them.  But that standardization often results in non-ideal user experiences, disjointed business workflows, slow innovation and importantly, in this case, it also commonly results in the either over or under mitigating security risks.

Startups, who are on the other end of the spectrum, are in a race to demonstrate market traction before their funding runs out. As a result, startups either virtually ignore security and privacy altogether or re-using a component they do not understand that is not well suited to the business problem they are solving or simply solves the wrong problems for their business risks.

Both enterprises and startups show the hard reality that we are often so close to our problems and set in our way of thinking we simply miss the big picture. This natural bias can hurt our businesses and in the context of security trade-offs, and result in incidents like the recent Equifax breach or the ever-growing list of Bitcoin exchange compromises.

The first step in preventing this “missizing” of risk is to make sure you understand what your risks actually are. The right way to do that is to think adversarially, taking a step outside of your business process or solution and thinking about the structure of the system your protecting and defining a threat model that captures those risks. This is not a one time exercise, it is something you need to constantly be re-visiting and getting new perspectives into.

Consider the typical Bitcoin exchange compromise, the exchanges usually start with a basic system limited to “online hot wallets” with weak architectural protections. They probably know better (for humanity’s sake I hope they do) but decided that the risk, in the beginning, is low enough because they have so little to lose that they go forward. Later they find success and are focused on other parts of their business and never get back to fixing that early trade-off.

As an aside, this bitcoin example showcases lots of problems, the largest being the asymmetric risk distribution. Specifically, the risk here is that of the depositor but the decision to take the risk is made by the exchange. I digress but this class of problem is a real problem in most startups and is the impact of which is multiplied 1000x in Bitcoin startups.

In any event, we can see how these sorts of things happen in hindsight so how can we limit how often these issues happen in the first place? As a technologist it hurts me to say this, the answer is process.

The good news is that process does not need to be heavy-weight. You need to make sure you approach the problem systematically and regularly, for example:

  • Instead of a threat model, you can do a simple threat tree,
  • You can use your bug tracking system to track the security issues you have found,
    • You can make sure those bugs capture the security decisions you have made,
    • The consequences of the identified risks for the actors in the system are captured,
    • What mitigations you have put in place for those issues along with how effective you think they will be are captured,
  • And importantly have a plan for how you will respond when things go wrong because they will regardless of how well you plan and invest in making the right security decisions.

You can then make sure you are reviewing these and acting accordingly on a regular schedule. This will ensure your organization at least has an inventory of issues that can last the individuals on a team and will make sure there is a point of conscious risk acceptance that the organization has taken.

This does not replace a full-on security program but it can at least make sure you are looking at the problem in the context of your business, your users and not just assuming every system has the same security needs.

On a related note for you startups, especially those who are operating in murky waters regarding regulation. The current regulations belong in your threat tree so you can make sure you understand them and begin to understand how they might apply to you even if you have to squint a bit to do it.

The Evolution of Security Thinking

In design sometimes we refer to the strategies used during the design process as Design thinking.  The application of these strategies helps ensure you are solving the right problems and doing so in a repeatable way. You can attribute much of the massive improvements in usability in software and devices over the two decades to these strategies.

If we look at how we have evolved thinking around building secure systems over the last two decades we can see that we have evolved similar strategies to help ensure positive security outcomes.

If we go back to the late 80s we see systems that were largely designed for a world of honest actors. There was little real business happening on the Internet at the time and the hard problems to be solved were all related to how do we enable a global network of interconnected systems so thats where efforts were put. These efforts led us to the Internet of today but it also gave us systems vulnerable to trivial attacks such as the Morris Worm.

By the 90s the modern “security industry” was born and products designed to protect these insecure systems from the internet started to come to market. One of the most impactful examples of this was the TIS Firewall Toolkit, other examples of this way of thinking include Antivirus products and other agents that promised to keep our applications and operating systems safe from “attackers”.

By the late 90s and early 2000s, it was clear that these agents were never going to be effective at keeping the bad guys out and that we needed to be building systems that were Secure by Default, Secure by Design and Private by Design. This shift in thinking meant that solution developers needed to develop their own strategies and tooling to ensure systems could be built to be inherently resilient to the risks they were exposed to. The concept of Threat Modeling is probably the most concrete example of this, believe it or not, this basic concept was essentially absent from software development up until this point.

By this time the technical debt in deployed systems was so great we spent most of a decade just trying to rectify the mistakes of the past. Windows XP SP2 and the Microsoft Security Stand Down is probably the most visible example of the industry making this shift, it also leads to the Security Development Lifecycle that largely informs how we as an industry, approach building secure systems today.

During this timeline, cryptography was treated as something that you sprinkled on top of existing systems with the hope to make them more confidential and secure. As an industry, we largely relied on the US Government to define the algorithms we used and to tell us how to use them securely. As a general rule only products designed for government use or for the small group of “cypherpunks” even considered the inclusion of cryptography due to the complexity of “getting it right”.

Things are changing again, we see the IETF via the CFRG working to standardize on international and independently created and cryptographic algorithms in lieu of relying exclusively on governments to do this standardization. We also see the concept of Formal Verification being applied to cryptographic systems (Galois is doing great work here with Cryptol as are other great projects in the verifiable computing space) which is leading us to have frameworks we can apply to build these concepts into other products securely (check out the Noise Protocol Framework as an example).

I think the Signal Protocol, Rough time, Certificate Transparency and even Blockchain Technologies are examples of the next phase of evolution in our thinking about how we build secure systems. Not because of “decentralization” or some anti-government bent in technologists, instead, these systems were designed with a more-complete understanding of security risks associated with their use.

Trust is a necessary component of human existence. It can give us peace of mind but It can also give us broken hearts. The same is true in the context of system design. Trust cautiously.

These systems, by design, go to great length to limit the need for “trust” for a system to work as intended. They do this by minimizing the dependencies that a system takes in its design, this is because each of those dependencies represents an attack vector as we advance technology our attackers become more advanced as well. They also make extensive use of cryptography to make that possible.

This focus on dependency reduction is why we see Blockchain enthusiasts taking the maximalist position of “Decentralize all the Things”. In my opinion, centralization is not always a bad thing, over-centralization maybe, but centralization can provide value to users and that value is what we should be focused on as solution developers.

My personal take is that when we look back on the next decade we will the say the trend was not “blockchain” but instead this is when we evolved our security thinking and tooling to better utilize cryptography. Specifically that this is when we started to use cryptography to make transparency, confidentiality and verifiability part of the core of the solutions we build instead of thinking of it as a layer we apply once we are done.

How to Build Your Own OpenSSL

So you have been reading all the press on forward secrecy and want to deploy it? But does your OpenSSL support it? Thankfully it is easy to tell, just run this command:

> openssl ciphers

If you see ciphers like “ECDHE-RSA-AES256-GCM-SHA384” then you have a version of OpenSSL that was built with ECC and ECDHE support enabled which is required if you want forward secrecy today.

So how do you go about doing this? Thankfully you don’t need to be a developer of cryptographer, with the following commands you should be able to get the latest (as of the time of this post) OpenSSL with ECC and ECDH enabled.

root> cp /usr/bin/openssl /usr/bin/openssl.orig
root> cd /tmp
root> wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
root> tar -xvzf openssl-1.0.1e.tar.gz
root> cd openssl-1.0.1e
root> ./config no-shared no-threads 
root> make depend
root> make
root> make install

You may also need to re-build your web server,you see even though the latest versions of Nginx and Apache include the necessary changes to enable ECDH if the version you are running was built against a version of OpenSSL that did not include support your going to have to rebuild it also. Here is a quick post on how to do that for Nginx.


Good luck!



Abstract: Revocation reality and the path to becoming effective

Just submitted my first abstract for the NIST workshop on “Workshop on Improving Trust in the Online Marketplace” in April, the title of the talk is “Revocation reality and the path to becoming effective”, the abstract of which is:


The concept of certificate revocation is core to the X.509 trust model however 18 years after its introduction the reality is as implemented and deployed it falls short of its promise to enable an issuer certificate issuers to protect relying parties from malicious actors and miss-issuance

This talk will discuss the findings of a project where I have observed the behavior (https://revocation-report.x509labs.com), up time and performance of revocation repositories for a number of commercial Certificate Authorities for a period of over six months.

Additionally I will overview the revocation behavior of the most common browsers, identifying the gaps as they exist in those implementations.

And finally I will provide a set of recommendations that I believe if followed can address the current gaps which would move us to a world where revocation checking is an effective means of protecting relying parties from known bad actors and miss-issuance.

Is SSL Broken?

[ This is a re-post of a article I wrote for the GlobalSign corporate blog, you can find it here]

It seems every month a new flaw is identified in SSL, and while that’s a slight exaggeration, after a while one starts to ask the question – is SSL broken? My answer would to that question would be no, but the protocol is nearly twenty years old and even though it now carries a new name (TLS) it also carries much of the baggage of the past in its design.

Despite this fact, my faith in TLS is stronger today than it ever was. My reasoning is simple – today we understand the strengths and weaknesses of this protocol better than we ever have. It is continuously reviewed by the world’s best engineers and cryptographers, trying to find the bad assumptions their predecessors made, strengthening it in response to identified weaknesses, and modernizing it to use the strongest forms of cryptography available.

This continuous investment in this foundational technology gives me faith.

Today another attack on TLS was made public.  “Lucky Thirteen” is a derivative of the work of French cryptographer Serge Vaudenay (Padding Oracles against CBC based ciphers – 2010), though unlike Vaudenay’s attack, Lucky Thirteen uses a known Timing Attack previously believed to be impractical. A successful application of this attack enables an attacker to decrypt your SSL communications.

Unlike other recent attacks, such as BEAST,  Lucky Thirteen requires a server-side fix. This means that complete and effective protection against this attack will require all webservers to be updated or patched.

That said, it is possible to mitigate the attack by removing CBC cipher suites, since the attack is against SSL/TLS’s use of CBC. But what to use in its place? The consensus of security researchers is to adopt suites based on AES-GCM, and while I agree, this has one problem – the large population of clients that do not yet support it.

This recommendation is complicated slightly by the BEAST attack from last year, the resolution of which required a client side fix which has, in all likelihood, not yet been deployed ubiquitously. As such, I still recommend prioritizing the older and less secure RC4 based suites above AES-GCM since it addresses both issues.

But should you be worried? It depends. If you are using TLS (and not its little brother DTLS) I would say your best bet is to walk calmly to the nearest exit, and use this as an excuse to ensure you are following industry Best Practices when deploying SSL – if  you’re not, this attack is the least of your worries.  Specifically I would recommend visiting the SSL Configuration Checker and make the critical (red) and important (yellow) configuration changes it suggests.

I would also encourage you to deploy HTTP Strict Transport Security  on your site since the attack this mitigates (SSL stripping) is much easier for an attacker to execute.

The good news is that if you were already following the advice of the SSL Configuration Checker you were prioritizing RC4 over other ciphers and most sessions to your server were resistant to this attack. This doesn’t mean you should not be deploying the patch to this issue, you just don’t need to do so in a crazed rush.

So are there any lessons we can take away from this? Of course there are. As a server operator, I would say this finding underscores the importance of regularly reviewing your server configuration to ensure that it follows industry best, and that you are always operating the most recent and stable release of your web server.

If you want a more technical walk through of this attack, I highly recommend this post by Mathew Green on TLS Timing Oracles or this one by Adam Langly.

What is the status of revocation checking in browsers?

Today we did an announcement of some work we have been doing with CloudFlare to speed up SSL for all of our customers through some improvements to our revocation infrastructure.

One of the things that come up when talking about this is how each of the browsers handles revocation checking, I thought it might be useful to put together a quick post that talks about this to clear up some confusion.

The first thing that’s important to understand is that all major browsers do some form of revocation checking, that includes Opera, Safari, Chrome, Firefox and Internet Explorer.

Let’s talk about what that means, the IETF standards for X.509 certificates define three ways for revocation checking to be done, the first is Certificate Revocation Lists (CRLs), next there is the Online Certificate Status Protocol (OCSP) and finally there is something called Simple Certificate Validation Protocol (SCVP).

In the context of browsers we can ignore SCVP as no browser implements them; this leaves us with CRLs and OCSP as the standards compliant ways of doing revocation checking.

All of the above browsers support these mechanisms, in addition to these standard mechanisms Google has defined a proprietary certificate revocation checking scheme called CRLsets.

If we look at StatCounter for browser market share that means today at least 64.84% (its likely more) of the browsers out there are doing revocation checking based on either OCSP or CRLs by default.

This means that when a user visits a website protected with SSL it has to do at least one DNS look-up, one TCP socket and one HTTP transaction to validate the certificate the web server presents and more likely several of these.

This is important because of the way revocation checking needs to be done, you need to know if the server you are talking to really is who they say they are before you start to trust them – that’s why when browsers do OCSP and CRLs they do this validation before they download the content from the web page.

This means that your content won’t be displayed to the user until this check happens and this can take quite a while.

For example in the case of IE and Chrome (when it does standards based revocation checking on Windows) it uses CryptoAPI which will time-out after 15 seconds of attempting to check the status of a certificate.

The scary part is that calls to this API do actually time out and when they do this delay is experienced by the users of your website!

So what can you do about it? It’s simple really you have to be mindful of the operational capacity and performance of the certificate authority you get your certificate from.

Check out this monitoring portal I maintain for OCSP and this one I maintain for CRLs, you will see GlobalSign consistently outperforms every other CA for the performance of their revocation infrastructure in most cases it’s nearly 6x as fast and in others is much more than that.

The other thing to understand is that today the default behavior of these browsers when checking the status of a certificate via OCSP or CRLs is to do what is often referred to as a “soft-revocation failure”.

This basically means that if they fail for any reason to check the status of a certificate (usually due to performance or reliability issues) they will treat the certificate as good anyways. This is an artifact of CAs not operating sufficiently performant and reliable infrastructure to allow the browsers to treat network related failures critically.

Each of these browsers all have options you can use to enable “hard” or “strict” revocation checking but until the top CAs operate infrastructure that meets the performance and reliability requirements of the modern web no browser will make these the default.

Finally its also important to understand that even with this “soft-failure” your website experiences the performance cost of doing these checks.

It’s my belief that the changes we have put into place in our own infrastructure meet that bar and I hope the other CAs follow in our lead as it is in the best interest of the Internet.


Algorithms, key size and digital certificates


On the surface the digital certificates are not complicated — a third-party (a certificate authority) verifies some evidence and produces a piece of identification that can be presented at a later date to prove that the verification has taken place.

As is usually the case when we look a little deeper things are not that simple. In the this case we have to care about a few other things, for example what are the qualifications of the third-party, what are their practices and what cryptographic algorithms did they use to produce the digital certificate?

As an administrator using digital certificates like in the case of SSL these things also can have impact on your operational environment – by using a certificate from a certificate authority you take dependencies on their practices and operational environment.

This is especially true when it comes to decisions relating to what cryptographic algorithms and key lengths are accepted and used by that third-party.

Thankfully you do not need to be a cryptographer to make good decisions on this topic, first we need to start with an understanding of the history, future and then considerations.


In recent history the industry has relied on two algorithms, the first being an encryption algorithm called RSA the second being a hash algorithm called SHA-1. Both of which have are considered weaker now due to advances in cryptanalysis.

RSA’s strength and performance is based on the size of the key used with it, the larger the key the stronger and slower it is.

These advances in cryptanalysis have driven the increase in key size used with this algorithm which in turn has increased the amount of computing power necessary to maintain the same effective strength.

The problem with this is that that every time we double the size of an RSA key the decryption operations with that key become 6-7 times slower.

As a result as of all of this as of January 2011 trustworthy Certificate Authorities have aimed to comply with NIST (National Institute of Standards and Technology) recommendations by ensuring certificates all new RSA certificates have keys of 2048 bits in length or longer.

Unfortunately this ever increasing key size game cannot continue forever, especially if we ever intend do see SSL make up the majority of traffic on the internet – the computational costs are simply too great.

That takes us to SHA-1, hash algorithms take a variable amount of input and reduce it to a typically shorter and fixed length output the goal of which being to provide a unique identifier for that input. The important thing to understand is that hash algorithms are always susceptible to collisions and the advances in the cryptanalysis have made it more likely that such a collision can be made.

The problem here is that there is no parameter to tweak that makes this problem harder for an attacker, the only way to address this issue is to change to a stronger algorithm to produce the hash.


For the last decade or so there has been slow and steady movement towards using two new algorithms to address these advances — SHA-2 and ECC.

ECC has the potential for significant performance benefits over RSA without reducing security and SHA-2 has three versions each with progressively longer lengths which help it both address the current risks and give it some longevity.


Our goal in configuring SSL is enabling users to communicate with us securely; to accomplish this goal we need to be able to do this with the fewest hassles, lowest costs and comply with any associated standards.

Interoperability is the key that ensures the fewest hassles — if it was not for this we would simply switch to these new algorithms and be done with it. As is normally the case when it comes to security this is where Windows XP rears its ugly head, SHA-2 was added to XP in Windows XP Service Pack 2 and ECC in Windows Vista.

These facts set the adoption clock for these new algorithms; if you care about XP (about 30% of the Internet today) you can’t adopt ECC and SHA-2 in full for about 5 years.

This leaves us with RSA 2048 and SHA-1 which thankfully is broadly considered sufficient for the next decade.

Performance is always a concern as well — a RSA 2048-bit RSA certificate used in SSL will result in around a 10% CPU overhead not huge but something to keep in mind.

As mentioned previously we can’t forget compliance — whether it is the Payment Card Industry / Data Security Standards (PCI/DSS), Federal Information Processing Standards (FIPS) 140-2 or some other set of criteria you need to meet this always needs to be considered.


The decision of what algorithm’s and key lengths to use in your digital certificates is dependent on a number of factors including security, interoperability, performance and compliance. Each situation may require a different trade-off to be made however a rule of thumb if you stick with SHA-2 and RSA 2048-bit certificates and keys you should be fine for now.



[1]   BlueKrypt Cryptographic Key Length Recommendations

[2]   Recommendation for Key Management, Special Publication 800-57 Part 1 Rev. 3, NIST, 05/2011

[3]   Fact Sheet Suite B Cryptography, NSA, 11/2010

[4]   Worldwide Operating System Statistics, Stat Counter, 9/2012

[5]   RSA Algorithm, Wikipedia

[6]   RSA Key Lengths, Javamex

[7]   ECC Algorithm, Wikipedia

[8]   Performance Analysis of Elliptic Curve Cryptography for SSL, Sun

[9]   Using ECC keys in X509 certificates, UnmitigatedRisk

[10] Using SHA2 based signatures in X509 certificates, UnmitigatedRisk

[11]Payment Card Industry / Data Security Standards – PCI

[12]Federal Information Processing Standards 140-2 – NIST

Government CAs in the Microsoft Root Program

Microsoft was the first Root program in a browser to have an open and transparent process for becoming a CA as well as the first to have public policy, audit and technical requirements that CAs must comply with.

Today while the other browsers have joined on and even raised the bar significantly Microsoft continues to operate their root program in an open and clear way.

One example of this is the list they publish of the companies who meet their requirements; you can see this list here.

There are a number of interesting things we can gleam from this list; one of them is how many governments have their own certificate authorities.

For example as of March 11, 2011 we know that there are a total of 46 government owned and operated “Root Certificates” in the Microsoft Root Program, these include:

Current CA Owner Country Thumbprint
Government of Austria, Austria Telekom-Control Commission Austria e7 07 15 f6 f7 28 36 5b 51 90 e2 71 de e4 c6 5e be ea ca f3
Government of Brazil, Autoridade Certificadora Raiz Brasileira Brazil 8e fd ca bc 93 e6 1e 92 5d 4d 1d ed 18 1a 43 20 a4 67 a1 39
Government of Brazil, Instituto Nacional de Tecnologia da Informação (ITI) Brazil ‎70 5d 2b 45 65 c7 04 7a 54 06 94 a7 9a f7 ab b8 42 bd c1 61
Government of Finland, Population Register Centre Finland fa a7 d9 fb 31 b7 46 f2 00 a8 5e 65 79 76 13 d8 16 e0 63 b5
Government of France France 60 d6 89 74 b5 c2 65 9e 8a 0f c1 88 7c 88 d2 46 69 1b 18 2c
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) d6 da a8 20 8d 09 d2 15 4d 24 b5 2f cb 34 6e b2 58 b2 8a 58
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) e0 92 5e 18 c7 76 5e 22 da bd 94 27 52 9d a6 af 4e 06 64 28
Government of India, Ministry of Communications & Information Technology, Controller of Certifying Authorities (CCA) India 97 22 6a ae 4a 7a 64 a5 9b d1 67 87 f2 7f 84 1c 0a 00 1f d0
Government of Japan, Ministry of Internal Affairs and Communications Japan 96 83 38 f1 13 e3 6a 7b ab dd 08 f7 77 63 91 a6 87 36 58 2e
Government of Japan, Ministry of Internal Affairs and Communications Japan ‎7f 8a b0 cf d0 51 87 6a 66 f3 36 0f 47 c8 8d 8c d3 35 fc 74
Government of Korea, Korea Information Security Agency (KISA) South Korea 5f 4e 1f cf 31 b7 91 3b 85 0b 54 f6 e5 ff 50 1a 2b 6f c6 cf
Government of Korea, Korea Information Security Agency (KISA) South Korea 02 72 68 29 3e 5f 5d 17 aa a4 b3 c3 e6 36 1e 1f 92 57 5e aa
Government of Korea, Korea Information Security Agency (KISA) South Korea f5 c2 7c f5 ff f3 02 9a cf 1a 1a 4b ec 7e e1 96 4c 77 d7 84
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 63 4c 3b 02 30 cf 1b 78 b4 56 9f ec f2 c0 4a 86 52 ef ef 0e
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 20 cb 59 4f b4 ed d8 95 76 3f d5 25 4e 95 9a 66 74 c6 ee b2
Government of Latvia, Latvian Post Latvia 08 64 18 e9 06 ce e8 9c 23 53 b6 e2 7f bd 9e 74 39 f7 63 16
Government of Latvia, Latvian State Radio & Television Centre (LVRTC) Latvia c9 32 1d e6 b5 a8 26 66 cf 69 71 a1 8a 56 f2 d3 a8 67 56 02
Government of Lithuania, Registru Centras Lithuania 97 1d 34 86 fc 1e 8e 63 15 f7 c6 f2 e1 29 67 c7 24 34 22 14
Government of Macao, Macao Post Macao SAR ‎89 c3 2e 6b 52 4e 4d 65 38 8b 9e ce dc 63 71 34 ed 41 93 a3
Government of Mexico, Autoridad Certificadora Raiz de la Secretaria de Economia Mexico 34 d4 99 42 6f 9f c2 bb 27 b0 75 ba b6 82 aa e5 ef fc ba 74
Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State Portugal ‎39 13 85 3e 45 c4 39 a2 da 71 8c df b6 f3 e0 33 e0 4f ee 71
Government of Serbia, PTT saobraćaja „Srbija” (Serbian Post) Serbia d6 bf 79 94 f4 2b e5 fa 29 da 0b d7 58 7b 59 1f 47 a4 4f 22
Government of Slovenia, Posta Slovenije (POSTArCA) Slovenia ‎b1 ea c3 e5 b8 24 76 e9 d5 0b 1e c6 7d 2c c1 1e 12 e0 b4 91
Government of Slovenia, Slovenian General Certification Authority (SIGEN-CA) Slovenia 3e 42 a1 87 06 bd 0c 9c cf 59 47 50 d2 e4 d6 ab 00 48 fd c4
Government of Slovenia, Slovenian Governmental Certification Authority (SIGOV-CA) Slovenia 7f b9 e2 c9 95 c9 7a 93 9f 9e 81 a0 7a ea 9b 4d 70 46 34 96
Government of Spain (CAV), Izenpe S.A. Spain 4a 3f 8d 6b dc 0e 1e cf cd 72 e3 77 de f2 d7 ff 92 c1 9b c7
Government of Spain (CAV), Izenpe S.A. Spain ‎30 77 9e 93 15 02 2e 94 85 6a 3f f8 bc f8 15 b0 82 f9 ae fd
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) Spain a0 73 e5 c5 bd 43 61 0d 86 4c 21 13 0a 85 58 57 cc 9c ea 46
Government of Spain, Dirección General de la Policía – Ministerio del Interior – España. Spain b3 8f ec ec 0b 14 8a a6 86 c3 d0 0f 01 ec c8 84 8e 80 85 eb
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain 43 f9 b1 10 d5 ba fd 48 22 52 31 b0 d0 08 2b 37 2f ef 9a 54
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain b8 65 13 0b ed ca 38 d2 7f 69 92 94 20 77 0b ed 86 ef bc 10
Government of Sweden, Inera AB (SITHS-Secure IT within Health care Service) Sweden 16 d8 66 35 af 13 41 cd 34 79 94 45 eb 60 3e 27 37 02 96 5d
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎6b 81 44 6a 5c dd f4 74 a0 f8 00 ff be 69 fd 0d b6 28 75 16
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎25 3f 77 5b 0e 77 97 ab 64 5f 15 91 55 97 c3 9e 26 36 31 d1
Government of Taiwan, Government Root Certification Authority (GRCA) Taiwan ROC f4 8b 11 bf de ab be 94 54 20 71 e6 41 de 6b be 88 2b 40 b9
Government of The Netherlands, PKIoverheid The Netherlands 10 1d fa 3f d5 0b cb bb 9b b5 60 0c 19 55 a4 1a f4 73 3a 04
Government of The Netherlands, PKIoverheid The Netherlands 59 af 82 79 91 86 c7 b4 75 07 cb cf 03 57 46 eb 04 dd b7 16
Government of the United States of America, Federal PKI USA 76 b7 60 96 dd 14 56 29 ac 75 85 d3 70 63 c1 bc 47 86 1c 8b
Government of the United States of America, Federal PKI USA cb 44 a0 97 85 7c 45 fa 18 7e d9 52 08 6c b9 84 1f 2d 51 b5
Government of the United States of America, Federal PKI USA ‎90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia 30 70 f8 83 3e 4a a6 80 3e 09 a6 46 ae 3f 7d 8a e1 fd 16 54
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia d9 04 08 0a 49 29 c8 38 e9 f1 85 ec f7 a2 2d ef 99 34 24 07
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) Turkey 1b 4b 39 61 26 27 6b 64 91 a2 68 6d d7 02 43 21 2d 1f 1d 96
Government of Uruguay, Correo Uruguayo Uruguay f9 dd 19 26 6b 20 43 f1 fe 4b 3d cb 01 90 af f1 1f 31 a6 9d
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎dd 83 c5 19 d4 34 81 fa d4 c2 2c 03 d7 02 fe 9f 3b 22 f5 17
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎39 8e be 9c 0f 46 c0 79 c3 c7 af e0 7a 2f dd 9f ae 5f 8a 5c


With a closer look we see that these 46 certificates are operated by 33 different agencies in 26 countries.


Wikipedia tells us there are 207 governments and now we know apparently 14% of them operate their own globally trusted root.


Though I love to travel and I consider myself a citizen of the world I have never needed to communicate with any of these governments using their private PKIs so I personally have marked them as “revoked” in CryptoAPI, I also manage which of the commercial root CAs I trust manually.

There are some other interesting observations we can gleam from the Root Program membership also, I will do more posts on these later.