Jothy Rosenberg - Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption

This appendix is a collection of detailed reference information covering algorithms, protocols, and mathematics to support the core material in the book. We kept this detail out of the core chapters to make them easier to read but felt this material is useful for you to gain a deeper understanding of the protocols and algorithms used throughout Web Services Security. In particular, we believe an understanding of the computational complexity of these algorithms will lend a deeper appreciation of the way your deployed secure Web services applications will perform.

In this section, we explain how the Secure Socket Layer (SSL) protocol works using an example in which the client is a Web service requestor and the server is the Web service provider. The steps outlined in

A certificate authority (CA) must keep an up-to-date list of all certificates revoked in a certificate revocation list (CRL). It goes without saying that the CA must make it easy for registration authorities to revoke any given certificate (but prove that they have the right to do so). With CRLs, relying parties have the burden of checking this list each time a certificate is presented. Best practices call for a certificate deployment point (CDP) URL to be embedded in each certificate. A CDP is a pointer to the location of the CRL on the Internet, accessible programmatically by any relying party's applications. CRLs are usually updated once per day because the process of generating them is non-trivial. When an organization is dealing with a compromised key or a rogue employee, once-per-day updates can mean a huge loss during that day of compromise. Currently, almost no one checks revocation lists at all. Although the sponsoring CAs obediently create CRLs, and numerous tools can and do process them, there are so many unsolved problems with them that, in our view, CRLs on the Internet are a technological failure.

Online Certificate Status Protocol (OCSP) was an attempt to create a much finer granularity protocol for essentially real-time revocation checking. But like CRLs, the information provided must be signed by the originating CA, which is an expensive operation to perform in real time. The best case on an unloaded system of moderate speed is 26ms response time for a single OCSP request in our tests. In our view, this makes OCSP so limited in scope that it will continue to be only a bit player in revocation solutions. We expect to see very little deployment of OCSP in the future.

Web Services Security must have a workable revocation, and the existing technologies are not strong enough. In our opinion, there is much promise in emerging revocation techniques that are scalable and respond in microseconds, such as Silvio Micali's technique based on chains of hashed secret codes.

The CA generates a secret random 20-byte value X 0. Using X 0 as input to hash function H , you generate X 1 = H ( X 0). Then you use the output of the previous hash computation as input to the next until you achieve X 365. Finally, you insert the value X 365 into the certificate before it is signed by the CA:

C = SIGCA( serial no ., PKU, U, issue date, expiration date, X 365)

This process is shown in .

This certificate is valid on the day it is signed by virtue of the fact that X 365 indicates this is a valid certificate. On the next day, the CA reveals X 364.

To check the validity of this certificate on the next day, you take the revealed X 364 and compute one hash computation using X '365 = H ( X 364), and if the new X '365 = X 365 stored in the certificate, this certificate is still valid. In general, on day D before expiration, the CA reveals XD , from which the correct number of hashes is performed to reach X 365. If the value matches what is in the certificate, it is still a valid certificate. Only the CA knows the starting point; nowhere along the chain can you compute backwards because these are one-way non-reversible hash functions. Furthermore, the intermediate values can always be openly revealed and published. The cost to the CA is a table lookup. The cost to the relying party is a few hashes.

Revocation will be a binary check; either the certificate is revoked, or it is not. Initially, the CA generates a random 20-byte value Y 0 and from this computes Y 1 = H ( Y 0). Y 1 is stored in the certificate before it is signed:

C = SIGCA( serial no. , PKU, U, issue date, expiration date, X 365, Y 1)

Although the certificate is valid, the revocation sentinel revealed by the CA is 0 because H (0) Y 1 for any Y 1. But as soon as this certificate is revoked, the CA reveals Y 0 as the revocation sentinel.