help-gnutls
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-gnutls] Re: Verifying subjectAltNames


From: Matthias Wimmer
Subject: [Help-gnutls] Re: Verifying subjectAltNames
Date: Mon, 29 Jan 2007 21:36:15 +0100
User-agent: Thunderbird 2.0b2 (Windows/20070116)

Hi Simon!

Simon Josefsson schrieb:
Well for my purpose / the purpose of using GnuTLS for XMPP (RFC 3920)
the best would be to have a higher level function like
gnutls_x509_crt_check_hostname(), e.g. gnutls_x509_crt_check_jid()
where instead of a hostname, a JID (= XMPP address) is passed in.

If the JID contains an '@' or '/' sign, the JID is only checked
against the id-on-xmppAddr. Else the JID is an IDN, which is checked
(as UTF-8 value) against the id-on-xmppAddr or (after punicode-encoding) against
dNSName. If neither id-on-xmppAddr nor dNSName is present in the
certificate, a check against CN is done.

But sure this is only a solution for XMPP, and it might be good to
have an interface to access arbitrary otherNames ...

GnuTLS currently doesn't do UTF-8 let alone any IDN stuff, and I think
it would be nice to keep that to a minimum, to reduce external
dependencies.  So that API isn't really a good solution.

I know. It only was the "what would be best for me" solution. UTF-8 shouldn't be a problem, as if the caller would provide the address in UTF-8 and in the certificate it is a UTF-8 string (required by standard) as well. So it is just a binary comparison. The IDN stuff could be solved by letting the caller provide the the punicoded string (in addition to the UTF-8 version) which can then be compared to the content of dNSName or CN like at present.

The thing is: without such a function, I even have to reimplement gnutls_x509_crt_check_hostname(), as this function does not allow me to request, that only dNSName is checked (but not CN). Which has to be done in case I detected, that there is an id-on-xmppAddr present but I had no match. - As fallback to CN should only be done, if neither id-on-xmppAddr nor dNSName has been present.

What is missing is a field to return the OID of the
otherName data.  Perhaps we could add a function like:

int
gnutls_x509_crt_get_subject_alt_name2 (gnutls_x509_crt_t cert,
                                       unsigned int seq,
                                       void *ret,
                                       size_t * ret_size,
                                       void *oid,
                                       size_t *oid_size,
                                       unsigned int *critical)

If the SAN is an otherName, it would return the OID.
Maybe gnutls_x509_crt_get_subject_alt_name() could return an error
code indicating, that it is an otherName. In that case the user could
have two functions: one to get the oid of the otherName, and another
to get the value!?

Not very pretty, but it is a solution.  Patches welcome..

I just noticed that the current API is lacking another important
thing: you don't know what kind of SAN was returned.  There should be
an 'gnutls_x509_subject_alt_name_t' output variable.

Yes, that would be very useful as well.

In that case the interface proposed above would get even simpler. No need to return an error indicating that it is an otherName in the first call. The result could be already returned in this first call with gnutls_x509_subject_alt_name_t telling that it is an otherName. There would be just a second call required, that returns the OID of the otherName then.


Matthias

--
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]