<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Georgia;
panose-1:2 4 5 2 5 4 5 2 3 3;}
@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:12.0pt;
font-family:"Times New Roman","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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Chema, thanks for posting the link to the EJBCA blog on pre-certificates. I’ve pasted in the text below. We should discuss these questions in Mountain View.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">By the way, the blog below says that
</span><span style="font-family:"Calibri","sans-serif"">Certificate Transparency is supported in <a href="http://www.primekey.se/Products/EJBCA+PKI/"><span style="color:windowtext;text-decoration:none">EJBCA Enterprise</span></a> as of EJBCA version 6.0.4.
However, in looking at the EJBCA website, that version has not yet been released, so any CA using EJBCA will not have updated software to use.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Operations Director, Trust Services<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Trend Micro<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">*************<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><a name="5399709216300742284"></a><span style="font-size:16.0pt;font-family:"Calibri","sans-serif";color:#CC6600">Certificate Transparency and PreCertificates, how will that work?<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="font-family:"Calibri","sans-serif"">The Certificate Transparency initiative (<a href="http://tools.ietf.org/html/rfc6962"><span style="color:windowtext;text-decoration:none">RFC6962</span></a>) is an
admirable suggestion to improve security of TLS web session for certificates issued by public CAs. It has cool technology with Merkle trees, is admirable short and could have been straight forward was it not for something called PreCertificates. PreCertificates
are hard for me to understand, I don't like them. I hope it is because I don't understand them...if so please let me know.<br>
<br>
Writing this post is a way to sort things out for myself and I'd be happy to edit this post if explained why I "just don't get it". Of course I am posting this to the CT forum as well...<br>
<br>
In the sake of transparency, I'm writing with the view point of an implementer of <a href="http://ejbca.org/"><span style="color:windowtext;text-decoration:none">open source CA software</span></a> (if you didn't figure that one out from the blog name:-)).<br>
<br>
<b>Update 1</b>: I got lots of comments already over at the <a href="https://groups.google.com/forum/?fromgroups#!topic/certificate-transparency/1tWzSXKe3gQ"><span style="color:windowtext;text-decoration:none">Certificate Transparency Forum</span></a>, really
good.<br>
<br>
<b>Update 2</b>: I created an issue in the Certificate Transparency issue tracker. <a href="https://code.google.com/p/certificate-transparency/issues/detail?id=18"><span style="color:windowtext;text-decoration:none">https://code.google.com/p/certificate-transparency/issues/detail?id=18</span></a><br>
<br>
<b>Update 3</b>: Of course my views on CT changes as the discussion continues, the post below was my original starting point. Follow the discussion in Update 1 for updates.<br>
<br>
<b>Update 4</b>: EJBCA supports Certificate Transparency in <a href="http://www.primekey.se/Products/EJBCA+PKI/"><span style="color:windowtext;text-decoration:none">EJBCA Enterprise</span></a> as of EJBCA version 6.0.4.<br>
<br>
On to PreCertificates...<br>
<br>
PreCertificates are defined in section "<a href="http://tools.ietf.org/html/rfc6962#section-3.1"><span style="color:windowtext;text-decoration:none">3.1. Log Entries</span></a>" as (text trimed by me) "The Precertificate is constructed from the certificate
to be issued by adding a special critical poison extension to the end-entity TBSCertificate". Then it describes how it can be produced and it is mentioned throughout the spec in many places.<br>
A PreCertificate is a essentially a certificate signed with one of two options:<br>
<br>
1. PreCertificates signed by the real CA.<br>
This sounds very dangerous as will break the fundamental X.509 rule of unique issuerDN/serialNumber pairs. The consequences of having two "certificates" with the same issuerDN/serialNumber in the wild can not possibly be estimated, making this practice quite
dangerous imho.<br>
<br>
2. PreCertificates signed by a separate PreCertificate signing CA, which is a SubCA to the real signing CA. This is a less scary, since it is normal practice that different CAs can issue certificate with the same subjectDN/serialNumber, just not the same issuerDN.<br>
<br>
The actual implementation of issuing PreCertificates makes it quite impractical. I would believe that most CA implementations creates the <a href="http://tools.ietf.org/html/rfc5280#section-4.1.1.1"><span style="color:windowtext;text-decoration:none">TBSCertificate</span></a> as
part of the actual certificate issuance. The CA will not create the TBSCertificate to have is lying around for a couple of days before using it to issue the real certificate.<br>
Thus, if the CA is to create a PreCertificate to send to the CT log, it might as well issue the real certificate and send it to the log. The time difference should be in the milliseconds for most CAs.<br>
If the CA wants to wait before distributing the real certificate, to make sure it's in the logs before put into production, it can surely do so as well.<br>
<br>
The PreCertificate imho suffers from several complicating factors for implementers, both on the CA and the CT log side. The TBSCertificate must have a poison extension inserted, and removed, effectively re-encoding the ASN.1 TBSCertificate several times, all
these are points of failure.<br>
<br>
The reason for PreCertificates are not clearly explained. Why would you want to use PreCertificates?<br>
<br>
Fine combing through the spec gives me some ideas on why, for example to be able to embed the Certificate extension from PreCertificate CT logs in the final certificate (<a href="http://tools.ietf.org/html/rfc6962#section-3.3"><span style="color:windowtext;text-decoration:none">section
3.3</span></a>). But the the TBSCertificate of the PreCertificate is then no longer the real TBSCertificate? In that case, why is the PreCertificate the TBSCertificate at all, and not just a new data structure with the data the CT log wants?<br>
<br>
The PreCertificate complicates the CT spec by orders of magnitude, which is not a good thing. There are so many ifs and buts about PreCertificate the RFC is not even itself consitent about what it is.<br>
<br>
Ok, I know the PreCertificate is is optional, but the best standards, who gets fast, wide and robust deployment, are the simpler ones (KISS). Skipping PreCertificates from the CT spec makes it so much simpler.<br>
<br>
My suggestion:<br>
- Skip PreCertificates altogether<br>
<br>
I see though why people will not accept that just because I say something...so in that case<br>
<br>
- Explain the purpose behind PreCertificates well<br>
- Describe what the actual information fro PreCertificate are used<br>
- Be consistent throughout in the RFC<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Chema López González<br>
<b>Sent:</b> Monday, February 10, 2014 8:29 AM<br>
<b>To:</b> Rob Stradling; certificate-transparency@googlegroups.com<br>
<b>Cc:</b> therightkey@ietf.org; CABFPub<br>
<b>Subject:</b> Re: [cabfpub] Updated Certificate Transparency + Extended Validation plan<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Have anyone take into account the <a href="http://blog.ejbca.org/2013/09/certificate-transparency-and.html">current position of EJBCA</a>, a mayor player in this stuff of digital certificates?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To summarize:<o:p></o:p></p>
</div>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<p class="MsoNormal">"<span style="font-size:10.0pt;font-family:"Georgia","serif";color:#333333">My suggestion:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Georgia","serif";color:#333333">- Skip PreCertificates altogether</span>"<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On the other hand, trying to use a thing that looks like a certificate (X.509v3) not to do the task of a certificate is like trying to use a screwdriver to nail nails.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We agree that the information contained in the precertificate is relevant, and that the signature of such information is also necessary, but maybe the container could be a different format or ASN.1 structure different from a X.509v3 cert.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<p class="MsoNormal"><a href="http://www.firmaprofesional.com/" target="_blank"><span style="color:#1155CC;text-decoration:none"><img border="0" id="_x0000_i1025" src="http://www.firmaprofesional.com/images/fp_firmas.png" alt="AC Firmaprofesional S.A."></span></a><o:p></o:p></p>
</td>
<td style="padding:.75pt .75pt .75pt .75pt">
<p><b><span style="font-family:"Arial","sans-serif";color:#999999">Chema López González<br>
<br>
AC Firmaprofesional S.A.</span></b><span style="color:#999999"><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt"></td>
<td style="padding:.75pt .75pt .75pt .75pt">
<p class="MsoNormal"><br>
<span style="font-family:"Arial","sans-serif";color:#999999">Av. Torre Blanca, 57.</span> <br>
<span style="font-family:"Arial","sans-serif";color:#999999">Edificio ESADECREAPOLIS - 1B13</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:#999999">08173 Sant Cugat del Vallès. Barcelona.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#999999">Tel: </span>93.477.42.45<span style="color:#999999"> /</span><span style="color:#3333FF"> 666.429.224</span><o:p></o:p></p>
</div>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, le hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si ha recibido este mensaje por error,
le agradeceríamos que lo haga saber inmediatamente al remitente y que proceda a destruir el mensaje.<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, Feb 10, 2014 at 12:50 PM, Rob Stradling <<a href="mailto:rob.stradling@comodo.com" target="_blank">rob.stradling@comodo.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">On 10/02/14 11:35, Ben Laurie wrote:<br>
> On 10 February 2014 10:13, Rob Stradling <<a href="mailto:rob.stradling@comodo.com">rob.stradling@comodo.com</a>> wrote:<br>
>> On 08/02/14 13:32, Ben Laurie wrote:<br>
>>><br>
>>> On 5 February 2014 18:21, Rob Stradling <<a href="mailto:rob.stradling@comodo.com">rob.stradling@comodo.com</a>> wrote:<br>
>>>><br>
>>>> On 05/02/14 17:49, Adam Langley wrote:<br>
>>>>><br>
>>>>><br>
>>>>> On Wed, Feb 5, 2014 at 12:26 PM, Rob Stradling<br>
>>>>> <<a href="mailto:rob.stradling@comodo.com">rob.stradling@comodo.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> Presumably it's somewhere between 10 and 31 days, since 1 SCT is<br>
>>>>>> acceptable<br>
>>>>>> for Stapled OCSP and the BRs permit OCSP Responses to be valid for up<br>
>>>>>> to<br>
>>>>>> 10<br>
>>>>>> days.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> The speed at which we need to distrust a log depends on the minimum<br>
>>>>> number of SCTs actually, which is why allowing a single SCT in stapled<br>
>>>>> OCSP responses is such a large concession. If the minimum number of<br>
>>>>> SCTs were two then the pressure to distrust a log (and the pressure on<br>
>>>>> the logs) would be dramatically reduced because compromising one log<br>
>>>>> wouldn't be sufficient.<br>
>>>>><br>
>>>>>> Do you still think [1] is a good plan?<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Sure, if any CAs are willing to do it now :)<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I think "servers could just download their refreshed certificate over<br>
>>>> HTTP<br>
>>>> periodically and automatically" is the showstopper at the moment. Yes<br>
>>>> they<br>
>>>> could, but I'm not aware of any server that actually implements such a<br>
>>>> feature.<br>
>>><br>
>>><br>
>>> Work is under way for Apache: <a href="https://github.com/trawick/ct-httpd/" target="_blank">
https://github.com/trawick/ct-httpd/</a>.<br>
>><br>
>><br>
>> That looks like great work, but AFAICT it's only for fetching SCTs from CT<br>
>> Logs.<br>
>><br>
>> I was talking about the lack of any mechanism in popular webserver software<br>
>> for automatically fetching and installing certificates from CAs. In<br>
>> particular: a short-duration certificate that reuses the same public key as<br>
>> the previous certificate.<br>
><br>
> Ah, I see! But why would you need it if you can refresh the SCTs yourself?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">To fix certificate revocation checking, by avoiding the need for it (as<br>
Adam proposed a couple of years ago - see [1]).<br>
<br>
But really, I was just trying to point out that just because CAs aren't<br>
noticeably issuing short-duration certs today, it doesn't mean that they<br>
won't do so in the future. So I think it is worth permitting just 1<br>
embedded SCT for short-duration certs (for some value of "short").<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
[1] <a href="https://www.imperialviolet.org/2011/03/18/revocation.html" target="_blank">
https://www.imperialviolet.org/2011/03/18/revocation.html</a><br>
"A much better solution would be for certificates to only be valid for a<br>
few days and to forget about revocation altogether. This doesn't mean<br>
that the private key needs to change every few days, just the<o:p></o:p></p>
</div>
<p class="MsoNormal">certificate. And the certificate is public data, so servers could just<o:p></o:p></p>
<div>
<p class="MsoNormal">download their refreshed certificate over HTTP periodically and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">automatically (like OCSP stapling). Clients wouldn't have to perform<br>
revocation checks (which are very complex and slow), CAs wouldn't have<br>
to pay for massive, DDoS proof serving capacity and revocation would<br>
actually work. If the CA went down for six hours, nobody cares. Only if<br>
the CA is down for days is there a problem. If you want to “revoke” a<br>
certificate, just stop renewing it."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">--<br>
Rob Stradling<br>
Senior Research & Development Scientist<br>
COMODO - Creating Trust Online<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>
<table><tr><td bgcolor=#ffffff><font color=#000000><pre><table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table></pre></font></td></tr></table>