Short-lived certs

[Gervase Markham]

Short-lived certs are one plank of our future revocation strategy.[0]
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).

I've just been reviewing discussions from July 2012 on the CAB Forum
mailing lists about short-lived certs. There was some significant
opposition to removing revocation information from short-lived certs at
the time (although things may be different now, I don't know). I
personally think much of that opposition was mistaken, but the
discussion nevertheless did not result in consensus.

How should we approach the issue of short-lived certs? It seems to me we
can do the following:

0) Try and get a motion passed to change the BRs to allow short-lived
certs to not have any revocation information. This would probably
require us to review the original discussion and make a wiki page
outlining our proposal and rebutting objections. We may still run into
heavy weather. We could also discuss it at the face-to-face.

1) Write an exception in Mozilla's policy that short-lived certs don't
have to have revocation info. This would likely have no effect, because
CAs would want to continue issuing to the BRs.

2) Stop checking revocation information for short-lived certs
unilaterally. This would result in reduced take-up of the idea, because
there would be no advantage in other browsers, and one would still need
to implement all the mechanisms, both at the CA and at the site, for
frequent cert renewals and deployments.

3) Configure Firefox to not bother checking revocation information for
any cert newer than N days. This way, you can "emulate" short-lived
certs by just reissuing an X-year cert every N days or less. It also
'fixes' the clock-skew problem in one direction, because the certs will
still work for users whose clocks are some way in the future (although
their browsers would check revocation).

4) Something else?

Gerv

[0] https://wiki.mozilla.org/CA:RevocationPlan

[Hubert Kario]

----- Original Message -----
> From: "Gervase Markham" <ge...@mozilla.org>
> To: mozilla-dev-s...@lists.mozilla.org
> Sent: Thursday, September 4, 2014 12:21:50 PM
> Subject: Short-lived certs
>
> Short-lived certs are one plank of our future revocation strategy.[0]
> 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
querying/stapling.

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.

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hka...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[Gervase Markham]

On 04/09/14 12:52, Hubert Kario wrote:
> 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
> querying/stapling.

The exact definition of "short-lived" is something I want to declare out
of scope for this particular discussion.

> I'm not sure what gives us the removal of revocation info from certificate.

Because there are lots of clients out there who check revocation info
always if the pointers are present. The only way to stop them doing that
(and so realise the speed advantage) is by not putting revocation info
in the cert.

> 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.

We can't update all the software in the world to magically follow our
recommendation.

> 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.

It is part of the plan, if you read it :-)
https://wiki.mozilla.org/CA:RevocationPlan

Gerv

[Hubert Kario]

----- Original Message -----
> From: "Gervase Markham" <ge...@mozilla.org>
> To: mozilla-dev-s...@lists.mozilla.org

> Sent: Thursday, September 4, 2014 3:04:33 PM
> Subject: Re: Short-lived certs
>
> On 04/09/14 12:52, Hubert Kario wrote:

> > 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
> > querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare out
> of scope for this particular discussion.
>

> > I'm not sure what gives us the removal of revocation info from certificate.
>

> Because there are lots of clients out there who check revocation info
> always if the pointers are present. The only way to stop them doing that
> (and so realise the speed advantage) is by not putting revocation info
> in the cert.

>From what I heard (and my limited personal experience matches), is that
the vast majority of clients not only completely ignore failures in OCSP
retrieval (soft-fail) but completely lack any mechanism for revocation checking
(be it OCSP or CRL).

In fact, that is the main driver behind must-staple.

Can you provide examples to the contrary?

[Rob Stradling]

On 04/09/14 14:04, Gervase Markham wrote:
> On 04/09/14 12:52, Hubert Kario wrote:

>> 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
>> querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare out
> of scope for this particular discussion.
>

>> I'm not sure what gives us the removal of revocation info from certificate.
>

> Because there are lots of clients out there who check revocation info
> always if the pointers are present. The only way to stop them doing that
> (and so realise the speed advantage) is by not putting revocation info
> in the cert.

Today, if an end-entity cert contains no AIA->OCSP URL and the server
sends no stapled OCSP response, it's a violation of the BRs. I wonder
if any clients out there would reject the cert in this situation? (I
suspect not, but it's something to watch out for).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Rob Stradling]

When attempting to access an HTTPS site with an expired cert on Firefox
32, you'll see a "This Connection is Untrusted" page that lets you add
an exception and proceed.

But when attempting to access an HTTPS site with a revoked cert, you'll
see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.

Would it make sense to treat expired certs in the same way as revoked
certs? (And if not, why not?)

On 04/09/14 12:52, Hubert Kario wrote:

> ----- Original Message -----
>> From: "Gervase Markham" <ge...@mozilla.org>
>> To: mozilla-dev-s...@lists.mozilla.org

>> Sent: Thursday, September 4, 2014 12:21:50 PM
>> Subject: Short-lived certs
>>
>> Short-lived certs are one plank of our future revocation strategy.[0]
>> 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
> querying/stapling.
>

> 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.
>

[Jeremy Rowley]

An exception to Mozilla's policy won't permit short-lived certificates since the other browsers won't have the same exception. Personally, I like 0 the best since it coordinates all of the CAs and browsers into a single plan of action rather than carving out individual exceptions to the guidelines.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Gervase Markham
Sent: Thursday, September 4, 2014 4:22 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Short-lived certs

Short-lived certs are one plank of our future revocation strategy.[0] 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).

I've just been reviewing discussions from July 2012 on the CAB Forum mailing lists about short-lived certs. There was some significant opposition to removing revocation information from short-lived certs at the time (although things may be different now, I don't know). I personally think much of that opposition was mistaken, but the discussion nevertheless did not result in consensus.

How should we approach the issue of short-lived certs? It seems to me we can do the following:

0) Try and get a motion passed to change the BRs to allow short-lived certs to not have any revocation information. This would probably require us to review the original discussion and make a wiki page outlining our proposal and rebutting objections. We may still run into heavy weather. We could also discuss it at the face-to-face.

1) Write an exception in Mozilla's policy that short-lived certs don't have to have revocation info. This would likely have no effect, because CAs would want to continue issuing to the BRs.

2) Stop checking revocation information for short-lived certs unilaterally. This would result in reduced take-up of the idea, because there would be no advantage in other browsers, and one would still need to implement all the mechanisms, both at the CA and at the site, for frequent cert renewals and deployments.

3) Configure Firefox to not bother checking revocation information for any cert newer than N days. This way, you can "emulate" short-lived certs by just reissuing an X-year cert every N days or less. It also 'fixes' the clock-skew problem in one direction, because the certs will still work for users whose clocks are some way in the future (although their browsers would check revocation).

4) Something else?

Gerv

[0] https://wiki.mozilla.org/CA:RevocationPlan

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Tim Moses]

Hi Mark. I think that makes sense.

Historically, the Development manager for the affected product has been invited to SARB. He or she has taken on the task of communicating with the relevant product managers.

"Relevant" product managers should include those with responsibility for services.

The service product managers should ensure that service components are remediated in an expeditious manner and that (where not already publicly disclosed) the security bulletin is not released until this has been done.

