How are possible uses for X.509 (SSL) certificates denoted?

Question

X.509 certificates can be used for servers, clients, email, code signing and more applications. http://twitpic.com/6gdxaq indicates that a certificate can have different of these 'capabilities' on it - but how do you see those? What X.509 field denotes these different uses?

Answer 1

There are several extensions which restrict usages for a certificate. A basic certificate, without any extension, is deemed "fit for any purpose", as far as X.509 is concerned. The key type can still have some consequences; e.g. a RSA key can work for both asymmetric encryption and signatures, but a DSA (or ECDSA) key, by construction, can only serve for signatures (a signature-only certificate is still good enough for a SSL client or server, though, because of "DHE" cipher suites).

The standard extensions which limit "capabilities" for a certificate are the two following:

• Key Usage: this is a set of flags which indicate low-level operations. There are exactly nine flags: digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, and decipherOnly. The semantics of each flag are subtle and not well-defined (e.g. the difference between digitalSignature and nonRepudiation is a matter of much more speculation than interoperability).

• Extended Key Usage: this is an open-ended list of "allowed usages" which are represented as OID. Since there virtually is an infinity of possible OID, there can be no exaustive list of possible extended key usages. Each protocol or standard using X.509 certificate is supposed to define its own extended key usages; e.g. time stamp authorities use 1.3.6.1.5.5.7.3.8 (see section 2.3).

Microsoft, in their own CA software ("Active Directory Certificates Services") decided that the standard extensions were not good enough, so they defined another called Application Policies, which contains the exact same information as Extended Key Usage except that its encoding format mimics that of the standard Certificate Policies extension, which means that it gets additional optional comment fields, which ADCS does not actually fill in. Note that ADCS also stores the information as a standard Extended Key Usage extension, so the net effect of this non-standard extension is to spread confusion.

Another, older, non-standard extension which attempted to convey usage restriction was the netscape-cert-type extension. This brings us back to the Netscape Navigator 4.0 times, at the end of the previous century. Some CA still include this extension in their certificates, more for the sake of Tradition than for actual interoperability.

---

The contents of an extension are honoured only insofar as the involved software understands it. Extensions can be marked "critical", meaning that an implementation which does not recognized an uncritical extension is allowed to ignore it, while an unknown critical extension MUST trigger unconditional rejection of the certificate. That's the theory, and, of course, practice may differ. Some implementations do not honour the criticality flag. Other ignore non-critical extension even if they recognize them. The wording of the standard is not crystal-clear either:

A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.

An implementation could claim that it has "processed" an extension by ignoring its contents, because there is a difference between recognizing an extension, and enforcing its semantics. The whole picture is made even more blurred with some extensions, in particular CRL Distribution Points, whose semantics depend on whether the extension was marked critical or not.

Answer 2

X.509 "Key Usage" defines what the issuer allows the certificate to be used for. Remember that not all applications follow this requirement however.

Answer 3

There is a summary of the extensions used for TLS/SSL in NSS Technical Note: 3, by Nelson B. Bolyard.