From nobody Thu Sep 17 08:46:58 2015 Return-Path: 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 34DF61ACE64 for ; Thu, 17 Sep 2015 08:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 GXj24-HRYmAy for ; Thu, 17 Sep 2015 08:46:55 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BDCB01ACE37 for ; Thu, 17 Sep 2015 08:46:49 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 96462F984 for ; Thu, 17 Sep 2015 11:46:42 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EE9661FF4D; Thu, 17 Sep 2015 11:46:42 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 17 Sep 2015 11:46:39 -0400 Message-ID: <87twqt121s.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Should we try to meet in Yokohama? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 15:46:57 -0000 --=-=-= Content-Type: text/plain IETF-94 is coming up in November [0]. If we want an in-person meeting there, we need to ask for it by tomorrow. Are enough OpenPGP WG participants planning to attend that it makes sense to schedule an in-person meeting, or should we stick to the list for this round? Feel free to mail me off-list if you have plans to be in yokohama but don't want to advertise them on-list. I'm currently still unclear on whether i'll make it to the meeting myself. The mailing list has been mostly silent this past month (possibly due to people being offline for the summer?) I plan to poke people about their committments from IETF-93 shortly to try to get things in action again, but if you want to follow up here without my poking you directly, that would also be fine :) So: does anyone think we need an in-person meeting in Yokohama? --dkg [0] https://www.ietf.org/meeting/94/index.html --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJV+uBgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcdDAQALTbeM09ZaWddgMQ/g9dmLuf t1hMx/7T5FoAwpqSRKfu24NzULtJG/VsG/5zJ76JDIQd4obfaadrT0r/yMre7tXu kJwMiSEwZG//fYKPRq+FFJxuA1mJjy0wLagCjDRZWDejlKq1wTS+UM57iWMBNhSm o2EV2KD7zwhH5hx3U+n333duV+vthtB20kScDVH5DMvm/ToDOdvAAgn64bXBx1KC shuEGEgcBkak5jOvrcZtNVKRW1uQz6ExkRV/vZxyjTG3zljG7CbcVX2bBZ2IpGS5 6H2fjV8YTlw1AawF+Gbz5YAV/opGIqMYCl4I4VY35t0aaq8oqvYwMjNO4MWhrQm4 VfPO83HVOX1k+qEAHe/ugtT0CIyaUTCvZIzl3IJRpWjI/NOgumu+HnEYb54rq/Ac g53GPzC4oMQczsmtjV+NED3OXQDoBvTsQZIx1nAFgr9h6NbKl066u5LJJoHzJnNj dMSV/BIode2/f+YUaCvzSI+pNaOxI96hxaKmazwLQeGawHHdtMLkX7MFHOFOtzyg 8axhyK7PRHXWFr4JCRrbLKvme0loh0AWt9TzzPAZ0RoV7VZMhEE5F3opTssostYy ICiqfBWxh6fm1eO4KDFnMpSGz9YYcCbrC3W5MeQJfKAi+U5WsSRcOtFEAzPS5ntv 5Bie0gz/tKnCcbrcigRa =HWh9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 17 11:45:56 2015 Return-Path: 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 C57A21B30F8 for ; Thu, 17 Sep 2015 11:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 ZMrkex0SJ0Jk for ; Thu, 17 Sep 2015 11:45:53 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814001B30D8 for ; Thu, 17 Sep 2015 11:45:53 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZceBr-0005fG-PG for ; Thu, 17 Sep 2015 20:45:51 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zce84-0006Gn-J9 for ; Thu, 17 Sep 2015 20:41:56 +0200 From: Werner Koch To: IETF OpenPGP Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: IETF OpenPGP Date: Thu, 17 Sep 2015 20:41:56 +0200 Message-ID: <878u84zy4r.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 18:45:55 -0000 Hi! I'd like to get opinions on one specific aspect of a new fingerprint format in 4880bis. In the past we bound the fingerprint format to the key packet version: v3 keys used MD5 and v4 keys SHA-1 fingerprints. This gained us the benefit of having a bijective connection between fingerprint and key. For X.509 and ssh (OpenSSH), there has always been an uncertainty which fingerprint to use because there is no well established standard for it. For a long time MD5 was used but then some users switched to SHA-1, and meanwhile SHA-256 is also seen more often. These fingerprint formats can easily be distinguished by their length and thus the format itself is not a problem. However, if you ask users to verify the fingerprint of a certificate and you given them SHA-1 but they have only access to the MD5 fingerprint things starts to get wrong. Complicated (human) reasoning about the identity of a certificate needs to be done. With OpenPGP is is easier: The specs say that a key is described by one and only one fingerprint. There is no way to assign a different fingerprint to the the same key. If we want to introduce a, say, SHA-256 fingerprint, the straightforward way is to define a v5 key packet format which will be identical to the v4 format with the exception of the packet version number (and maybe rules on what algorithms to use with a v5 key) [1]. Such a v5 format also means that it is not possible to switch to the new fingerprint format for existing v4 keys. The v4 keys would continue to use SHA-1 fingerprints. Some people claim that a SHA-1 fingerprint might soon be problematic due to collision attacks. If we assume that this is indeed the case, the question is whether switching to SHA-256 for the very same key does actually help: The mix of different fingerprints for the same key will lead to the same confusion we have seen with X.509 and ssh. Further, if there is a need to switch to a stronger fingerprint format for the same key, should the user not also assume that the use of the key has already been compromised and it is time to create a new key? Given that we are expecting to soon switch from RSA to ECC for improved security and that the current base of OpenPGP implementations supporting ECC is quite small, I would recommend not to allow a second fingerprint format for v4 keys but to bind a new fingerprint format to a v5 key packet version. Shalom-Salam, Werner [1] I recently talked to the guy who asked a long time ago for a hard expiration time in a future key packet format. He is not anymore interested in this and thus other technical changes to the key packet format a not needed. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Sep 17 15:05:38 2015 Return-Path: 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 0EAC01A885F for ; Thu, 17 Sep 2015 15:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 UgKirC_RRNYI for ; Thu, 17 Sep 2015 15:05:37 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C0B1A8821 for ; Thu, 17 Sep 2015 15:05:36 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 719EC6026B for ; Thu, 17 Sep 2015 22:05:36 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=Q+3gptW1p/y1t+Pi1p8J2hLMcw0B7/SKbq4/P+mmoP8=; b=bUMVwG2JszZaB9/ho4JmH7YqNM3fOx25bhpKSW+AmLc7qGv6bmpCZ2l6eKKqeDKfk18VB+vLKAbNTgfuC52ZRrQRWgaSEp/9EzIoOWt3NhI3zUM3I8jcQxEYzOenpp9LAQk1F9ad2h2Q5ONneM8A2YoG9gs6ldaxOey6n0qsd1x2O6gyPgKUK6XW79ApWA+VB/NfB3+pzmZUupmgOoj6ZHYn8YODqjqlD180bWH6qOuSabSvi5KrqTqT8/KUu3FkssCmwyzyOo1NBrS1JUIpDFwCFdFoBc4yxkMUm3d+jBI6MA45Xt6HnFIb3v3LLlocVl9MS2GD9xtzlI5hdQ1gkA== Received: from smtp.hushmail.com (w3.hushmail.com [65.39.178.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS for ; Thu, 17 Sep 2015 22:05:36 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 574C4C035D; Thu, 17 Sep 2015 22:05:36 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 17 Sep 2015 18:05:36 -0400 To: openpgp@ietf.org From: vedaal@nym.hush.com In-Reply-To: <878u84zy4r.fsf@vigenere.g10code.de> Content-Type: multipart/alternative; boundary="=_06b944fe06bdebc164b5fa5ded257e8d" Message-Id: <20150917220536.574C4C035D@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 22:05:38 -0000 --=_06b944fe06bdebc164b5fa5ded257e8d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" On 9/17/2015 at 2:44 PM, "Werner Koch" wrote: Some people claim that a SHA-1 fingerprint might soon be problematic due to collision attacks. If we assume that this is indeed the case, the question is whether switching to SHA-256 for the very same key does actually help: The mix of different fingerprints for the same key will lead to the same confusion we have seen with X.509 and ssh. Further, if there is a need to switch to a stronger fingerprint format for the same key, should the user not also assume that the use of the key has already been compromised and it is time to create a new key? ===== If Collision attacks become viable for SHA-1 fingerprints, then they would probably also become viable for subkeys as well, and it might be possible for an attacker to generate a subkey with a collision for the cross-certifying signature, and be able to graft a false subkey onto a master key with a SHA-1 signature, which would definitely be a key compromise. so, yes, it would be reasonable to have a new V5 format for the new fingerprint. vedaal --=_06b944fe06bdebc164b5fa5ded257e8d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On 9/17/2015 a= t 2:44 PM, "Werner Koch" <wk@gnupg.org> wrote:

Some peop= le claim that a SHA-1 fingerprint might soon be problematic due
to colli= sion attacks. If we assume that this is indeed the case, the
question i= s whether switching to SHA-256 for the very same key does
actually help:= The mix of different fingerprints for the same key will
lead to the sam= e confusion we have seen with X.509 and ssh. Further, if
there is a nee= d to switch to a stronger fingerprint format for the same
key, should th= e user not also assume that the use of the key has already
been compromi= sed and it is time to create a new key?

=3D=3D=3D=3D=3D

If Co= llision attacks become viable for SHA-1 fingerprints, then they would proba= bly also become viable for subkeys as well, and it might be possible for an= attacker to generate a subkey with a collision for the cross-certifying si= gnature, and be able to graft a false subkey onto a master key with a SHA-1= signature, which would definitely be a key compromise.

so, yes,&nbs= p; it would be reasonable to have a new V5 format for the new fingerprint.<= br>

vedaal
 --=_06b944fe06bdebc164b5fa5ded257e8d-- From nobody Fri Sep 18 05:25:58 2015 Return-Path: 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 CB25A1B2B63 for ; Fri, 18 Sep 2015 05:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RwA6LI2x4XkZ for ; Fri, 18 Sep 2015 05:25:55 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B241B2B68 for ; Fri, 18 Sep 2015 05:25:55 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Zcujg-0001TU-Tb for ; Fri, 18 Sep 2015 14:25:52 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Zcuer-00006X-LH; Fri, 18 Sep 2015 14:20:53 +0200 From: Werner Koch To: vedaal@nym.hush.com References: <20150917220536.574C4C035D@smtp.hushmail.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: vedaal@nym.hush.com, openpgp@ietf.org Date: Fri, 18 Sep 2015 14:20:53 +0200 In-Reply-To: <20150917220536.574C4C035D@smtp.hushmail.com> (vedaal@nym.hush.com's message of "Thu, 17 Sep 2015 18:05:36 -0400") Message-ID: <87zj0jx6je.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 12:25:57 -0000 On Fri, 18 Sep 2015 00:05, vedaal@nym.hush.com said: > would probably also become viable for subkeys as well, and it might be > possible for an attacker to generate a subkey with a collision for the > cross-certifying signature, and be able to graft a false subkey onto a You mean the back signatures (Primary Key Binding Signature), right? They are done directly on the key material and not on the fingerprint. Thus back signatures can be updated to SHA-256 without problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From guillem@master.debian.org Fri Sep 18 09:25:08 2015 Return-Path: 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 0E37A1A1A7C for ; Fri, 18 Sep 2015 09:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] 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 pI_xRf5NSg5T for ; Fri, 18 Sep 2015 09:25:06 -0700 (PDT) Received: from master.debian.org (master.debian.org [IPv6:2001:41b8:202:deb:216:36ff:fe40:4001]) (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 D2D6E1A1A94 for ; Fri, 18 Sep 2015 09:25:05 -0700 (PDT) Received: from guillem by master.debian.org with local (Exim 4.84) (envelope-from ) id 1ZcyT9-0001ef-Fq for openpgp@ietf.org; Fri, 18 Sep 2015 16:25:03 +0000 Date: Fri, 18 Sep 2015 18:24:58 +0200 From: Guillem Jover To: openpgp@ietf.org Message-ID: <20150918162458.GA14374@gaara.hadrons.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [openpgp] OpenPGP Armor Message specification X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 16:47:14 -0000 Hi! As I mentioned to Werner and Daniel at DebConf 15, I think the specification of the OpenPGP Armor Messages has some unclear parts, which I think were part of the reason for several security issues in multiple projects due to mismatched parsing of Armor Header Lines. Here are some things that would be good to clarify in RFC4880: * In §6.2 there's no explicit definition of what ASCII characters are to be considered whitespace (contrast that with §7.1). In this case GnuPG considers whitespace to be «SPACE 0x20, HT 0x09 and CR 0x0D» and now most tools in Debian do too. I don't know if that matches with PGP for example. * In §7, mention that this is a specific instance of §6.2? * In §7, probably clarify that by «empty» in: «- Exactly one empty line not included into the message digest,» it means «blank» as in §6.2: «- A blank (zero-length, or containing only whitespace) line» Thanks, Guillem From nobody Sat Sep 19 08:19:26 2015 Return-Path: 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 8167A1B5E7A for ; Sat, 19 Sep 2015 08:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 lTtgePKpfrNa for ; Sat, 19 Sep 2015 08:19:22 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDA11B5E77 for ; Sat, 19 Sep 2015 08:19:22 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 65E856D74A; Sat, 19 Sep 2015 11:19:20 -0400 (EDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> From: ianG Message-ID: <55FD7CF0.8030200@iang.org> Date: Sat, 19 Sep 2015 16:19:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <878u84zy4r.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 15:19:24 -0000 Hi Werner, On 17/09/2015 19:41 pm, Werner Koch wrote: > I'd like to get opinions on one specific aspect of a new fingerprint > format in 4880bis. > > In the past we bound the fingerprint format to the key packet version: > v3 keys used MD5 and v4 keys SHA-1 fingerprints. This gained us the > benefit of having a bijective connection between fingerprint and key. I'm hugely on that side. I'll always vote for that. I even staked my rep on it :) http://iang.org/ssl/h1_the_one_true_cipher_suite.html Which came directly from the experience of hacking PGP & OpenPGP in Perl/Java as part of Cryptix. The tears, the fears, the costs. So: the only choice for me is which hash you pick for v5. If you want another one, start planning for v6. > For X.509 and ssh (OpenSSH), there has always been an uncertainty which > fingerprint to use because there is no well established standard for it. > For a long time MD5 was used but then some users switched to SHA-1, and > meanwhile SHA-256 is also seen more often. These fingerprint formats > can easily be distinguished by their length and thus the format itself > is not a problem. However, if you ask users to verify the fingerprint > of a certificate and you given them SHA-1 but they have only access to > the MD5 fingerprint things starts to get wrong. Complicated (human) > reasoning about the identity of a certificate needs to be done. > > With OpenPGP is is easier: The specs say that a key is described by one > and only one fingerprint. There is no way to assign a different > fingerprint to the the same key. > > If we want to introduce a, say, SHA-256 fingerprint, the straightforward > way is to define a v5 key packet format which will be identical to the > v4 format with the exception of the packet version number (and maybe > rules on what algorithms to use with a v5 key) [1]. > > Such a v5 format also means that it is not possible to switch to the new > fingerprint format for existing v4 keys. The v4 keys would continue to > use SHA-1 fingerprints. Yes. > Some people claim that a SHA-1 fingerprint might soon be problematic due > to collision attacks. If we assume that this is indeed the case, the > question is whether switching to SHA-256 for the very same key does > actually help: The mix of different fingerprints for the same key will > lead to the same confusion we have seen with X.509 and ssh. Further, if > there is a need to switch to a stronger fingerprint format for the same > key, should the user not also assume that the use of the key has already > been compromised and it is time to create a new key? The message is clear to me: "Start upgrading to v5." Put your energy in the future. Put your users' energy into the future... > Given that we are expecting to soon switch from RSA to ECC for improved > security and that the current base of OpenPGP implementations supporting > ECC is quite small, I would recommend not to allow a second fingerprint > format for v4 keys but to bind a new fingerprint format to a v5 key > packet version. > > > > Shalom-Salam, > > Werner > > > [1] I recently talked to the guy who asked a long time ago for a hard > expiration time in a future key packet format. He is not anymore > interested in this and thus other technical changes to the key packet > format a not needed. iang, who not everyone agrees with... From nobody Mon Sep 21 02:14:02 2015 Return-Path: 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 6DB5D1A877B for ; Mon, 21 Sep 2015 02:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no 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 YwdKpvXmQ4eO for ; Mon, 21 Sep 2015 02:13:59 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0461A035F for ; Mon, 21 Sep 2015 02:13:58 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8L9Dnvo006394 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 21 Sep 2015 11:13:50 +0200 From: Simon Josefsson To: ianG References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150921:openpgp@ietf.org::4ohuFNmPcZfLDSDO:0fHd X-Hashcash: 1:22:150921:iang@iang.org::Ah2RMaAsX0mwxoqV:55Sn Date: Mon, 21 Sep 2015 11:13:48 +0200 In-Reply-To: <55FD7CF0.8030200@iang.org> (iang@iang.org's message of "Sat, 19 Sep 2015 16:19:12 +0100") Message-ID: <87io742kz7.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 09:14:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ianG writes: > Hi Werner, > > > On 17/09/2015 19:41 pm, Werner Koch wrote: >> I'd like to get opinions on one specific aspect of a new fingerprint >> format in 4880bis. >> >> In the past we bound the fingerprint format to the key packet version: >> v3 keys used MD5 and v4 keys SHA-1 fingerprints. This gained us the >> benefit of having a bijective connection between fingerprint and key. > > I'm hugely on that side. I'll always vote for that. I even staked my > rep on it :) > > http://iang.org/ssl/h1_the_one_true_cipher_suite.html > > Which came directly from the experience of hacking PGP & OpenPGP in > Perl/Java as part of Cryptix. The tears, the fears, the costs. > > So: the only choice for me is which hash you pick for v5. If you > want another one, start planning for v6. +1 I believe sub-negotiating in security protocol leads to obscure problems and makes security evaluation harder. If we can avoid that, and that appears to be the case, I'm all for it. Regarding which hash to use, SHA-256 is probably the simplest choice From=20a practicallity and consensus point of view. Are there any strong reasons to favor something else? What would be the relevant options be anyway? SHA-256, BLAKE2, SHA3-256, SHA-512, CubeHash? Would there be value in being able to use variable length SHAKE variants? /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJV/8pMAAoJEIYLf7sy+BGdZnIH/2caVxila4zn5ZPh/pkn6ZyI FKZon7VVm5LzI5lfa7tY7u4H9vQh+W+YaYu9l97f1U09ruWB6tELY80P9M93R8Tk qtC8tEREZsMi/gsFVkcC86o4YIk0wT9Q87mzk8XN3ZkMr/HYPmRFb4kN2lZcMFKV aMOMR1dN31rNpAcu6VTR/wXtYNPk255VVXEHwq02dfPOFtt4Z5bfndcEmG7yVSEc oFUW1sxumNh/MGJZJy+etncvVpAfHECBQsz1oexP1aCBqnAiPqDbQIdDqn0vKmr2 oOvGVuQWl6YyNx57SYdGuQkTEuX0gZE6urtdHzecqLY4AFSD1IankzeuzSU5Cd8= =60UU -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 29 06:54:22 2015 Return-Path: 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 2317B1B3FDF for ; Tue, 29 Sep 2015 06:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 3Jc7FYo-qqpw for ; Tue, 29 Sep 2015 06:54:20 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4370D1B3FDE for ; Tue, 29 Sep 2015 06:54:20 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 37A816D77F; Tue, 29 Sep 2015 09:54:19 -0400 (EDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> From: ianG Message-ID: <560A982A.1040409@iang.org> Date: Tue, 29 Sep 2015 09:54:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87io742kz7.fsf@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 13:54:22 -0000 On 21/09/2015 05:13 am, Simon Josefsson wrote: > ianG writes: > >> Hi Werner, >> >> >> On 17/09/2015 19:41 pm, Werner Koch wrote: >>> I'd like to get opinions on one specific aspect of a new fingerprint >>> format in 4880bis. >>> >>> In the past we bound the fingerprint format to the key packet version: >>> v3 keys used MD5 and v4 keys SHA-1 fingerprints. This gained us the >>> benefit of having a bijective connection between fingerprint and key. >> >> I'm hugely on that side. I'll always vote for that. I even staked my >> rep on it :) >> >> http://iang.org/ssl/h1_the_one_true_cipher_suite.html >> >> Which came directly from the experience of hacking PGP & OpenPGP in >> Perl/Java as part of Cryptix. The tears, the fears, the costs. >> >> So: the only choice for me is which hash you pick for v5. If you >> want another one, start planning for v6. > > +1 > > I believe sub-negotiating in security protocol leads to obscure problems > and makes security evaluation harder. If we can avoid that, and that > appears to be the case, I'm all for it. > > Regarding which hash to use, SHA-256 is probably the simplest choice > From a practicallity and consensus point of view. Are there any strong > reasons to favor something else? > > What would be the relevant options be anyway? SHA-256, BLAKE2, > SHA3-256, SHA-512, CubeHash? Would there be value in being able to use > variable length SHAKE variants? There are a few reasons to go to SHA3 or SHAKE, as far as I see it. 1. It leaps us ahead by about a decade in terms of cryptographic experience. 2. It can do any size so we can use the same algorithm for all the different uses, without getting into esoteric arguments about truncation. Indeed this is intended -- although rare, the team that made SHA3 felt our pain and improved our interface to the black box known as the message digest. 3. This further leads to the possibility that if we get scared of the "short" length, we can just lengthen the base array and let the software work it out. Similar to PHB's concept, we could just pre-ordain some applicable lengths that work for all purposes. 4. The same base algorithm can be used as a symmetric AE cipher. This leads to the possibility of one algorithm family giving most of the cryptographic needs (we'd need an asymmetric one too). The development savings and the size savings are not to be sniffed at: leads to small lightweight deployments e.g., on IoT and many more and maintainable language implementations. 5. As a higher level meta-advantage, getting us away from the alphabet soup approach to protocol design might clarify to us why it is that there is an advantage in having more than one of everything around. iang From nobody Tue Sep 29 07:26:16 2015 Return-Path: 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 54D941B4205 for ; Tue, 29 Sep 2015 07:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Hg5BWBFVXop8 for ; Tue, 29 Sep 2015 07:26:10 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 5135A1B4204 for ; Tue, 29 Sep 2015 07:26:09 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so153259045wic.1 for ; Tue, 29 Sep 2015 07:26:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=FDGNvGTd+Oj/ReeqFTdGSu/O5ONVzf144gKq6FKJl0A=; b=TdUiTole1Qig7wOqEo5r9Q9LG2ZNxJZCLUk3DvrYJsOGolFbzRdTutYTWFrTSsBI7J Nyhta/wNeIIxqoXO+apgd3Z6tEsewOTFk8IH1xHaKAu6x02lu0PHA38FB2jAQhC2Jpnd lstcuWD9d7oyJPSwATJmJ5OC9E/t0QcOwI5e1zEn7ISXj4gjcuGbf2eFYzDKyenSs83S 1USXO4SrN6LHAMbZ2R58M/er+lzxC9pNogEqeh/1IH+h8NNv8rp44X0pizVbf7TaqXSU nlLz4LA8c8uRS946Bl++9K7Hj037PzZeMbsrHOuB58ct8imgkFaQUz31Fsg05wvuLXb3 u3eQ== X-Gm-Message-State: ALoCoQkRmU2TMyx6jq0GzW4J+pJ00sIAebquLre3MaMxkj8Gb9ElCeSAfQL6XWetaoL6kTzJUaoL X-Received: by 10.180.211.243 with SMTP id nf19mr26455953wic.74.1443536767778; Tue, 29 Sep 2015 07:26:07 -0700 (PDT) Received: from [192.168.120.120] (dhcp142.cs.elte.hu. [157.181.227.142]) by smtp.googlemail.com with ESMTPSA id z2sm24215910wij.1.2015.09.29.07.26.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 07:26:06 -0700 (PDT) To: openpgp@ietf.org References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <560A982A.1040409@iang.org> From: "Daniel A. Nagy" X-Enigmail-Draft-Status: N1110 Message-ID: <560A9F7B.9080907@epointsystem.org> Date: Tue, 29 Sep 2015 16:26:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560A982A.1040409@iang.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 14:26:14 -0000 Hi, I fully support the "One True Cipher Suite" paradigm of Ian. At Ethereum (which is where I currently work), we have had quite a long explorative discussion about the choice of THE hash function, and we came out in favor of SHA3 (Keccak) for a multitude of good reasons most of which apply to OpenPGP as well. I believe that the most important documents from that debate are publicly available, but if necessary, I am willing to repeat the arguments in a nutshell. Furthermore, I also believe that if OpenPGP finally leaves the convoluted CFB variant behind and goes for stream ciphers, SHAKE has some very clear benefits over AES-CTR, chief among them that by using a closely related hash function and stream cipher, we follow the "keep all your eggs in one basket and watch that basket" principle; in other words, we present a smaller cross-section to potential attackers. Bests, Daniel On 2015-09-29 15:54, ianG wrote: > On 21/09/2015 05:13 am, Simon Josefsson wrote: >> ianG writes: >> >>> Hi Werner, >>> >>> >>> On 17/09/2015 19:41 pm, Werner Koch wrote: >>>> I'd like to get opinions on one specific aspect of a new fingerprint >>>> format in 4880bis. >>>> >>>> In the past we bound the fingerprint format to the key packet version: >>>> v3 keys used MD5 and v4 keys SHA-1 fingerprints. This gained us the >>>> benefit of having a bijective connection between fingerprint and key. >>> >>> I'm hugely on that side. I'll always vote for that. I even staked my >>> rep on it :) >>> >>> http://iang.org/ssl/h1_the_one_true_cipher_suite.html >>> >>> Which came directly from the experience of hacking PGP & OpenPGP in >>> Perl/Java as part of Cryptix. The tears, the fears, the costs. >>> >>> So: the only choice for me is which hash you pick for v5. If you >>> want another one, start planning for v6. >> >> +1 >> >> I believe sub-negotiating in security protocol leads to obscure problems >> and makes security evaluation harder. If we can avoid that, and that >> appears to be the case, I'm all for it. >> >> Regarding which hash to use, SHA-256 is probably the simplest choice >> From a practicallity and consensus point of view. Are there any strong >> reasons to favor something else? >> >> What would be the relevant options be anyway? SHA-256, BLAKE2, >> SHA3-256, SHA-512, CubeHash? Would there be value in being able to use >> variable length SHAKE variants? > > > There are a few reasons to go to SHA3 or SHAKE, as far as I see it. > > 1. It leaps us ahead by about a decade in terms of cryptographic > experience. > > 2. It can do any size so we can use the same algorithm for all the > different uses, without getting into esoteric arguments about > truncation. Indeed this is intended -- although rare, the team that > made SHA3 felt our pain and improved our interface to the black box > known as the message digest. > > 3. This further leads to the possibility that if we get scared of the > "short" length, we can just lengthen the base array and let the software > work it out. Similar to PHB's concept, we could just pre-ordain some > applicable lengths that work for all purposes. > > 4. The same base algorithm can be used as a symmetric AE cipher. This > leads to the possibility of one algorithm family giving most of the > cryptographic needs (we'd need an asymmetric one too). The development > savings and the size savings are not to be sniffed at: leads to small > lightweight deployments e.g., on IoT and many more and maintainable > language implementations. > > 5. As a higher level meta-advantage, getting us away from the alphabet > soup approach to protocol design might clarify to us why it is that > there is an advantage in having more than one of everything around. > > > > > iang > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Tue Sep 29 11:40:44 2015 Return-Path: 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 3B5411B4AB3 for ; Tue, 29 Sep 2015 11:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 g9cuEC2k72BX for ; Tue, 29 Sep 2015 11:40:42 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DB3631B4AB2 for ; Tue, 29 Sep 2015 11:40:41 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 8D34CF984; Tue, 29 Sep 2015 14:40:39 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CB0C82005C; Tue, 29 Sep 2015 14:40:11 -0400 (EDT) From: Daniel Kahn Gillmor To: Werner Koch , IETF OpenPGP In-Reply-To: <878u84zy4r.fsf@vigenere.g10code.de> References: <878u84zy4r.fsf@vigenere.g10code.de> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 29 Sep 2015 14:40:11 -0400 Message-ID: <87fv1xxe5w.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 18:40:43 -0000 On Thu 2015-09-17 14:41:56 -0400, Werner Koch wrote: > If we want to introduce a, say, SHA-256 fingerprint, the straightforward > way is to define a v5 key packet format which will be identical to the > v4 format with the exception of the packet version number (and maybe > rules on what algorithms to use with a v5 key) [1]. Thanks for raising these points, Werner. It should be straightforward to take the key material from an existing v4 key and wrap it in a v5 packet, thereby producing a "new key" that's actually the "same key". So claiming that key material can only be used as *either* v4 or v5 wouldn't quite be correct. The difference here is that existing OpenPGP certifications made against the key wrapped in v4 public key packet won't be applied to the "new" v5 public key. Similarly, existing revocations or rejections of the old key won't be applied to the "new" key. That is, the same key material presented as a new version is effectively treated as a distinct key no matter what. i personally find the argument about wanting bijectivity pretty compelling. If we can say with confidence that one OpenPGP object has exactly one fingerprint format to use, that should greatly simplify matching and verification. So far, all responses in this thread have been in favor of coupling the version with the fingerprint choice. Does anyone in the WG want to speak against this, or should we treat it as a conclusive and move forward on that basis? --dkg From nobody Tue Sep 29 23:06:03 2015 Return-Path: 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 4F9721B5CAB for ; Tue, 29 Sep 2015 23:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] 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 2vK4j4XdsRgC for ; Tue, 29 Sep 2015 23:06:01 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D971B5CA6 for ; Tue, 29 Sep 2015 23:06:01 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZhAWd-0006LM-Fb for ; Wed, 30 Sep 2015 08:05:59 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZhARf-0005rO-Qf; Wed, 30 Sep 2015 08:00:51 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Daniel Kahn Gillmor , IETF OpenPGP Date: Wed, 30 Sep 2015 08:00:51 +0200 In-Reply-To: <87fv1xxe5w.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 29 Sep 2015 14:40:11 -0400") Message-ID: <87r3lgcup8.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] New fingerprint: to v5 or not to v5 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 06:06:03 -0000 On Tue, 29 Sep 2015 20:40, dkg@fifthhorseman.net said: > v4 key and wrap it in a v5 packet, thereby producing a "new key" that's > actually the "same key". So claiming that key material can only be used > as *either* v4 or v5 wouldn't quite be correct. FWIW: I was thinking about this but that is not limited to OpenPGP. I can use the same key material for an OpenPGP key, an X.509 key, and an SSH key. This is actually sometimes useful if you have a single key on a smartcard. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Sep 29 23:21:03 2015 Return-Path: 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 9A5BA1B5CCC for ; Tue, 29 Sep 2015 23:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 k6ss5ol7nDxb for ; Tue, 29 Sep 2015 23:21:00 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F91B1B5CCB for ; Tue, 29 Sep 2015 23:21:00 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZhAl8-0006su-Qy for ; Wed, 30 Sep 2015 08:20:58 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZhAj8-0005tq-Rk; Wed, 30 Sep 2015 08:18:54 +0200 From: Werner Koch To: Simon Josefsson References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Simon Josefsson , ianG , openpgp@ietf.org Date: Wed, 30 Sep 2015 08:18:54 +0200 In-Reply-To: <87io742kz7.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 21 Sep 2015 11:13:48 +0200") Message-ID: <87mvw4ctv5.fsf_-_@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: openpgp@ietf.org, ianG Subject: Re: [openpgp] New fingerprint: which hash algo (was: to v5 or not to v5) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 06:21:01 -0000 On Mon, 21 Sep 2015 11:13, simon@josefsson.org said: > Regarding which hash to use, SHA-256 is probably the simplest choice > From a practicallity and consensus point of view. Are there any strong > reasons to favor something else? I see also several reasons to favor SHA-256: - SHA-2 has shown no weaknesses during the SHA-3 competition. - SHA-256 is the commonly used hash algorithm for OpenPGP messages and keys and thus available in all code bases. - Although not an issue for fingerprints, SHA-3 is slower than SHA-2. - On embedded systems SHA-512 has a substantially performance penalty over SHA-256. Given that modern ECC requires a larger than 256 bit hash, I am not sure whether the next point is valid: - If we would go for a newer hash algorithm, all implementations would need to support SHA-256 (and SHA-1) anyway to support existing keys and allow verification of existing signatures. Also decryption of symmetrically encrypted messages may require SHA-256 for the S2K. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.