<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
CT is required for EV in January, and most CAs are trying to get
ready before the deadline. Waiting for the Trans group isn't really
an option anymore, especially if there is delay between any document
adopted by Trans and the implementation date by Google. I also don't
think we need to time-box on the language since (a) we don't have a
timeline from Trans on when a standard will be adopted and (b) we
don't have a timeline from Google on when any ideas from Trans will
be adopted. <br>
<br>
That said, we might want to clarify that the language about what
constitutes a "pre-certificate". Your definition seems reasonable.<br>
<br>
Jeremy<br>
<br>
<br>
<div class="moz-cite-prefix">On 9/17/2014 9:55 PM, Brian Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAFewVt4pesX907VP8RdGCBM5c43iKtgZi3cf8TgSABndo4ZQEQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Sep 17, 2014 at 7:01 PM, <a
moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"> <br>
</p>
<p class="MsoNormal">1. Amend the Definitions as
follows:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-left:.5in">Valid
Certificate:<b> </b>A Certificate that passes the
validation procedure specified in RFC 5280
<b><i><u>(except for the limited exemption provided
in Appendix B).</u></i></b></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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 </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<p class="MsoNormal"> 2. Amend Appendix B as follows:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"
style="margin-left:.5in;text-autospace:none">Appendix
B – Certificate Extensions (Normative<i>)<u>;<b>
Limited Exemption from Compliance with RFC 5280</b></u></i></p>
<p class="MsoNormal"
style="margin-left:.5in;text-autospace:none"><b> </b></p>
<p class="MsoNormal"
style="margin-left:.5in;text-autospace:none">This
appendix specifies the requirements for Certificate
extensions for Certificates generated after the
Effective Date. ***</p>
<p class="MsoNormal"
style="margin-left:.5in;text-autospace:none"> </p>
<p class="MsoNormal" style="margin-left:.5in"><b><u>(<i>5)
Limited Exemption from Compliance with RFC 5280</i></u></b></p>
<p class="MsoNormal" style="margin-left:.5in"><b><i><u><span
style="text-decoration:none"> </span></u></i></b></p>
<p class="MsoNormal" style="margin-left:.5in"><b><i><u>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.</u></i></b></p>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Also, I suggest that you time-box the exemption so that
it doesn't continue in perpetuity, past when CT is fixed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Brian</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>