Hi Thijs, On 05/26/2009 05:51 AM, Thijs Kinkhorst wrote: > I'm not so sure about this. I think you campaign to prepare us for SHA-1 > becoming too weak is definately useful.
Thanks, i'm glad you understand the goal here! > However, caff does not set the > cert-digest-algo for GnuPG anywhere explicitly. We just rely on gnupg's > defaults. Understood; however, i've set cert-digest-algo in ~/.gnupg/gpg.conf (where i would expect to set it), and caff ignores that. I understand technically *why* caff ignores that (it uses its own GNUPGHOME) but i think it should either default to something post-SHA1, or it should acknowledge and somehow adopt a user's stated preferences. > The right solution to this issue seems to me to update GnuPG's > default instead of applying a workaround at the caff level. Are you having > any progress in getting GnuPG upstream to do such a thing? gpg's upstream doesn't seem to be about to change the defaults, fwict, but they've also implicitly declined to outline what specifically would need to change to make them willing to change the defaults for cert-digest-algo: http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025097.html The main rationale given by upstream seems to be that there are clients in the wild that do not support signatures made over digests from the SHA-2 family. Here's my rationale for why caff should change even if gpg's defaults don't change in the near future: * caff (and signing-party) are currently primarily used by free software developers establishing WoT connections to other free software developers. These particular users *do* have access to implementations which can handle certifications over SHA-2 digests. * We will ultimately need a functional WoT even if we discard all certifications made over SHA-1. Users who rely heavily on the WoT (e.g. debian) need this post-SHA-1 WoT to be intact *before* SHA-1 is severely compromised. * it would most likely help gnupg decide to change defaults if there is a demonstrated movement away from SHA-1 by people who can responsibly report interoperability problems that arise from the transition. free software developers are uniquely situated to do this, as they have experience reporting problems and finding the root technical causes. Another way that caff could address this besides changing the defaults is to issue *two* certifications instead of one: 0) an SHA-1 certification which all RFC-4880-compliant clients could read, though it may be considered untrustworthy in the future, and 1) if the certifying key is capable of it, a certification over an SHA-2 digest. Some legacy clients will fail to comprehend this certification, but it will have a longer shelf-life than the earlier certification. This is clumsier to implement in the current GnuPG API, though, since it doesn't automatically allow a second certification on the same key. --dkg
signature.asc
Description: OpenPGP digital signature
