- From: Robin Berjon <robin@w3.org>
- Date: Tue, 15 Oct 2013 21:14:16 +0200
- To: Brad Hill <hillbrad@gmail.com>
- CC: Odin Hørthe Omdal <odinho@opera.com>, public-test-infra <public-test-infra@w3.org>
Hi Brad, thanks a lot for those details. On 15/10/2013 19:08 , Brad Hill wrote: > No default-trusted CA is going to be OK with issuing a certificate and > then having you pass the private key around, even for a non-public name. > They will consider that a key compromise and revoke it. (they are > actually mandated to by the agreements they have with browsers) Are there reasons *other* than their agreements with the browsers why they would have to revoke it? I ask because, well, we have browser vendors around here. It's a bit more overhead that I was hoping for in addressing this problem, but if that's the only issue, we could possibly negotiate an exemption. > 1) built and distributed a VM image with browsers that have a custom CA > provisioned and certs issued off that CA installed on the server, to be > used for offline testing I don't think that works for us, we need people to test with arbitrary browsers (or I'm missing something). > 2) stood up an AWS image with a real domain name and certificate on it > (https://webappsec-test.info) and I give non-root shells to people who > ask, to do online testing We are definitely also publishing the test suite online, and using a real cert there in the usual way. Our concern is about > GlobalSign will issue a wildcard certificate for free to open source > projects, which is what I did for #2 to save a few hundred $$, but they > for sure won't be OK with sharing the private key around. Thanks, I'll check that out. That said this project, while open source, is also heavily supported by W3C so we might not qualify :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 15 October 2013 19:14:34 UTC