ircv3-specifications icon indicating copy to clipboard operation
ircv3-specifications copied to clipboard

OOB distribution of cert fingerprints

Open attilamolnar opened this issue 9 years ago • 2 comments

One idea: as a network generate a CA, include the fingerprint of it in the irc:// link and sign the certs of all your servers certs with the CA.

Clients can possibly preload the fingerprint of a network's CA.

attilamolnar avatar Feb 04 '16 12:02 attilamolnar

Any CA must have either very short certificate lifetimes or a revocation mechanism (CRL/OCSP) and you'd also need a way to change the network CA.

You don't need a network CA to meet this requirement, it's already supported by the DNS: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

_6697._tcp.irc.example.com. 60 IN TLSA 3 1 2 (
                                  316E3DDAD4AF309C8FA0479277E31FCAE7BC1819AA80
                                  16C3BA5CD7E6634297380281143301406ECA847251B8
                                  74E914BA800A6DBC98450920EFEA7BE6B12D21EF )

The only missing part is currently practical support in TLS libraries to allow clients to use it: https://github.com/weechat/weechat/pull/121

This can also be used by clients connecting to plaintext ports. If there are any TLSA records for port 6667 then it must require STARTTLS to continue.

nomis avatar Feb 06 '16 10:02 nomis

Clients could always implement DANE/DNSSEC, that's nothing new and that's not what this ticket is about. Some people dislike the centralized model of the standard root CAs, and, without getting into details, the same kind of people argue that DANE isn't any better regarding centralization.

This is about pushing the fingerprints elsewhere, like the website of the irc network. That website might have a proper certificate signed by a standard root CA (it's slightly easier to set up for web servers), or it might use pgp or whatever else.

dequis avatar Feb 06 '16 13:02 dequis