I don't think that contradicts anything in the proposed amendment. We just have to make sure that the Development manager brings ALL the relevant product managers into the discussion.

All the best. Tim.

> On Sep 4, 2014, at 12:41 PM, "Ben Wilson" <ben.w...@digicert.com> wrote:
>
> Options for trying this out might fit under an exception, if one were
> created, for "test, experimental, temporary, pilot, provisional, etc."
> certificate types.

[Tim Moses]

Oops. Does it look like I replied to wrong email?

Red-faced. Tim.

[David E. Ross]

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:
> How should we approach the issue of short-lived certs?

Spammers change their E-mail addresses quite frequently, using the same
address for only a day or two. Hackers also frequently change their
"residence" so as to prevent tracing them. The same is true of
distributors of malware.

If short-lived certificates are subjected to less stringent security by
client applications, I would fear that they would become hacker and
malware tools.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Jeremy Rowley]

They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 11:36 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:

> How should we approach the issue of short-lived certs?

Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their "residence" so as to prevent tracing them. The same is true of distributors of malware.

If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Phillip Hallam-Baker]

On Thu, Sep 4, 2014 at 7:52 AM, Hubert Kario <hka...@redhat.com> wrote:
> ----- Original Message -----
>> From: "Gervase Markham" <ge...@mozilla.org>
>> To: mozilla-dev-s...@lists.mozilla.org

>> Sent: Thursday, September 4, 2014 12:21:50 PM
>> Subject: Short-lived certs
>>
>> Short-lived certs are one plank of our future revocation strategy.[0]
>> 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
> querying/stapling.
>
> 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.

Some constraints:

1) Any new scheme has to work equally well with legacy browsers and
enabled browsers.

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
everywhere.

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
button on.


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
hard fail.

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
feature.


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
extraction.

I have a scheme of this type described here...

https://datatracker.ietf.org/doc/draft-hallambaker-omnipublish/



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
computing.

[fhw...@gmail.com]

Hi Jeremy, 

Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable?

Are there really cases where the extra 50 bytes (or whatever) for the revocation info is t‎oo great a burden? Or is the desire really to short circuit the revocation checks? Or...?

I'm also wondering what the plan is for handling an expired short term cert. Will the user be given a choice of allowing an exception or does it get special handling? 


  Original Message  
From: Jeremy Rowley
Sent: Thursday, September 4, 2014 12:46 PM
To: 'David E. Ross'; mozilla-dev-s...@lists.mozilla.org
Subject: RE: Short-lived certs

They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 11:36 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:

> How should we approach the issue of short-lived certs?

[David E. Ross]

On 9/4/2014 10:44 AM, Jeremy Rowley wrote:
>
> They aren't subject to less stringent security in issuing the
> certificate. The benefit is that the certificate doesn't include
> revocation information (smaller size) and doesn't need to check
> revocation status (faster handshake). The issuance of the certificate
> still must meet all of the Mozilla root store requirements.
> > Jeremy
>

Are you suggesting that NO certificate authority applying stringent
procedures has ever signed a subscriber certificate for someone who
intended to use it for malevolent purposes?

[Jeremy Rowley]

Of course not. I'm implying that the level of security in a short-lived cert is at least equal to any other certificate with a longer life cycle. I'd argue that the security is perhaps better since revocation happens automatically by the certificate's expiration without the need to push a CRL or provide OCSP.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 12:44 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On 9/4/2014 10:44 AM, Jeremy Rowley wrote:
>

> They aren't subject to less stringent security in issuing the
> certificate. The benefit is that the certificate doesn't include
> revocation information (smaller size) and doesn't need to check
> revocation status (faster handshake). The issuance of the certificate
> still must meet all of the Mozilla root store requirements.
> > Jeremy
>

Are you suggesting that NO certificate authority applying stringent procedures has ever signed a subscriber certificate for someone who intended to use it for malevolent purposes?

[Peter Bowen]

On Thu, Sep 4, 2014 at 7:54 AM, Ben Wilson <ben.w...@digicert.com> wrote:
> Options for trying this out might fit under an exception, if one were
> created, for "test, experimental, temporary, pilot, provisional, etc."
> certificate types.

Ben,

I think there is value in allowing some level of non-compliance for
the purposes of testing and development, as that is the only way to
get real world data. However the challenge is going to be not
creating a loophole large enough to drive a truck (or business)
through. I have no question there are customers who would love to pay
a CA to issue a 1024-bit RSA certificate directly from a root with a
subject of "CN=exchange" with no subject alternative name. What would
prevent a CA from issuing such a certificate as a "test, experimental,
temporary, pilot, provisional, etc." type certificate?

Thanks,
Peter

[Ryan Sleevi]

On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote:
> Some constraints:
>
> 1) Any new scheme has to work equally well with legacy browsers and
> enabled browsers.

Sure. However, this requires a definition of legacy.

>
> 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.

Respectfully, Phillip, I disagree. CAs MAY offer such short-lived certs as
an option. No one's requiring they exclusively limit issuance to it.
There's no concern for legacy servers. If you're a legacy server, you
don't use this. It's that simple.

>
> 3) The status vulnerability window needs to be no longer than 48 hours
> for a machine with an accurate clock

That's an opinion, and not a hard requirement memorialized in the current
Baseline Requirements or Mozilla program. So I don't think it's fair or
reasonable to introduce it as a requirement upon some new scheme or
proposal.

>
> 4) The scheme must tolerate some degree of clock skew, though the
> amount might vary over time.

That's up to the server operator, not the CA, and whether or not the
solution is viable for them.

Which is to say, a solution that tolerates no degree of clock skew is
still immensely viable for a group of people. The more clock skew
supported, the more viable it becomes for others, but that is NOT a gating
factor to the overall scheme.

>
>
> 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.

I'm not sure I agree with your conclusion for 1. As noted elsewhere, a
short-lived cert is effectively the same as the maximal attack window for
a revocation response. That's it. The AIA can be dropped if they're
equivalent.

>
> 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
> everywhere.
>
> 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
> button on.

I disagree here. What's at stake is not the particular mechanisms of doing
so, nor would I endorse going down the route of standardizing such
mechanisms as you do. I would much rather see the relevant frameworks -
Mozilla and the BRs - altered to support them, and then allow site
operators and CAs interested in this model to work to develop the
infrastructure and, based on real world experience, rough consensus, and
running code, rather than idealized abstractions.

>
>
> 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
> hard fail.

This is something you should nail down before 1 or 2.

The correct answer is hard fail. Any other answers and we'll be back here
again in 5 years with the same issues.

>
> 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
> feature.

And implementing it in policy is the gating function before thinking about
implementing it in the server or the browser.

>
>
> 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
> extraction.
>
> I have a scheme of this type described here...
>
> https://datatracker.ietf.org/doc/draft-hallambaker-omnipublish/
>
>
>
> 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
> computing.

Which are a different, and valuable, set of mitigations, but orthogonal
the key issue at hand.

That is, I would like to see the world rotate keys on the regular, but I'm
not at all willing to throw the baby out with the bathwater and require
it.

[Brian Smith]

On Thu, Sep 4, 2014 at 6:04 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 04/09/14 12:52, Hubert Kario wrote:

