The current use of
X.509v3 certificates loaded directly into
web browsers (as opposed to referenced in a directory structure) was necessary for e-commerce to develop by allowing for secure web based (SSL/TLS) communications which did not require the X.500 directory as a source of digital certificates as originally conceived in X.500 (1988). X.509 was designed to be the secure access method for updating X.500 before the
World Wide Web, but then as web browsers became popular, there needed to be a simple method of encrypting connections on the
transport layer to web servers. Hence, trusted
root certificates for supported certificate authorities were pre-loaded into certificate storage areas on the communicating devices (e.g. personal computer, proxy, or web server). Added security is envisaged by the scheduled 2011-2014 implementation of the US
National Strategy for Trusted Identities in Cyberspace, a two- to three-year project protecting digital identities in cyberspace. The WWW e-commerce implementation of X.509v3 bypassed, but did not replace, the original ISO standard authentication mechanism of binding distinguished names in the X.500 Directory. These packages of certificates can be added or removed by the end user in their software, but are reviewed by browser and operating system vendors (such as
Microsoft and
Mozilla) in terms of their continued trustworthiness. Should a problem arise, such as what occurred with
DigiNotar, browser vendors can issue an update to mark a certificate authority as untrusted, but this is a serious removal effectively of that CA from "internet trust". X.500 offers a way to view which organization claims a specific root certificate, outside of that provided bundle. This can function as a "4 corner model of trust" adding another check to determine if a root certificate has been compromised. The contrast of this browser bundled approach is that in X.500 or LDAP the attribute "caCertificate" can be "bound" to a directory entry and checked in addition to the default pre-loaded bundle of certificates of which end users typically have never noticed unless an SSL warning message has appeared. For example, a web site using SSL, typically the DNS site name "www.foobar.com" is verified in a browser by the software using libraries that would check to see if the certificate was signed by one of the trusted root certificates given to the user. Therefore, creating trust for users that they had reached the correct web site via HTTPS. However, stronger checks are also possible, to indicate that more than the domain name was verified. To contrast this with X.500, the certificate is one attribute of many for an entry, in which the entry could contain anything allowable by the specific Directory schema. Thus X.500 does store the digital certificate, but it is one of many attributes that could potentially verify the organization, such as physical address, a contact telephone number and an email contact. CA Certs or certificate authority certs are loaded into the browser automatically (in the case of Microsoft's update mechanism), or in new version updates of browsers, and the user is given further choices to import, delete, or develop an individual trust relationship with the loaded Certificate Authorities and determine how the browser will behave if OCSP revocation servers are unreachable. This is in contrast with the Directory model which associates the attribute "caCertificate" with a listed certificate authority. Thus the browser can verify the SSL cert of the website by means of the loaded group of accepted certificates or the root certificates can be looked up in an X.500 or LDAP Directory (or via HTTP/S) and imported into the list of trusted certificate authorities. The "bound" distinguished name is located in the subject fields of the certificate which matches the Directory entry. X.509v3 can contain other extensions depending on the community of interest other than international domain names. For broad Internet use, RFC-5280 PKIX describes a profile for fields that may be useful for applications such as encrypted email. An end user who relies on the authenticity of a certificate being presented to a browser or email has no simple way to compare a forged certificate presented (perhaps which triggers a browser warning) with a valid certificate, without also being given the opportunity to validate the DN or Distinguished Name which was designed to be looked up in an X.500 DIT. The certificate itself is public and, because of
its signature, considered to be unforgeable and can therefore be distributed in any manner, but an associated binding to an identity occurs in the Directory. Binding is what links the certificate to the identity who claims to be using that certificate. For example, the X.500 software that runs the Federal Bridge has cross certificates that enable trust between certificate authorities. If a X.509v3 certificate is bound to a valid organization's distinguished name within the Directory, then a simple check can be made in regards to the authenticity of the certificate by a comparison with what is presented to the browser with what is present in the Directory. Some options do exist to check notaries to see if a certificate has only recently been seen, and therefore more likely to have been compromised. If the cert is likely to be trusted and is failing because the domain name is a slight mismatch, it will then initially fail in the browser, but then be subjected to the notary trust, which can then bypass the browser warning. A valid organizational entry, such as o=FoobarWidgets, will also have an associated alphanumeric OID, and it has been "identity proofed" by ANSI, providing another layer of assurance regarding binding the certificate to the identity.
Certificate distribution via DNS and directories; sector-specific uses Some deployments (for example, the US
Direct Project, which created standards for PKI in the healthcare industry) specify DNS-based publication of recipient
S/MIME certificates, with options for DNS-based or LDAP-based discovery. Early profiles used the DNS CERT Resource Record (); newer specifications define DANE mechanisms, including TLSA for TLS and SMIMEA for S/MIME. In practice, many production healthcare exchanges rely on curated trust-anchor bundles and directory/HTTP services, with
DNSSEC/
DANE adoption varying by ecosystem. DNS is sometimes preferred for storing and distributing information as it is
highly available, and this can be applied to certificates and identities.
Namespace and governance considerations The concept of DNS
root name servers has been contentious within the Internet community, though the issue is largely resolved for DNS. By contrast, the X.500 namespace has traditionally been viewed as starting with a national naming authority, mirroring ISO/ITU approaches with national representation. Different countries therefore create their own unique X.500 services.
Security incidents and transparency efforts Events in 2011 highlighted threats from unknown nation-state actors forging certificates. A man-in-the-middle attack against political activists in Syria accessing Facebook over the web would normally have triggered a browser warning (which many ordinary users would reflexively dismiss), but would not have done so had the MITM certificate been issued by a CA already trusted by the browser. Similar techniques were used by Stuxnet to allow malicious software to impersonate trusted code – in that event, using stolen rather than forged certificates. The aim of
certificate transparency is to provide an end user with a simple procedure to determine whether a certificate is valid; checking only against the default bundle may be insufficient, hence the desire for an additional check. Other proposals for certificate transparency have also been advanced. A different attack affected Comodo, resulting in forged certificates targeting high-profile communications websites and necessitating urgent updates to major browsers. In that case, the certificates were actually issued by a trusted CA, leaving end users with no warning if they visited a spoofed site – unlike the Syrian incident, where the certificate was crudely forged (substituting "Alto Palo" for "Palo Alto") and contained incorrect serial numbers. ==List of X.500 series standards==