[cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates

[Tim Hollebeek]

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.

 

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.

 

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).

 

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.

 

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).

 

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?

 

-Tim

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180501/e2b5b097/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180501/e2b5b097/attachment-0002.p7s>