[Standards-JIG] Re: wildcards in certs
stpeter at jabber.org
Mon Nov 27 19:32:56 UTC 2006
Peter Saint-Andre wrote:
> Alexander Gnauck wrote:
>> Matt Tucker wrote:
>>> We find that in many deployments of Wildfire that new components get
>>> added to the server quite often. It would be a huge bummer if people had
>>> to get new certs everytime that happened (so that s2s would work). We'd
>>> advocate using wildcards all the time for simplicity.
>> i agree with Matt. I would not like to install a different certificate
>> for each component/transport.
> Agreed. I will write up some proposed text for rfc3920bis here soon...
How does this look within point 8 of Section 5.1 (some text borrowed
from RFC 2818)?
If a JID for an XMPP client (e.g., an end user account) 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.
If a JID for an XMPP server is represented in a certificate, it SHOULD
at a minimum 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; however,
the JID for an XMPP server MAY be represented as a subjectAltName
extension of type dNSName, where the dNSName may contain the wildcard
character '*', which is considered to match any single domain name
component or component fragment (e.g., *.example.com matches
foo.example.com but not bar.foo.example.com).
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards