[jdev] JID and X.509
stpeter at jabber.org
Tue Mar 7 15:35:05 CST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev