*.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”.