Matthias Wimmer <[EMAIL PROTECTED]> writes:
> Hi Simon!
>
>
> I now implemented checking of id-on-xmppAddr in the RFC 3920 server
> using libtasn1 directly (to be compatible with existing versions of
> GnuTLS).
Hi Matthias! Ok.
> But I am still interested in having direct id-on-xmppAddr support in
> GnuTLS, so I continued thinking about an interface: I don't think that
> our initial idea would be working. (Having one or two functions
> returning the OID for an otherName and its content.)
> This won't work, as I think we cannot know the content of the
> otherName.value part. In case of id-on-xmppAddr it is an UTF8String,
> but I guess it might also use other string representations. So we will
> still be only able to return known types of otherName. Right?
My idea was to extract the raw bytes in the 'value' field of the
otherName, and let the caller figure out how to interpret it. If the
caller knows about the OID, that should be simple. This should work
well for you, since for id-on-xmppAddr you could use the raw string as
the UTF-8 string directly. However...
> So if I am not wrong, we should be able to just extend
> gnutls_x509_subject_alt_name_t to be able to represent id-on-xmppAddr
> and report the new value back in
> gnutls_x509_crt_get_subject_alt_name().
...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...
My current idea is that gnutls_x509_crt_get_subject_alt_name() can
parse "virtual" SAN's, identified by:
typedef enum gnutls_x509_subject_alt_name_t
{
GNUTLS_SAN_DNSNAME = 1,
GNUTLS_SAN_RFC822NAME,
GNUTLS_SAN_URI,
GNUTLS_SAN_IPADDRESS,
GNUTLS_SAN_OTHERNAME,
/* The following are "virtual" subject alternative name types, in
that they are represented by an otherName value and an OID. */
GNUTLS_SAN_XMPP = 1000
} gnutls_x509_subject_alt_name_t;
So if it finds an "otherName" which it understands (currently only
XMPP), it should return GNUTLS_SAN_XMPP, otherwise it will return
GNUTLS_SAN_OTHERNAME and the "value" data. I have one new API that
will return the otherName OID, to handle non-supported otherName's.
That should make it possible for others to use GnuTLS APIs instead of
having to use libtasn1 directly, for other unsupported SAN's.
/Simon
_______________________________________________
Help-gnutls mailing list
Help-gnutls@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnutls
