[cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates
sleevi at google.com
Tue May 1 14:25:08 MST 2018
On Tue, May 1, 2018 at 5:13 PM, Tim Hollebeek via Public <
public at cabforum.org> wrote:
> 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
> 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?
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 18.104.22.168 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"?
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.
If so, I'm not sure that's at all healthy for the ecosystem or users.
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.
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public