>> Sent: Thursday, September 4, 2014 12:21:50 PM
>> Subject: Short-lived certs
>> Short-lived certs are one plank of our future revocation strategy.
>> Currently, it is not permitted by the CAB Forum Baseline Requirements to
>> revocation pointers out of a cert, ever. However, this is part of the
>> big value of short-lived certs, as it's what unlocks their
>> speed-increasing potential across all browsers. (The logic is that a
>> 3-day expiry misissued cert with no revocation pointers has a similar
>> risk profile to a 1-year expiry misissued cert where the attacker has
>> captured a valid 3-day expiry OCSP response they can staple to it).
> It all depends on the exact definition of "short-lived". If the definition
> is basically the same as for OCSP responses or shorter, then yes, they
> provide the same security as regular certs with hard fail for OCSP
> I'm not sure what gives us the removal of revocation info from certificate.
> I mean, if the recommendation for PKIX is to not check revocation info
> for certificates that have total validity period of less than, say 2 days,
> then inclusion or exclusion of AIA extension is secondary.
> There's also the must-staple extension in the works, which can be part of
> the plan: you either get short lived certs or you get a long lived with
> must-staple. They would provide the same security guarantees.
1) Any new scheme has to work equally well with legacy browsers and
2) Ditto for legacy servers and this is actually a harder problem as
upgrading a server can force a complete redesign if they are using a
middleware layer that has changed radically.
3) The status vulnerability window needs to be no longer than 48 hours
for a machine with an accurate clock
4) The scheme must tolerate some degree of clock skew, though the
amount might vary over time.
Because of (1), the AIA field is going to have to be populated in EV
certs for a very long time and so we probably don't need to raise any
of this in CABForum right now. Lets do the work then let them follow
the deployment. A browser doesn't have to check the AIA field just
because it is there.
At worst we reword the requirements on browsers to say that they have
to verify that the status is current and not specify how. Short lived
certs would automatically qualify.
Must Staple and short lived certs are pretty much the same as far as
the security requirements go. The difference is that the server
requirements for supporting stapling with must staple are pretty
simple. All that is needed is that the server specify the must staple
extension when the certificate is applied for (just a flag on the key
generator) and then the server pulls the OCSP token from the AIA
extension every n hours which is already implemented almost
Short lived certs are just as easy in theory BUT they require some new
infrastructure to do the job right. At minimum there needs to be a
mechanism to tell the server how to get its supply of short lived
certificates. And we haven't designed a standard for that yet or
really discussed how to do it and so it isn't ready to press the fire
What I suggest browsers do right now is
1) Join in the IETF discussion on the TLS/PKIX lists saying that you
support my TLS Feature extension proposal aka MUST STAPLE.
2) Read and comment on the proposal you have just committed to.
3) Implement an appropriate response to a certificate that specifies a
MUST STAPLE condition when the server does not staple. This could be
(1) Hard Fail immediately or (2) attempt to do an OCSP lookup and hard
fail if it does not succeed or (3) choose randomly between options 1
and 2 so as to disincentivize CAs misusing setting the flag to force
4) Implement a mechanism that regards certificates with a total
validity interval of 72 hours or less to be valid without checking. I
do not expect this feature to be used very soon but implementing the
feature in the browser is probably a gating function on starting the
server folk thinking about the best way to implement the cert update
The simplest way to do cert update would be for the server to keep the
same key throughout and just issue fresh certs for the same old key.
A much better approach that provides a lot of robustness in all sorts
of ways is to rotate the private key with each new certificate. Under
one scheme the server would have some means of authenticating the cert
update request to a CA (probably a long term RSA or ECC key pair).
But in a large server farm where outsourcing etc is involved you might
want to have a scheme that makes use of trustworthy hardware to bind
unique keys to particular hardware in a manner that prevents
I have a scheme of this type described here...
Rotating the server private key every 24 hours practically eliminates
key compromise due to a server or hard drive being disposed of within
the cert validity interval. It vastly increases the cost of pervasive
attacks against well known keys. It also works a lot better for cloud