Re: system-wide crypto policies
On 28/06/13 09:34, Thijs Kinkhorst wrote:
> On Thu, June 27, 2013 22:16, Daniel Pocock wrote:
>> On 27/06/13 21:44, Florian Weimer wrote:
>>> * Daniel Pocock:
>>>> However, are such issues at the discretion of package maintainers and
>>>> upstream, or is it useful to have a uniform Debian approach to
>>>> cryptographic strength?
>>> Keep in mind that RFC 4880 (OpenPGP) hard-codes SHA-1 in several
>>> places, notably for key fingerprints. If there's a uniform strength
>>> requirement, we need some weasel words that GnuPG remains compliant.
>>> It's also unclear if SHA-256 or SHA-512 is stronger, and if either
>>> really is that much better than SHA-1.
>> Just to clarify, although my query was related to the use of this hash
>> in GnuPG, the reason for the email on debian-devel is for the
>> system-wide policy on hashes: which could mean any package (e.g. git
>> uses SHA-1 too, some of the X.509 root certs use an SHA-1 hash)
>> The first question then - do we even need to care, as a project, about
>> being pro-active? Or just leave it at the discretion of derivatives and
>> end-users to make their own policies? That's quite OK as long as this
>> approach is documented. The security page says "Debian takes
>> security very seriously" and some users may ask how we apply that
>> philosophy to SHA-1 given that it is on various alerts.
>> It may be that we say "Some packages include SHA-1 technology and if the
>> attack potential crosses some threshold X the security team will not
>> support them." Then it is up to maintainers and upstreams to think
>> about and start making plans for the future of their packages.
> I think such decisions are indeed best left to individual package
> maintainers as there's in my opinion no one sound advice that works for
> all cases. While moving away from SHA-1 right now might make sense in some
> cases, in others it's still problematic. You name X.509: CA roots are by
> and large not moving away from SHA-1; you name GnuPG: SHA-1 is indeed in
> the standard and signing stuff with non-SHA-1 hashes still leads to
> compatibility issues which make that there's a good case for keeping the
> current default.
Just out of interest, a CA can re-issue their root cert with the same
key pair but a stronger hash. This type of thing has happened before.
> Although deprecation is good, there's also still doubt on where to migrate
> to. Per-package decisions are hence a much more suited approach than
> archive-wide policies.
I agree it is not clear - if there was a clear bug and a clear solution
I would have just filed a bug report.
As it stands, I will probably start a wiki on crypto-strength issues to
start gathering information that is relevant. Then users and
maintainers will have something to refer to when such issues come up in