If the WFA want to have their own PKI - which is perfectly OK - great. They should have their own PKI, and have it not work with the Web PKI, and everything is fine.
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. 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) 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. 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…. 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. Alternatively, the HS2.0 profile might be updated to distinguish the user-facing OSU interaction from the "app" or "server-to-server" facing OSU interaction (which is the whole reason for the custom PKI to begin with), such that any browser-based interaction with the OSU is left to "the Web PKI", while any app-to-server-based OSU interaction is handled by the OSU PKI. That would at least recognize that the use cases and needs are different - if you're going to face Web Browsers, you need the Web PKI, and if you're going to do S2S communication, you can (and probably should) do your own PKI. This is, I think, fundamentally the same as the Payments discussion - if your customers (read: browsers) are going to use the endpoint, use Web PKI and follow Web PKI - and if you have devices or software which cannot/is not maintained as securely as browsers, then using your own PKI (on a different endpoint) is the safer solution, because you won't have to worry about browser changes breaking your legacy devices. [JR] This isn’t the same as the payment discussion. Payment systems are legacy systems asking for an exception that downgrades security. This is a member of both groups asking for a modification to the BRs that would permit inclusion of information that Google doesn’t actually use or care about. 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. 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
