Re: [certid] open issue: wildcards in component fragments

[ArkanoiD <[e-mail]>]

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) ;-)