[cabfpub] Ballot 184: rfc822Names and otherNames

Jeremy Rowley jeremy.rowley at digicert.com
Fri Jan 6 07:40:19 MST 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://cabforum.org/pipermail/public/attachments/20170106/4ac44e90/attachment.bin>


More information about the Public mailing list