You know that you want to bring PKI into your organization. You’ve got approval from the leadership team, and you’re starting to work out your budget and requirements. An early question to answer: what trust model do you go with? Public trust, private trust, or a combination of the two? What do the different options mean, and what are the considerations around each?

In a public-key-based authentication system, the policy authority plays a critical role: it dictates the rules by which the system operates, and therefore, the level of assurance it achieves. Policy authority rules cover everything from acceptable algorithm choices to registration procedure. Those rules may evolve over time (such as adding new algorithms), but the systems covered by the authority will always adhere to whatever is in the current set of rules. The policy authority enforces its rules by means of the root certification authority and the endpoint certificates whose verification it enables.

Authentication system implementers face a choice of policy authorities; they can choose to operate within one of the policy regimes set up either by the browser suppliers or by Adobe to serve the needs of the secure web or secure documents (“public trust”), or they can operate as their own policy authority (“private trust”). This is the most basic way to explain the options, but the nuances are more complex.  In fact, many organizations may opt for a hybrid model, with some systems under public trust and others under private trust. In addition, specific industries sometimes define their own public trust domains (see FBCA or SAFE-Biopharma), and organizations may wish to operate under one of those trust domains or be cross certified by one or more trust domains. Each organization will evaluate their business needs and the costs and benefits of different trust models to arrive at an optimal structure.

Public Trust

The term “public trust” is often applied to the situation in which an independent software vendor (ISV) acts as the policy authority. This situation may apply to certificates used for SSL/TLS, S/MIME, code-signing, time-stamping and electronic documents. The ISVs distribute root certification authority public keys pre-installed in their publicly-available endpoint software products, such as browsers and document viewers.

The browser suppliers, in particular, have endorsed two policy regimes for SSL and TLS certificates, defined by the CA/Browser Forum’s Baseline Requirements and Extended Validation Guidelines respectively. These two regimes receive distinct visual treatments in the browser UI, with no additional (and potentially confusing) dialog boxes being presented to the user.

Fig. 1: Visual representation of a site with a CA following Baseline Requirements

Fig. 2: Visual representation of a site with a CA following Extended Validation Guidelines

The level of assurance achieved by these two policy regimes strikes a balance between cost and the consequences of a compromise; a balance that experts deem appropriate for authentication in common web applications, such as e-commerce and social networking. (Note that we shouldn’t underestimate the sensitivity of information exchanged in social networks, as we’ve seen them used in such politically fraught situations as the recent coup attempt in Turkey).

In addition to the SSL/TLS certificate policy regimes, the CA/Browser Forum has developed a policy for EV Code Signing certificates. A working group has also developed minimum policy requirements for non-EV code signing certificates and time stamping certificates.

When considering public trust, ask yourself: on which systems do I need to be publicly trusted? Public trust is quite attractive when providing assurance for publicly accessible systems like SSL/TLS on a customer facing website. End users that leverage common browsers will recognize the visual indicators of a publicly trusted site. Purchasing and installing a public trust SSL certificate on your organization’s website may offer significant cost savings, as custom certificate policy and procedures are not required, and root public-keys are already installed in popular endpoint software products. No one in your organization is charged with defining policy (though someone needs to monitor their CA and/or the CAB Forum for any changes), and you do not have the operational headache of distributing the root certificate to hundreds or thousands of endpoints.

While public trust is a low cost, sensible option for your customer facing website (where the certificate is issued by a publicly trusted commercial CA), the opposite is true for your corporate CA. If you opt for public-trust policy regime, you forego considerable autonomy. Operating procedures are dictated at quite a fine level of detail, including endpoint registration procedures, algorithm choices and audit requirements. Also, those requirements can change, and organizations have to keep up with those changes. Why do that to yourself on systems that the public will never see?

Recently, this became an issue when browsers updated their requirements to disallow use of the SHA-1 hash algorithm (which is no longer considered secure). Some organizations found that parts of their systems had been hard-coded with SHA-1; a choice that was completely appropriate at the time of initial deployment, but which then suddenly represented an unacceptable policy violation. Some implementers were unable to achieve compliance with the new requirements within the granted timeline, and found themselves scrambling to redesign their solutions in order for their certificates to remain valid.

Another consideration: how do you wish to manage your certificates? As with certificate policy, you will be constrained by what the public CA allows. For a small number of customer facing certificates, you may be able to easily operate within those constraints. Larger internal deployments can be more problematic, as publicly trusted CAs may not allow you to issue and manage the certificates or customize their content the way you’d like.

Finally, it’s worth noting that under the Certificate Transparency project, public trust certificates are often sent to public log servers.  That means that the name of the domain protected by the certificate will be logged somewhere. If that domain is your public website, no big deal. However, if a public certificate is protecting an internal corporate domain, the name of that internal domain will be logged publicly.

So, that’s public trust. What about private trust? And which is right for you? Stay tuned for Part 2…