Re: [openpgp] Regulation of algo deprecation

"Stan Borinski" <stan@futureinfosec.com> Wed, 04 November 2015 10:51 UTC

Return-Path: <stan@futureinfosec.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2FE1B2D0E for <openpgp@ietfa.amsl.com>; Wed, 4 Nov 2015 02:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level:
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ERw-G8JUswQ for <openpgp@ietfa.amsl.com>; Wed, 4 Nov 2015 02:51:35 -0800 (PST)
Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA821B2D0C for <openpgp@ietf.org>; Wed, 4 Nov 2015 02:51:35 -0800 (PST)
Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id C34EE4012E6D1; Wed, 4 Nov 2015 02:51:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=futureinfosec.com; h=from :to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s= futureinfosec.com; bh=ERi/E+dDy2DlFG8gGrq8XKBGjBQ=; b=hgwBwVXw3N 5jqlf3YjbCdyStbuE/7YKJb8JP1/+f0mBPMMvUAICrwjnW1Ry3jlLiTRYAydWCeT 67nz5fU7O+9vNwwJckC8Ftr1IF9MvuIBwh2jh/g5ywQIIgbOIpFTAxyem5mu/Fqe TvsABNbxhad5x3SU2RGx5yszfizBWliFU=
Received: from amtpw5302w8p (dhcp-30-45.meeting.ietf94.jp [133.93.30.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: stan@futureinfosec.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id A5AB54012E6CD; Wed, 4 Nov 2015 02:51:33 -0800 (PST)
From: Stan Borinski <stan@futureinfosec.com>
To: 'Werner Koch' <wk@gnupg.org>, 'Nils Durner' <ndurner@googlemail.com>
References: <563931B6.9050107@googlemail.com> <87bnbauqmu.fsf@vigenere.g10code.de>
In-Reply-To: <87bnbauqmu.fsf@vigenere.g10code.de>
Date: Wed, 04 Nov 2015 05:51:37 -0500
Message-ID: <011d01d116ee$c96f7f10$5c4e7d30$@futureinfosec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQL7Chs280Ho1Y5b18pV4ZRAscJo7wIOX+AHnCdFQ9A=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/4rTidDQq21li-D45KmOFl5zM4_M>
Cc: openpgp@ietf.org
Subject: Re: [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: Wed, 04 Nov 2015 10:51:36 -0000

On Wednesday, November 4, 2015 at 3:16 AM, Werner Koch wrote:
> To: Nils Durner <ndurner@googlemail.com>
> Cc: openpgp@ietf.org
> Subject: Re: [openpgp] Regulation of algo deprecation
> 
> On Tue,  3 Nov 2015 23:14, ndurner@googlemail.com said:
> 
> > 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
> 
> That is just one catalog but there are others.  For the German VS-NfD
(restricted
> level) other rules apply.  And the Russians have a different catalog, as
do the
> Japanese, and the Koreans, ...

This was my general thought when I read Nils' e-mail advocating using
regulation as guidance for deprecation.  I'm surprised he wasn't flooded
with responses.  I don't like this for two main reasons:

1. As Werner alludes to, we'd have to research the regulations of many
different countries.  And which countries are we talking about?... do we
have to come to agreement that we follow the guidelines/catalogs of only a
subset of countries?  This all seems very problematic.

2. If we're just going to rubber-stamp what Germany's Bundesnetzagentur,
USA's NSA/NIST, and others are recommending, then what's the point of *us*
going through the exercise of figuring out which algorithms that we
recommend or require to be deprecated?

Perhaps I'm taking Nil's use of the word "guidance" too strongly.  My view
is that our value as an IETF workgroup comes from an objective view of the
current state, where we judge the security of cryptographic algorithms based
on their technical and operational merits, unbiased by the view of any
governments or their standards bodies.

Regards,
Stan Borinski