[cabfpub] Ballot 184: rfc822Names and otherNames

Sun Jan 8 09:06:01 UTC 2017

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: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
> 
> 
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> 

-- 
Scott Rea, MSc, CISSP
Ph# (801) 874-4114