Kai, I can give you a little history to explain our actions. Although it's clear today that there's (at least) two classes of users for SSL certificates, browsers and non-browsers (devices like POS terminals, TVs, etc.), that's not always been the case. For years, we (and I'm sure other CAs) have issued certs to both classes from the same roots and intermediates.
If we had known that in 2012, one class (browsers) would begin enforcing strict rules on certificate issuance, we probably would have created separate roots and intermediates for the other class(es) to keep them separate. But we didn't do that. Now we find ourselves in a situation where customers have embedded our roots in their non-browser devices. These devices don't auto-update like browsers, so they cannot now move to new roots; in some cases, they can't even move to new intermediates; in many cases they can't handle 2048-bit keys or SHA-2). They come to us and ask for a renewal of their cert, and it usually needs to be the same as what they had been using. We tell them we can't give them what they want, because of Baseline Requirements. Many of them ask why browser vendors have the ability to tell them what kind of cert they can or can't have. It's always a difficult conversation. So our position has been that the requests from these non-browser customers are legitimate; the situation evolved and was not planned to be this way. We work with each customer to try to find a solution that works for them and is BR-compliant. But if all else fails, we try to find a solution that works for them and does not harm the browser-user community. That's what happened in this case. As one of the founding members of the CA/Browser Forum, we take the Baseline Requirements very seriously and we certainly don't ignore them. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
