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

Listing 5-23: “asn1.c” asn1_get_bit
int asn1_get_bit( const int length,
const unsigned char *bit_string,
const int bit )
{
if ( bit > ( ( length - 1 ) * 8 ) )
{
return 0;
}
else
{
return bit_string[ 1 + ( bit / 8 ) ] & ( 0x80 >> ( bit % 8 ) );
}
}
Another potentially useful extension is the subjectAltName extension 2.5.29.17.
Look over the defi nition of the subjectName . It specifi es a country, a state, a city,
an organizational unit. This is a pretty good qualifi er for a person, but fairly
irrelevant for a web site. Or an e-mail address. Or an IP address. Or any of a dozen
other entities that you might want to identify with a certifi cate. Therefore, the
subjectAltName extension allows the certifi cate to simply identify, for instance,
a domain name. If the subjectAltName extension is present, the subjectName
can actually be empty. However, the subjectAltName extension is pretty rare, so
in general the subjectName 's C N fi eld identifi es the domain name of the bearer
site. Of course, there's also an IssuerAltName (OID 2.5.29.18), which serves the
same purpose and is equally rare.
The last extension examined here has to do with certifi cate validation. The
entire trust model outlined in this chapter hinges on how accurately CAs vet
certifi cate requests. The CertificatePolicies extension 2.5.29.32 provides a
way for the CA to indicate how it goes about verifying that the requester of a
certifi cate is, in fact, the entity it purports to be. Recently, the CA/Browser forum
began compiling a list of CAs that perform what is called extended validation.
Extended validation just indicates that a CA has made extraordinary efforts to
ensure that it is signing a certifi cate on behalf of the true owner of the identity
in question. Recent browsers have begun displaying a green bar in addition to
the traditional padlock icon to tell the user that the certifi cate is not only valid,
but that it has been signed by an extended validation CA.
A complete X.509 implementation should recognize all of the extensions
listed in RFC 5280.
The extensions mark the end of the TBSCertificate . There are two fi elds
left in the signed certifi cate structure: the signature algorithm and the signa-
ture itself. The signature algorithm is an OID, and must match the signature
algorithm listed in the tbsCertificate . The signature, of course, is a bit string
whose interpretation varies depending on the signature algorithm. For RSA,
it's simply a large integer, parsed in Listing 5-24.