PKI Use-Cases
In the beginning, PKI was thought of as a global infrastructure to securely identify members of a large population where everyone has digital certificates, and these certificates are the primary means to authenticate users over the network for a wide variety of activities—sending mail, making purchases over the Web, conducting financial transactions, even participating in electronic voting and so on. Such widespread use has not become a reality. However, in certain niche areas, PKI has successfully been deployed to meet very specific needs. We look at two such PKI use-cases in this section.
Server Authentication for Online Transactions
This particular use-case is something most of us encounter in our daily life. Go to the website of online broker E*Trade through the HTTPS URL https://www.etrade.com. When you point your browser to this URL, under the hood, the browser gets a certification path from the E*Trade Web server and attempts to validate it based on the trusted certificates in its certificate store. It also matches the hostname specified in the URL with the common name specified within the server certificate. If the validation succeeds, the browser loads the page served by the Web server, indicating the use of a secure connection by displaying a small padlock image in the right bottom corner of the browser. Clicking on this padlock, you get the information about the certificate furnished by the server. Figure 4-5 shows the Certificate Information panel displayed by Internet Explorer.
Figure 4-5. Certification Path of E*Trade Server Certificate
If the validation fails, the browser indicates the reason for failure and prompts you either to proceed, ignoring the validation result or to discontinue the operation. The presence of a certificate issued by a trusted CA provides assurance that the identity of the organization operating the website has been verified by the CA as per its policies.
We learn more about use of PKI in HTTPS in Chapter 6, Securing the Wire.
Authenticating a JCE Provider
We learned in Chapter 3, Cryptography with Java that the JCE engine of J2SE v1.4 expects JCE provider jar file(s) to be signed by JCE Code Signing CA or a CA whose certificate it has signed. This is a special case of a PKI-based code signing application where a user or program accepts a piece of code only from sources that have been certified by a trusted authority.
This is how this scheme works: The JCE engine verifies the signature at the time of loading a new JCE implementation class. If the class doesn't belong to an appropriately signed jar file, the verification fails and the JCE engine returns an error. Otherwise, the class loads and executes silently. This is the case with Bouncy Castle JCE provider. The jar file of this provider, bcprov-jdk14-118.jar, is signed by The Legion of the Bouncy Castle CA. The certificate of this CA is signed by JCE Code Signing CA, making it an accepted provider.
This also implies that vendors of new JCE providers must get their jar files signed by JCE Code Signing CA. This way, the JCE Code Signing CA can maintain a degree of control over all the JCE proviers.