5

Are there any extensions/extended key usage attributes of a X.509Certificate that are rarely or never used in practice?
Either due to never being part of an issued certificate or because they are skipped during validation for some reason (e.g. obscurity in the RFC on the usage of the attribute)?
A documentation of the opposite (i.e. list of attributes extensions/extended key usage that are known to be used in the field) if available would be also of interest to me.

1 Answer 1

7

Take care that the set of possible extensions is, by definition, not bounded (at least not practically; there is an internal limit a bit of about 1282255). There are standard extensions which are described in the X.509 standard, but there could be a lot more elsewhere. In particular, Microsoft's implementations (e.g. AD Certificate Services) tend to use a few Microsoft-specific extensions (such as an extension which designates the "certificate template" which was used to issue a given certificate).

Among the extensions described in RFC 5280 (which is the standard for "X.509 on the Internet"), the following are rarely used in practice:

  • Policy Mappings: people rarely get policies right anyway, and to use mappings meaningfully you have to understand how certificate policies work.

  • Issuer Alternative Names: this is not a very useful extension, since name chaining in a certificate path uses Distinguished Names, so there is little reason to give extra names to the issuer (if extra names are needed for an entity, they will be as Subject Alternative Names in the certificate for that entity).

  • Name Constraints: support from existing implementations is, let's say, a bit lacking in reliability. Also, the semantics are convoluted and contrived, so even if someone says that they implemented it, you cannot be sure that they implemented it properly and it is hard to test. Thus, nobody really uses them.

  • Policy Constraints and Inhibit anyPolicy: same reasons as for policy mappings.

  • Subject Directory Attributes: too new, too broad in scope.

All other standard extensions are commonly used (not always used, but common enough). However, some features of these extensions are rarely used, including indirect CRL (where the CRL issuer is not the CA), CRL scopes which do not cover all revocation reasons, X.400 addresses,...

2
  • So I understand that an organization can create its own "custom" extensions?Is this what you mean with the example of Microsoft?But in this case how are clients supposed to take these into account?Or are they for MS client implementations as well?
    – Jim
    Oct 24, 2012 at 18:26
  • Every extension can be marked as "critical" or "non critical". Systems which encounter extensions that they do not understand can ignore them if they are marked non-critical, and must reject the certificate altogether if one of these unknown extensions is marked "critical". Thus, non-standard extensions can be embedded in certificates. Oct 24, 2012 at 19:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .