Skip to content

CA-based system for client certificates #414

@slingamn

Description

@slingamn

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:

  1. Allows multiple certificates per account
  2. 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:

  1. We want to have a valid account entry for storing user preferences, etc.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions