<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 30, 2016 at 11:38 AM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Ryan,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Rich summed it up pretty well without getting into the gory details – making certificates is a bit like making sausages, the details are better left out. </span></p></div></div></blockquote><div><br></div><div>I appreciate the analogy, but I don't think it's a good position to take. Ultimately, the CA/Browser Forum exists to balance the costs - the costs to the ecosystem as a whole, the costs to users, the costs to browsers, and the costs to CAs. There are things we can do to improve the ecosystem, but at a cost to one or more parties - and we're always trying to strike a balance.</div><div><br></div><div>For example, the SHA-1 is a great example where there's high costs to a few particular users (those who didn't adequately plan for transition, either directly or through their vendors), and for which solutions exist to trade those costs on to browsers/relying parties (e.g. blacklisting) or to the ecosystem as a whole (e.g. allowing it, putting the entire ecosystem at risk).</div><div><br></div><div>So it's always helpful, and useful, to understand what the actual, concrete costs or challenges are to a CA, to better inform the discussion and balance the tradeoffs - that's why it helps to know how the sausage is made. It also helps the public, who, for better or worse, I suspect have an image of CAs' sausage making factories as a bit akin to those meatpacking facilities in Sinclair's "The Jungle" ... to stretch the metaphor even more.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">From my perspective there is little  benefit – some customers like longer validity period certificates so they don’t need to change them as often (not everyone
 is fully automated), and we don’t mind selling them when asked. It’s a lot of work with sales, marketing, legal, compliance, vetting and development teams to make changes like this and  I don’t see the much of a gain in security from going from a max of 39
 months to 27 months. </span></p></div></div></blockquote><div><br></div><div>That's useful to understand, because then we can have a productive dialog about the concrete security benefits. That said, given that Jeremy already included some of them in the initial message, it's a bit of a challenge trying to see if you don't understand the benefits outlined, or if you don't agree - the former suggests there's productive room for discussion, but the latter is harder to solve and may not be useful.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Perhaps I’m not understanding the implications behind your statement “…reducing validity times and revalidation times is a big win for security and the ability
 to change”.  I think we’re actually contemplating increasing EV validation times. </span></p></div></div></blockquote><div><br></div><div>While that was included by Jeremy's post, as discussed in the past, multiple browsers were opposed to 2 (a and b). So unless new information is shared, I don't think that's realistically a topic for discussion, but moreso included for completeness.</div><div><br></div><div>As we know browsers can and do go off and update their root program requirements when they feel it is in the interest of their users' and security, it seems useful to use the Forum as the (public) venue to help explain and understand the opposition to the variants of 1, and understand whether the challenges faced are unique to a particular CA (and thus less likely to be considered blocking, if the overall benefit is greater), or whether they're shared by the industry (and thus require more discussion and creative solution taking)</div><div><br></div><div>That's why it's important to understand why reducing the validity time to 27 months, across the board, is problematic, from a CAs perspective.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> Regardless, if there are things we need to change, let’s start moving out on making the changes sooner rather than later and leave the current validity period options unchanged.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Start making SCTs mandatory in DV (or in all certs with validity period of over 27 months)</span></p></div></div></blockquote><div><br></div><div>While I appreciate this enthusiasm, I haven't seen any suggestions from CAs on how to actually address the problems previously identified. While I am and continue to be an ardent supporter of CT, when phrased like this, it's a bit like saying "Start making everything fair" - which is a very loaded statement, and requires unpacking what does "fair" mean and what is "everything".</div><div><br></div><div>To that end, since you've brought it up before, I would encourage you to think about how to quantify the "mandatory" from an audit perspective, and how to determine what logs SCTs must come from. Please note, the log list does change over time, and logs can and will be removed - in fact, we'll be announcing something on ct-policy@ shortly to that effect.</div><div><br></div><div>If this is a topic you're passionate about, and I suspect you are, it may be useful revisiting the past threads on this topic, and seeing if you can put a ballot that addresses the concerns. However, it may be worth considering that, at Google, we have yet to find what we believe is an acceptable, consistent, and fair policy for mandating this, given the state of the ecosystem - which is why we're working hard to improve and diversify it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Allow short lived certs to omit OCSP/CDP because nobody checks them anyway</span></p></div></div></blockquote><div><br></div><div>Are you suggesting we revisit Ballot 153? I don't believe there's been any new contributions to suggest the result would be any different.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">- Encourage the move to ECC-384 or RSA-4096, or whatever security changes you see coming</span></p></div></div></blockquote><div><br></div><div>You're not the only CA that has brought this up, and I admittedly gave responses in person rather than on the list. I think this line of thinking is dangerous and short-sighted, though I appreciate that it's trying to be forward thinking. When you consider the SHA-1 problem, and why it's been a persistent thorn, it becomes clear that the reason for it is the inability to express simultaneously the 'old' and the 'new' thing. That is, a certificate has either SHA-1 or SHA-2, but not both. Past efforts (from other CAs) to improve this has failed. Perhaps this is something GlobalSign can invest its engineering resources on, to attempt to solve.</div><div><br></div><div>Similarly, parts of the SHA-1 problem relate to CAs' communications to their customers. While I realize you can't change what another CA says to their customers, perhaps this is something GlobalSign can investigate and explore and propose solutions for.</div><div><br></div><div>Another part of the SHA-1 problem relates to legacy systems, and their support for limited cryptographic options. There are no doubt opportunities to improve the ecosystem there, and no doubt GlobalSign can make valuable contributions to this space.</div><div><br></div><div>Finally, we also need to consider the "enterprise root" problem - mixing public trust anchors and private use cases, unfortunately with different change/release cycles.</div><div><br></div><div>The reason I highlight all of these is that any transition to security changes - such as ECC-384 or RSA-4096, will inevitably suffer from the same problems, much as we saw with the transition from MD5, the transition from SHA-1, and the transition from RSA-1024. While browsers continue to try to adapt new strategies to improve this transition, there remains a whole unexplored field for CAs to contribute to. I want to encourage and exhort you to revisit the systemic challenges the industry has faced, and to see what contributions you can make, either as an individual CA, or to the Forum at large.</div><div><br></div><div>Ultimately, if these are topics you're passionate about, I hope you'll explore proposing solutions for them. However, just because these are also challenges we as an industry need to solve, it shouldn't prevent or discourage us from solving the problems faced with long lived certificates. So while much of this email might seem 'off-topic' to the thread at hand, my hope is that it meaningfully addresses your (unrelated) concerns, so that you can see why there is value in exploring this issue.</div></div></div></div>