G'day Ryan, See my responses to your requests, and some further clarifications, inline below...
Regards, _Scott On 1/9/2017 8:19 AM, Ryan Sleevi wrote: > On Sun, Jan 8, 2017 at 1:06 AM, Scott Rea via Public > <[email protected] <mailto:[email protected]>> 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: https://www.eugridpma.org/documentation/hashrat/sha2-timeline 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: https://www.google.ae/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0ahUKEwjg64K33LTRAhXsCcAKHau1BKIQFgg4MAU&url=https%3A%2F%2Fservices.directtrust.org%2Fwp-content%2Fuploads%2F2014%2F10%2FDirectTrust-CP-V1.2.1-.pdf&usg=AFQjCNGUHvx1wI2kFEblbzk-19rb7VJpGQ 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 _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
