<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 5:13 PM, Tim Hollebeek via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</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 class="m_-9106929136428332987WordSection1"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So, from time to time, approximately every month or two, someone comes up with a brand new idea about some piece of information they would like to require be present in every TLS digital certificate.  Unhindered, this would cause the size of TLS digital certificates to linearly increase with time.  Luckily, we have been saved from this catastrophe by the natural inertia of standards groups, which guarantees that nothing changes unless someone is highly motivated to make the change, and most of the information people want to add are “nice to haves” and not actually necessary for inclusion in validation decisions.  An example is the proposal from the last F2F about putting a problem reporting address into the certificate itself.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">This actually matters for TLS certificates in particular, because they have to be passed across the wire, so the size of certificates and the length of chains can make a big difference in latency of initial connections if they grow too much.  Since we’ve seen a lot of evidence that at least some browsers optimize for performance at almost any cost, this is something worth paying attention to.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">That said, there’s certainly a lot of additional metadata information CAs have about certificates they issue, and for much of the data there isn’t a good reason why it couldn’t be made public.  So I’ve been thinking a bit about Certificate Metadata Transparency Logs as a place to securely publish data about a certificate that doesn’t require it to actually be in the certificate.  Some of the data associated with how a certificate was validated could be published there (not all validation data can be published because some of it is confidential and/or contains PII).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Someone who’s identity I will withhold, on the grounds that I think his idea is bad, proposed simply including such information in pre-certificates logged to CT, but not the certificates themselves.  I don’t like this because I already hate the poison extension, and I think there should be fewer differences between certificates logged to CT and the real certificates, not more.  But we could put a metadata field or capability into CT if that’s what we wanted.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I had similar thoughts during the LAMPS meeting in London, where we were discussing certificates that include post-quantum public keys, which you might want to incorporate by reference instead of by value, because they are large.  Maybe we actually want a generic mechanism for pointing to additional information about a particular certificate that is available at another location.  If the specification was well written, it could support in a generic way a lot of what it currently there (for example, CRL and OCSP locations are pointers to external state information).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So when something comes up three times in the space of a few months, I think it is officially A Thing.  How do we decide what information is appropriate to put into a certificate, what information is best kept elsewhere, and do we need logging capabilities beyond what CT provides in order to publish some of that data?<span class="HOEnZb"><font color="#888888"><u></u><u></u></font></span></p><span class="HOEnZb"><font color="#888888"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">-Tim</p></font></span></div></div></blockquote><div><br></div><div>To make sure I understand: Are you proposing an explicit prohibition against including any other extension or metadata within a Certificate unless it meets a stringent CA/Browser Forum defined profile - that is, the complete and total removal of Section 7.1.2.4 of the BRs in favor of language that is the moral equivalent to "The CA may not set any other fields or extensions except as defined within these Baseline Requirements"?</div><div><br></div><div>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. </div><div>If so, I'm not sure that's at all healthy for the ecosystem or users.</div><div><br></div><div>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.</div><div><br></div><div>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?</div></div></div></div>