[Standards] wildcards in XMPP certs

Peter Saint-Andre stpeter at stpeter.im
Thu Jul 17 16:22:51 UTC 2008

Shumon Huque wrote:
> On Wed, Jul 16, 2008 at 10:28:45AM -0600, Peter Saint-Andre wrote:
>> Scrap that idea. I was right the first time. RFC 5280 says:
>>    The name constraints extension, which MUST be used only in a CA
>>    certificate, indicates a name space within which all subject names in
>>    subsequent certificates in a certification path MUST be located.
>> Oh well, it was a pleasant notion while it lasted. All of 15 minutes or 
>> so. ;)
> Right :-)
> Only for CA certificates. If I'm operating a CA that only issues
> certificates for names in the upenn.edu name space (including 
> SRVName name types), then it might be appropriate for the CA
> certificate to include a 'upenn.edu' name constraint extension.
> It might even make it more likely for other people to use that
> CA certificate as a trust anchor since they could be assured that
> this CA can only issue certificates for upenn.edu names, and not
> start issuing certs for microsoft.com or some other unrelated entity. 
> This of course assumes that certificate validation software is correctly
> processing and applying the name constraint, which might be a big
> assumption!

I was told that OpenSSL doesn't support that extension, I don't know 
about other implementations. But for our purposes the point is moot 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080717/4a6c3e59/attachment.bin>

More information about the Standards mailing list