[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

Phillip philliph at comodo.com
Mon Mar 25 09:44:49 MST 2013


Let us look at the situation in the most abstract terms possible. There are three types of information that might affect the client's decision to accept a certificate and present an assurance to the user (i.e. padlock or green bar):

* The first date on which the subject was validated by the issuer (aka Member Since)
* The most recent date on which the subject was validated by the issuer (aka Last validated)
* The most recent date at which the issuer is known to have reported valid status (Last status)

From a security point of view it does not matter how the information is obtained, what matters is what information is available and how it is processed. Right now the issue date of the cert is identical to Last Validated which leads to the BR making particular assumptions. If that assumption is getting in the way of making the right decision to allow short lived certs as an alternative to OCSP then lets put that information into a certificate extension so that a client does not lose any information if we move to short lived certs. I would like to put Member Since and Last Validated in the cert if they are not the same as the issue date.

Since we already allow for a delay in issue of status information it seems perfectly acceptable to assume that cert status is valid within a short time window of issue. If we look at what we have to do server side for OCSP stapling and what we have to do for short lived certs it is essentially the same. Short lived certs are simpler on the client side, only one trust chain to check. The client could even pre-fetch status for frequently used certs if that makes sense.

There are issues to do with time. But note that even though we are obliged to allow for time to be out of sync on the client we can reasonably demand that CAs are correct to within an minute. The question is how the client should react when the status appears to be stale. There are serious issues there but they are exactly the same regardless of the status mechanism. We can't solve a time sync problem for short lived certs by pulling an OCSP token as that will appear to be stale or in the future as well.

There are three questions for Last Status:

* What status mechanisms do we want issuers to support?
* What should the client do when it does not have valid status?
* What should the BR allow?

The last is not necessarily the same as first two. I think that we should not try to force the client into any particular approach to status other than a client should not be telling an end user a certificate is good if it does not have recent status. Turning on SSL is fine, a client should be able to turn on SSL any time that it would accept a raw TCP connection. But telling the user that they are safe with either the padlock or the green bar should not happen if the status is stale.





More information about the Public mailing list