On Thu, Oct 07, 2010 at 02:44:18PM -0600, Peter Saint-Andre wrote: > On 10/7/10 6:57 AM, ArkanoiD wrote: > > Are there any such certificates "in the wild"? Do current clients > > support it? If there aren't any and it is not supported anyways, > > let's keep status quo and do not make things more complicated than > > needed. For www1, www2 etc one may use extra name component and > > that's all. > > What do you mean by "the status quo" -- the text in version -09 of the > server-id-check I-D (no wildcard in component fragments, like foo*) or > the text in RFC 2818 and several other specs (*oo and f*o and foo* are > fine)?
I mean current implementations and already issued certificates. > As far as I can see, allowing wildcards in component fragments makes > things more complicated than needed because a CA needs to have more > complex rules for issuance and a TLS library or application client needs > to have a more complex parsing algorithm (checking for things like > *oo.example.com and foo*.example.com and f*o.example.com instead of just > *.example.com -- it's also not clear to me from RFC 2818 if multiple > instances of the wildcard character are allowed, such that > f*b*r.example.com would be acceptable). Allowing '*' only as the > complete left-most label seems easier to me (and I've received feedback > to that effect off-list, as well). It was my primary concern too, i definitely prefer simple and straightforward parsers that are less likely to behave any unexpected way :-) Once we agree to implement complex parsing, someone almost certainly will just use his favourite regexp library just because it saves time (causing total havoc) ;-) _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