>> 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
>> querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare out
> of scope for this particular discussion.

Precisely defining a short-lived certificate is a prerequisite for a
proper discussion of policy for short-lived certificates. It seems
likely to me that short-lived certificates will be defined as
certificates that would expire before the longest-acceptable-life OCSP
response for that certificate would expire. Then it would be easy to
understand the security properties of short-lived certificates, given
that we understand the security properties of OCSP.

Previously, we decided it was important that we have evidence that the
OCSP responder know about all certificates that were issued by the CA,
so we made it a requirement that OCSP responders must return not
return "Good" for certificates that they do not know about. But,
accepting short-lived certificates is equivalent to an OCSP responder
returning "Good" for all certificates, whether it knows about them or
not. So, we need to decide whether this aspect (a type of multi-factor
authentication or counter-signature mechanism) is really important or
not. It seems wrong for us to make it mandatory for long-lived
certificates but not short-lived certificates, considering that the
highest period of risk is immediately after issuance.

Cheers,
Brian

[Jeremy Rowley]

Yeah - the cert would have to be shorter than the longest acceptable OCSP response for certificates. I think that's set to 10 days in the CAB Forum, but I'd be surprised if anyone issues OCSP responses that are valid that long.

The issue of revocation checking is where the proposal died in the CAB Forum. Opponents argued that mis-issued certificates are revoked immediately after issuance, meaning that traditional revocation is, on average, faster than short-lived certificate since the revocation usually occurs before the revocation information is cached.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Brian Smith
Sent: Thursday, September 4, 2014 5:07 PM
To: Gervase Markham
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On Thu, Sep 4, 2014 at 6:04 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 04/09/14 12:52, Hubert Kario wrote:

>> 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 querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare
> out of scope for this particular discussion.

Precisely defining a short-lived certificate is a prerequisite for a proper discussion of policy for short-lived certificates. It seems likely to me that short-lived certificates will be defined as certificates that would expire before the longest-acceptable-life OCSP response for that certificate would expire. Then it would be easy to understand the security properties of short-lived certificates, given that we understand the security properties of OCSP.

Previously, we decided it was important that we have evidence that the OCSP responder know about all certificates that were issued by the CA, so we made it a requirement that OCSP responders must return not return "Good" for certificates that they do not know about. But, accepting short-lived certificates is equivalent to an OCSP responder returning "Good" for all certificates, whether it knows about them or not. So, we need to decide whether this aspect (a type of multi-factor authentication or counter-signature mechanism) is really important or not. It seems wrong for us to make it mandatory for long-lived certificates but not short-lived certificates, considering that the highest period of risk is immediately after issuance.

Cheers,
Brian

[Jeremy Rowley]

I agree with Ryan - as long as Mozilla (or the CAB) isn't requiring short lived certs, there isn't a concern about legacy servers. Since short-lived certs are optional, each server operator can individually decide on their own whether to implement short-lived certs on their server.

Also, before anyone can specify a 48/72/etc. hour lifecycle of short-lived certs, we'd need more information on clock skew, current OCSP validity period, and caching. Although tolerable clock skew is up to the operator (working with their CA), if Mozilla will provide special treatment for short-lived certificates, they'll need a cap on the lifecycle that fits in this window. Gerv's suggestion to exclude a debate on the exact definition from this discussion is a good one*. First, decide on how (and whether) to handle short-lived certs policy-wise, then decide on what constitutes an acceptable lifecycle.

Jeremy

*Presuming that short lived at least means shorter than the typical OCSP validity period

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Ryan Sleevi
Sent: Thursday, September 4, 2014 4:44 PM
To: Phillip Hallam-Baker
Cc: Gervase Markham; mozilla-dev-s...@lists.mozilla.org; Hubert Kario
Subject: Re: Short-lived certs

[Jeremy Rowley]

Sure - short lived certs are desirable where:
1) 50 bytes does matter, such as high traffic websites (it's why some CAs were issuing certs directly from the root)
2) Revocation information cannot be reliable obtained, such as areas with low internet connectivity - the cert simply expires instead of being revoked
3) the server is in a region with probable government influence/intervention - the government may block revocation checking or may seize control over the servers, in which case the issuer simply turns off the certificate issuance
4) the server is in a region where there is civil unrest - again, the server operator can abandon the server without having to worry about the sufficiency of revocation checking

I think the an expired short-term certificate should be treated as revoked, but I don't have strong feelings. The expired certificate interstitial will likely give site visitors sufficient notice that something is going wrong.

Jeremy

-----Original Message-----
From: fhw...@gmail.com [mailto:fhw...@gmail.com]
Sent: Thursday, September 4, 2014 12:33 PM
To: Jeremy Rowley; 'David E. Ross'; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

Hi Jeremy, 

Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable?

Are there really cases where the extra 50 bytes (or whatever) for the revocation info is t‎oo great a burden? Or is the desire really to short circuit the revocation checks? Or...?

I'm also wondering what the plan is for handling an expired short term cert. Will the user be given a choice of allowing an exception or does it get special handling? 


  Original Message  
From: Jeremy Rowley
Sent: Thursday, September 4, 2014 12:46 PM
To: 'David E. Ross'; mozilla-dev-s...@lists.mozilla.org
Subject: RE: Short-lived certs

They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 11:36 AM
To: mozilla-dev-s...@lists.mozilla.org

Subject: Re: Short-lived certs

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:

> How should we approach the issue of short-lived certs?

Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their "residence" so as to prevent tracing them. The same is true of distributors of malware.

If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Phillip Hallam-Baker]

On Thu, Sep 4, 2014 at 6:43 PM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:
> On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote:
>> Some constraints:
>>
>> 1) Any new scheme has to work equally well with legacy browsers and
>> enabled browsers.
>
> Sure. However, this requires a definition of legacy.
>
>>
>> 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.
>
> Respectfully, Phillip, I disagree. CAs MAY offer such short-lived certs as
> an option. No one's requiring they exclusively limit issuance to it.
> There's no concern for legacy servers. If you're a legacy server, you
> don't use this. It's that simple.

It is still a problem.

The point I am trying to get across here is that there are very few
good reasons for an end user sticking to an obsolete browser and
almost all would upgrade given the choice. This is not the case for
servers and there are lots of folk who will complain if they are
forced to upgrade their server because that might require them to
change their PHP version which in turn requires them to completely
rework a ton of spaghetti code piled on top.

>> 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.
>
> I'm not sure I agree with your conclusion for 1. As noted elsewhere, a
> short-lived cert is effectively the same as the maximal attack window for
> a revocation response. That's it. The AIA can be dropped if they're
> equivalent.

It can be dropped as far as security is concerned. But that is only
going to save a few bytes and might cause legacy issues. So why make
being allowed to drop it a major concern at this point?

Dropping AIA is useful for the CA as I don't need to bother with OCSP
at all. But I can only drop AIA if it is not going to cause legacy
browsers to squeak about a missing OCSP distribution point.

If there are browsers that give appropriate treatment to short lived
certs then I am sure getting CABForum to update the BRs etc. is not
going to be hard. All I am saying here is that is not a critical path
concern.

