What does adding a certificate to a digital-signature login protocol get you?
Alice's public key no longer has to be pre-shared — she presents a certificate signed by a CA Bob trusts, and Bob extracts pk_Alice from it.
Setup: Alice has sk_Alice and a certificate (issued by a CA). Bob trusts a root CA, but doesn't need to know Alice in advance.
Login:
- Alice → Bob:
"I'm Alice",Zertifikat (contains pk_Alice). - Bob: validate the certificate (signature, validity period, revocation). Extract
pk_Alice. - Bob → Alice: random
challenge. - Alice → Bob:
SIGN(sk_Alice, challenge). - Bob:
VERIFY(pk_Alice, challenge, signature). OK / NOK.
Why certificates matter: without them, Bob would have to maintain a database of every user's public key, established out-of-band. Certificates outsource that to a CA, so any user with a valid cert from a trusted CA can authenticate to Bob — no pre-registration needed.
Examples:
- TLS server authentication (the inverse direction — server presents cert to client).
- TLS client certificates — banks, government services, enterprise VPNs.
- SmartID, Suisse ID, Estonian eID — national PKI authentication.
Caveats:
- Bob must check the cert is not expired and not revoked (CRL / OCSP).
- The CA's trust is now load-bearing — if a CA is breached, every cert it ever issued is suspect.
- Certificate Transparency logs (since 2016) help detect mis-issuance.
Tip: Most users encounter certificate-based login as their bank's "card reader" (a smartcard holding the cert + sk) — and they don't realise that's what it is.