[cabfpub] Pre-Ballot - Short-Life Certificates
richard.smith at comodo.com
Fri Oct 24 06:42:33 MST 2014
You're argument hinges upon either the browser having already cached a
Good OCSP response, OR an active attacker serving up a stapled Good OCSP
response, and in those cases, yes, short lived w/out revocation info is
equal to longer lived cert with revocation info. BUT in a case where
neither of those (cached response or active attacker) is true, at least
as far as Comodo systems are concerned, we will serve a Revoked OCSP
response as soon as we revoke a certificate. If there is no cached
response already stored by the browser and there is not an active
attacker who has already obtained and is serving a Good OCSP response,
anyone encountering that cert WILL see that it is revoked, so it is NOT
equal in such a case. In a case of simple fraudulent activity by a site
owner, it is very likely that for many users there will be neither a
cached response nor an active attacker and I don't like the idea of
assuming those things will ALWAYS be the case, and just writing off all
other situations in which the user WILL see that the cert has been
revoked rather than just allowing them to possibly be compromised by
other factors for the remainder of the certificate life.
On 10/24/2014 9:12 AM, Gervase Markham wrote:
> On 24/10/14 13:40, Rich Smith wrote:
>> I keep coming back to this same question every time this comes up, and I
>> have not received a satisfactory answer yet:
>> Why MUST a short lived certificate be issued without containing
>> revocation information?
> And I keep asking it every time you ask: because putting in revocation
> information eliminates 90% of their advantage, because there is then no
> advantage in all the currently-existing clients. A short-lived cert with
> revocation pointers will still incur the delay of revocation checking,
> even though (this is the argument, and the argument with which I hope
> you will engage) it's not necessary to provide them because the security
> properties of a 3-day cert are broadly comparable to a 1-year cert with
> 10-day, 5-day or 3-day-expiry OCSP responses.
>> The simple fact of the matter is that revocation info in the certificate
>> MAY help SOME users IF the certificate gets revoked, and I have yet to
>> see anyone offer up any decent argument for why the revocation info
>> absolutely MUST NOT be present for short-lived certs to work.
> No one is arguing that it MUST NOT be present for short-lived
> certificates to "work". But if a site and a CA are together considering
> deploying such a technology, they will look at the costs and benefits.
> There will be significant costs in setting up the system; if the
> benefits are only in 5% or 10% of clients, it may well be judged not to
> be worth it.
>> I'm open
>> to such an argument, but until I see it I remain opposed to a ballot to
>> allow any certificate to be issued without revocation information.
> I don't understand this position. Surely the acceptability or not of
> short-lived certificates should depend on whether their security
> properties are broadly comparable to existing solutions, not on whether
> I can construct an argument that shows it's required to remove the
> revocation information for it to be technically feasible to deploy them?
More information about the Public