>> 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
>> button on.
>
> I disagree here. What's at stake is not the particular mechanisms of doing
> so, nor would I endorse going down the route of standardizing such
> mechanisms as you do. I would much rather see the relevant frameworks -
> Mozilla and the BRs - altered to support them, and then allow site
> operators and CAs interested in this model to work to develop the
> infrastructure and, based on real world experience, rough consensus, and
> running code, rather than idealized abstractions.

I am not interested in issuing any product until my customers can use
it. And I don't see how they can use it until the cert update process
can be automated.

>> 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
>> hard fail.
>
> This is something you should nail down before 1 or 2.

OK, if I have to nail it down I will pick 1.

> The correct answer is hard fail. Any other answers and we'll be back here
> again in 5 years with the same issues.

That is my preference.

>> 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
>> feature.
>
> And implementing it in policy is the gating function before thinking about
> implementing it in the server or the browser.

I don't see the need to gate on policy changes. What do you think
stops me issuing a 72 hour certificate today? I can't think of
anything.

>> 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
>> computing.
>
> Which are a different, and valuable, set of mitigations, but orthogonal
> the key issue at hand.
>
> That is, I would like to see the world rotate keys on the regular, but I'm
> not at all willing to throw the baby out with the bathwater and require
> it.

Which is why I mentioned the simple approach.

[Gervase Markham]

On 04/09/14 14:14, Hubert Kario wrote:
>>From what I heard (and my limited personal experience matches), is that
> the vast majority of clients not only completely ignore failures in OCSP
> retrieval (soft-fail) but completely lack any mechanism for revocation checking
> (be it OCSP or CRL).

I believe all browsers have some mechanisms for revocation checking.
Firefox does indeed soft-fail OCSP; our revocation plan as referenced in
the parent post demonstrates how we are hoping to improve this, with
short-lived certs part of the mix.

Gerv

[Gervase Markham]

On 04/09/14 14:18, Rob Stradling wrote:
> Today, if an end-entity cert contains no AIA->OCSP URL and the server
> sends no stapled OCSP response, it's a violation of the BRs. I wonder
> if any clients out there would reject the cert in this situation? (I
> suspect not, but it's something to watch out for).

I'm not aware of any browser which enforces the presence of revocation
information, but if such a browser existed, that would of course affect
the viability of the option of updating the BRs to not require
revocation information for short-lived certs.

Gerv

[Gervase Markham]

On 04/09/14 14:25, Rob Stradling wrote:
> When attempting to access an HTTPS site with an expired cert on Firefox
> 32, you'll see a "This Connection is Untrusted" page that lets you add
> an exception and proceed.
>
> But when attempting to access an HTTPS site with a revoked cert, you'll
> see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.
>
> Would it make sense to treat expired certs in the same way as revoked
> certs? (And if not, why not?)

Logically, it does make sense. In practice, revocation has a near-zero
false-positive rate, whereas expired sadly has a much greater
false-positive rate. Which is why Firefox treats them differently.

It might be good, in the future, to get CAs to guarantee to continue
providing revocation information for e.g. 3 months after expiry, and for
those 3 months, we treat as "Untrusted Connection", but after that we
switch to "Secure Connection Failed". What do you think of that idea?

Gerv

[Gervase Markham]

On 04/09/14 18:36, David E. Ross wrote:
> Spammers change their E-mail addresses quite frequently, using the same
> address for only a day or two. Hackers also frequently change their
> "residence" so as to prevent tracing them. The same is true of
> distributors of malware.
>
> If short-lived certificates are subjected to less stringent security by
> client applications, I would fear that they would become hacker and
> malware tools.

Can you explain in detail the differences you see in the threat model
between:

a) a cert with a lifetime of 3 days and no revocation pointers

b) a cert with a lifetime of a year whose OCSP responder's responses
have a lifetime of 3 days

?

It seems to me that, if either are compromised, the attacker has 3 days
to exploit the issue. (In case b), they can staple the good OCSP
response they have obtained, even if the cert is revoked.)

Gerv

[Gervase Markham]

On 04/09/14 19:20, Phillip Hallam-Baker wrote:
> 1) Any new scheme has to work equally well with legacy browsers and
> enabled browsers.

Yes; I think short-lived certs meet that criterion.

> 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.

I don't agree; as others have said, no-one is forced to use such certs.

> 3) The status vulnerability window needs to be no longer than 48 hours
> for a machine with an accurate clock

How do you come up with your figure of 48 hours?

> 4) The scheme must tolerate some degree of clock skew, though the
> amount might vary over time.

Investigation of clock skew still needs to be done. We think that the
problem may not be insurmountable.

> 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.

As my original post noted, a lot of the advantage of short-lived certs
evaporates if they contain revocation pointers.

> 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
> button on.

I don't think it necessarily requires a standard.

> 1) Join in the IETF discussion on the TLS/PKIX lists saying that you
> support my TLS Feature extension proposal aka MUST STAPLE.

We definitely support it.

> 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

I think that's what we will be doing.

> 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
> hard fail.

I don't quite understand the problem you are trying to mitigate here;
can you expand?

Gerv

[Gervase Markham]

On 05/09/14 00:06, Brian Smith wrote:
> Precisely defining a short-lived certificate is a prerequisite for a
> proper discussion of policy for short-lived certificates. It seems
> likely to me that short-lived certificates will be defined as
> certificates that would expire before the longest-acceptable-life OCSP
> response for that certificate would expire. Then it would be easy to
> understand the security properties of short-lived certificates, given
> that we understand the security properties of OCSP.

I strongly want to avoid ratholing on this discussion; if I say "OK,
let's say for the sake of argument that short-lived is the same as the
max OCSP lifetime", then someone else will say "but that's still too
long!" and so on.

I realise that this issue would need to be resolved precisely before
short-lived certs were allowed by policy; but I just don't want to focus
on it right _now_. I want to assume that we could come up with an
appropriate time window, and work out how Mozilla should push towards
making short-lived certs possible, using the options I outlined above.

> Previously, we decided it was important that we have evidence that the
> OCSP responder know about all certificates that were issued by the CA,
> so we made it a requirement that OCSP responders must return not
> return "Good" for certificates that they do not know about. But,
> accepting short-lived certificates is equivalent to an OCSP responder
> returning "Good" for all certificates, whether it knows about them or
> not.

Is that actually true? I am assuming that if a cert is mis-issued, for a
few minutes at least the CA will stand by their issuance, and that the
attacker can obtain a good OCSP response for it with a lifetime of X,
and staple that response during their attack. So the security properties
of that are about the same as those for a cert with lifetime X.

Hmm... is there some mileage in saying that OCSP responses for certs
during their first week of existence must have a max lifetime of
significantly less than for the rest of their lives? That wouldn't
increase OCSP server load much, but would perhaps mitigate this issue if
the CA were to discover the misissuance soon after it happened.

Gerv

[Gervase Markham]

On 05/09/14 01:32, Phillip Hallam-Baker wrote:
> The point I am trying to get across here is that there are very few
> good reasons for an end user sticking to an obsolete browser and
> almost all would upgrade given the choice. This is not the case for
> servers and there are lots of folk who will complain if they are
> forced to upgrade their server because that might require them to
> change their PHP version which in turn requires them to completely
> rework a ton of spaghetti code piled on top.

