<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 6:33 PM, Tim Hollebeek <span dir="ltr"><<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wouldn't be so quick to throw cold water on additional transparency <br>
mechanisms.  Some are probably bad ideas, but there are almost certainly good <br>
ideas in there, too.  Blockchain pixie dust does make some things better, <br>
though it isn't a silver bullet.<br></blockquote><div><br></div><div>Transparency is a good idea, but profoundly difficult to build as an ecosystem. I'm merely encouraging far more caution in thinking that "* Transparency" is just flipping a few bits and magically an ecosystem capable of achieving the desired properties and goals pops out :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I'm not fully sure I understand your position, then. Based on my <br>
> understanding, one option is that this problem is a nothingburger if there's <br>
> no compelling use case before a world of 6962-bis (which itself has an <br>
> indeterminate future). Alternatively, if we believe this is a problem for <br>
> today-or-the-soon to be, then it seems the position is:<br>
><br>
> 1) There's a desire to express additional information (Question: What?)<br>
<br>
</span>Let's go with Apple's problem reporting address suggestion for now.  I'm not <br>
kidding about a new one getting suggested every two to three months. <br>
Sometimes more.<br></blockquote><div><br></div><div>So this is a bit of an inconsistent reply. You insist there are many, but then only elaborate on one. This makes it unreasonably difficult to actually evaluate the claim or the goals. The "problem reporting" method can be expressed in the intermediate, and all the problems are suddenly 'solved'.</div><div><br></div><div>If that's the example, great, we've solved something in 5 minutes that could have spent 5 years of unnecessary overarchitecture. Otherwise, we need a more concrete list.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 2) This information is not valuable to express in the certificate itself <br>
> (Question: Why?)<br>
<br>
</span>The information is primarily used by an arbitrarily small subset of <br>
certificate consumers, and is not part of or necessary for TLS handshakes. <br>
Some customers like tiny certificates.  I think we produce some of the <br>
tiniest.<br></blockquote><div><br></div><div>Great. So don't use it, and host it on your website.</div><div><br></div><div>I've snipped the remainder of the replies, because the point was to demonstrate the basic problem space to be evaluated for any example, but that wasn't actually done for the one specific example given.</div><div><br></div><div>I don't think this is valuable. If anything, I think it's detrimental, in that the proposal is a premature attempt to standardize something that's not well-understood nor demonstrated to be an actual problem. Considering how much work is left to tighten up the validation methods still, is the view that such improvements are not a priority, or less of a priority than this?</div></div></div></div>