[cabfpub] Ballot 184: rfc822Names and otherNames
sleevi at google.com
Thu Jan 5 17:35:33 MST 2017
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.
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.
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.
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public