Why would anyone ever be forced to upgrade their server?

No-one is suggesting that browsers _only_ support short-lived certs!

> It can be dropped as far as security is concerned. But that is only
> going to save a few bytes and might cause legacy issues. So why make
> being allowed to drop it a major concern at this point?

The reason for dropping it is to save the N hundred milliseconds
(sometimes much more, if network is bad or server is down) that you have
to wait before you can actually go on and request data and display it to
the user. This is the big advantage of no-AIA. It's not the miniscule
cert size saving.

>> This is something you should nail down before 1 or 2.
>
> OK, if I have to nail it down I will pick 1.

Great :-)

> I don't see the need to gate on policy changes. What do you think
> stops me issuing a 72 hour certificate today? I can't think of
> anything.

Nothing, but they are no advantage to anyone unless you can also omit
the revocation pointers. Which is currently not permitted, hence this
discussion.

Gerv

[Gervase Markham]

On 04/09/14 19:32, fhw...@gmail.com wrote:
> Could you (or anyone) elaborate a bit on the use cases where short
> lived certs are desirable?

See other messages in this thread - it saves a significant amount of
setup time not to have to wait for a response from the OCSP server.

> I'm also wondering what the plan is for handling an expired short
> term cert. Will the user be given a choice of allowing an exception
> or does it get special handling?

What if I say it's treated the same as any other expired cert?

Gerv

[Rob Stradling]

On 05/09/14 10:30, Gervase Markham wrote:
> On 04/09/14 14:25, Rob Stradling wrote:

>> When attempting to access an HTTPS site with an expired cert on Firefox
>> 32, you'll see a "This Connection is Untrusted" page that lets you add
>> an exception and proceed.
>>
>> But when attempting to access an HTTPS site with a revoked cert, you'll
>> see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.
>>
>> Would it make sense to treat expired certs in the same way as revoked
>> certs? (And if not, why not?)
>

> Logically, it does make sense. In practice, revocation has a near-zero
> false-positive rate, whereas expired sadly has a much greater
> false-positive rate. Which is why Firefox treats them differently.

Hi Gerv.

Yes, that is sad.

> It might be good, in the future, to get CAs to guarantee to continue
> providing revocation information for e.g. 3 months after expiry, and for
> those 3 months, we treat as "Untrusted Connection",

Unless the recently expired cert is found to be revoked, in which case
you'd show "Secure Connection Failed" I presume?

> but after that we switch to "Secure Connection Failed". What do you think
> of that idea?

If the false positive rate drops to near-zero by 3 months after expiry,
then I think that could work. However, it would need to work equally
well for both long-lived certs and short-lived certs. Therefore,
short-lived certs would still need to provide revocation info, even if
the browser only uses that revocation info if it encounters the
short-lived cert after its expiry date.

[Gervase Markham]

On 05/09/14 10:47, Rob Stradling wrote:
> Unless the recently expired cert is found to be revoked, in which case
> you'd show "Secure Connection Failed" I presume?

Yes :-)

>> but after that we switch to "Secure Connection Failed". What do you think
>> of that idea?
>
> If the false positive rate drops to near-zero by 3 months after expiry,
> then I think that could work. However, it would need to work equally
> well for both long-lived certs and short-lived certs. Therefore,
> short-lived certs would still need to provide revocation info, even if
> the browser only uses that revocation info if it encounters the
> short-lived cert after its expiry date.

Short-lived certs have different characteristics here, because if
someone is deploying them, we know that they have the infrastructure to
rotate certs quickly. It's not going to be some admin forgetting a
yearly renewal. So I think that we would leave revocation info out of
short-lived certs, but we would switch to Secure Connection Failed after
hours or a day rather than 3 months. Or even go straight there.

Gerv

[Rob Stradling]

On 05/09/14 10:55, Gervase Markham wrote:
> On 05/09/14 10:47, Rob Stradling wrote:

<snip>

>> If the false positive rate drops to near-zero by 3 months after expiry,
>> then I think that could work. However, it would need to work equally
>> well for both long-lived certs and short-lived certs. Therefore,
>> short-lived certs would still need to provide revocation info, even if
>> the browser only uses that revocation info if it encounters the
>> short-lived cert after its expiry date.
>

> Short-lived certs have different characteristics here, because if
> someone is deploying them, we know that they have the infrastructure to
> rotate certs quickly. It's not going to be some admin forgetting a
> yearly renewal. So I think that we would leave revocation info out of
> short-lived certs, but we would switch to Secure Connection Failed after
> hours or a day rather than 3 months. Or even go straight there.

OK. That would work. :-)

[Phillip Hallam-Baker]

On Fri, Sep 5, 2014 at 5:30 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 04/09/14 14:25, Rob Stradling wrote:
>> When attempting to access an HTTPS site with an expired cert on Firefox
>> 32, you'll see a "This Connection is Untrusted" page that lets you add
>> an exception and proceed.
>>
>> But when attempting to access an HTTPS site with a revoked cert, you'll
>> see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.
>>
>> Would it make sense to treat expired certs in the same way as revoked
>> certs? (And if not, why not?)
>
> Logically, it does make sense. In practice, revocation has a near-zero
> false-positive rate, whereas expired sadly has a much greater
> false-positive rate. Which is why Firefox treats them differently.

Which means that expired short lived certs probably need to be treated
differently.

We probably need to mark them in some way as being intended to be
short lived. And we certainly need to fix the problem of getting them
renewed efficiently.

[Hubert Kario]

----- Original Message -----
> From: "Phillip Hallam-Baker" <ph...@hallambaker.com>
> To: "Gervase Markham" <ge...@mozilla.org>
> Cc: "Rob Stradling" <rob.st...@comodo.com>, mozilla-dev-s...@lists.mozilla.org, "Hubert Kario"
> <hka...@redhat.com>
> Sent: Friday, September 5, 2014 2:11:09 PM
> Subject: Re: Short-lived certs
>
> We probably need to mark them in some way as being intended to be
> short lived. And we certainly need to fix the problem of getting them
> renewed efficiently.

I'd say that this is purely CA problem.

Since the short lived certs are supposed to be a replacement for the
revocation checking, using the same key for those certs is not a problem.

As such, the CA may just re-sign the certificate on a daily basis and
publish it in a non-obvious directory (e.g. SHA-1 hash of the certificate
public key) if they don't want to make it easy to compute how many
certificate they issue. Then the server downloads the certificate over
HTTP, FTP, or gets it in email, validates if it matches the key it has,
validates the signature and issuer and then starts serving it to clients.

If you want to use new key for every certificate you'll have to use
Simple Certificate Enrollment Protocol (SCEP), Certificate Management
Protocol (CMP) or something similar.

So it is possible to have a full spectrum between trivial and very complex
as far as certificate re-issuance and management goes. I don't think it
is good idea to mandate one specific implementation over another...

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hka...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[fhw...@gmail.com]

Hi Gerv, you've been busy! 

