[Help-gnutls] Re: Verifying subjectAltNames

[Simon Josefsson]

Simon Josefsson <simon at josefsson.org> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> ...yes, I think we should do this.  I have a partial implementation
>> working now, but I could use a sample certificate with a
>> id-on-xmppAddr to finish it.  Could you send me one?  I'll try to
>> figure out how to create such a certificate using certtool as well...
>
> No need, I figured enough of the XMPP protocol to get gnutls-cli to
> STARTTLS to it, so I got jabber.org's certificate.  This should be
> implemented soon.

Ok, we now have generic support for otherName's in SAN, and specific
support for XMPP.  The NEWS entry is:

** Support for 'otherName' Subject Alternative Names.
The existing API gnutls_x509_crt_get_subject_alt_name may now return
the new type GNUTLS_SAN_OTHERNAME together with the otherName value.
To find out the otherName OID (necessary for proper parsing of the
value), use the new API gnutls_x509_crt_get_subject_alt_othername_oid.
For known OIDs, gnutls_x509_crt_get_subject_alt_othername_oid will
return "virtual" SAN values, e.g., GNUTLS_SAN_OTHERNAME_XMPP to
simplify OID matching.  Suggested by Matthias Wimmer <m at tthias.eu>.

** Certtool can print otherName SAN values for certificates.
For known otherName OIDs (currently only id-on-xmppAddr as defined by
RFC 3920), it will also print the name.
...
** API and ABI modifications:
gnutls_x509_crt_get_subject_alt_othername_oid: ADD.
GNUTLS_SAN_OTHERNAME: ADD, new gnutls_x509_subject_alt_name_t element.
GNUTLS_SAN_OTHERNAME_XMPP: ADD, new gnutls_x509_subject_alt_name_t element.

For the jabber.org certificate, certtool in CVS prints:

X.509 Extensions:
        Subject Alternative name:
                otherName:
                        DER: 0c0a6a61626265722e6f7267
                        ASCII: ..jabber.org
                        OID: 1.3.6.1.5.5.7.8.5 (id-on-xmppAddr)
                DNSname: jabber.org
                DNSname: *.jabber.org
...

I'm not sure whether the 0c0a should have been stripped or not.
Possibly libtasn1 should have done that.  It looks like length fields
(first 0c includes second length field and the final zero, second 0a
give length of the string without final zero).  Feedback on that would
be appreciated.  I suspect the lengths are specific to UTF8String, so
gnutls_x509_crt_get_subject_alt_name probably shouldn't mess with it.
But I'm not sure.  If it helps, we can provide a decoding-function for
UTF8String if you like, though.

I slightly changed the API since earlier e-mails, so that
gnutls_x509_crt_get_subject_alt_name doesn't return the
GNUTLS_SAN_OTHERNAME_* types.  It was easier to implement and will be
easier to use too.

Let me know if this looks good for you, and I'll release 1.7.6.

/Simon