*.scripts.mit.edu certificate doesn't handle lockers with dots in their name

[geofft]

See, for instance, ​https://6.034.scripts.mit.edu:444/ or ​https://www.ksplicethesoftware.jbarnold.scripts.mit.edu/.

I'm not sure what the good options are here. We could

• get a few levels of *.*.*.*.scripts.mit.edu as alternate subject names from our money-costing cert
• get a few *.*.*.*.scripts.mit.edu certs from MIT, and do SNI
• fix SSL upstream and wait for it to filter down into browsers in a few months

(Reported by adehnert.)

[andersk]

It turns out that ​none of those solutions work.

[geofft]

Okay, how about

• Amend the RFC (or even just the implementations) to support a cert for **.scripts.mit.edu doing what we want? Or add support for an extra something field to say "This wildcard can cover multiple levels", so it remains a cert with subject name *.scripts.mit.edu for backwards-compatibility?

[andersk]

I think the RFC people will say that what we want is our own signed CA with a ​Name Constraints extension of “.scripts.mit.edu”. I bet it’s approximately impossible to buy such a signature from a “real” CA (though I haven’t looked very hard), but maybe we’d have better luck with the MIT CA?

[xavid]

A less exciting solution would be to give something like 6-034.scripts.mit.edu to the 6.034 locker and suggest they use that for https.

[geofft]

I shot Eric Rescorla, the RFC's author, this e-mail:

> Hi Eric,
> 
> I'm writing in regards to section 3.1 of RFC 2818, specifically:
> 
> > Names may contain the wildcard
> > character * which is considered to match any single domain name
> > component or component fragment. E.g., *.a.com matches foo.a.com but
> > not bar.foo.a.com. f*.com matches foo.com but not bar.com.
> 
> I'm wondering what you would recommend for a certificate that would, in 
> fact, match bar.foo.a.com as well as foo.a.com. Options that occur to me 
> include a special extension in the certificate indicating that the 
> wildcard in *.a.com should be permitted to match multiple components, and 
> issuing a certificate for **.a.com.
> 
> Because of a lack of direction in RFC 2818, browsers and libraries don't 
> implement a way to let a wildcard certificate match multiple components, 
> and websites and CAs won't come up with a certificate that no browser 
> supports -- see <http://code.google.com/p/support/issues/detail?id=2990> 
> for a specific example of this problem.
> 
> Rather than attempting to lobby for an arbitrary choice in my favorite 
> browsers, I'm curious if you have specific recommendations as the RFC 
> author, or if you're aware of other efforts or standards or drafts that 
> address this issue, so we have something on which to base 
> multiple-wildcard support in HTTPS.

Thanks,
-- 
Geoffrey Thomas
geofft@mit.edu

We'll see where it goes. One possible outcome is that he mentions that he doesn't know any solutions but thinks ** might work (it's analogous to, say, bash's syntax for globbing multiple directories), in which case I have something slightly stronger with which to lobby said favorite browsers. At that point we can get **.scripts.mit.edu as a subjectAltName.

[geofft]

Eric replies, CC'ing IETF applications area director Peter Saint-Andre, who he claims is "working on more general guidance on such issues" and suggesting the *.*.scripts solution. I mentioned that we really want the option this ticket calls "fix SSL upstream", i.e., arbitrary levels, but that *.*.scripts would be a good start.

[ezyang]

Poke.

[andersk]

See also #262 “Mangle locker names that are invalid hostnames and MySQL usernames”.