Comment 18 for bug 991342

The current spec of KeyPrint (in the repo, not the original draft) is not just keeping it simple, it is punching holes into it and it does not even explicitly forbid the use of chains anyways.

You can't impose such restriction as "only use self-signed certificates" when the text originally did not have such restriction, because it will leave all existing implementations vulnerable. In practice if you do impose such restriction at later date it has no impact in real world scenarios since implementations would still have to code defensively because of old clients and in order to retain the same level of security across the board.

The only restriction you can realistically impose at this point is that clients should use self signed certificates (because that is the status quo), for hubs this ship has long since sailed.

If you want a real world use case, then here is one. Every time hubs peer certificate expires the KeyPrint changes, if they can pin a root or an intermediate certificate with a longer lifetime instead then that problem is no longer as relevant without loosing the benefit of regenerating peer certificates as they are supposed to.

Right now clients out there do not care about expiration of certificates at all (because they can't, with the generous validity period of 10 days dcpp had), but who is to say this will not change. I would even go as far as to say that it should particularly for hub connections at least (which my patch incidentally also addressed, provided correct options are set).

You are essentially saying: "Let's promote bad TLS setup practices so we can keep our code simple" and this shouldn't sit well with anybody (especially for servers, who stick around for a long time).