[cabfpub] Ballot for limited exemption to RFC 5280 for CT implementation

Brian Smith brian at briansmith.org
Thu Sep 18 03:55:41 UTC 2014

On Wed, Sep 17, 2014 at 7:01 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

>  1. Amend the Definitions as follows:
> Valid Certificate: A Certificate that passes the validation procedure
> specified in RFC 5280 *(except for the limited exemption provided in
> Appendix B).*

This seems like a bad and unnecessary idea to me. The trans working group
is already debating discussing the format of precertificates so that they
are not syntactically-valid certificates for the standards-track CT
mechanism. The version of CT Google and the CAs have implemented is an
experiment, not a standard or proposed standard. The CAs can work around
this issue by using the OCSP-based CT mechanism instead of the
precertificate mechanism. Finally, IIUC, the only negative consequence of
this that EV certificates

IMO, it makes more sense to change the experiment than it does to
(effectively) change the fundamental standards that all CABForum work is
based on.

Note that the use or non-use of a precertificate signing certificate has no
bearing (IIUC) on whether the precertificate would be a duplicate of the
final certificate, because the difference between Option 1 and Option 2
doesn't affect the issuer and serial number fields of the precertificate.

>   2. Amend Appendix B as follows:
> Appendix B – Certificate Extensions (Normative*); Limited Exemption from
> Compliance with RFC 5280*
> This appendix specifies the requirements for Certificate extensions for
> Certificates generated after the Effective Date. ***
> *(5) Limited Exemption from Compliance with RFC 5280*
> *In order to comply with the requirements of Certificate Transparency, CAs
> may use pre-certificates and certificates that contain the same serial
> number and are issued from the same Subordinate CA Certificate.*

I think the language here should be cleaned up, because "pre-certificate"
is not defined in the document. In particular, I suggest that you state the
exemption in terms of the presence of the critical poison extension and
that the two certificates must be bit-for-bit identical except for the
poison extension, the SCT extension, and the signature, and the length
fields of the tbsCertificate and tbsCertificate.extensions fields. This
way, you avoid creating a giant and unintended loophole in the BRs.

Also, I suggest that you time-box the exemption so that it doesn't continue
in perpetuity, past when CT is fixed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140917/853700a6/attachment-0003.html>

More information about the Public mailing list