[cabfpub] [cabfman] Notes of meeting, CAB Forum, 21 March 2013, Version 1

[Eddy Nigg (StartCom Ltd.)]

On 03/22/2013 09:47 PM, From Jeremy Rowley:
>
> Why?  What risks do short lived certificates provide over other types 
> of certificates.
>

First of all I don't believe that there can be a robust mechanism to 
issue certificates with such a frequency where the CA does its pre and 
post issuance diligence. I'd consider such issuance more risky than a 
controlled and supervised manner (assuming that CAs did implement some 
due diligence for issuing certificates in the post Diginotar aera). This 
is my main objection and critical in my opinion.

Second, for an attacker 3 - 7 days is a long time to achieve their goals 
most of the time, by repeating same attack which would go undetected due 
to the above mentioned missing diligence, this could go on for a while.

Third, most software (browsers and other clients) check revocation 
usually on a higher frequency then possible nextUpdate fields in OCSP 
and CRLs, specially when relying on OCSP. Removing revocation status DPs 
will allow an attacker to complete his attack happily even if the CA has 
become aware of it. Software updates wouldn't be fast enough either.

Forth, browsers don't check revocation status all at the same time, 
making attacks more difficult when revocation status DPs are defined 
(system restarts, first access, access after 24 hours depending on 
software trigger a revocation status check). This will make an attack 
less reliable and also detectable by the client (if configured correctly).


Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	startcom at startcom.org <xmpp:startcom at startcom.org>
Blog: 	Join the Revolution! <http://blog.startcom.org>
Twitter: 	Follow Me <http://twitter.com/eddy_nigg>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130322/14a6d936/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130322/14a6d936/attachment-0001.p7s>