search

ircv3 / ircv3-ideas

46 stars 3 forks source link

IRC specific X.509 data fields for user certificates #125

Open GIJack opened 3 months ago

GIJack commented 3 months ago

When authenticating with a certificate, most of the User config data should be put in the x.509 cert.

Fields: username nick, or list of valid nicks(to be authenticated against which one is used with nickserv) real name email (optional) networks - list of networks certificate is valid for.

slingamn commented 3 months ago

What problem would this solve? The client still has to send the nickname, IRC username, and realname via NICK and USER to complete connection registration. Should the server ignore the NICK and USER lines in favor of the X509 fields?

Normally the function of adding X509 fields to the certificate is that they are trusted data signed by the certificate issuer, but that seems largely inapplicable to the IRC case.

If the goal is to simplify client configuration of those fields, then I'm not sure what the value-add is from using X509.

GIJack commented 2 months ago

What problem would this solve? The client still has to send the nickname, IRC username, and realname via NICK and USER to complete connection registration. Should the server ignore the NICK and USER lines in favor of the X509 fields?

That was the plan, or at least stick them in an X.509 cert.

The idea is to move to a user profile that is identified and authenticated by public key, or at least make that an optional part of the spec.

grawity commented 2 months ago

If the certificates are meant to be self-signed, then I don't really see how this is useful – anyone who can use the certificate (i.e. has a private key) can self-sign another variant of the certificate with new fields, so it doesn't protect anything, only adds new complexity to achieve the same thing that's already done.

If the certificates are meant to be issued by the network, then it might work (reminds me of Lotus Notes...) but

  1. I would be strongly against having 'Real Name' as one of the fields – it is not part of the IRC account, and IRC networks shouldn't get into the business of verifying it;

  2. otherwise, such certificates would work as long as each network issues its own, but multi-network certificates (the "list of networks certificate is valid for" part) aren't going to work:

    If the fields in the certificate are supposed to be anything but decorative, then something needs to certify them – you need a CA that somehow validates ownership of those nicknames, and that the networks in question agree to trust it, and I don't see the latter ever happening.

    (Not to mention you now have revocation to solve! For a single network that's easy, it only needs to update its own revocation list, but for multiple networks that's about as likely to work as TLS cert revocation.)