Creating a Network of Trust Using X.509 Certifi cates - Implementing SSL/TLS Using Cryptography and PKI - page 240

certify other authorities, and the client only has to be aware of a dozen or so
root authorities. You can extend this scheme to any level of sub-delegates; the
client just goes on checking signatures until it fi nds a signature issued by an
authority it already trusts.
Unfortunately, this system was put in place and used for a while before
somebody identifi ed a fatal fl aw. The problem is that every certifi cate includes
a public key, and any public key can sign another certifi cate. Therefore, there's
nothing stopping an unscrupulous site administrator from using a regular
server certifi cate to sign another certifi cate, as shown in Figure 5-6, for example.
root
delegate
legitimately
obtained server
certificate
certificate
identifying any
website
Figure 5.6: Illegitimate delegation
As a result, almost all clients are designed to require that each certifi cate be
signed by a trusted authority and to reject delegated signatures.
The Key Usage certifi cate extension — OID 55 1D 0F — was introduced to
allow this sort of delegated signature scheme in a safe way; this (critical) exten-
sion encodes a bit string, each of whose eight bits is either set or unset to iden-
tify that the public-key contained in this certifi cate may or may not be used
for a particular purpose. Of course, there's nothing stopping an unscrupulous
user from using the key for a nonspecifi ed purpose anyway, but the receiver
can check the key usage bit and determine whether to allow the sender to do
so. The most important bit is bit 5, which, if set, identifi es this certifi cate as a
legitimate signing authority. Presumably, the issuing CA only allows this bit