<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 5:45 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"><span class=""><br>
> To make sure I understand: Are you proposing an explicit prohibition against <br>
> including any other extension or metadata within a Certificate<br>
<br>
</span>Wow, no, certainly nothing so extreme.  There is certainly some metadata that <br>
is necessary and appropriate within the certificate itself.  Certainly <br>
anything that a browser uses or wants to use for trust decisions should be in <br>
the certificate itself.  I just think that not ALL such metadata belongs in <br>
certificates ...<br></blockquote><div><br></div><div>Do you have an example?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> If not, I'm not sure what you're proposing here - CAs that want to include <br>
> information will be able to, just as they are today.<br>
<br>
</span>Sure, DigiCert can put kitchen sinks into certificates today, and we totally <br>
will, when it's appropriate.  I just think there is some value in <br>
standardizing across the industry what information is available where, instead <br>
of having all CAs make independent decisions.<br></blockquote><div><br></div><div>Much like I was (and am) opposed to proposals to introduce Yet Another Way to request revocation, I'm equally inclined to be skeptical-to-opposed to premature standardization. I'd much rather facilitate and encourage open discussion, but see no reason to presume a solution (such as "Metadata Transparency") in the absence of a concrete problem.</div><div><br></div><div>Further, I'm deeply skeptical of any claims for more "Transparency Log" types solutions (e.g. Revocation Transparency, DNSSEC transparency) without a succinct and firm definition of the concrete set of problems that are both in scope and out of scope. Transparency is a hugely complex system that involves thinking about ecosystem incentives and alignment. That it's taken CT 6 years to get to that point for DV, and we're still working through a host of fun and interesting challenges anticipated back then should hopefully demonstrate that CT is not blockchain pixie dust we get to sprinkle on :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> While I agree that there are all sorts of terrible ideas for things to stuff <br>
> into certificates (if only because those proposing may not be aware of the <br>
> technical constraints or the alternatives that exist), there's also plenty <br>
> of good ideas.<br>
<br>
</span>Agreed.  Which is why I'm hoping this will be a useful discussion that will <br>
provide some good guidance going forward on what is and is not a good idea.<br></blockquote><div><br></div><div>I'm very skeptical that it will or can, without concrete examples to facilitate discussion, which I may have missed or misunderstood.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Regarding your dislike of the poison extension, how does that square with <br>
> RFC 6962-bis? Are you saying that you don't believe 6962-bis already <br>
> accommodates the system you're describing, or that you don't want to wait <br>
> for 6962-bis to be deployed to be able to take advantage of this? If the <br>
> latter, do you have specific, concrete examples that might demonstrate why <br>
> it's more valuable sooner than later?<br>
<br>
</span>I think RFC 6962-bis is a perfectly reasonable solution to the poison <br>
extension problem, and am in no particular hurry to solve that problem, since <br>
all it does is annoy my preferences about architectural cleanliness, and there <br>
are plenty of other things that annoy me along those lines that can distract <br>
me from this particular annoyance.<br>
<br>
I just don't want people creating any ADDITIONAL divergences between CT logged <br>
certificates and real certificates.<br></blockquote><div><br></div><div>I'm not fully sure I understand your position, then. Based on my understanding, one option is that this problem is a nothingburger if there's no compelling use case before a world of 6962-bis (which itself has an indeterminate future). Alternatively, if we believe this is a problem for today-or-the-soon to be, then it seems the position is:<br></div><div><br></div><div>1) There's a desire to express additional information (Question: What?)</div><div>2) This information is not valuable to express in the certificate itself (Question: Why?)</div><div>3) This information needs to be expressed before RFC 6962-bis (Question: When does it need to be expressed, and why?)</div><div>4) This information is concrete enough to be expressible via defined semantics that can be agreed upon (Question: How and where would such semantics exist?)</div><div><br></div><div>I'm not sure I agree with any or all of those, so I must be misunderstanding the problem you're trying to solve. Concrete, real-world (that is, those that can be tied to specific customers and problem spaces) examples would be tremendously useful in this regard.</div></div></div></div>