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

[Eddy Nigg (StartCom Ltd.)]

On 03/23/2013 12:15 AM, From Jeremy Rowley:
>
> 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.
>
> [JR] Depends on the CA.  Obviously, some CAs have better post and pre 
> issuance diligence practices than others.
>

Right, and don't forget that we aren't talking about Digicert and 
StartCom, but a general policy change that could have some significant 
implications.

>   I think a correctly operating CA issuing short lived certificates 
> can have just as good of post issuance and pre issuance diligence as 
> one that issues longer lived certs.
>

That's what I have difficulty to believe - knowing the efforts required 
for certificates with normal expiration periods, I can't imagine that 
when volume of some automated mechanism goes up, anything reasonable can 
be sustainable. Furthermore I don't believe that there can be any 
pre-issuance diligence since that would risk renewal of such 
certificates that rely on timely renewal.

It's hard to believe that CAs would do their real due diligence for such 
certificate, considering that there are probably still many CAs which 
have to get their normal issuance processes improved (or which consider 
theirs sufficient, but actually aren't).

>   In fact, better practices since they don’t have to worry about OCSP 
> up-time, CRL availability, and the timely processing of revocation 
> requests.
>

That's BS - a CA issuing such certificate wont stop their regular 
issuance practices I assume. Would your CA stop issuing certificates 
with a longer validity period of seven days if this proposal would got 
forward? If not, you'll have to deal with it in any case.

> 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.
>
> [JR] That argument is bogus. Because of the BR 7/10 update 
> requirement, any attacker has between 7-10 days to make their attack.
>

We can make it shorter if you want, no problem.

> If you are arguing for a shorter time under the BRs, I’d support that 
> and update my proposal for short-lived certs accordingly.
>

I'm supportive of the first part - how about 48-72 hours?

> 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.
>
> [JR] Not accurate.  As someone pointed out a while ago, Microsoft 
> caches responses for 80% of the OCSP next update. Under the BRs this 
> is 8 days.
>

And Mozilla caches for 24 hours. Very reasonable in my opinion.

> 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).
>
> [JR] Correct.  Some browsers don’t check revocation at all.
>

Don't get me started :-)

> I hardly think that is an argument against a guaranteed method of 
> revocation checking like short lived certs provides. Also, if the 
> client can’t access the revocation information (say in the case of a 
> government sponsored attack), you’re basically screwed using 
> traditional revocation. You simply can’t revoke the certificate, 
> whereas with short lived certificates you have assurance that those 
> certificates will at least cease functioning after a certain time.
>

OK, lets replace something broken with something broken....or lets get 
it fixed. I prefer the later - which reminds me to ask the browser 
vendors which improvements they've done lately for us?

> Would it alleviate concerns if short-lived certs are issued from a 
> different intermediate than other certs?  The intermediate still 
> contains revocation information.  If something goes horribly wrong, 
> you can always shut off the intermediate.
>

That might be an idea, but what's the benefit? The intermediate CAs will 
have to be checked in that case (which some software vendors don't), so 
the benefit would be questionable. Also note that the nextUpdate 
information for intermediates wouldn't be reasonable at the moment for 
such certs (it would have to be similar to today's leaves, e.g. 7 days 
or less for those that specially issue short-lived certs).


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/20130323/19340e8b/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/20130323/19340e8b/attachment-0001.p7s>