The cases Jeremy identified (thanks, Jeremy!) are all good problems to address and while I'm not unsympathetic I don't necessarily find them all that compelling. The situations involving network meddling by someone in power is especially troubling and goes beyond what I'm interested in covering in this discussion. 

That said, the case for performance ‎is troubling for a couple reasons. First is that I've seen many times where someone says "(whatever) would work so much better if we could bypass this security stuff". I don't mean to suggest that people who want small cert chains are wanting to bypass security but a practice such as this does open the door for people who might consider such things. So my initial concern is where this might lead, and what protections might be needed to ensure it doesn't go further. 

The bigger problem I have with this, however, really has nothing to do with people who have good server c‎onfigs and are competent server admins. In such cases, we can probably assume there are likely to be fewer mistakes made and thus less of an impact to security. 

My problem is what happens when the cert holder loses control of the private key, no matter what the reason is. Relying on the expiration date is only a partial answer for 2 reasons: 1) a user might choose to allow the expired cert with the compromised key anyway (hence my asking about its treatment); and 2) a short expiry might still be long enough to cause harm. Consider that a phishing site might only exist for 2 days, just as an example. 

So in order to safely proceed with a small cert solution I think we need to flesh out how key compromises can be mitigated.

From: Gervase Markham Sent: Friday, September 5, 2014 4:47 AM To: fhw...@gmail.com; Jeremy Rowley; mozilla-dev-s...@lists.mozilla.org Subject: Re: Short-lived certs

On 04/09/14 19:32, fhw...@gmail.com wrote:

> Could you (or anyone) elaborate a bit on the use cases where short
> lived certs are desirable?

See other messages in this thread - it saves a significant amount of
setup time not to have to wait for a response from the OCSP server.

> I'm also wondering what the plan is for handling an expired short
> term cert. Will the user be given a choice of allowing an exception
> or does it get special handling?

[Phillip Hallam-Baker]

+1

Short lifetime certs don't solve every problem with revocation. But they
allow us to drastically reduce the problem space. That makes applying other
mechanisms viable.

The end goal has to be to reduce the time window of vulnerability to the
time it takes people to respond to phishing sites and other attacks. That
is minutes, not days.

We are not going to get there soon. But that is where we have to aim for.

> *From: *Gervase Markham
> *Sent: *Friday, September 5, 2014 4:47 AM
> *To: *fhw...@gmail.com; Jeremy Rowley;
> mozilla-dev-s...@lists.mozilla.org
> *Subject: *Re: Short-lived certs

>
> On 04/09/14 19:32, fhw...@gmail.com wrote:

> > Could you (or anyone) elaborate a bit on the use cases where short
> > lived certs are desirable?
>

> See other messages in this thread - it saves a significant amount of
> setup time not to have to wait for a response from the OCSP server.
>

> > I'm also wondering what the plan is for handling an expired short
> > term cert. Will the user be given a choice of allowing an exception
> > or does it get special handling?
>

> What if I say it's treated the same as any other expired cert?
>
> Gerv
>
>
>

[Jesper Kristensen]

A short-lived certificate is equivalent to at long-lived certificate
with a stapled OCSP-response, if we assume they have equivalent
lifetimes and equivalent client behavior on expiry vs. revocation.

However a stapled OCSP-response is not fully equivalent to an actively
requested OCSP-response. A client may choose to not support stapling and
always actively request an OCSP-response, if it believes this to be more
secure. By allowing a short-lived certificate to not include an
OCSP-url, CABForum would drop support for such hypothetical client
opinion. That may be OK, but we need to acknowledge it. Should we also
allow the OCSP-url to be omitted from a certificate, if it has must-staple?

Short-lived certificates still have an advantage, even with an embedded
OCSP-url. Clients that support them would not perform OCSP-requests for
short-lived certificates, and compared to stapling, you still save the
entire stapled OCSP-response from the handshake. If both Firefox and
Chrome supports it, you will quickly get to a point where a site would
get the speed advantage for over half its users.

We should consider to treat an expired short-lived certificate the same
as a revoked certificate in browser UI. I believe the reason for
click-through certificate error UI is backwards compatibility. If
browsers never had click-through, the number of false positives would be
far less. Short-lived certificates are rare or non-existent today. If we
can get enough browsers to prevent click-trough for these certificates
before they become widespread, I think it would work. But if only
Firefox prevents click-through, server-operators would just drive users
to other browsers, so this would need to be a coordinated effort.

Before short-lived certificates can become practically usable, servers
need to automatically fetch certificates from CAs. Since browser makers
seem to show the most interest in fixing revocation, browser makers need
to facilitate development and/or adoption of protocols that support
this. Otherwise I fear that nobody else will.

Den 04-09-2014 kl. 12:21 skrev Gervase Markham:
> Short-lived certs are one plank of our future revocation strategy.[0]
> 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).
>
> I've just been reviewing discussions from July 2012 on the CAB Forum
> mailing lists about short-lived certs. There was some significant
> opposition to removing revocation information from short-lived certs at
> the time (although things may be different now, I don't know). I
> personally think much of that opposition was mistaken, but the
> discussion nevertheless did not result in consensus.
>
> How should we approach the issue of short-lived certs? It seems to me we
> can do the following:
>
> 0) Try and get a motion passed to change the BRs to allow short-lived
> certs to not have any revocation information. This would probably
> require us to review the original discussion and make a wiki page
> outlining our proposal and rebutting objections. We may still run into
> heavy weather. We could also discuss it at the face-to-face.
>
> 1) Write an exception in Mozilla's policy that short-lived certs don't
> have to have revocation info. This would likely have no effect, because
> CAs would want to continue issuing to the BRs.
>
> 2) Stop checking revocation information for short-lived certs
> unilaterally. This would result in reduced take-up of the idea, because
> there would be no advantage in other browsers, and one would still need
> to implement all the mechanisms, both at the CA and at the site, for
> frequent cert renewals and deployments.
>
> 3) Configure Firefox to not bother checking revocation information for
> any cert newer than N days. This way, you can "emulate" short-lived
> certs by just reissuing an X-year cert every N days or less. It also
> 'fixes' the clock-skew problem in one direction, because the certs will
> still work for users whose clocks are some way in the future (although
> their browsers would check revocation).
>
> 4) Something else?
>
> Gerv
>
> [0] https://wiki.mozilla.org/CA:RevocationPlan
>

[Gervase Markham]

On 07/09/14 10:25, Jesper Kristensen wrote:
> However a stapled OCSP-response is not fully equivalent to an actively
> requested OCSP-response. A client may choose to not support stapling and
> always actively request an OCSP-response, if it believes this to be more
> secure. By allowing a short-lived certificate to not include an
> OCSP-url, CABForum would drop support for such hypothetical client
> opinion. That may be OK, but we need to acknowledge it.

That is true. However, would such a client soft-fail or hard-fail? If
such a client soft-failed, they aren't actually trying to be more
secure. If they hard-failed, that client would have, as it went around
the Net, all of the problems that hard-failing OCSP-requesting clients
have today, and so may turn out not to be usable in practice.

> Should we also
> allow the OCSP-url to be omitted from a certificate, if it has must-staple?

