Ludovic Courtès writes: > Marius Bakke skribis: > >> Ludovic Courtès writes: >> >>> Leo Famulari skribis: >>> > > [...] > >>> Initially, I didn’t want to have ‘nss-certs’ in ‘%base-packages’ or >>> anything like that, on the grounds that the whole X.509 CA story is >>> completely broken IMO. I wonder if we should revisit that, on the >>> grounds that “it’s better than nothing.” >>> >>> The next question is what to do with foreign distros, and whether we >>> should bundle ‘nss-certs’ in the binary tarball, which is not exciting. >>> >>> Alternately we could have a package that provides only the Let’s Encrypt >>> certificate chain, if that’s what Savannah uses. >>> >>> Thoughts? >> >> If the private key used on https://git.savannah.gnu.org/ is static, one >> option would be to "pin" the corresponding public key. However, some LE >> clients also rotate the private key when renewing, so we'd need to ask >> SV admins. And also receive notices in advance if the key ever changes. >> >> Pinning the intermediate CAs might work, but what to do when the >> certificate is signed by a new intermediate (which may happen[0])? How >> to deliver updates to users with old certs? >> >> See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and >> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning >> >> ..for quick and long introductions, respectively. >> >> [0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450 > > All good points. Well, I guess there’s not much we can do? I think pinning the public key could work, if the Savannah administrators are aware of it. But we'd need a reliable fallback mechanism in case the private key needs to be updated. I think having a separate 'le-certs' package that can verify the Lets Encrypt chain sounds like the easiest option. Presumably new intermediates etc will be known well in advance.