Service Provider not checking for certificate expiration

Cantor, Scott cantor.2 at osu.edu
Wed Jul 21 13:31:38 UTC 2021


On 7/21/21, 9:10 AM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at shibboleth.net on behalf of rullfig at uic.edu> wrote:

> The cat's out of the bag - it doesn't take very long to get access all the information. By the time you find out
> you should assume it's all been accessed and compromised. I don't see how a key rollover offers any
> protection whatsoever.

Nor do certificate expiration or offline CRLs.

OCSP was never part of the PKIX picture until later, at which point it had turned a deliberately offline and non-real-time system into an online system that metadata can also emulate (i.e., don't cache and check for updated metadata every time and live with the availability limitations).

Also, this isn't TCP over TLS. There is no hostname binding defined such that a certificate can be associated with an entity without...you guessed it, metadata (or equivalent) again, or creating certificate requirements no commercial issuer would satisfy.. So PKIX is neither necessary nor sufficient to solve the problem SAML has. Things that are neither necessary nor sufficient, and are also possibly the single hardest, worst-implemented technology ever devised, are a bad fit and I stand by the decision to reject it.

I would add that the same code bases that don't honor metadata frequently don't honor certificate expirations or rely on revocation either. They simply do nothing. We didn't do "nothing".

I would also add that OIDC relies chiefly on bare keys.

So I am entirely comfortable with what I did and why I did it.

-- Scott




More information about the users mailing list