G'day folks, I have a couple of perspectives to share on this discussion if I may...
One challenge I see from this discussion is that we have a trust community consisting of service providers only - whether that service provider is the Browser or interface through which customers interact, or the service provider is the CA or Trust Introducer/Facilitator that a customer relies upon - and neither of those two groups can cleanly represent the Relying Parties' interests who are conducting business/transactions online - although this community has done a pretty amazing job of getting that mostly right for a long time. Other trust communities that I have (and continue to) participate in, have mostly moved to a model of inclusion of Relying Parties in trust determinations and standards building - this may be something that the GovReform WG is considering? (I don't know, haven't researched that). I want to correct Jeremy on one thing - the "other" communities relying upon WebPKI actually moved away from SHA1 BEFORE CABF mandated it. Those communities are very much driven by RP participation, and they got it, and demanded the framework address the vulnerability, and the communities adjusted accordingly. To be sure, the fact that CABF was having the SHA1 discussion was a motivator for them, and informed their decisions and timelines, but they actually mobilized and updated their communities BEFORE the CABF mandates came into play. Maybe what would be good in this discussion, is to have some input from RPs rather than just service providers whose objectives are always tainted now matter how purely motivated? I don't subscribe to a cert has "two masters" as creating a problem - and there does not appear to be any request for "coupling" of the WFA and WebPKI policies in any way. PKIs are hierarchical in nature, if a cert meets all the requirements of Policy 1 and behaves accordingly, its trusted in PKI 1. If the same cert meets all the requirements of Policy 2, its trusted in PKI 2 also. I am a Husband and a Father - if I provide for my kids and teach them properly and treat them kindly (Father Policy), they will continue to rely upon me as their father. If I provide for my wife in the manner for which she has become accustomed, and bring her chocolates and flowers on a regular basis (Husband Policy), she will continue to rely upon me for comic relief... Two policies, same entity is valid under each. Now I could get revoked (divorced) under one policy, but still continue to operate effectively under the other. PMA 1 determines whether cert remains valid under Policy 1, and PMA 2 determines whether cert remains valid under Policy 2. This does not mean that PMA 1 & 2 need to interact or coordinate or "couple" their policies in any way whatsoever. And from what Jeremy has said, WFA is not asking for any coordination between the communities - that would be an entirely different discussion. If actual cert usage breaks Policy 2, PMA 2 will request CA to revoke cert and it will no longer be valid for either community. I fail to see any issue for WebPKI with this approach. If I understand what Jeremy is asking for correctly, he is saying, can I put a pink widget in my WebPKI cert please, and here is how it will be encoded, and here is how it will be validated before I encode it. And most folks appear to agree that pink widgets are entirely ignored currently by the WebPKI community operations today - so that seems pretty straight forward to me... The pink widgets are not mandatory, everyone is free to continue to ignore them, however, if you decide you like pink widgets at some point in the future, then Jeremy is asking if the BRs could have a clause to state they are Not Prohibited, and if you include them, you should do so like this. That does not cause any objections from me, and I am failing to see the reasons behind other's objections to the proposal. >From my perspective, this is not about blending 2 PKIs - its about looking at a real life use case where there are actually 3 PKIs in play (WebPKI, WFA, Self-Attestation and I use PKI loosely for this last one because it's not, but it is at least a 3rd trust realm that comes into play for the use case), and it is strengthening controls by getting rid of the problem step-child of Self-Attestation - which I see as an improvement of overall trust for the RP. The cost of doing this is to allow pink widgets that no one in WebPKI currently cares about anyway... So... Improve Trust by getting rid of Self-Attestation, cost to do so is zero or minuscule for WebPKI, little to no risk to WebPKI (assuming that its true that its ignored today in WebPKI), this would seem a good thing to do then, would it not? If you don't care about pink widgets, why would you suddenly care if someone else cares about pink widgets? Or am I missing something? Regards, -Scott On 1/6/2017 6:40 PM, Jeremy Rowley via Public wrote: > Because the two (Web PKI and OSU) are already not separate. Some > implementations of OSU already use the same cert for both the user > interaction > and server-to-server interaction. Some implementations already use the > browser > to validate the certificate, which results in an interstitial during sign-up. > The implementors may not care that this is a self-signed certificate, but I > care strongly about the customers' experience. As the only significant > difference between the two frameworks is the otherName and inclusion of the > otherName is ignored by the browsers anyway, the best fix I could come up > with > is to permit publicly-trusted OSU certs. > > "Although unlike Ryan, I am not fully informed about the exact technical > details here, like Ryan I am concerned about the idea of permitting > certificates which will have "two masters", because the fewer couplings the > Web PKI has with other sets of requirements, the less likely it is we'll have > problems down the road when we want to move and they object that we've broken > something important." > > - This already exists throughout the Web PKI. There's plenty of frameworks > that use public trust and layer their own requirements on top of it (e.g. > the > grid system and medical PKIs). These frameworks moved to SHA1 when the CAB > Forum moved to SHA1. > > > -----Original Message----- > From: Gervase Markham [mailto:[email protected]] > Sent: Friday, January 6, 2017 3:17 AM > To: CA/Browser Forum Public Discussion List <[email protected]>; Jeremy > Rowley <[email protected]> > Cc: Ryan Sleevi <[email protected]> > Subject: Re: [cabfpub] Ballot 184: rfc822Names and otherNames > > On 06/01/17 00:35, Ryan Sleevi via Public wrote: >> 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. > > Jeremy: this seems like the obvious solution; why is this problematic? > > Although unlike Ryan, I am not fully informed about the exact technical > details here, like Ryan I am concerned about the idea of permitting > certificates which will have "two masters", because the fewer couplings the > Web PKI has with other sets of requirements, the less likely it is we'll have > problems down the road when we want to move and they object that we've broken > something important. > > Gerv > > > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > -- Scott Rea, MSc, CISSP Ph# (801) 874-4114 _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
