[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Tue Aug 27 00:25:34 MST 2019

Hi Tobi,

On 27/8/2019 1:32 π.μ., Tobias S. Josefowitz wrote:
> On Mon, 26 Aug 2019, Dimitris Zacharopoulos (HARICA) via Servercert-wg 
> wrote:
>> HARICA does not agree with further reducing the lifetime of TLS 
>> Certificates as it creates unnecessary burden to site operators. If 
>> the main problem we are trying to solve is Domain Validation and the 
>> fact that some domains are "changing owners", thus putting at risk 
>> the new Domain owners as BygoneSSL demonstrated, we should look for 
>> alternatives rather than having millions of site operators replace 
>> millions of Certificates at a shorter timeframe.
>> Certificates are used in far more systems than I could possibly list. 
>> Routers, modems, cameras, scientific equipment, proxys, are just to 
>> name a few that have zero (or close to zero) support for automation 
>> in certificate renewal. We could try to disconnect the Domain 
>> Validation part from the Certificate Installation part. The Domain 
>> Validation part is usually done via alternative channels and are 
>> easier for site operators to handle. Perhaps we have discussed this 
>> before but we could add rules in the BRs to re-validate Domain Names 
>> more frequently, like every 12 months. If the Domain is not 
>> re-validated within 13 months, the Certificate MUST be revoked 
>> (leaving 1 month "grace period" for reminders to be sent to the 
>> Domain owner).
>> The fact that revocation doesn't work for some browsers is not (IMHO) 
>> an excuse for requiring millions of site operators to replace 
>> certificates in these "admin unfriendly"environments, every year, 
>> just to check if the site is still owned by the same 
>> individual/organization.
> In some sense, 100% secure revocation (from the browser perspective) 
> involves finding out if the certificate presented by a server is still 
> valid at the *then-current specific point in time*, and would require 
> the browser to reject the certificate presented if it cannot receive 
> such confirmation in pretty much real-time.
> For OCSP this means to actively ask, for CRLs this means to make sure 
> CRLs present at the client are up to date (by actively asking), update 
> if not, and then to verify the certificate presented is not on the 
> relevant CRLs.
> In a 100% secure revocation scenario, both mechanisms require remote 
> network services to be queried and results received and verified to be 
> correct.
> 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.

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

> Now, 100% secure revocation is obviously quite a strict requirement 
> compared to a 13 months certificate lifetime; and nobody has really 
> suggested this anyway. Looking at this hypothetical scenario does 
> however hint to me that for browsers to rely much more on revocation 
> than they do today may have far-reaching implications for the ecosystem.
> In comparison, how much does asking operators behind the 6% of 
> certificates with a currently greater than 13 months lifetime (as 
> according to Ryan) to renew more often actually burden them? I fully 
> understand few operators will be *excited* by the prospect, or even by 
> not having the option, and as demonstrated, there can be strong 
> reactions from site operators.
> But then really, how hard can it be? At most twice as hard as currently.
> The amount of organizations and individuals that will actually be hit 
> hard by the reduced lifetime, if it comes to pass here or is enforced 
> some other way, especially in ways that are not remedied by changes in 
> process and approach will be limited. This group will presumably 
> mostly consist of those that operate devices/products that make it 
> unnecessarily burdensome to replace SSL/TLS certificates.
> Having such devices/products hold back the entire ecosystem could at 
> best be described as tragic. In addition, for devices that really make 
> it hard to properly and swiftly manage SSL/TLS certificates, one would 
> think that they probably have other issues as well, I would assume one 
> does not generally make devices or products that require special 
> persuasion to update certificates but will have good and easy 
> processes for applying firmware updates. Futher, I doubt such devices 
> will frequently be supplied with firmware updates. That allegedly so 
> many of these are operated with publically trusted certificates - 
> which implies some might need to be globally reachable - is worrying 
> as well.
> I see no mechanism that we would have available to cause the producers 
> of such devices/products to make updating SSL/TLS certificates less 
> problematic in the future (so that we could adopt a 13 months lifetime 
> at reduced operator cost), and to overall improve the overall security 
> properties of their devices/products that would not burden the 
> operator of such devices/products.
> As stated above, SC22 will probably put a small amount of operators 
> into a situation that will be tricky for them, arguably at no fault of 
> their own. It will however also clearly generate market pressure that 
> will lead to devices (and other products) to have better management 
> options for SSL/TLS certificates in the future.
> Tobi

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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/e870f8a5/attachment.html>

More information about the Servercert-wg mailing list