Marius Bakke <mba...@fastmail.com> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Leo Famulari <l...@famulari.name> 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? Ludo’.