That was discussed and it was decided No, for two reasons. Firstly, not
all clients support stapling. Secondly, the webserver has to know where
to find the OCSP response in order to fetch it and staple it, and making
that information externally-specified metadata just increases the risk
of the admin screwing up the config.

> Short-lived certificates still have an advantage, even with an embedded
> OCSP-url. Clients that support them would not perform OCSP-requests for
> short-lived certificates, and compared to stapling, you still save the
> entire stapled OCSP-response from the handshake. If both Firefox and
> Chrome supports it, you will quickly get to a point where a site would
> get the speed advantage for over half its users.

As I noted in my original post, the advantages if revocation information
is still required are not zero, but they are a lot less. There are many,
many clients and browsers out there.

> We should consider to treat an expired short-lived certificate the same
> as a revoked certificate in browser UI.

Yes, I pretty much agree with this.

Gerv

[Man Ho (Certizen)]

In an open forum like here, we discuss on standard practice, policy and
baseline requirements so to make browsing the Internet more secure.
Ad-hoc pre-approval process is not a good practice because it probably
has no rules. Moreover, who is going to approve it? Mozilla or members
in this group? Will it become another super "Authority"?

On 9/6/2014 12:27 AM, Ben Wilson wrote:
> Maybe an ad-hoc pre-approval process would work.

>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb...@gmail.com]
> Sent: Thursday, September 4, 2014 1:07 PM
> To: Ben Wilson
> Cc: Gervase Markham; mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Short-lived certs
>

[Richard Barnes]

Coming in late to the party...

This discussion seems pretty wildly off-target to me, at least from a browser perspective.

From a browser perspective, I don't care at all whether certificates excused from containing revocation URLs if they're sufficiently short lived. I can look at the validity interval and make a decision to check revocation or not, regardless of whether the OCSP URI is there or not. In fact, a short-lived cert with an OCSP URI gets the benefit of added speed from browsers that suppress OCSP for short-lived certs, while at the same time working with legacy browsers.

From a CA perspective, though, I can see how this is important, since it lets you reduce the load on your OCSP server, or maybe even get rid of it.

So in units of Gerv's options below, the only action for Mozilla is (2). We could do (0) in addition, or support similar efforts by CAs to get the BRs update to let them out of OCSP obligations for short-lived certs. Honestly, I would prefer if CAs led, since they're the ones that benefit.

--Richard

[Gervase Markham]

On 16/09/14 23:13, Richard Barnes wrote:
> From a browser perspective, I don't care at all whether certificates
> excused from containing revocation URLs if they're sufficiently short
> lived.

>From a technical perspective, that is true. However, if we have an
interest in making short-lived certs a usable option, we have to
consider the ecosystem. CAs will have to do engineering work to issue
(and reissue) such certs every 24 hours, and sites will have to do
engineering work to request and deploy those certificates.

Whether those things are worth doing depends on the gain you get. If the
improved speed is only for a small population of browsers, it is
probably a lot less worth it than if it makes things faster for almost
everyone. The latter is only achievable if it's permitted to remove the
revocation pointers.

I can look at the validity interval and make a decision to
> check revocation or not, regardless of whether the OCSP URI is there
> or not. In fact, a short-lived cert with an OCSP URI gets the
> benefit of added speed from browsers that suppress OCSP for
> short-lived certs, while at the same time working with legacy
> browsers.

A short-lived cert _without_ an OCSP URI also works with legacy
browsers. Unless you are using some other definition of "works"?

> So in units of Gerv's options below, the only action for Mozilla is
> (2).

As I noted, "this would result in reduced take-up of the idea".

> We could do (0) in addition, or support similar efforts by CAs
> to get the BRs update to let them out of OCSP obligations for
> short-lived certs. Honestly, I would prefer if CAs led, since
> they're the ones that benefit.

If this is something we want to be part of our revocation strategy, then
we benefit if we make it attractive to sites and CAs.

Gerv

[Kurt Roeckx]

On 2014-09-17 09:25, Gervase Markham wrote:
> A short-lived cert _without_ an OCSP URI also works with legacy
> browsers. Unless you are using some other definition of "works"?

A browser could perfectly reject a certificate that doesn't comply with
the BR because the required OCSP URI is missing.


Kurt

[Brian Smith]

On Wed, Sep 17, 2014 at 12:34 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On 2014-09-17 09:25, Gervase Markham wrote:
>>

>> A short-lived cert _without_ an OCSP URI also works with legacy
>> browsers. Unless you are using some other definition of "works"?
>

> A browser could perfectly reject a certificate that doesn't comply with the
> BR because the required OCSP URI is missing.

A browser can reject any certificate it wants to. No browsers are
rejecting certificates because the OCSP URI is missing, and if they
were to implement such policies, they'd have to do so in concert with
support for short-lived certificates, unless they are trying to
prevent short-lived certificates from becoming a thing.

Cheers,
Brian

[Brian Smith]

On Wed, Sep 17, 2014 at 12:25 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 16/09/14 23:13, Richard Barnes wrote:

>> From a browser perspective, I don't care at all whether certificates
>> excused from containing revocation URLs if they're sufficiently short
>> lived.
>

> From a technical perspective, that is true. However, if we have an
> interest in making short-lived certs a usable option, we have to
> consider the ecosystem. CAs will have to do engineering work to issue
> (and reissue) such certs every 24 hours, and sites will have to do
> engineering work to request and deploy those certificates.

Changing a server to properly and safely support replacing its
certificate on the fly is a very error-prone and difficult thing to
do, compared to changing a server to properly and safely support OCSP
stapling. For example, when the server updates its certificate, it
needs to verify that the new certificate is the right one. Otherwise,
the updated certificate could contain a public key for which an
attacker owns the private key, and the server would be facilitating
its own compromise by switching to that new certificate.
In contract, with OCSP stapling, an attacker can never replace your
server's public key, and so there is much less risk of catastrophe
with OCSP stapling.

Because of the added risk and added complication of short-lived
certificates relative to OCSP stapling, and because OCSP stapling is
already well-specified and quite widely implemented (though not yet
commonly enabled), it would be better to prioritize shortening the
maximum acceptable OCSP response validity period (e.g. to 72 hours)
and to define and implement Must-Staple, over defining new standards
for short-lived certificates. Those two improvements would have an
immediate positive impact.

Note, also, that browsers already effectively support short-lived
certificates, even without any CABForum or browser policy work. And,
also, I do support defining standards for short-lived certificates; I
just think that fixing OCSP stapling should be a higher priority.

Cheers,
Brian

[Brian Smith]

On Fri, Sep 5, 2014 at 2:43 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 05/09/14 00:06, Brian Smith wrote:
>> Precisely defining a short-lived certificate is a prerequisite for a
>> proper discussion of policy for short-lived certificates. It seems
>> likely to me that short-lived certificates will be defined as
>> certificates that would expire before the longest-acceptable-life OCSP
>> response for that certificate would expire. Then it would be easy to
>> understand the security properties of short-lived certificates, given
>> that we understand the security properties of OCSP.
>
> I strongly want to avoid ratholing on this discussion; if I say "OK,
> let's say for the sake of argument that short-lived is the same as the
> max OCSP lifetime", then someone else will say "but that's still too
> long!" and so on.

