[cabfpub] Ballot for limited exemption to RFC 5280 for CTimplementation

Brian Smith brian at briansmith.org
Fri Sep 19 03:03:17 UTC 2014

On Thu, Sep 18, 2014 at 6:57 PM, Ryan Sleevi <sleevi at google.com> wrote:
> I think this discussion of AKI/SKI/issuer name is much better suited for the
> IETF list rather than here.

I agree that it should be discussed there, but...

> That is, it's not so much a question about the ballot, nor similar to the
> debate Erwann and I are having about the interaction with regards to both
> the BRs and RFC5280, but about technical details in a CT implementer needs
> to worry about, right?

Given a Precertificate-definitely-not-a-certificate X and a
Certificate Y, where the serial number of X is equal to the serial
number of Y, how does one determine whether this is an acceptable
situation or not under the ballot proposal? My suggestion was to
compare the contents of X and Y, however there is no comparison
function that is completely and unambiguously defined yet (which is
surprising, since CT itself seems like it could also use that).
Answering these encoding questions is a prerequisite for defining such
a comparison function, AFAICT.

> such (at least, not under the PreCert intermediate). As to why the PreCert
> intermediate had basicConstraints, that was unfortunately/ironically seen as
> necessary by the CAs who were involved in the discussions to make it easier
> for their systems, but it's not necessary from the logs point of view  (a
> PreCert intermediate is conceptually equivalent to a Proxy cert, which also
> doesn't require/derive authority from the basicConstraints).

The question isn't how they are intended to be used, but rather how
they could be misused or abused. It is important to understand how the
precertificate mechanism could be abused or mis-implemented (e.g. the
CA forgets to set the critical bit on the poison extension on some
precertificates, magically transforming a non-certificate into a
certificate) in order to understand how much it makes sense, if at
all, to accept the risks that the precertificate mechanism adds

> And on that note, again, the details of the bytes on wire/memory should
> probably move over to IETF, and the discussion about how it relates to
> policies - and most importantly, what an auditor examines - can be left
> here, since it's very much a CA/B Forum area of expertise and opinion.

I agree it is worth discussing in the IETF mailing list, but it also
is relevant here, for the reasons I stated in my previous paragraph.


More information about the Public mailing list