This one of a series of a messages describing new features in Isode R14.4, scheduled to ship in April 2009. You can see all of the messages on this blog relating to R14.4 by clicking on this link
Support of X.509 SubjectAltName is important for all applications using Digital Signatures and X.509 PKI, apart from Directory Applications. Background information is provided in "Why Strong Authentication? - The Security and Administrative Benefits of using X.509 PKI based Strong Authentication"
An X.509 Certificate identifies the entity being certified by the "Subject Name", which is an (X.500/LDAP) directory name. This Subject Name can be used directly by directory protocols, as this is how directory entities are identified. Other protocols names entities in different ways. For example Internet Email identifies users by an email address, so that a digitally signed email needs to have the certificate associated with that email address. If the email address does not match, the signature is pretty much worthless.
X.509 Certificates support this by use of the "Subject Alternate Name" extension mechanism, which is commonly abbreviated to "SubjectAltName". This mechanism allows different names to be associated with a Certificate. In particular:
- Internet Email Address
- Domain Name
- IP Address
- URI
- Two X.400 forms:
- OR Address (for Users, UAs, P7 and P3; defined in X.509)
- MTA (for P1 and P3; defined in X.402)
- Two XMPP forms (define in RFC 3920 Section 5.1.1):
- Client (the JID - which is the XMPP User Name)
- Server (according to the services offered)
R14.4 adds support for these forms of SubjectAltName (apart from X.400 MTA, which will be added in a future release). The rest of this message looks at what support means.
First, support ties back to the various places where digital signatures are used. Isode products using digital signature check validity of the appropriate SubjectAltName. This covers XMPP, Internet Messaging, Web Applications and X.400 messaging. Note that directory products use SubjectName.
R14.4 also adds support to help generate certificates with the correct SubjectAltName values. The starting point for generating a certificate is to use Sodium's capability to build a PKCS#10 CSR (Certificate Signing Request) that is sent to the Certificate Authority (CA) that generates the Certificate Sodium's starting point for the CSR is a directory entry that holds information on the entity to be certified. The SubjectAltName information will usually be held as attributes in the directory entry, so Sodium makes it straightforward to include SubjectAltName values derived from appropriate attributes in the directory entry. SubjectAltName values can also be manually entered into the CSR.
Finally, there is support for ongoing management. SubjectAltName values in certificates stored in the directory are displayed by Sodium along with other information in the certificate. The values of SubjectAltName are checked against values in the entry in the directory. Similarly, the Subject Name is checked against the name of the entry. Any inconsistencies are clearly flagged. This enables problems to be easily detected; for example it would show where a user changed email address (as represented in the email attribute) and this change was not correctly reflected in an updated certificate.
Comments