[Help-gnutls] Re: Verifying subjectAltNames

[Matthias Wimmer]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20070129/04fb38f9/attachment.bin>