<div dir="ltr"><div class="gmail_extra">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?<div>
<br></div><div>To summarize:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>"<span style="color:rgb(51,51,51);font-family:Georgia,serif;font-size:13px;line-height:20.799999237060547px">My suggestion:</span></div>
<div><span style="color:rgb(51,51,51);font-family:Georgia,serif;font-size:13px;line-height:20.799999237060547px">- Skip PreCertificates altogether</span>"</div></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">
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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div><div class="gmail_extra"><br clear="all">
<div><div dir="ltr"><table><tbody><tr><td><a href="http://www.firmaprofesional.com/" style="color:rgb(17,85,204)" target="_blank"><img alt="AC Firmaprofesional S.A." src="http://www.firmaprofesional.com/images/fp_firmas.png" border="0"></a><br>
</td><td style="color:rgb(153,153,153)"><p><font face="Arial"><b>Chema López González<br> <br>AC Firmaprofesional S.A.<br></b></font></p></td></tr><tr><td><br></td><td><br><span style="color:rgb(153,153,153);font-family:Arial;font-size:small">Av. Torre Blanca, 57.</span> <br>
<font color="#999999" style="color:rgb(153,153,153)"><span style="font-family:Arial;font-size:small">Edificio ESADECREAPOLIS - 1B13</span><br></font><blockquote style="padding:0px;border-style:none;margin:0px 0px 0px 40px">
</blockquote><font><span style="color:rgb(153,153,153);font-family:Arial;font-size:small"><div style="text-align:-webkit-auto">08173 Sant Cugat del Vallès. Barcelona.</div></span><div style="text-align:-webkit-auto"><font><font color="#999999">Tel: </font><a value="+34934774245" style="color:rgb(17,85,204)">93.477.42.45</a><font color="#999999"> /</font><font color="#3333ff"> <a>666.429.224</a></font></font></div>
</font></td></tr></tbody></table><br><div>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.</div>
</div></div>
<br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 12:50 PM, Rob Stradling <span dir="ltr"><<a href="mailto:rob.stradling@comodo.com" target="_blank">rob.stradling@comodo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">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?<br>
<br>
</div></div>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").<br>
<div class=""><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<br>
</div>certificate. And the certificate is public data, so servers could just<br>
<div class="im">download their refreshed certificate over HTTP periodically and<br>
</div><div class="im">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."<br>
<br>
</div><div class="im">--<br>
Rob Stradling<br>
Senior Research & Development Scientist<br>
COMODO - Creating Trust Online<br>
<br>
</div><div class=""><div class="h5">_______________________________________________<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><br>
</div></div></blockquote></div><br></div></div>