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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
