[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Tobias S. Josefowitz tobij at opera.com
Tue Aug 27 13:31:13 MST 2019


Hi Dmitris,

On Tue, 27 Aug 2019, Dimitris Zacharopoulos (HARICA) wrote:

> On 27/8/2019 1:32 ?.?., Tobias S. Josefowitz wrote:
>>
>>  OCSP stapling has, in many ways, functional equivalences to extremely
>>  short-lived certificates that are automatically renewed.
>
> OCSP stapling from a site operator's perspective is a "set it and forget it" 
> option. The software will automatically fetch a new OCSP response when the 
> previous response expires.

My point exactly! In the future, automation should and probably will 
enable a similiarly seamless experience for operators regarding 
validation, renewal and possibly deployment across the board. In fact, the 
majority of systems currently serving certificates already have this 
option available, and it would be for the benefit of both operators and 
browser users for this to become available on all remaining platforms as 
well.

>>  All of these mechanisms, especially if used to reach 100% secure
>>  revocation, fundamentally change the nature of a certificate from
>>  something that on its own could vouch for the identity of a site to (yes,
>>  hyperbole) somewhat of a second factor in whatever online mechanism is
>>  chosen for revocation. One might even say to rely on revocation means to
>>  make certificates less certificate-y, maybe even to the degree where one
>>  might ask: If we talk about an online, realtime component - do we even
>>  need X509 certificates to begin with?
>
> Revocation was always part of the X.509 specification, RFC 5280 and of course 
> RFC 6960 which are normative requirements for CAs according to the Baseline 
> Requirements. CRLs are not mandatory for end-entity certificates according to 
> the BRs but OCSP is.

Completely independend of how and when revocation was introduced, from my 
(a browser?) perspective, the one main thing it ever *reliably* achieved 
was to remove the business value from mis-issuance, both for CAs and for 
end-entities that would actively pursue to get a certificate mis-issued 
for some reason. OCSP and CRLs could be blocked by an attacker on the 
path, and thus work most reliably with no actual attack present. This will 
make (intentionally) mis-issued certificates reasonably useless, but 
leaves plenty of security-relevant cases uncovered.

> You are taking for granted that "the goal" is to reduce the lifetime of 
> Certificates to 13 months and then trying to support how it can be achieved. 
> Then you are trying to provide arguments how "easy" or "difficult" it is for 
> some site operators to replace certificates, keeping the ecosystem "hostage" 
> to this "improvement". HARICA mostly cares about the "why" and what is the 
> benefit for Relying Parties and the ecosystem at large. With the 
> justification provided, our engineering and security experts don't see any 
> significant security improvement.

I do not mind your summary too much, as indeed I am exploring a 13 months 
lifetime somewhat in the context of the less-than-stellar operator 
reception here. As to the "why", esp. in the sense of "why could one 
possibly want that", I think the motivation for SC22 gives some pretty 
good starting points. And I will emphasize that, yes, revocation does not, 
probably should not and maybe even cannot address all of the issues 
brought forward there.

However, while under some perspective maybe you could say "I" am "taking 
the ecosystem hostage", I certainly do not see in how far a 13 months 
certificate lifetime would be *unethical*, *illegitimate* or even further 
to "my" or Opera's "personal" gain. If it were not extremely unproductive, 
this is where you could find arguments about how some device manufacturers 
and/or site operators take the ecosystem hostage by not being able to 
conveniently deal with a 13 months certificate lifetime.

> More specifically:
>
>  * Relying Parties will not even notice the change of Certificates as
>    they mostly care about accessing the web site. The renewed
>    certificate is not a detectable change for them.

... in some, no, *the* unproblematic case, things will keep working as 
before?

>  * For Domain Names that don't change owners, there is zero security
>    benefit for the ecosystem. We don't have the numbers but most
>    Domains should be more frequently renewed than abandoned; at least
>    the most popular ones that matter to the vast majority of Relying
>    Parties.

You do realize that this is a weakest link problem and that pointing out 
strong links does not really attest to the strength of the whole?

>  * Agility is "nice to have" but at what cost. For the current proposal
>    (to reduce lifetime to 13 months), in HARICA's opinion, it is "zero"
>    for Relying Parties, "very low" for CAs, "significant" for site
>    operators. At the same time, the security improvement for Relying
>    Parties is "zero" as well. The only party that might gain some
>    security improvement is a Domain owner that recently purchased a
>    previously-owned Domain, that will reduce the risk-factor of the
>    previous Owner maintaining a valid certificate for a site that will
>    probably have already changed DNS and is directed to a different
>    server. That's the only reason why HARICA focuses on Domain
>    re-validation because we can see some real benefit. Replacing
>    perfectly valid/compliant certificates without any security
>    compromise, seems unnecessary.

The security of a domain owner of a recently transferred domain cannot be 
viewed separately from the security of relying parties, but in fact while 
"fresh" domain owners are only threatened in actuality, relying parties 
are threatened in potentiality, which makes this a weakest link issue. 
That you would claim that relying parties would have zero security gains 
from this surprises me.

When you say the impact for site operators is "significant", I do not 
challenge that many site operators are legitimately under the impression 
that it would be. I do however challenge that it would turn out to be such 
a big problem as they expect, and given that apparently only 6% of 
existing certificates are even affected, it becomes even harder for me to 
believe that a 13 months lifetime would lead to certain doom.

>  * Applying new validation rules and checking Domain control annually,
>    reaches the same goal as SC22 without the need for site operations
>    to install a new certificate. So in case a validation method is
>    deprecated, it can no longer be used when the certificate is
>    re-validated, even though it was issued with a deprecated
>    validation. So unless the certificate is re-validated using a valid
>    method, it would have to be revoked.

I am certainly in favour of this, i.e. independent of whether 13 months 
certificate lifetimes will turn out to be the new thing or not. However I 
will emphasize again that revocation is not as sharp a sword from my 
perspecitve as it seems to be from yours.

> I totally agree with your last paragraph about the device vendors and we 
> see some progress being made, but it's slow. Still, though, we must 
> focus on the "reasons" to replace a perfectly validated/compliant 
> certificate.

If anyone can think of any other options here to somehow drive, facilitate 
or nurse improvements regarding these device issues, I would also 
(presumably) be very much in favour, also independent of whether 13 months 
certificate lifetimes will turn out to be the new thing or not.

Tobi


More information about the Servercert-wg mailing list