Impact of Reduced TLS Certificate Lifetimes on CA-Signed SAML Certificates

[Peter Schober]

Wei Dai via users <users at shibboleth.net> [2025-05-23 16:44 CEST]:
> I'm asking from an SP perspective, as we are occasionally requested
> by customers to issue SP certificates following their policies.

Unless we're talking about multitenancy how could do those customers'
policies make prescriptions for *your* certificates? Your service is
your service and your keys are your keys.

(The customer/IDP is of course free to determine that your
certificates are not up to its own standards and decide to end its use
of your service. If that's a realistic scenario -- which I find
unlikely given that the big publishers today enjoy de-facto
monopolistic powers over their customers -- you could still charge a
hefty premium to allow the customer/IDP to dictate the SP's
certificates. So much that the customer/IDP may start feeling a little
more flexible about this specific issue.)

> As mentioned in the document below, a German federation has started
> requiring SAML certificates with a 3072-bit RSA key. Are any other
> federations or institutions planning to implement this policy? Any
> comments? https://doku.tid.dfn.de/de:certificates

While RSA 2k bit keys are still considered secure for common uses in
2025 CE, AFAIK, I don't think it's excessive asking for 3k bit RSA
keys. Migrate to a 4k (4096) bit RSA key and be done with it for a
while, possibly until RSA itself needs to go.

> Regarding using a long-term certificate, what's the recommended
> period and is there a standard? The default Microsoft Entry ID IdP
> certificate is valid for 3 years, while another major IdP vendor
> issues a 10-year certificate.

I would have said 10y or 20y but there will be federations that will
not let you register entities with certificates with longer validity
periods. From the aforementioned DFN-AAI wiki
https://doku.tid.dfn.de/en:certificates in the English version:

> Self-signed certificates may be used if they are not valid for
> longer than 39 months.

(I find that somewhat hypocritical because those same federations will
happily republish your service to their members if it comes in via
eduGAIN, registered by another federation. Maybe it's time to stop
being a member of every academic federation out there and start doing
this only via eduGAIN. That would help avoid conflicting requirements
for your service's certificates from different federations, at least.)

Also, since we're talking certificates, I'd advise you to only ever
change the private key when (1) the technology/key-size/algorithm or
(2) the specific key itself is no longer considered sufficiently
secure, and just change the certificate (i.e., re-wrap the existing
key into a new certificate with a new expiration date) in all other
cases.
That allows those with non-broken software (we're on the Shibboleth
mailing list here, after all) to skip any key rollover steps (it's not
actually a key rollover when the key remains the same) and simply
replace the existing certificate with the new one.
One can easily determine that the public key (modulus, for RSA) hasn't
changed and forgo any longwinded rollover ceremonies, then.

-peter