On Thu, Jan 5, 2017 at 5:43 PM, Jeremy Rowley <[email protected] <mailto:[email protected]> > wrote: If the WFA want to use the Web PKI, well, then I'd encourage them to participate in the Web PKI discussions - which, unfortunately, is largely gated on GovReform. [JR] This discussion, right now, is essentially the WFA participating in the Web PKI discussions. Then are you the person to direct all the hatred at the stupidity of the OSU design to? [JR] Yes please. I’d love the feedback and can use it to push meaningful improvements to the project. What HS 2.0 tries is to have its own PKI, while also having it be part of the Web PKI. I don't think that's a necessarily good or desirable outcome, and I think the issue (the otherName) is simply a symptom of the same issue we saw with Spain (re: subjectAltNames) and potentially the same issue as with the SHA-1 payment terminals. And since we haven't taken meaningful steps to address or prevent those, I don't think it's good or desirable to mix those two. [JR] I think this is a misunderstanding. I’m asking the Web PKI/CAB Forum to permit me to create a dual use certificates that effectively function in both PKIs. I’m not asking the CAB Forum to support the WFA or WFA PKI other than not prohibit their certificates. If there was an actual security reason for prohibiting otherNames, I could see the objection. But there’s not (other than a vague worry making changes to our document might be more difficult in the future) I agree we are misunderstanding. I'm stating explicitly I do not believe dual use is good for the Web PKI, as every other 'dual use' case has shown. What I don't feel you've really addressed is how do we prevent *this* dual-use from turning out as badly as the *other* dual-use cases. [JR] Ah – there’s the disconnect. I see how few dual-use cases have turned out poorly and am amazed its worked so well! Really, looking at how many different industries use public trust, it’s surprising that more frameworks weren’t upset. I heard more complaints over the SHA-1 move from Web PKI participants than any of the industries interoperating with Web PKI. That's fundamentally the objection: There's been zero improvement. Your response above "essentially the WFA participating" doesn't particularly instill hope (especially as the WFA bits are still kept behind onerous-enough walls to resources and discussions) [JR] To be fair, the objections haven’t originated from us on this one… The number of CAs asking for an exception in the SHA-1 case is very small. Most of us have told our customers there isn’t an exception. Further, I think the history with HS 2.0/Passpoint and the OSU interaction model highlight a lack of awareness/concern to the Web PKI issues - HS2.0 just naively assumed that browsers/UAs would blindly trust Cablelabs and Digicert, if not explicitly, then implicitly through its members' actions (from my limited interactions). That's a critical misunderstanding of the Web PKI and root store management. [JR] I don’t think they did assume public trust would be blindly implemented. Instead, I’m asking for permission to create dual certs. The WFA chose Cablelabs and DigiCert for the PKI because we asked them to include us, not because they expected browsers to add them to the root store. There’s nothing blind about the decision. Plus, I’m only asking for permission to create a publicly trusted WFA profile, not embed the WFA roots or for Google to support public OSU. They did assume public trust, and you are asking for Google to support the WFA/OSU model, but I can understand that this may not be obvious to you. By creating dual-use certs, all of the HS2.0 risks and concerns become concerns that you will represent to the Web PKI (as WFA representative, as you've suggested). Unlike other "multi-use" cases - say, S/MIME - your certificates will be, from a technical capability point - indistinguishable from TLS server certificates. This is by design of the OSU model. As such, any changes to how id-kp-serverAuth certificates work will request, for those CAs participating in WFA / HS2.0, that their particular usage be considered. For a technical metaphor, this would be akin to exposing a public interface from a library. The library maintainers are now on the hook to support that interface and everyone who depends on it. For a business metaphor, you're asking the CA/Browser Forum to sign a support contract to agree to consider HS2.0 use cases and business needs in the future. And I'm telling you those have tangible costs associated with that, even if they're not obvious, we know from historical precedent those costs ended up being quite large (c.f. SHA-1 exception process), and it's not clear that there's an actual win here - for security or for users - that justifies that costs. [JR] Again - that’s the difference. I’m looking at how well our customer-base did with the transition and am surprised at how readily and quickly they moved. I don’t really se this as a sign-off on WFA – I view it as a “Sure, you can do this WFA but you also inherit the baggage with public trust, and we can change the rules without notice and without considering your feelings. If you’re okay with that, then here is your exception.” Naturally, and explicitly, my concern is that if/as the HS2.0 OSU profile diverges - even though it necessarily requires id-kp-serverAuth in order to accomplish the goals as an OSU - then we end up with the SHA-1 problem. So the best way to avoid that, as I see it, is to vote No on the (presently) necessary condition to allow the OSU and WebPKI profiles to be shared. [JR] This is a general worry about any entity using serverAuth. The same worry can be extrapolated to vote “no” against particular customers we might find troublesome in the future, such as small businesses or cloud providers. I may even prove troublesome in the future so we should probably prevent me from using WebPKI…. Yes. It is a general worry about any entity using id-kp-serverAuth in cases not represented in the Forum by the parties responsible for maintaining those interactions (i.e. the browsers, which control both the root store *and the software that consumes the root store*). [JR] But that happens all the time. There’s nothing that limits how people use serverAuth certs provided they are compliant with the BRs. Now, it could be that if the Forum voted against this, as I would hope it would, HS2.0 would decide to modify the profile to remove the otherName, and otherwise just coopt the BRs. They might even go as far as to say the OSU PKI is identical to the Web PKI (such as by saying the OSU PKI is the intersection of trusted CAs in X). And that would equally be awful, because as the Web PKI changes, no consideration is going to be given to the OSU PKI's use - the same as we've seen with payment terminals and SHA-1. [JR] They’d go the other way. I’m okay with no consideration given to the OSU PKI’s use. They’d be okay with that stance as well. Most of them don’t care if public trust is involved. I do though. "Most of them don't care if public trust is involved" is precisely the awfulness that is HS2.0. You can't not care but expect it to work in the browser, as it's clear the vendors do. [JR] The ones who don’t care if public trust is involved don’t expect it to work in the browsers. The ones who want it to work in the browsers care about public trust. But this is largely irrelevant to the current topic. I guess I don’t understand the objection other than a vague “Google doesn’t plan on using OSU and the WFA may ask for more changes in the future”. There’s lots of groups that interact with the WebPKI (such as qualified certs, grid certs, the payment industry, etc.) that lead to complications when making changes. And I argue this is bad, and we should try to discourage, not encourage it, and this reaction is a natural consequence of that. It's a balancing act, for sure, but in general, the security is greatly improved the *fewer* consumers we have of the Web PKI (Ideally, just the Web), so that concerns about interoperability and testing can be addressed at a single layer. As the Payments example has demonstrated, it doesn't do any good to have 2 out of the 3 parties consuming the Web PKI, because even if 2 agree, the third holds everyone back. [JR] We don’t have payments to rely on, but I heard a lot more complaints about the SHA1 move from Web PKI consumers than other PKI groups. I suppose security is improved by fewer consumers (if no one is using something, then no one’s data can be affected, right?), but that’s at odds with usefulness. This is why we need a more open participation model. However, the WFA isn’t necessarily looking to limit the Web PKI (or change it for that matter) but could gain efficiencies with interoperability. I disagree. It introduces inefficiencies by adding a new layer of concerns that have to be taken into account, and the efficiencies suggested aren't actually realized. [JR] I suppose we’ll have to disagree on this, although I see where you are coming from now. The inefficiencies don’t affect Google unless Google is planning to utilize HotSpot 2.0. Because you aren’t an implementer (from the sounds of it), the concern over added users outweighs the positives (as, for Google, there are none). Since we support HS2.0, the theoretical concern of future complexities isn’t as large as the need to provide a dual-use cert for an improved customer experience. The difference is insurmountable regardless of the language used in the ballot as the cost-benefit balance greatly differs.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
