[cabfpub] Ballot 184: rfc822Names and otherNames
jeremy.rowley at digicert.com
Mon Jan 9 16:05:57 UTC 2017
WFA and NFC are additional examples of groups requiring SHA2 prior to the
CAB Forum. Both of these groups required SHA2 independent of any CAB Forum
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Scott Rea via
Sent: Monday, January 9, 2017 3:58 AM
To: Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public Discussion List
<public at cabforum.org>
Cc: Scott Rea <scott at scottrea.com>
Subject: Re: [cabfpub] Ballot 184: rfc822Names and otherNames
See my responses to your requests, and some further clarifications, inline
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
> I want to correct Jeremy on one thing - the "other" communities
> 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
> 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
> 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
> that PMA 1 & 2 need to interact or coordinate or "couple" their
> 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
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
> 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
> like this. That does not cause any objections from me, and I am
> 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
[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
> zero or minuscule for WebPKI, little to no risk to WebPKI (assuming
> its true that its ignored today in WebPKI), this would seem a good
> 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
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
Public mailing list
Public at cabforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4964 bytes
Desc: not available
More information about the Public