[Standards-JIG] Re: wildcards in certs
Mridul.Muralidharan at Sun.COM
Tue Nov 28 10:09:50 UTC 2006
Peter Saint-Andre wrote:
> 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).
In this case, why not just remove the xmpp oid and rely only on dNSName ?
What is the additional functionality provided by the xmpp oid ?
dNSName is defined by http-tls for purpose of https ... we could decide
to reuse that entirely, or define xmpp's way of doing things : there
need not always be a match between both.
More information about the Standards