I agree, because the maximum allowed OCSP *is* too long, regardless of
whether you want to do short-lived certificates or not.

>> Previously, we decided it was important that we have evidence that the
>> OCSP responder know about all certificates that were issued by the CA,
>> so we made it a requirement that OCSP responders must return not
>> return "Good" for certificates that they do not know about. But,
>> accepting short-lived certificates is equivalent to an OCSP responder
>> returning "Good" for all certificates, whether it knows about them or
>> not.
>
> Is that actually true? I am assuming that if a cert is mis-issued, for a
> few minutes at least the CA will stand by their issuance, and that the
> attacker can obtain a good OCSP response for it with a lifetime of X,
> and staple that response during their attack. So the security properties
> of that are about the same as those for a cert with lifetime X.

Then what was the value in adding requirement that an OCSP responder
cannot return "Good" for an unknown cert to the BRs? We added that
requirement specifically in response to Diginotar. Note that this
requirement has caused Firefox more trouble than anybody, because
Firefox is the only browser that tries to enforce this in a useful
way. Consequently, site stop working (only) in Firefox when the
website replaces their cert from a CA (in particular, StartSSL) that
does not keep their OCSP responder in sync with their cert issuance.
(Search Twitter for "sec_error_ocsp_unknown_cert").

> Hmm... is there some mileage in saying that OCSP responses for certs
> during their first week of existence must have a max lifetime of
> significantly less than for the rest of their lives? That wouldn't
> increase OCSP server load much, but would perhaps mitigate this issue if
> the CA were to discover the misissuance soon after it happened.

There are also reasons for shortening the max lifetime of an OCSP
response well past the initial issuance time. In particular, a server
getting its private key stolen is almost definitely more common than a
CA mis-issuing a certificate, and a stolen private key also requires a
quick response time.

Cheers,
Brian

[Jeremy Rowley]

I agree that we should reduce the validity period of OCSP responses and also that must staple is a high priority. 10 day responses is way too long (although I doubt any CAs are actually doing 10 days).

Mozilla appears to be considering their entire revocation policy at this time, including future projects. Better to work out what is required now rather than make an exception to the policy after the changes are set in motion. I'd support a change on all three issues (even if short lived are the last to be implemented)!

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Brian Smith
Sent: Wednesday, September 17, 2014 2:22 AM
To: Gervase Markham
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On Wed, Sep 17, 2014 at 12:25 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 16/09/14 23:13, Richard Barnes wrote:

>> From a browser perspective, I don't care at all whether certificates
>> excused from containing revocation URLs if they're sufficiently short
>> lived.
>

> From a technical perspective, that is true. However, if we have an
> interest in making short-lived certs a usable option, we have to
> consider the ecosystem. CAs will have to do engineering work to issue
> (and reissue) such certs every 24 hours, and sites will have to do
> engineering work to request and deploy those certificates.

Changing a server to properly and safely support replacing its certificate on the fly is a very error-prone and difficult thing to do, compared to changing a server to properly and safely support OCSP stapling. For example, when the server updates its certificate, it needs to verify that the new certificate is the right one. Otherwise, the updated certificate could contain a public key for which an attacker owns the private key, and the server would be facilitating its own compromise by switching to that new certificate.
In contract, with OCSP stapling, an attacker can never replace your server's public key, and so there is much less risk of catastrophe with OCSP stapling.

Because of the added risk and added complication of short-lived certificates relative to OCSP stapling, and because OCSP stapling is already well-specified and quite widely implemented (though not yet commonly enabled), it would be better to prioritize shortening the maximum acceptable OCSP response validity period (e.g. to 72 hours) and to define and implement Must-Staple, over defining new standards for short-lived certificates. Those two improvements would have an immediate positive impact.

Note, also, that browsers already effectively support short-lived certificates, even without any CABForum or browser policy work. And, also, I do support defining standards for short-lived certificates; I just think that fixing OCSP stapling should be a higher priority.

Cheers,
Brian

[Gervase Markham]

On 17/09/14 08:34, Kurt Roeckx wrote:
> A browser could perfectly reject a certificate that doesn't comply with
> the BR because the required OCSP URI is missing.

It could. If such browsers existed, I agree it would have a negative
effect on the likelihood of success of a short-lived certs plan. But I
do not know of any such browsers. Do you?

Gerv

[Jeremy.Rowley]

I wouldn't be worried about a browser rejecting a cert that doesn't
comply. Instead, I'd be worried about a qualified audit showing
non-compliance. Although Mozilla might not care about that particular
non-compliance, other browsers and partners might.

Jeremy

On 9/22/2014 8:36 AM, Gervase Markham wrote:
> On 17/09/14 08:34, Kurt Roeckx wrote:

>> A browser could perfectly reject a certificate that doesn't comply with
>> the BR because the required OCSP URI is missing.

> It could. If such browsers existed, I agree it would have a negative
> effect on the likelihood of success of a short-lived certs plan. But I
> do not know of any such browsers. Do you?
>
> Gerv
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

> .
>

[keyta...@gmail.com]

Short introduction:
I'm not a member of the CAB forum, since my company neither is a public CA, or a browser manufacturer. I was yesterday informed that under specific conditions I could take part in the CAB forum and will be looking into this opportunity this week. So hope to be able to participate and meet with you in the months to come.

I've been operatoinally involved in short lived certificates since beginning 2007. My company started to develop its short lived certificate secure generation and issuance engine in 2003, and had it operational end 2006.

In my humble opinion when we talk short lived certificates, one needs to first define what is a short lived certificate.

Talking to different companies and (semi) government, they all end up with a different description, ranging from a few days, up to a few months validity even.

In my opinion a short lived certificate, has a validity period equal or less than the time the CRL is updated.
When the standard for a CRL update is 12 hours, than a short lived certificate is valid from 1 second up to 12 hours.

The companies who have embraced the technology we developed tend to agree with me, that a reference to a revocation pointer is useless, when the CRL update time is longer than the time of the longest valid issued short lived certificate.

This leaves the discussion on OCSP. Though OCSP works in theory, practically I have not met many companies who in fact have deployed OCSP in a workable manner. And even those that do, I ask: What is your corporate report policy towards lost devices/smartcards.
They tell me, they need to be reported asap....
When I ask what does asap mean practically, they tell me within 4-5 hours.

Again my argument is: So why not issue a short lived certificate with a validity of 4 hours in that case, so no more need for OCSP?

Back to the initial question: should there be a revocation pointer in the certificate in accordance to current CAB Forum Baseline Requirements?
I would say, no, not when you are working with true short lived certificates.
When working with a different description of a short lived certificate, where validiy is longer than the time it practically takes to update the OCSP/CRL, then yes it should.

However, several applications still require a revocation pointer, simply because they are built around the established requirement of having a revocation pointer. For example for digital signing purposes.

So only for this purpose have we been forced to allow for a revocation pointer in the true short lived certificates our technology makes possible.

Again practically none of my customers make use of revocation pointers, where none of my customers are CSPs, but companies running a private CA.