-
Notifications
You must be signed in to change notification settings - Fork 216
Description
IMO our current system for handling certfps is not very useful, in that it offers few advantages relative to the use of a strong and unique password over TLS.
My sense of how client certificates are used in the wild is that typically they get issued by some certificate authority, and then a service endpoint (like Oragono) verifies the client certificate against the CA certificate, checks it against a CRL, and then sets the authorized account name to be some field of the certificate (maybe just CN / common name). This has several advantages:
- Allows multiple certificates per account
- Allows rotation, expiration, and revocation of certificates per account
The account MUST exist in the database as well, i.e., you can't just present an arbitrary valid certificate and have Oragono create an account for it on the fly if necessary. (These accounts could be created by a one-parameter mode of SAREGISTER, i.e., /msg NickServ SAREGISTER user38475 registers an account that has no passphrase and cannot be logged into via a passphrase, only a valid CA-signed certificate.) Reasons:
- We want to have a valid account entry for storing user preferences, etc.
- Revoking access shouldn't require pushing out a new CRL, you should just be able to delete the account and lock them out
TODO: clarify how passphrase-less accounts interact with NS PASSWD.