<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></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?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>