[cabfpub] Ballot 184: rfc822Names and otherNames

Ryan Sleevi sleevi at google.com
Sun Jan 8 21:19:25 MST 2017

On Sun, Jan 8, 2017 at 1:06 AM, Scott Rea via Public <public at cabforum.org>

> this may be something that the
> GovReform WG is considering? (I don't know, haven't researched that).

It is, which is an argument to avoid introducing this until that completes.

> I want to correct Jeremy on one thing - the "other" communities relying
> upon WebPKI actually moved away from SHA1 BEFORE CABF mandated it.

This is an extraordinary claim for which many of your comments below
reflect, but which I might suggest requires somewhat extraordinary evidence.

In order for your arguments further to pass muster, can you provide
evidence of any industry which used the WebPKI and migrated away from SHA-1
prior to the sunset date being set in 2012 by Microsoft? Or even 2014 by
the Forum? I am hardpressed to think of a single industry that successfully
recognized those concerns.

> I don't subscribe to a cert has "two masters" as creating a problem -

Are you choosing to ignore every SHA-1 exception request message we
received, as well as every industry raised as one impacted? Or are you
disqualifying them based on some unclear criteria?

> 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.

I'm sorry, but I must again highlight my disagreement with this sentiment.
PMA 1 setting policies that preclude PMA 2's certificates affects all those
that rely on the validity between PMA 1 and PMA 2.

The Forum has seen this time and time again - with long-lived certificates,
with internal server names, with SHA-1, with domain validation, with name
types. Each one of these problems resulted from industries existing and
relying on a single certificate being valid for PMA 1 and PMA 2. When PMA 1
moved to forbid the practice, people were opposed because it would mean you
could no longer provide certificates valid for both.

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.

Except, as you no doubt are aware, the pink widgets may represent
environmental danger that introduces risk even if you don't use them.

You can choose your favourite metaphor - the tragedy of the commons, second
hand smoke, greenhouse gasses. Even if you don't participate in/abuse a
particular resource, if others' do, it can negatively affect you.

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?

These conclusions are falsely premised on flawed logic. The risk to the Web
PKI has been demonstrated time and time again by the blending of the Web
PKI with alternative PKIs. I would simply ask and challenge that if this
will be the line of argument, then evidence be provided of blended usages
that haven't been the tire fires of every other deprecation the CA/Browser
Forum has imposed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170108/4742b3d0/attachment.html>

More information about the Public mailing list