[cabfpub] Short Lived Certificates

[Eddy Nigg (StartCom Ltd.)]

On 07/27/2012 09:36 PM, From kirk_hall at trendmicro.com:
>
> Jeremy, even if an attacker could cache and supply a previously good 
> response (clearly a problem) – wouldn’t that be the rare case?
>
> More likely a short lived cert might be revoked soon after issuance 
> because of a key compromise, etc. – in those cases, quick revocation 
> with required OCSP responses would, in fact, deliver correct 
> revocation information (“revoked”)  to the vast majority of relying 
> parties (as no attacker would be devilishly supplying cached but 
> incorrect good responses to relying parties in those cases).
>


We have been through this discussion already a few times and one of the 
clear risks involved that nobody seems to consider right now is the 
necessity to issue new certificates on a regular basis (turn-over) very 
frequently and most likely in an automated fashion. Those certificates 
will also have to be installed in a similar (automated) manner. There 
are risks when doing so and removes the ability to closely monitor 
issuance and review of the certificates or at least it makes it a lot 
harder, being it at the CA or at the subscriber side. Assuming that 
every week a bunch of those certificates have be pushed out, with 
increasing numbers the risk grows exceptionally.

A CA that issues tens or hundred of thousands of certificates per year 
would have to issue the same amount of certificates times 52. I can't 
see how any due diligence can be done here. And done tell me that the 
issuing systems are all secured beyond any doubt that no human 
intervention and monitoring is necessary.

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://cabforum.org/pipermail/public/attachments/20120727/5f3b1043/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4506 bytes
Desc: S/MIME Cryptographic Signature
Url : http://cabforum.org/pipermail/public/attachments/20120727/5f3b1043/attachment.bin