<div dir="ltr">Can you clarify whether you've been asked as chair of the CA/Browser Forum, or as Symantec's representative?<div><br></div><div>For example, with the WorldPay issuance recently, the solution that was ultimately implemented clearly favored Symantec's interests, in that other CAs (who, perhaps, have removed roots already capable of addressing this problem) were not given an opportunity to participate and explore in this system. If you are approaching on behalf of these organizations, perhaps it would be more beneficial to specifically contribute who in the "payment processor ecosystem" is indicating a need, so that other CAs may be able to reach out and explore solutions that do not require any of your four proposed solutions - which would seem the best of all worlds.</div><div><br></div><div>With respect to blacklisting, I think it's truly unfortunate that the mechanism designed to address CA incompetence, malfeasance, or direct misissuance is now being proposed as a solution that would allow CAs to continue to offer a defective, insecure product - and to outsource the costs of the maintenance of that product onto all relying parties. That is, just as it's clear that preventing SHA-1 misissuance affects more than just the TLS Web ecosystem, due to CAs encouraging disparate use cases to use a trust anchor shared with web use cases, it's also clear that permitting SHA-1 issuance affects, and puts at risk, more than just browser users. For example, consider the vast ecosystem of server to server communication that actually does intend to talk to the 'public' web (such as the many tools using libcurl, wget, or their programming language's built in HTTPS fetching capabilities) - none of these ecosystems would be able to effectively, at scale, blacklist.</div><div><br></div><div>If we are to accept that, as the Forum, we entertain cases other than TLS issuance, it would seem natural that, as a Forum, we would also have to entertain the risks that certain practices pose to the non-browser community, and balance our risk calculus appropriately.</div><div><br></div><div>So, to that end, I think it would be useful if someone has a use case for a SHA-1 certificate - whether they're a direct customer of Symantec's or expressing concern to you, as chair of the Forum - that the concerns be shared in a public venue (such as by posting to <a href="mailto:questions@cabforum.org">questions@cabforum.org</a> and having someone repost on their behalf to <a href="mailto:public@cabforum.org">public@cabforum.org</a>)</div><div><br></div><div>When someone poses such a request, it would be useful to understand:</div><div>  a) Who the existing CA is</div><div>  b) When their current certificates expire</div><div>  c) What trust anchors their devices/clients support. If they're unable to answer this, an understanding as to why they can't answer this</div><div>  d) When they first became aware of the SHA-1 sunset.</div><div>  e) Were they notified by their CA, or did they discover it through other means</div><div>  f) When did they begin transitioning from SHA-1</div><div>  g) When do they anticipate finishing transitioning from SHA-1</div><div>  h) How many domains they would need reissued for SHA-1</div><div><br></div><div>Your approach, both with WorldPay and now with this topic again, is operating on an assumption that the only way to satisfy these users is to violate the Baseline Requirements and browsers' root program requirements. That assumption, however, doesn't have the (public) evidence behind it, nor have we gotten to an understanding of how we arrived here.</div><div><br></div><div>In posing the questions above, this helps better inform the Forum, so as to evaluate options that may be provided by other CAs' non-BR compliant roots, thus ideally avoiding the debate entirely. Further, it also helps to better understand the nature and situation surrounding how this issue came to be a critical issue that you've now brought to the Forum several times on unnamed parties' behalf, so that we can see what opportunities there are, in the future, to improve the situation for the inevitable deprecations that will come.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 12:51 PM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">I’ve been asked by the payment processor ecosystem to explore some options for assisting with the SHA-1 issue. The scope of this problem is quite large but there may be a few options for dealing with it which need vetting by this community. I’ll outline them below and <u>would appreciate some constructive feedback</u>:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">1. Issue and then immediately revoke a new SHA-1 certificate. <u></u><u></u></p><p class="MsoNormal">>>It turns out some payment terminals don’t check for revocation and this would fix a large percentage of them for one North American company.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">2. Issue a cert with a poison critical extension<u></u><u></u></p><p class="MsoNormal">>>Some terminals may work with this but we won’t know until it can be tested. This requires issuing a new SHA-1 cert with this extension. Browsers would see the extension and not allow this certificate to be used. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">3. Issue a cert from a new, name constrained intermediate<u></u><u></u></p><p class="MsoNormal">>> Same as #2 from a testing perspective. Browsers could blacklist this intermediate.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">It would be interesting to get feedback from not only the community at large but specifically browsers to know what to expect from a proposed ballot.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks,<u></u><u></u></p><p class="MsoNormal">Dean<u></u><u></u></p></div></div><br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div></div></div>