[openpgp] Regulation of algo deprecation

Nils Durner <ndurner@googlemail.com> Tue, 03 November 2015 22:14 UTC

Return-Path: <ndurner@googlemail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C05F91B2B00 for <openpgp@ietfa.amsl.com>; Tue, 3 Nov 2015 14:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CJhQmikAbIOX for <openpgp@ietfa.amsl.com>; Tue, 3 Nov 2015 14:14:24 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC631B2B03 for <openpgp@ietf.org>; Tue, 3 Nov 2015 14:14:17 -0800 (PST)
Received: by wmec75 with SMTP id c75so98502544wme.1 for <openpgp@ietf.org>; Tue, 03 Nov 2015 14:14:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=W6EkCGgiHPQ4uIxM5CaObyCoIZU1qNmZOOfeoeqDV0U=; b=i4WEkJj9qil96mYzgzzM43yC9d0ectxoW2KtkAg1Tcoj2T9pry3DurRzzCJvugQ+jY qTFlWgMrkF9qDvRJdNJ39O316/bH73R6fhoLLne8QVuYzwlVSyjTi9BjmOnzS5BmyT62 j7Hms5EVqF4JblYKN1OWVl4ndUyMQ0cZjJqwyXCUeRrWUgxcRSrF8/TxsREugVMp62Av gNc3e6qVaqAL9jqwvwsHY2tIW1GNY5uaaZO6WI6nlUOFz4gus3/vVbfjEPd9C4mrsGSk 61VWaWOpe0uHiowSS/kWVJpBdBjOUV7/Yx6XkBBKzl7VZ1DqlJEvPzdl4dl806RWX2Lf kbjQ==
X-Received: by with SMTP id e138mr20928754wma.69.1446588855910; Tue, 03 Nov 2015 14:14:15 -0800 (PST)
Received: from [] (x4db00818.dyn.telefonica.de. []) by smtp.googlemail.com with ESMTPSA id 20sm25448227wmh.8.2015. for <openpgp@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2015 14:14:15 -0800 (PST)
From: Nils Durner <ndurner@googlemail.com>
X-Enigmail-Draft-Status: N1110
To: "openpgp@ietf.org" <openpgp@ietf.org>
Message-ID: <563931B6.9050107@googlemail.com>
Date: Tue, 3 Nov 2015 23:14:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/NARWDRFxoEeng52WMJmzGk_NEG0>
Subject: [openpgp] Regulation of algo deprecation
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 22:14:25 -0000


I would like to elaborate on why I feel that algorithm deprecation
should also be guided by regulations. For Germany, the algorithm catalog
for Electronic Signatures[0] issued by the Federal Network Agency,
dictates that
> SHA-1 and RIPEMD-160, respectively, are suitable only for verification
> of qualified certificates until the end of 2015.

I feel that implementations should help users use crypto correctly - and
incorrect use also includes use of methods deemed insufficient by law,
IMO. IANAL, but repudiability based on algorithm choice should be
prevented against. Concrete example: a particular mail sent by Alice is
not considered legally binding because Bob failed to realize that the
algorithms used by Alice had already expired by regulation at the time
she sent the mail. In order not to burden implementers with such
considerations, I feel we should reflects this in the RFC already -
perhaps as RECOMMENDATIONs so that implementations may still provide a
--force parameter for anyone who exactly knows what they are doing or
just don't follow the legal canon (if there is one, I think this would
need some further research).

Responding to Werner's concern that, following this line of thought,
only Brainpool curves could be used: I don't see why. The 2014 version
of aforementioned catalog[0], as well as the 2015 draft (dated
28.10.2014), merely recommend Brainpool, but don't require it. For the
US, NIST naturally recommends NIST curves[2], but I don't see a
restriction to just P-384 there either. At any rate, I would just make
it RECOMMENDATIONs, not MUSTs - except for cases like MD5 where there is
general consensus for other, actually technical, reasons.

What do others think?



[1] https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml