[jdev] JID and X.509

[Justin Karneges]

On Wednesday 08 March 2006 05:39, Heiner Wolf wrote:
> I understand that the certificate holds keys as OIDs. Any idea how this
> fits to the mentioned key-value pairs? I doubt that X.509 APIs know the
> OID for id-on-xmppAddr. So I doubt that putting
> "id-on-xmppAddr"-"node at domain.tld" into my API does any good. Ideas?

You are correct.  Many APIs work with a set of known keys.  You need an API 
that is either aware of xmppAddr, or one that will allow you to set an 
otherName extension with an OID (that dotted string thing) and everything.  
Some APIs won't even have this, in which case adding xmppAddr would be 
impossible.  However, even if you're able to set an extension, you'll still 
need to create the "value" part, which would be some sort of binary packed 
ASN.1 (but fortunately for xmppAddr, it is rather simple).

Below is a snippet of one of my mails with Jack Lloyd (of Botan) last November 
discussing the otherName support in QCA (my security library).  I had to 
learn up on ASN.1 to get this right.  Maybe it will be useful:

--
To be sure that I'm doing OtherName properly, here is a sample SubjectAltName 
value that contains the XMPP OtherName (from 
http://www.xmpp.org/specs/rfc3920.html Section 5.1.1).

30 = 00110000 - universal, constructed, type 16 (sequence)
35 = 00110101 - 53 bytes
 81 = 10000001 - context specific, primative, type 1 (email)
 12 = 00010010 - length 18
  6A 75 73 74 69 6E 40 61 66 66 69 6E 69 78 2E 63 6F 6D (justin at affinix.com)
 A0 = 10100000 - context specific, constructed, type 0 (otherName)
 1F = 00011111 - length 31
  06 = 00000110 - universal, primitive, type 6 (object id)
  08 = 00001000 - length 8
   2B 06 01 05 05 07 08 05 -> 0x2B = 43, x = 1, y = 3 (1.3.6.1.5.5.7.8.5)
  A0 = 10100000 - context specific, constructed, type 0 (otherName value)
  13 = 00010011 - length 19
   0C = 00001100 - universal, primative, type 12 (utf8 string)
   11 = 00010001 - length 17
    6A 75 73 74 69 6E 40 61 6E 64 62 69 74 2E 6E 65 74 (justin at andbit.net)

The DER was generated by some openssl-based code that I shared with you eons 
ago, and this is my hand-decoding of the resulting OCTET STRING found inside 
SubjectAltName.  Maybe you can check this to see if it looks right (and I've 
attached the cert to this email if you want to parse it).

Right now, QCA has direct support for the XMPP OtherName.  However, I'm 
considering taking it out and having my XMPP code use the QCA extension API 
instead, as a way to "prove" the extension system.  Here's an example of what 
it might look like in use:

  #define XMPP_NAME "1.3.6.1.5.5.7.8.5"

  QString jid = "justin at andbit.net";
  QByteArray buf(19);
  buf[0] = 0xC0; // universal, primative, type 12 (utf8 string)
  buf[1] = 17;   // length 17
  buf += jid.toUtf8();

  altNames.addOtherName(XMPP_NAME, buf);

Of course, I'll probably want more advanced "length" encoding for larger 
UTF8String values, but you get the idea.  I think this interface shouldn't be 
too painful for minimal extension values, such as XMPP.  I guess if things 
get complex then the user will want to bring along an ASN.1 parser, but at 
least it will be possible.
--

Good luck,
-Justin