[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[Ben Wilson]

Eddy wrote:

 

On 03/22/2013 09:48 PM, From Ryan Sleevi: 

Every byte is critical during the critical SSL/TLS handshake 


As for me, security can't be traded for speed - no matter what - and
personally I don't care a bit (nor byte). My task isn't to make the Internet
faster (of course I love if it does), but whenever possible more secure.
What we are discussing has been in place as a basic and in my opinion
minimum mechanism to indicate a certificate's status.

If speed is an issue lets work on making revocation check both faster and
more reliable by enabling hard fail.




Regards 


 


Signer: 

Eddy Nigg, COO/CTO

 

 

 

Eddy also wrote:

 

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

 

Jeremy wrote:

I've stated the benefits of short lived certs in the past.  Here they are
again for completeness:

1)      What possible advantage is there to either the CA or to the end user
for issuing a certificate w/out revocation information?

[JR} We have several business cases for these types of certs.  For example,
these certs are ideal for servers in less stable environments where they
don't trust the reliability of the Internet.  I do not think the BRs should
restrict a practice simply because some of the participants don't see the
practice as  part of their business.  The question should never be about
whether there is an opportunity of a particular CA, since that would require
divulgence of the CA's trade secrets.  The question should only be about
whether these constitute a security risk.  Restricting business practices
without a valid security or trust concern only serves to stifle innovation.

2)      CAs issue signed Good OCSP responses with signatures good beyond 24
hours because it is technically onerous to try to sign a new Good response
for EVERY cert we have live every 24 hours.  I don't see that translating
into a statement by the CA to the client software that you SHOULD CACHE that
response for more than 24 hours.  If we sign a Good response today that has
a signature that's good for 7 days, then revoke the cert tomorrow, we are
going to replace the response given by our OCSP server tomorrow, not next
week.  It's the caching of the response for what I consider to be an
excessive amount of time that's the problem, not the OCSP response itself.

[JR] Translates to the same thing.  A revocation response is only updated
every seven days under the BRs.  Therefore, short lived certificates have
the same reliability as a regular certificate.  Both are only revoked at the
end of the 7 day cycle.  If you want to talk about shorting the period
specified under the BRs, then I would accept that and similarly modify my
proposal.  The BRs are a minimum.  The minimum selected was seven days.
Therefore, a short lived cert that imposes the same minimum level of
revocation is equally as valid.

3)      I still fail to see how revocation information in the cert prevents
or hinders short lived certs in ANY way.  If the client sees a cert that is
only good for 7 days and decides NOT to check revocation, that is the
decision of the client software vendor and has nothing to do with the CA.

[JR] It does. As mentioned, short lived certs are ideal for places without a
reliable internet.  Traditional revocation checking always times out in
these cases.  Requiring inclusion of useless information does nothing but
slow the entire processes.  As mentioned, since the certificates are only
good for 7 days, there isn't a good reason to include the AIA extension.

Just to reiterate my position, I am absolutely against changing the
guidelines to allow issuing any end entity certificate without revocation
information.  We've talked around this subject for months and no one has yet
brought forth any convincing argument why it is necessary or desirable
either from the point of view of the CA or the end user.

[JR] I've presented many arguments why we should permit short lived certs
but haven't yet heard a compelling argument why they shouldn't be permitted.
The only argument seems to be that it gives CAs who plan to use them a new
market to capture.  I've given you lots of why there isn't a security risk.
I've also given a lot of reasons why they should be permitted.  I don't
really care if other CAs plan to issue these certs. What I care about is the
use of BRs to try and prevent a CA from entering different business
opportunities.  

Jeremy 

 

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Friday, March 22, 2013 2:59 PM
To: public at cabforum.org
Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

 

Also, Jeremy reminds me that he has a few tweaks to make, including
adjusting the proposed validity window of a short-lived certificate (to
accommodate potential clock skew on client machines). 

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Friday, March 22, 2013 2:55 PM
To: public at cabforum.org
Subject: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

 

Moving this pre-proposal to the public list for more discussion.

 

From: management-bounces at cabforum.org
[mailto:management-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Wednesday, March 20, 2013 4:08 PM
To: CABFMAN
Subject: [cabfman] OCSP Stapling and Short-Lived Certificates

 

All,

 

Before moving this toward a ballot, attached are a few redlined pages of the
Baseline Requirements to address OCSP stapling and short-lived certificates.
After you've had the chance to look at them, please review some of the
reasoning below that is in support of the proposed changes.   

 

As background, the language being modified was originally intended to
address the omission of the AIA for OCSP if the CA and the customer properly
configured retrieval of OCSP responses in a must-staple scenario.  However,
since then our Forum discussions have revealed that the server software
handles stapling best by pulling the OCSP server address from the
certificate (manual configuration errors are more likely to occur if the
certificates do not contain an AIA pointer to the OCSP Server).  

 

Section 13.2.1

1.       The Baseline requirements should not imply that OCSP stapling is
restricted to high-traffic sites.  Also, we think that defining
"high-traffic" is problematic. 

2.       A customer is not required to always staple.  It's not the sine qua
non, and as mentioned above, CAs won't have as much control here as the
current language seems to imply.  

3.       If the customer requests the MustStaple OID because it is confident
enough in its capabilities to provide stapling consistently, then we should
make that available - but the mustStaple identifier should not be required
or prohibited.  So this language should be a "MAY."   The existing language
only partially explains what the MustStaple OID can be used for (i.e. it's a
step toward preventing a downgrade attack when OCSP response are being
blocked), but again, the suggested revision does not require anything unless
the CA includes the OID in the certificate at the request of the customer.
We're welcome to suggestions on how to word this better.

 

Appendix B Section (2)C - Subordinate CA Certificate

"With the exception of stapling" should be deleted because it neglects the
need for the AIA for OCSP, as discussed above.   (The language in the last
paragraph is also an incorrect description of the Sub CA's AIA contents.)

 

Appendix B Section (3)C. - Subscriber Certificate

Again, deleting exception for AIA for OCSP stapling, but replacing it with
exception for short-lived certificates ("certificates with validity periods
of 168 hours or less").  It has been argued that this type of short-lived
certificate presents the same risk profile as certificates supported by CRLs
and OCSP responses, which are valid and cached for a week to 10 days.
Because at least some form of testing should be allowed, and the Baseline
Requirements should only set a floor and not prohibit innovative solutions,
short-lived certificates without revocation information should not be
prohibited.  

 

Thanks,

 

Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130322/cf56542a/attachment-0001.html