Re: [jdev] JID and X.509
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"-"[EMAIL PROTECTED]" 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 = 0011 - universal, constructed, type 16 (sequence) 35 = 00110101 - 53 bytes 81 = 1001 - 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 ([EMAIL PROTECTED]) A0 = 1010 - context specific, constructed, type 0 (otherName) 1F = 0001 - length 31 06 = 0110 - universal, primitive, type 6 (object id) 08 = 1000 - 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 = 1010 - context specific, constructed, type 0 (otherName value) 13 = 00010011 - length 19 0C = 1100 - 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 ([EMAIL PROTECTED]) 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 = "[EMAIL PROTECTED]"; 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
Re: [jdev] JID and X.509
Peter Saint-Andre wrote: Heiner Wolf wrote: I am writing a Jabber CA. Good luck. It's no fun to be a certification authority. Thanks. If a JID for any kind of XMPP entity (e.g., client or server) is represented in a certificate, it MUST be represented as a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] Object Identifier "id-on-xmppAddr" specified in Section 5.1.1 of this document. [...] RFC 3920 is clear on this. I would say that userID is not a candidate (although RFC 3920 does not prohibit that, since it says only that the JID MUST be stored as an otherName in the subjectAltName, IMHO it is not a good idea to store the same information in two places). So it is "id-on-xmppAddr". I don't know much about ASN.1 and X.509. Maybe you can give me a hint: The API I am using allows to put key value pairs like "countryName"-"UK" and "commonName"-"Wez Furlong" into the certificate. Would "id-on-xmppAddr"-"[EMAIL PROTECTED]" fit into the scheme? 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"-"[EMAIL PROTECTED]" into my API does any good. Ideas? It will be stored as a JID of the form "[EMAIL PROTECTED]". It will not be stored as an XMPP URI (i.e., with a "xmpp:" prefix). It will not be stored with a "jabber:" prefix since no document defines that prefix. Yes, just an accident, don't know how jabber: came into play here. :-) hw -- Dr. Heiner Wolf bluehands GmbH & Co.mmunication KG http://www.bluehands.de/people/hw +49 (0721) 16108 75 -- Jabber enabled Virtual Presence on the Web: www.lluna.de Open Source Future History: www.galactic-developments.de
Re: [jdev] JID and X.509
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Karneges wrote: > On Tuesday 07 March 2006 12:05, Peter Saint-Andre wrote: >>> Canditates for storing the JID are: userID id-on-xmppAddr >> RFC 3920 is clear on this. I would say that userID is not a candidate >> (although RFC 3920 does not prohibit that, since it says only that the >> JID MUST be stored as an otherName in the subjectAltName, IMHO it is not >> a good idea to store the same information in two places). > > Currently, everyone puts the domain of a server in the commonName. And this > is also consistent with RFC 3920's recommendation of using the HTTP methods > to verify if a certificate in a c2s/s2s connection is valid. Thus, it should > be quite acceptable to put the value in three fields: commonName, dNSName, > and xmppAddr otherName. > > We should probably not put nodes into the commonName and dNSName fields. > These fields should only be used if your JID is domain-only. However, it is > not clear if this is forbidden (maybe something to note in 3920bis?). It's not forbidden and I don't think it should be. > As I think about this some more, it seems to me that in a Jabberized world, > the only field we'd care about is xmppAddr. dNSName and commonName are > really only there for compatibility with existing CAs and restrictive TLS > implementations. Exactly. > As I think about this even /more/, I wonder if we should allow fallback of > JIDs with nodes into the rfc822Name field. Remember that an rfc822Name is not UTF-8, so beware of i18n problems. > This may help with > similarly-restrictive S/MIME implementations, as well as CAs. I agree that > putting the same information in two places is not a great idea, but there > seems to be a standard practice of already doing it with domains, so I think > it is worth considering for jid->email. Sure, it's analogous to using CN for domains. I don't have strong objections to the practice, but it is suboptimal in the sense that id-on-xmppAddr is preferred. Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDfyINF1RSzyt3NURAv6yAJ4sO7ons/OCEQaeZPMfjqbsZhDkZQCdGWhP dFYvEyAL/DHnQSRSo3na78w= =fsQY -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [jdev] JID and X.509
On Tuesday 07 March 2006 12:05, Peter Saint-Andre wrote: > > Canditates for storing the JID are: userID id-on-xmppAddr > > RFC 3920 is clear on this. I would say that userID is not a candidate > (although RFC 3920 does not prohibit that, since it says only that the > JID MUST be stored as an otherName in the subjectAltName, IMHO it is not > a good idea to store the same information in two places). Currently, everyone puts the domain of a server in the commonName. And this is also consistent with RFC 3920's recommendation of using the HTTP methods to verify if a certificate in a c2s/s2s connection is valid. Thus, it should be quite acceptable to put the value in three fields: commonName, dNSName, and xmppAddr otherName. We should probably not put nodes into the commonName and dNSName fields. These fields should only be used if your JID is domain-only. However, it is not clear if this is forbidden (maybe something to note in 3920bis?). As I think about this some more, it seems to me that in a Jabberized world, the only field we'd care about is xmppAddr. dNSName and commonName are really only there for compatibility with existing CAs and restrictive TLS implementations. As I think about this even /more/, I wonder if we should allow fallback of JIDs with nodes into the rfc822Name field. This may help with similarly-restrictive S/MIME implementations, as well as CAs. I agree that putting the same information in two places is not a great idea, but there seems to be a standard practice of already doing it with domains, so I think it is worth considering for jid->email. > > Any other ideas? BTW: What means "id-on-" in id-on-xmppAddr? Why nt > > just "xmppAddr"? > > It's ASN.1 madness, don't ask. And just shorthand for documentation purposes. The string is basically like a namespace, and the prefix helps give an idea of what it is for, which I think is Identity-OtherName (just a guess). This namespace string doesn't appear in the Certificate anywhere, only the OID does, so there's no reason to get too hung up about it. -Justin
Re: [jdev] JID and X.509
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heiner Wolf wrote: > Hi > > I am writing a Jabber CA. Good luck. It's no fun to be a certification authority. > I would like to sign a certificate which > certifies that the holder of the certificate owns the JID, that is > embedded in the certificate. I will issue X.509 certificates. Where > in X.509 should the JID be stored and how? This is explained in Section 5.1 of RFC 3920: http://www.xmpp.org/specs/rfc3920.html#tls-overview Specifically: *** If a JID for any kind of XMPP entity (e.g., client or server) is represented in a certificate, it MUST be represented as a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] Object Identifier "id-on-xmppAddr" specified in Section 5.1.1 of this document. *** See also http://www.xmpp.org/specs/rfc3920.html#tls-overview-oid for the ASN.1 definition. > Canditates for storing the JID are: userID id-on-xmppAddr RFC 3920 is clear on this. I would say that userID is not a candidate (although RFC 3920 does not prohibit that, since it says only that the JID MUST be stored as an otherName in the subjectAltName, IMHO it is not a good idea to store the same information in two places). > Any other ideas? BTW: What means "id-on-" in id-on-xmppAddr? Why nt > just "xmppAddr"? It's ASN.1 madness, don't ask. > Next question: how will it be stored: [EMAIL PROTECTED] > jabber:[EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] It will be stored as a JID of the form "[EMAIL PROTECTED]". It will not be stored as an XMPP URI (i.e., with a "xmpp:" prefix). It will not be stored with a "jabber:" prefix since no document defines that prefix. Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDedvNF1RSzyt3NURAq8DAKC5l3nAqvfqmsgnDR/Ee7w0cEhXoQCeNy2/ swQwAiXMzcYRE4acqKPqXmc= =Sj+7 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
[jdev] JID and X.509
Hi I am writing a Jabber CA. I would like to sign a certificate which certifies that the holder of the certificate owns the JID, that is embedded in the certificate. I will issue X.509 certificates. Where in X.509 should the JID be stored and how? Canditates for storing the JID are: userID id-on-xmppAddr Any other ideas? BTW: What means "id-on-" in id-on-xmppAddr? Why nt just "xmppAddr"? Next question: how will it be stored: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] hw -- Dr. Heiner Wolf bluehands GmbH & Co.mmunication KG http://www.bluehands.de/people/hw +49 (0721) 16108 75 -- Jabber enabled Virtual Presence on the Web: www.lluna.de Open Source Future History: www.galactic-developments.de
