I propose that a group known as the "IRCv3 Security Council" is created.
This group is a separate part of the IRCv3 effort, will have their own section on the website just as the IRCv3 Working Group page is being split off from the landing page, and for most intents and purposes act independently of the IRCv3 Working Group.
Rationale: The traditional CA model has, widely, not worked with IRC today. Large portions of IRC networks out there today use self-signed certificates, and disabling certificate verification or otherwise working around the certificates not validating using traditional methods is fairly common.
This proposal would allow the creation of certificate bundles and revocation lists controlled by the IRCv3 Security Council, which when used by clients (instead of the traditional CA roots provided by operating systems) should solve the majority of these issues for IRC users and network operators.
The IRCv3 Security Council is chartered to manage and investigate the security mechanisms currently used by IRC and the ones that should be used in the future. This includes but is not limited to ideas such as certificate preload lists, certificate bundles, and overall TLS architecture as it applies to the IRC protocol and typical IRC networks.
Members of the IRCv3 Security Council should aim to improve the security of the IRC protocol and improve the security experienced by IRC users. They should do this through investigating and proposing extensions with the IRCv3 Working Group, as well as by suggesting other best practices documents and resources to be created and/or maintained by the Security Council or the Working Group.
[this section is to be decided and deals with who should be a member of the security council, bringing new people onto the council, and removing people from the council]
The #example-sc-chan channel at irc.freenode.net is the main public space for the Security Council. This channel is publicly-accessible, but discussion may be temporarily limited to members of IRCv3-SC if deemed necessary by the council.
The IRCv3 Security Council may have discussions on their IRC channel on various issues around IRC security and TLS architecture. Important points brought about by these discussions and issues which must be revisited may be made into issues on the IRCv3-SC Github repository.
These are resources which the IRCv3 Security Council will maintain and provide for the benefit of interested IRC clients and servers.
[the methods of distributing and ensuring these lists are up to date on clients, ie through preloading and clients retrieving new lists or something to that effect, is to be decided on]
The IRCv3 Security Council will maintain the IRCv3-SC certificate bundle, provided and intended for use by IRC clients in their verification of TLS certificates presented by servers. This is intended to be used in place of the typical root certificate(s) provided by OS vendors.
Large IRC networks may sign all of the certificates provided by their servers are signed by their own CA (ie, a 'certificate authority' that they create and manage). They may then propose to get their root certificate added to the IRCv3-SC bundle in place of signing their certificates with one of the existing roots in the bundle.
Along with the certificate bundle, the IRCv3 Security Council will maintain the IRCv3-SC certificate revocation list. This is a list of serial numbers of certificates -- those provided by or signed by the IRCv3-SC certificate bundle -- which should no longer be considered secure by IRC software.
Certificates should only be accepted into the IRCv3-SC certificate bundle if the council agrees that the certificate, and by extension the network administrators or group that runs the certificate, is trusted. Deciding this is a detail that is to be worked out, but will likely revolve around some majority of the IRCv3-SC members agreeing with adding the given certificate.
Certificate pinning should be investigated, and if it is possible and implementable by clients, we may investigate a reduced-trust pinned list of certificates that we maintain.
To ensure smooth operations of the security council, we request that:
- Participants assume good faith from other participants. Members have full moderation privilege over the council resources and may make moderation decisions if one or more members is unable to assume good faith.
- Participants do not use social media aggregators to “bomb” security council resources because they do not personally agree with a change being made.
- Participants maintain a respectful and professional atmosphere. This means no use of coercive threats to force cooperation.
- Participants refrain from soapboxing on the IRC channels. If there is an issue that needs that level of discussion, a bug or pull request should be filed and discussed on the tracker.