On Tue, May 1, 2018 at 5:45 PM, Tim Hollebeek <[email protected]> wrote:
> > > To make sure I understand: Are you proposing an explicit prohibition > against > > including any other extension or metadata within a Certificate > > Wow, no, certainly nothing so extreme. There is certainly some metadata > that > is necessary and appropriate within the certificate itself. Certainly > anything that a browser uses or wants to use for trust decisions should be > in > the certificate itself. I just think that not ALL such metadata belongs > in > certificates ... > Do you have an example? > > > If not, I'm not sure what you're proposing here - CAs that want to > include > > information will be able to, just as they are today. > > Sure, DigiCert can put kitchen sinks into certificates today, and we > totally > will, when it's appropriate. I just think there is some value in > standardizing across the industry what information is available where, > instead > of having all CAs make independent decisions. > 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. 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 :) > > > While I agree that there are all sorts of terrible ideas for things to > stuff > > into certificates (if only because those proposing may not be aware of > the > > technical constraints or the alternatives that exist), there's also > plenty > > of good ideas. > > Agreed. Which is why I'm hoping this will be a useful discussion that > will > provide some good guidance going forward on what is and is not a good idea. > I'm very skeptical that it will or can, without concrete examples to facilitate discussion, which I may have missed or misunderstood. > > Regarding your dislike of the poison extension, how does that square > with > > RFC 6962-bis? Are you saying that you don't believe 6962-bis already > > accommodates the system you're describing, or that you don't want to > wait > > for 6962-bis to be deployed to be able to take advantage of this? If the > > latter, do you have specific, concrete examples that might demonstrate > why > > it's more valuable sooner than later? > > I think RFC 6962-bis is a perfectly reasonable solution to the poison > extension problem, and am in no particular hurry to solve that problem, > since > all it does is annoy my preferences about architectural cleanliness, and > there > are plenty of other things that annoy me along those lines that can > distract > me from this particular annoyance. > > I just don't want people creating any ADDITIONAL divergences between CT > logged > certificates and real certificates. > 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: 1) There's a desire to express additional information (Question: What?) 2) This information is not valuable to express in the certificate itself (Question: Why?) 3) This information needs to be expressed before RFC 6962-bis (Question: When does it need to be expressed, and why?) 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?) 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.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
