[cabfpub] Ballot 184: rfc822Names and otherNames

Scott Rea scott at scottrea.com
Mon Jan 9 10:57:37 UTC 2017

G'day Ryan,

See my responses to your requests, and some further clarifications,
inline below...


On 1/9/2017 8:19 AM, Ryan Sleevi wrote:
> On Sun, Jan 8, 2017 at 1:06 AM, Scott Rea via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>     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.

[SR] Ryan, I was talking about communities - meaning PKI based trust
communities, so I am not sure how that morphed to a request about
substantiating any INDUSTRY that migrated - because those are two
different things. If instead your request for "extraordinary evidence"
is scoped to my original assertion about trust communities, then I
simply refer you back to Jeremy's original examples - these were the
ones that motivated my comments (although to be fair, I am not sure what
criteria is used to establish extraordinary-ness so how about we agree
that I just give some evidence or pointers to evidence and you can
decide if it's extraordinary or not ;-)

My assertion was based on Ballot 118 where CABF outlawed SHA1 as a MUST
NOT from 1 Jan 2016. Again my assertion was based on the CABF's decision
and not just a single vendor in MicroSoft - the CABF is not just a
single vendor, and therefore it would be disingenuous to represent that
the actions of a single vendor as being the a representation of the
whole Forum.

Oh - perhaps you were interpreting what I wrote as meaning the trust
communities transitioned away from SHA1 "before" CABF made its
announcement of intention to do so as some future date... no - that was
not what I was asserting, but I can perhaps see how you might be able to
infer that from what I wrote (with a few beers).

To clarify: I was asserting that other trust communities transitioned
away from SHA1 before the CABF mandated dates from Ballot 118 came into
play - so perhaps with that clarification, extraordinary evidence is no
longer required?? But I will point to what I was referring to anyway to
help folks see where I was coming from...

Jeremy mentioned medical PKIs and grids.
For Grids, see IGTF bulletin on SHA2 Timeline at:

For IGTF all previous SHA1 issued certs were to be expired or revoked by
1 Feb 2015, whereas CABF was only stopping issuance from 1 Jan 2016.
Stopping issuance was to be done in IGTF by 1 Apr 2014, almost 2 years
before CABF's mandated date.

For medical PKIs, I present DirectTrust as evidence - you can pull an
older version of their CP from here:

This version was approved in December 2014, and required ALL end entity
certs to be equivalent of SHA2 or higher at that point. What I was
unable to locate was an earlier version 1.2 of the CP which shows that
SHA2 was requirement long before this, back in 2013.

Both Jeremy's examples (grids and medical PKIs) enforced a SHA1 to SHA2
transition for their communities BEFORE the dates mandated by the CABF.
This is what I meant when I was saying other trust communities
transitioned before CABF mandates (and by mandates, I actually meant the
CABF dates enshrined in those mandates - not the date that the mandates
themselves were announced...)

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

[SR] I am sorry I don't understand the question or point being made here
Ryan?? If CABF got a request for an exception of some element of its
community to continue SHA1 - it came from your community (the CABF trust
community) and therefore, a community member was asking for
consideration of the community Master (the Forum) - this is one
community, one master scenario is it not?

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

[SR] Ryan, all the "industries" you are referring to are relying parties
in the WebPKI are they not? #1. CABF does not currently recognize RPs -
we agreed to save that discussion for another date. #2 the examples you
cite above are all part of the WebPKI  - so again just one PMA in play
here from my perspective.

Can you give an example of where a separate trust community came to CABF
as the WebPKI PMA and requested you make changes that affected their
community members? That would indeed be a strange request!!

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

[SR] Haha you are funny Ryan - I know you don't stay home because you
think the risk of crossing the street is too high - that Latte Shoppe
contains the promise of some positivity that outweighs the potential
negativity of braving the chaos of the street. I know you go get your
coffee/green tea/fav beverage despite the plethora of negative
potentials from the environment of the street you have to cross, or some
meteorite falling on you from the sky - which could actually happen
without you moving at all I might add. My point is not that there isn't
negatives - there always are - its that they are minuscule, and a good
Mango Kombucha is really worth it...

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

[SR] I must have missed my ginger tea this morning because for the life
of me, I cannot derive the flawed logic you are referring to - can you
please pretend that I am a nub on back of a camel and have no capacity
for sentient thought and spell out out the logic deficiency in small
words (OK so you don't have to pretend much, but still some sliver of
imagination might need to be deployed... ;-)

Actually I think what perhaps we need to get on the same page about is
what is meant by the blended PKIs that you are referring to above. From
my perspective, WebPKI is one trust community, and CABF governs that.
Its members today have representation from Browsers and CAs, and that's
it. The Browsers and the CAs have done a fantastic job in my opinion in
catering to and securing a very diverse Relying Party community for the
WebPKI. But those RPs don't currently have representation other than by
their CA and Browser surrogates/advocates.

But when I say PKI1 and PKI2 - I am talking about trust communities
governed by different PMAs. So this would be like PMA1 = WebPKI and PMA2
= IGTF (supercomputing grids). In this case, browsers don't participate
in IGTF, so the only "members" that bridge the 2 PKIs are CAs. I would
also say they are large swathes of Relying Parties that are potentially
bridged by these PKIs but since CABF doesn't recognize those at this
point, lets keep this particular example simple - we will focus just on
the CA members...

A CA can operate a trust anchor under a policy that qualifies by audit
to be included in the WebPKI community. It can also be operated under a
policy that qualifies the same trust anchor to be included in the IGTF
community. Those two policies can be different, and as long as there can
be constructed a CPS that meets both policies, then you have a single
entity that sits in both trust communities or both PKIs which are
governed by different PMAs. this is my scenario of two masters.

PMA1 manages its policies and members. PMA2 manages its policies and
members. The PMAs in this instance are the two masters - each has
autonomy within their frame of reference. If PMA2 one day decides to
require pink widgets, as long as PMA1 does not prohibit pink widgets,
then there should be a CPS that can be created to satisfy both trust
communities. I understood Jeremy to be describing just such a scenario.

In this example, there is no "blending' of the PKIs, only an
intersection of the members of the respective PKIs.

For me, blending implies coordination between the PKIs and acceptance of
each others trust anchors - this can be done technically by
subordination or cross-certification, but I don't believe that Jeremy is
asking for any such relationship. I understood him to simply be seeking
to provide some clarity under PKI1 to his pink widget desire which will
allow him to more reliably demonstrate compatibility with PKI1, which at
the same time, allows him meet the requirements of PKI2 with the same
trust anchor, because he can now create a CPS that meets the
requirements of both respective PKI policies.

If PKI2 decides that it must be mandatory yellow widgets next year, and
PKI1 has already decided that yellow widgets are an abomination, well
guess what, Jeremy will have to create a new trust anchor for the PKI2
community if he intends to continue to service them, because now his
existing anchor cannot meet the future needs of PKI2. Put simply, he can
no longer crate a singel CPS that meets both policies.

You will notice however, that PKI2's yellow widget mandate in no way
impacted Jeremy's ability to operate his existing CA with the pink
widget in the WebPKI (PKI1). The decision by PMA2 does not enforce any
change on PKI1 community - PMA1 controls that in its entirety.

Please help me understand the flaw in this logic...??


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

More information about the Public mailing list