[cabfpub] Pre-Ballot - Short-Life Certificates

Gervase Markham gerv at mozilla.org
Fri Oct 31 22:30:18 UTC 2014


On 31/10/14 22:24, Rick Andrews wrote:
>> 3) Subscribers can avoid call-backs to the CA
> 
> They can avoid calling the CA to get an OCSP response (to staple), but in exchange they have to call the CA every day to get a new cert!

I think Jeremy means that a callback by each client can be avoided.

OCSP stapling is another way of avoiding this, but short-lived certs
work in all of today's webservers. For some, it may be easier to
implement an external certificate-rotation system than to upgrade the
server.

>> There are 9 advantages that I could readily find. I'm sure many more exist.
> 
> It would be helpful to list the disadvantages. Here's some:
> a) Short-lived certs won't work on some number of machines whose clocks are too far out of sync. The actual number is debatable. It's small, but non-zero.

I don't think this has any bearing on whether they should be allowed or
not. If they turn out to be impractical, so be it. But the CAB Forum is
not in the business of disallowing products because some members believe
them to be impractical to implement.

> b) Subscriber has to deal with the additional risk that their servers have to call back to the CA every day, obtain a fresh cert, and deploy that new cert without any negative impact to existing traffic.

I would say that an automated process can easily be less risky than a
manual one, because it can be examined, tested and is entirely repeatable.

> c) What a CA saves in OCSP infrastructure is offset by new infrastructure needed to distribute new certs to these customers every day.

Again, the CAB Forum is not in the business of disallowing products
because some members believe them to be impractical to implement.

Gerv



More information about the Public mailing list