<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 18/09/2014 04:01,
<a class="moz-txt-link-abbreviated" href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:EF70381B2D29784EA4FC66042BE81EAF2BB7E053@SJDCEXMBX03.us.trendnet.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Bradley Hand ITC";
panose-1:3 7 4 2 5 3 2 3 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Ben – at our F2F meeting yesterday, I
presented the following draft ballot to provide a limited
exemption from RFC 5280 for the purpose of CT implementation.
The background for this proposed ballot is included below.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The Members were favorable to the idea, and
there were four endorsers for the draft ballot: Digicert,
Entrust, GoDaddy, and Symantec.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">At the right time, can you present this to
the Members as a Ballot for discussion and voting? Thanks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><i><span
style="font-size:14.0pt;font-family:"Bradley Hand
ITC";color:#0F243E">Kirk R. Hall<o:p></o:p></span></i></b></p>
<p class="MsoNormal">Operations Director, Trust Services<o:p></o:p></p>
<p class="MsoNormal">Trend Micro<o:p></o:p></p>
<p class="MsoNormal">+1.503.753.3088<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">*****<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Proposed amendments to Baseline
Requirements. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">New language is shown in <b><i><u>bold ,
italics, and underlined.</u></i></b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Amend the Definitions as follows:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Amend Appendix B as follows:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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><b><o:p></o:p></b></p>
<p class="MsoNormal"
style="margin-left:.5in;text-autospace:none"><b><o:p> </o:p></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. ***<o:p></o:p></p>
<p class="MsoNormal"
style="margin-left:.5in;text-autospace:none"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><b><u>(<i>5)
Limited Exemption from Compliance with RFC 5280<o:p></o:p></i></u></b></p>
<p class="MsoNormal" style="margin-left:.5in"><b><i><u><o:p><span
style="text-decoration:none"> </span></o:p></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><u><o:p></o:p></u></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Effective Date: Upon approval by the
Members.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">*****<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Reasons for ballot:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><u>The Problem<o:p></o:p></u></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CT envisions three methods for presenting
the necessary SCTs to browsers to show that a certificate has
been logged in CT logs, but only one method (using precerts to
gather the SCTS, then include them with the production cert
sent to the customer) is currently workable.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">RFC 6962 seems to say that CAs have two
choices for how to issue precerts and production certs after
CT logging and gathering of SCTs.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><u>Option 1</u> –
The CA can use the
<i><u>real</u></i> issuing sub-CA <i><u>both</u></i> to issue
the precert (for logging the precert and collecting SCTs) and
to issue the final production cert containing the SCTs, or<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><u>Option 2</u> -
The CA can use a <i>
<u>special</u></i> precert signing sub-CA for the precert
(for logging the precert and collecting SCTs), and then use
the
<i><u>real</u></i> issuing sub-CA to issue the final
production cert containing the SCTs. The CA must change the
name of the issuing sub-CA in the final production cert (from
the name of the special precert signing sub-CA).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I polled the members of the CA Security
Council on which option they prefer, and at this point we all
strongly prefer Option 1. For some, Option 2 is especially
difficult, as it will involve a handoff of information between
the precert sub-CA and the production cert sub-CA.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">CAs have been told that they must implement
CT by January 1, 2015, and there is little time left to
complete engineering if this deadline is to be met. Also, the
IETF group working on RFC 6962 (which is still “experimental”
with “errata”) has not yet completed specifications around
precerts.<o:p></o:p></p>
</div>
</blockquote>
<br>
Current work at IETF on precerts specifications will be for
RFC6962-bis. RFC6962 already exists and has its own (not perfect)
definition of what a precert is.<br>
<br>
<blockquote
cite="mid:EF70381B2D29784EA4FC66042BE81EAF2BB7E053@SJDCEXMBX03.us.trendnet.org"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p>However, this creates a dilemma
– both the precert and the production cert will be issued from
the same sub-CA (the entire issuing chain will be the same),
and both will have the same Serial Number – something
necessary for CT, but not permitted under RFC 5280. To remedy
this, the precert will have a so-called “poison extension” to
tell applications it is not to be used as a real SSL cert.
The use of the poison extension may or may the precerts do not
violate RFC 5280, but this is not clear.</p>
</div>
</blockquote>
<br>
It is clear that the poison extension has no impact of X.509/RFC5280
violation. The uniqueness of issuerName+serialNumber does NOT depend
on any other factor or element.<br>
<br>
<blockquote
cite="mid:EF70381B2D29784EA4FC66042BE81EAF2BB7E053@SJDCEXMBX03.us.trendnet.org"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p>
</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The current Baseline Requirements seem to
require all certificates to comply with RFC 5280. See the
Definition of Valid Certificate, and see the references to RFC
5280 in Appendix B.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Given that CAs will likely be implementing
CT Option 1 before 2015 to meet the CT deadlines, we would
like clarity in the BRs that we are not violating the
requirements to comply with RFC 5280.</p>
</div>
</blockquote>
<br>
That's wrong. The requirements to comply with RFC5280 will be
violated by CAs that choose Option 1. That's why {you, they, we}'re
asking for an exemption.<br>
<br>
<blockquote
cite="mid:EF70381B2D29784EA4FC66042BE81EAF2BB7E053@SJDCEXMBX03.us.trendnet.org"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<o:p> </o:p>
<p class="MsoNormal"><b>Proposed Solution</b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The proposed solution is to amend the BRs
to provide a limited exemption to RFC 5280 compliance for CT
implementation. See the ballot language above. <br>
</p>
</div>
</blockquote>
<br>
I fail to see where the limit is stated.<br>
<br>
For the previous exemption (non critical NC extension), the
exception to RFC5280 runs "until the Name Constraints extension is
supported by Application Software Suppliers whose software is used
by a substantial portion of Relying Parties worldwide."<br>
<br>
I'd like to see the same kind of limit expressed.<br>
Maybe something like "until a successor of RFC6962 defines a
structure that doesn't violate RFC5280 constraints"? We'll have to
deal with then-legacy software, again.<br>
</body>
</html>