[cabfpub] Ballot 184: rfc822Names and otherNames
Jeremy Rowley
jeremy.rowley at digicert.com
Fri Jan 6 14:40:19 UTC 2017
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:gerv at mozilla.org]
Sent: Friday, January 6, 2017 3:17 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>; Jeremy
Rowley <jeremy.rowley at digicert.com>
Cc: Ryan Sleevi <sleevi at google.com>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170106/4ac44e90/attachment-0001.p7s>
More information about the Public
mailing list