From nobody Thu Mar 12 05:36: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 185431A005D for ; Thu, 12 Mar 2015 05:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-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 q44CTe6J99TL for ; Thu, 12 Mar 2015 05:36:18 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F391A0013 for ; Thu, 12 Mar 2015 05:36:18 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YW2LY-00054D-SQ for ; Thu, 12 Mar 2015 13:36:16 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YW2H3-0006Ng-JP for ; Thu, 12 Mar 2015 13:31:37 +0100 From: Werner Koch To: openpgp@ietf.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 Date: Thu, 12 Mar 2015 13:31:37 +0100 Message-ID: <878uf2iehi.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] How to re-launch the OpenPGP WG 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, 12 Mar 2015 12:36:21 -0000 Hi, Since some time the OpenPGP protocol is again en vogue and the tendency to prefer S/MIME over OpenPGP is not as strong as it seems to have been once. Case in point, the DANE WG has a last call for an OpenPGP DNS record type. This is obviously related to OpenPGP and should have been discussed here as well (actually we did briefly in Summer 2013). There are several tasks the WG should do: - New signature subpackets. For example one to specify a fingerprint and not just the keyid. - Take care of individual I-Ds. - The use of SHA-1 needs to be replaced. - A v5 key format. Prepare for forthcoming public key algorithms. - A new encryption mode to replace our aging CFB+SHA1 method with a fast and standard mode. - Maybe extend it to key distribution. Is there any interest in this? How can we get the WG out of the concluded state? Would the Dallas meeting be a starting point for this? Who would volunteer as Chair? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Mar 12 05:38:15 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 063AF1A0013 for ; Thu, 12 Mar 2015 05:38: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 lKtYzj_vsO5B for ; Thu, 12 Mar 2015 05:38:11 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 39A511A00B0 for ; Thu, 12 Mar 2015 05:38:05 -0700 (PDT) Received: by wiwh11 with SMTP id h11so19877174wiw.5 for ; Thu, 12 Mar 2015 05:38:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fe/SbR+6D25QMjfvtQRJIR0pcyeNuwuGvl4+fuV0Ct0=; b=DUF82yCo/ME2FbW6SiJrDZ7O72/oz1sSvS//Q0VwYyG5VOIzIL9ZnLqv/vH3aMeuio Vtdu05L0MuaqWzp1cXjDW7duXmOccHpknebgApWMyGGkn5yFwwRGoENuJ09aW3SZ6f+M htfNpevUmeM9W3nKaAcocB+r4KLdLAEgnrT6pPnFp3/caCABBg6AtUd4IHMZu2eA44/5 F51FW7LlCH79sL9miqcslCoHgwecGV5Zd852AFoq2onqsQwvPivfHDqFIVue155EnH+I +IZW9EAtavAO/a4P6cSDxFEHkPWdbq9T2nDgBixrfm3ZyDAjtwvusFjsWhiWR50TbtzK /dkQ== X-Gm-Message-State: ALoCoQlAp7JCZ1ZVU4AxvBHWmNS4BosaZEau3MW5YImBAWgv94arLKsOxzzcvd7xmAK3LE4ZspZ8 X-Received: by 10.194.8.99 with SMTP id q3mr89023437wja.88.1426163883989; Thu, 12 Mar 2015 05:38:03 -0700 (PDT) Received: from [192.168.120.139] (dial6.cs.elte.hu. [157.181.227.226]) by mx.google.com with ESMTPSA id pa4sm9876866wjb.11.2015.03.12.05.38.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 05:38:02 -0700 (PDT) Message-ID: <550188A8.1000502@epointsystem.org> Date: Thu, 12 Mar 2015 13:38:00 +0100 From: "Daniel A. Nagy" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <878uf2iehi.fsf@vigenere.g10code.de> In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 12:38:14 -0000 Hi, I'd be very much interested. I even have some ideas/suggestions that I am going to write to the list, if there is some interest. Cheers, Daniel On 03/12/2015 01:31 PM, Werner Koch wrote: > Hi, > > Since some time the OpenPGP protocol is again en vogue and the tendency > to prefer S/MIME over OpenPGP is not as strong as it seems to have been > once. Case in point, the DANE WG has a last call for an OpenPGP DNS > record type. This is obviously related to OpenPGP and should have been > discussed here as well (actually we did briefly in Summer 2013). > > There are several tasks the WG should do: > > - New signature subpackets. For example one to specify a fingerprint > and not just the keyid. > > - Take care of individual I-Ds. > > - The use of SHA-1 needs to be replaced. > > - A v5 key format. Prepare for forthcoming public key algorithms. > > - A new encryption mode to replace our aging CFB+SHA1 method with a > fast and standard mode. > > - Maybe extend it to key distribution. > > Is there any interest in this? > How can we get the WG out of the concluded state? > Would the Dallas meeting be a starting point for this? > Who would volunteer as Chair? > > > Salam-Shalom, > > Werner > From nobody Thu Mar 12 05:42:15 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 78FF31A0099 for ; Thu, 12 Mar 2015 05:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 hirEVzwZGKgw for ; Thu, 12 Mar 2015 05:42:13 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 1B74C1A0013 for ; Thu, 12 Mar 2015 05:42:13 -0700 (PDT) Received: by lamq1 with SMTP id q1so15420811lam.12 for ; Thu, 12 Mar 2015 05:42:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U3r6h3PBMKPbKWwOPh41Ui086cMf5ZwdgmBfAHA9aIk=; b=BXjrmyJIaKSfbGapWoSnejqD/N/u4y0jnPCpurhjVvJgxr47R98tMFQIAxZKKRmGXz QBWIQhOButpu2wuMJMoelDDc3ksdxknD/M3KFEAnPHXwz6rKcXdAIzX/Nr4EgW2E4KRu kAzAt4OT3NdGjDVtnx71slcnQ/67tJYx3LKtqtuqkcsGAgJuAz7IOF3xtJV+0yuXxdbY Kv8CpIRY6ejag7i/pYP8CQ6f3CGWzEmYuCoCC3awr8x1zkhXvzsqKpLO5TSS/1CBBgs4 8wi7oUitRKGFtREZBXbFGSl1r4STXUfHTtTMFrQV+SVjllF3j3FP7lPraZQ2iVc9yAYm AT5A== X-Gm-Message-State: ALoCoQnzs2pbkcID0pZsLEjnNuTtgZ6lQ1JJMY8O7oRajtxVRjqDiO07gw8UR/BEWZeTEkMlN2/H X-Received: by 10.112.239.1 with SMTP id vo1mr38966521lbc.110.1426164131411; Thu, 12 Mar 2015 05:42:11 -0700 (PDT) Received: from [192.168.4.200] ([195.1.8.34]) by mx.google.com with ESMTPSA id v13sm1301899lal.4.2015.03.12.05.42.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 05:42:10 -0700 (PDT) Message-ID: <550189A1.9050802@sumptuouscapital.com> Date: Thu, 12 Mar 2015 13:42:09 +0100 From: Kristian Fiskerstrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Werner Koch , openpgp@ietf.org References: <878uf2iehi.fsf@vigenere.g10code.de> In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 12:42:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/12/2015 01:31 PM, Werner Koch wrote: > Hi, > ... > > Is there any interest in this? I certainly think it is a good idea - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nomina stultorum scribuntur ubique locorum Fools have the habit of writing their names everywhere -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVAYmSAAoJEP7VAChXwav65sIH/ilsyxQmeJqxXW7kzaLKf2fi Po0x9NHIj8m1QDBLIH28PVqrKxWC45D4utqWX+0SETdOkm+YwIDD7REHVxdgedSB ZcasHEc4T3vY5W18aQ9wqNjjA1Qs+vMsP8SmdV0rggAEWNp1q6zThJZiK7K4znX9 SgJdTPy1sRDxR0BfyknTw1ijL3C+B+pGEsHExJt47WhPrKrW2Cr26ZCirNtozDTH Be6bpEK2qYGJ1hnzsAbYn/VB7lylQmvCuB4PTx5+/jz8APkbukm0uNECKEZrP6oO vOlgeO+MJ2bDwO77FqOgLtrWn22RZUHiyK1d4MnVGyg6tjThiGbmpcsWjKXUeOI= =BqzP -----END PGP SIGNATURE----- From nobody Thu Mar 12 06:37:11 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 644E61A014A for ; Thu, 12 Mar 2015 06:37:10 -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 U9Y7amAeSCns for ; Thu, 12 Mar 2015 06:37:08 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD131A00CC for ; Thu, 12 Mar 2015 06:37:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DE2C6E2035; Thu, 12 Mar 2015 09:37:06 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16070-02; Thu, 12 Mar 2015 09:37:04 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id E474AE2036; Thu, 12 Mar 2015 09:37:04 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 12 Mar 2015 09:37:04 -0400 Message-ID: In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> References: <878uf2iehi.fsf@vigenere.g10code.de> Date: Thu, 12 Mar 2015 09:37:04 -0400 From: "Derek Atkins" To: "Werner Koch" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 13:37:10 -0000 Hi, On Thu, March 12, 2015 8:31 am, Werner Koch wrote: > Hi, > > Since some time the OpenPGP protocol is again en vogue and the tendency > to prefer S/MIME over OpenPGP is not as strong as it seems to have been > once. Case in point, the DANE WG has a last call for an OpenPGP DNS > record type. This is obviously related to OpenPGP and should have been > discussed here as well (actually we did briefly in Summer 2013). > > There are several tasks the WG should do: > > - New signature subpackets. For example one to specify a fingerprint > and not just the keyid. > > - Take care of individual I-Ds. > > - The use of SHA-1 needs to be replaced. > > - A v5 key format. Prepare for forthcoming public key algorithms. > > - A new encryption mode to replace our aging CFB+SHA1 method with a > fast and standard mode. > > - Maybe extend it to key distribution. > > Is there any interest in this? There certainly seems to be. > How can we get the WG out of the concluded state? We would need to effectively create a new WG. > Would the Dallas meeting be a starting point for this? We couldn't necessarily charter it in Dallas, but we could certainly have a bar bof in Dallas to work out a charter. We would need to talk to the SecADs about chartering the group. > Who would volunteer as Chair? The Chair(s) is(are) appointed by the ADs. Volunteers are good, but not necessarily used. ;) > > Salam-Shalom, > > Werner -derek, former chair :) -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 12 06:38:50 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 5D1C41A0113 for ; Thu, 12 Mar 2015 06:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 FtjQ5l6wiXm0 for ; Thu, 12 Mar 2015 06:38:48 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3283D1A0111 for ; Thu, 12 Mar 2015 06:38:48 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 858EEF2124; Thu, 12 Mar 2015 13:38:47 +0000 (UTC) Date: Thu, 12 Mar 2015 08:38:46 -0500 From: Stephen Paul Weber To: Werner Koch Message-ID: <20150312133846.GA2983@singpolyma-liberty> References: <878uf2iehi.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 13:38:49 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > - New signature subpackets. For example one to specify a fingerprint > and not just the keyid. This needs to happen. > - A v5 key format. Prepare for forthcoming public key algorithms. What sorts of changes do you see being needed here? > - A new encryption mode to replace our aging CFB+SHA1 method with a > fast and standard mode. Right. >Is there any interest in this? Yes. >How can we get the WG out of the concluded state? So, some of these things have been proposed as, like, extension RFCs or=20 whatever instead of a supercession to main OpenPGP. But I guess that work= =20 is usually done under this WG as well. Do you see moving more in that=20 direction, or a full-on new RFC coming out of proposed work? --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVAZbmAAoJENEcKRHOUZze3N4QAMqrboFq+nTvFbKvnXntoxFN qMlrQpPAnme5yA71qbV93ijgLJwu9djYv2/Vz9TZEJw+TWZsbS517CMWbZQsJGgs xHX36tNMLfl7sewZCGgYIoaVFWqtt3Gd48K8oLb6GuFJPjkR0C2FtI58QgRvSZww MJo7jBjL297IujcG6m43xb8mFMmfusnK+R+9WnFs60/BjTbC8s/C3mX6VTt+EGEq Pz/u5Ib7zDaX7uWlLQEEBawb6RdYMSibsFxTHMQ2+I9YKFAf4pzsEQj1J/s+/U8f XxdYAkOS8r/EcoRdd0Q4asmCz3muhs0lAkZLsd2BWBXKo3F9KOQbxo3A80W5206r jQLyT+q87Yoflo0z6GOQ/c+BM5wL1Kjq6jt60Z9dpNxi1Mb5CYRm2LonYKoP+3wy Mi7Iaypd2eMM+0+anF6rOY4DmhYbI0azSqFGj/A5G9jTBde7chISTt3qGLqfF6La Ki1ZFIGdlYIK9zhSyMo6rJrvtQJMKHfb6X+sqtZwkDBfJjSTWK6ogXGRZoCmS80j 5Nhca5tluvkWNZH1CGov3mV2D4FFHKKUhRtXHLW26Ruu0KtTvHnWIxkFcfuiER7T iUCbMtxfoQAkLPzDONMHaDOrlLhyrxEEj6sNYtX+xOI6uuIjK7BymGEBtLgifoqN uOEZVRyxnEXf8uTHxmTv =3DPk -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From nobody Thu Mar 12 06:50:29 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 638541A0113 for ; Thu, 12 Mar 2015 06:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6mYbRTzSAQOj for ; Thu, 12 Mar 2015 06:50:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D6C1A0111 for ; Thu, 12 Mar 2015 06:50:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l2s3y5BwMzDZ0; Thu, 12 Mar 2015 14:50:22 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=rOW9yWuC; dkim-adsp=pass X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LqB7MOJ8FARF; Thu, 12 Mar 2015 14:50:21 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 12 Mar 2015 14:50:21 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 64F0A82A1E; Thu, 12 Mar 2015 09:50:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426168220; bh=bVNrxG8qVsnia62AaR2wbJPk2RiqC9ELLpb6Dx8ibHY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rOW9yWuCsTwK/DbqESrfEesQ51+ROtJdNOYrraGAwmD0RDeiwbaxDydznYgoIVH3z nGcpAVTcm7NGX0quZy2PgTr4fUyeBdadoYv6FBhQrZgon5655NUCdlscQs1xwnv4sr dKisrkeFI89NPDk8zczQb9T2kcbeSW+p0+IGFl+0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2CDoJvk010515; Thu, 12 Mar 2015 09:50:20 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 12 Mar 2015 09:50:19 -0400 (EDT) From: Paul Wouters To: Werner Koch In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> Message-ID: References: <878uf2iehi.fsf@vigenere.g10code.de> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 13:50:28 -0000 On Thu, 12 Mar 2015, Werner Koch wrote: > There are several tasks the WG should do: > > - New signature subpackets. For example one to specify a fingerprint > and not just the keyid. > > - Take care of individual I-Ds. > > - The use of SHA-1 needs to be replaced. > > - A v5 key format. Prepare for forthcoming public key algorithms. > > - A new encryption mode to replace our aging CFB+SHA1 method with a > fast and standard mode. > > - Maybe extend it to key distribution. > > Is there any interest in this? I think there is interest. > How can we get the WG out of the concluded state? Write up a list of things to do, draft a new charter. You started some of that already with your list above. > Would the Dallas meeting be a starting point for this? Deadlines for organising things "officially" are passed: http://www.ietf.org/meeting/important-dates-2015.html#ietf92 But I'm happy to organise an unofficial meetup and take notes. > Who would volunteer as Chair? I'd be happy to be a co-chair. Paul From nobody Thu Mar 12 07:07:10 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 A5C281A02BE for ; Thu, 12 Mar 2015 07:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GNrtvV46Ii0k for ; Thu, 12 Mar 2015 07:07:02 -0700 (PDT) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 169991A034C for ; Thu, 12 Mar 2015 07:06:59 -0700 (PDT) Received: from toad.stack.nl (toad.stack.nl [IPv6:2001:610:1108:5010::135]) by mx1.stack.nl (Postfix) with ESMTP id 45F913592DC; Thu, 12 Mar 2015 15:06:56 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 801) id 3DF16730B8; Thu, 12 Mar 2015 15:06:56 +0100 (CET) Date: Thu, 12 Mar 2015 15:06:56 +0100 From: Johan van Selst To: Werner Koch Message-ID: <20150312140656.GA33621@stack.nl> References: <878uf2iehi.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> OpenPGP: id=31c8d089ddb696c6f3c129c0a9c86c8dd3ae8d3a; preference=signencrypt User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 14:07:08 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Werner Koch wrote: > There are several tasks the WG should do: [..] > Is there any interest in this? Yes, I think it is a good idea to re-launch an OpenPGP WG for this. Regards, Johan --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iF4EAREIAAYFAlUBnX8ACgkQAEpMHW8nCPRH2QD/SVYvcpEdno7nDEUYn8sKdx46 TsQzhoJcZQ7MvpLpCowA/RtH3J3j9XORV3+B6cMBrMKyAdumpzavH46sQb7JsgeD =OQyV -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From nobody Thu Mar 12 07:39: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 E710D1A1EEA for ; Thu, 12 Mar 2015 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 fVdODzCew7nX for ; Thu, 12 Mar 2015 07:39:49 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (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 12A2C1A1AA9 for ; Thu, 12 Mar 2015 07:39:48 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so42649499iec.1 for ; Thu, 12 Mar 2015 07:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eH+AwBWjF7DWoIzFDf/P4g5MxvJZJ8qt5yqYr5fu8Y4=; b=5AWedBqMR/fyCTEWRCqvzJIgwU7ngxxZZHZdmeMXxk38Mq3iacoOXuF3dr5QQpptOF C9ePsQPzv8S9kV77ZYvA+Nu5Ipcu5IboUEYdp4/iOi5Hw2Ismqzl4NTt/U7yNbA0EHWl O05KEabVKxFy6hfrfXJDWRvxHq6FNvZ+YiQsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eH+AwBWjF7DWoIzFDf/P4g5MxvJZJ8qt5yqYr5fu8Y4=; b=JMtppVy0QmmKpcBumOnVJwwwpwet9nxvdTmm3PRWGs7rRVxTjXXuEZyM6PZcjoXInM bzW37VzfOS0DHTzrtEGNPrjIWS2ix+M2Mh37yniEFO0mCkr7lOJlZS8i/gyem3EOQdng 9DKrgRG1O2vyol4z5uSqZUNmyArLrh6AsooTDMrc0a5OtQjLyLpvWQK5CpxmGRUMUJfR NMvJ+j1qd7KfpyIhGCzCCzo8vNFJMQAXJorTayNm3hl8Fmq40BspzFoQe1tj/+s2g7e2 Bv8+fAZcZdyDBMlVCdHNsSd+k/ioSPhVeOw/DvlNYZKvq1h8LXp0vXICcd009IsJJFtF ChIA== X-Gm-Message-State: ALoCoQlpMwrBbIShlfUIKTFtklJjEPgdkLVPJParkYIkdWVyxbkCxbvtxGzBZQg7sHoKSAUAAXLJ X-Received: by 10.50.234.194 with SMTP id ug2mr101749444igc.39.1426171183732; Thu, 12 Mar 2015 07:39:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.14.142 with HTTP; Thu, 12 Mar 2015 07:39:22 -0700 (PDT) In-Reply-To: <20150312140656.GA33621@stack.nl> References: <878uf2iehi.fsf@vigenere.g10code.de> <20150312140656.GA33621@stack.nl> From: Tom Ritter Date: Thu, 12 Mar 2015 09:39:22 -0500 Message-ID: To: Johan van Selst Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 14:39:53 -0000 I'm not sure what the numbers needed to show interest are, but +1. -tom From nobody Thu Mar 12 11:06:21 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 CA0A71A0404 for ; Thu, 12 Mar 2015 11:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 oz-2KS5D1IVC for ; Thu, 12 Mar 2015 11:06:19 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E0F1A0065 for ; Thu, 12 Mar 2015 11:06:19 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YW7Uv-0002gl-BC for ; Thu, 12 Mar 2015 19:06:17 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YW7QS-0007Jn-U7; Thu, 12 Mar 2015 19:01:40 +0100 From: Werner Koch To: Stephen Paul Weber References: <878uf2iehi.fsf@vigenere.g10code.de> <20150312133846.GA2983@singpolyma-liberty> 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 Date: Thu, 12 Mar 2015 19:01:40 +0100 In-Reply-To: <20150312133846.GA2983@singpolyma-liberty> (Stephen Paul Weber's message of "Thu, 12 Mar 2015 08:38:46 -0500") Message-ID: <87twxqgkmz.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] How to re-launch the OpenPGP WG 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, 12 Mar 2015 18:06:21 -0000 On Thu, 12 Mar 2015 14:38, singpolyma@singpolyma.net said: >> - A v5 key format. Prepare for forthcoming public key algorithms. > > What sorts of changes do you see being needed here? In the past we collected several ideas for a v5 key format. We need to revisit the list archives. IIRC, the plan was to first wait for the outcome of the SHA-3 competition. > that work is usually done under this WG as well. Do you see moving > more in that direction, or a full-on new RFC coming out of proposed > work? Eventually a single new RFC should be done - for a v5 format this will be needed anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Mar 12 11:58: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 D644A1A1B72 for ; Thu, 12 Mar 2015 11:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7cWrO-KuYQgn for ; Thu, 12 Mar 2015 11:58:54 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 60AB21A1BA2 for ; Thu, 12 Mar 2015 11:58:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id D7A166C3CD5D; Thu, 12 Mar 2015 11:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1YS13KqnX62; Thu, 12 Mar 2015 11:58:11 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 3C3946C3CD4C; Thu, 12 Mar 2015 11:58:10 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Thu, 12 Mar 2015 11:58:11 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 12 Mar 2015 11:58:11 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-Reply-To: <87twxqgkmz.fsf@vigenere.g10code.de> Date: Thu, 12 Mar 2015 11:58:09 -0700 Message-Id: References: <878uf2iehi.fsf@vigenere.g10code.de> <20150312133846.GA2983@singpolyma-liberty> <87twxqgkmz.fsf@vigenere.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Stephen Paul Weber , "openpgp@ietf.org OpenPGP" , Jon Callas Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 12 Mar 2015 18:58:56 -0000 > On Mar 12, 2015, at 11:01 AM, Werner Koch wrote: >=20 > On Thu, 12 Mar 2015 14:38, singpolyma@singpolyma.net said: >=20 >>> - A v5 key format. Prepare for forthcoming public key algorithms. >>=20 >> What sorts of changes do you see being needed here? >=20 > In the past we collected several ideas for a v5 key format. We need = to > revisit the list archives. IIRC, the plan was to first wait for the > outcome of the SHA-3 competition. There were other things we talked about as well in V5. I think that = connected and separate, a hash-independent way to do a fingerprint is = called for. There was a nice proposal for that in the archives -- = algorithm-id:hash-value -- the abbreviated one. >=20 >> that work is usually done under this WG as well. Do you see moving >> more in that direction, or a full-on new RFC coming out of proposed >> work? >=20 > Eventually a single new RFC should be done - for a v5 format this will > be needed anyway. Or not -- it's a decision of the new working group. We traditionally put everything into one document. That has a lot of = advantages. There's essentially one place to check. Other WGs -- for = example, S/MIME -- have a lot of separate documents. That means they can = work on things in parallel, but makes it harder to wind through the mass = of documents. I think more than one but less than fifty (which is only a slight = exaggeration -- the last time I checked there were over 35 S/MIME = documents) is a good compromise. But yeah, I think you'd want to revise 4880 for new stuff. There are, = however, a number of ways to organize that. Jon= From nobody Thu Mar 12 17:38:45 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 EECD01AC3D1 for ; Thu, 12 Mar 2015 17:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 jWJw3F1xO3MA for ; Thu, 12 Mar 2015 17:38:42 -0700 (PDT) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BB41AC3C7 for ; Thu, 12 Mar 2015 17:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=wqgO/7wlHkWciomkgzpuH1haP7z8BelNrxxUCZosasc=; b=lrBrAFquw+fUYmitU1puMzxQ+jDoZjyvEqtLpSkSUePQ0Lr3Lh27UpJ0KS/qw6Aw5X3pMGYdf43wJt3opvdUhRi81QhJSXxzlbI46QHUjYN6YNUwE8Do6F9cLsN/WgUc3xqrWUA0IHDK4LuySIdaRIfhEmyH+/iyBX8fIAW1860iRE2AgTJ6yxBsAKsAfeJ9KL/lMEzmGm9XQiO/DA9omGv5YfisCteohu0WjJM2yuzsb6FEIu/8hjqfwB3N5LHwNn9il6iVznjHFYmZFZTL+Zo1xu1JboeRF4SfDhYevXAQKcYw26WZA4f7CH8ziezXiWfXujru+IQjhn23dcFsYw==; Received: from 140.200.232.153.ap.dti.ne.jp ([153.232.200.140] helo=[192.168.2.105]) by akagi.fsij.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YWDbJ-0002Hz-0j for openpgp@ietf.org; Fri, 13 Mar 2015 09:37:17 +0900 Message-ID: <5502318C.7050704@fsij.org> Date: Fri, 13 Mar 2015 09:38:36 +0900 From: NIIBE Yutaka Organization: Free Software Initiative of Japan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <878uf2iehi.fsf@vigenere.g10code.de> In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 00:38:44 -0000 On 03/12/2015 09:31 PM, Werner Koch wrote: > There are several tasks the WG should do: [...] > Is there any interest in this? Yes. I think that some improvements would be expected for ECC. My specific interests are the point format(s) and Curve25519 support. There are two drafts for new point formats: Compact representation of an elliptic curve point (expired): https://tools.ietf.org/html/draft-jivsov-ecc-compact-05 EdDSA for OpenPGP: http://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-02 And, IIUC, we will introduce another point format for Curve25519. -- From nobody Thu Mar 12 18:11:32 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 260731AC40E for ; Thu, 12 Mar 2015 18:11:31 -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 csyUijWOyg29 for ; Thu, 12 Mar 2015 18:11:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9AF1AC3E8 for ; Thu, 12 Mar 2015 18:11:29 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 7E0FCF984 for ; Thu, 12 Mar 2015 21:11:27 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 31BA02038E; Thu, 12 Mar 2015 18:11:22 -0700 (PDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 12 Mar 2015 21:11:22 -0400 Message-ID: <87zj7hvgzp.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 01:11:31 -0000 On Thu 2015-03-12 09:50:19 -0400, Paul Wouters wrote: > On Thu, 12 Mar 2015, Werner Koch wrote: >> Would the Dallas meeting be a starting point for this? > > Deadlines for organising things "officially" are passed: > http://www.ietf.org/meeting/important-dates-2015.html#ietf92 > > But I'm happy to organise an unofficial meetup and take notes. I'm also happy to help with something unofficial in Dallas even though the "official" dates are past. I think this is a good idea. fwiw, i'd consider a re-chartered wg to cover possible revisions or extensions to several RFCs, not just 4880: https://tools.ietf.org/html/rfc4880 -- OpenPGPv4 https://tools.ietf.org/html/rfc3156 -- PGP/MIME https://tools.ietf.org/html/rfc6637 -- ECC in OpenPGP To add an item to Werner's earlier list: * i'd like to spec out an adjustment to PGP/MIME that provides signature and encryption protection for RFC 822 headers. We've had some discussion and interest about this on the Enigmail mailing list already, and there was an in-person discussion at the CTF in Valencia last week (using the placeholder name "memory hole"). Nailing down exactly how we expect that to work should be in-scope to a new WG. --dkg From nobody Thu Mar 12 18:24:06 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 5E9F01AC408 for ; Thu, 12 Mar 2015 18:24:06 -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 D3gO_YJcZvbI for ; Thu, 12 Mar 2015 18:24:05 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C961AC3E6 for ; Thu, 12 Mar 2015 18:24:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id AAC5CE2036; Thu, 12 Mar 2015 21:24:03 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 03706-07; Thu, 12 Mar 2015 21:24:02 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 8315AE2038; Thu, 12 Mar 2015 21:24:02 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 12 Mar 2015 21:24:02 -0400 Message-ID: In-Reply-To: <87zj7hvgzp.fsf@alice.fifthhorseman.net> References: <878uf2iehi.fsf@vigenere.g10code.de> <87zj7hvgzp.fsf@alice.fifthhorseman.net> Date: Thu, 12 Mar 2015 21:24:02 -0400 From: "Derek Atkins" To: "Daniel Kahn Gillmor" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 01:24:06 -0000 Okay, there is clearly an interest in forming something, so... Who will be in Dallas? When would be a good time to have a BAR BOF? I propose we meet Monday after the plenary? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 12 18:25:21 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 E31721AC3E8 for ; Thu, 12 Mar 2015 18:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 EDTzPiVJ2_nW for ; Thu, 12 Mar 2015 18:25:18 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357211AC415 for ; Thu, 12 Mar 2015 18:25:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l38Tm3lQKz9Yg; Fri, 13 Mar 2015 02:25:16 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=Hoc1hnqc; dkim-adsp=pass X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id u9_vP-_09yTM; Fri, 13 Mar 2015 02:25:16 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 13 Mar 2015 02:25:16 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 315B6803E0; Thu, 12 Mar 2015 21:25:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426209915; bh=vrjTtEjbcmbS2DKC7P9x6DWhCDrWC1dZ3ogeRNQqQSQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Hoc1hnqcscRqqPF42Iyaw6cmmMu6O+4h44Zb3+YHBHvwM2I/gaNOnl3vXK2XL+xYX TclYqoyOPYP+BmIDnP4MuykAuBpqfHCF9r0NP24PNSseZo1fwuTg+UIxVlbY1Hd2U0 tNevCMn7JAuPvHfDF9JdE6jkD+qr6lR7tGaZuRwg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2D1PEsW023382; Thu, 12 Mar 2015 21:25:14 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 12 Mar 2015 21:25:14 -0400 (EDT) From: Paul Wouters To: Daniel Kahn Gillmor In-Reply-To: <87zj7hvgzp.fsf@alice.fifthhorseman.net> Message-ID: References: <878uf2iehi.fsf@vigenere.g10code.de> <87zj7hvgzp.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 01:25:20 -0000 On Thu, 12 Mar 2015, Daniel Kahn Gillmor wrote: > I'm also happy to help with something unofficial in Dallas even though > the "official" dates are past. I think this is a good idea. Ok, let's go throug the schedule and find a time slot that might work? > * i'd like to spec out an adjustment to PGP/MIME that provides > signature and encryption protection for RFC 822 headers. > > We've had some discussion and interest about this on the Enigmail > mailing list already, and there was an in-person discussion at the CTF > in Valencia last week (using the placeholder name "memory hole"). > Nailing down exactly how we expect that to work should be in-scope to a > new WG. openpgpkey-milter currently only masks the Subject: line and places it as the first line in the body of the (encrypted) email, followd by a blanc line, kinda like mbox. It would be very useful to do this for more headers! Paul From nobody Thu Mar 12 20:52:57 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 6A9561A8A25 for ; Thu, 12 Mar 2015 20:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=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 5RI589_bTE_B for ; Thu, 12 Mar 2015 20:52:52 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7561A89FC for ; Thu, 12 Mar 2015 20:52:52 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw02.dd24.net (Postfix) with ESMTP id 0DB155FBBD for ; Fri, 13 Mar 2015 03:52:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id cvpBciXtyWQh for ; Fri, 13 Mar 2015 03:52:48 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Fri, 13 Mar 2015 03:52:48 +0000 (UTC) Message-ID: <1426218768.22326.80.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Fri, 13 Mar 2015 04:52:48 +0100 In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> References: <878uf2iehi.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-yhubnpTOUIi1tgIOd2g6" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 03:52:56 -0000 --=-yhubnpTOUIi1tgIOd2g6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-03-12 at 13:31 +0100, Werner Koch wrote: >Is there any interest in this? There definitely is ... contrary to what some loud campaigners (recently heise in Germany, or the advocates rubbish X.509 of crappy key pinning technologies) try to make people believe, OpenPGP is still alive and actually the only really securely usable PKI standard (anything strict hierarchical like X.509 is IMHO inherently insecure, at least in practical usage) for the masses.=20 > There are several tasks the WG should do: Since people start to come up with their wishlists... here'd be mine: 1) More general things - The WG should consider whether to just bring OpenPGP up to date... or whether to completely overhaul or even re-design it. In the later case: - The basic meshed web of trust must obviously be retained, but apart from that there should IMHO be no taboos, like dropping the old formats or perhaps even completely changing the format (if some people would think an XML representation would be better, discussions should be open for that - not that I'd be an advocate of this). - OpenPGP should be made fit or at least extensible enough for any mid- or long-term developments in engineering and crypto, this might include things like: - Since the X.509 PKI infrastructure in the internet is inherently broken and since DANE would only partially improve things (one still has several CA's above which could be evil), the time may come in which at least some security conscious people would want to use TLS or similar with a fully meshable PKI as OpenPGP. For that we might need similar things as X.509 got eventually,... things like SubjectAlternativeNames for IP, DNS, email, etc. - Any preparations for PQ Crypto? Or for hybrids of PQ and "normal" crypto? - For the ultra-paranoid: Semantics that allow usage of multiple ciphers and hash algos (i.e. encrypt a message with AES first, then Serpent, then Cesar chiffre ;) ... or make signatures with SHA2 and SHA3 and require all to be valid. 2) More specific things: - get rid of any SHA1 - fingerprints should allow to use different hash algos, in order to keep it easily up to crypto developments - ideally not using fingerprints in the signature subpacktes if that can be avoided (thinking of the Revocation Key subpacket - the whole standard should be much more definite and strict, currently we have many places which are quite vague or which allow to do the same thing in different ways, examples: - the critical flag should become a non-critical flag (i.e. per default everything is considered critical unless something else is explicitly said. - other properties are simply not well enough defined or could at least be made better, e.g. what if a policy URI is used on a selfsig/direct key sig... is that then still the "the policy under which the signature was issued", which would be kinda useless... or should it be better they policy under which this key/user makes signatures? - there need to be a definite algorithm which decides which selfsig/direct key sig/user sig is to be used, if there are still multiple valid (IIRC, that wasn't defined, but it's some time ago since I last read through the RFC) - We have the direct key sig, which would make sense to be used for some things, but actually no one seems to really use it. So either drop it, or if it is kept, then it should be more clearly specified how the semantics change when some subpackets are used on a selfsig vs. a direct key sig? E.g. what happens if one has a key which a direct key sig (0x1F) that says "certification only key" while a 0x13 selfsig says "certification + encryption"). Similar for the other properties like Policy URL, where this could actually make sense, e.g. a PolicyURL on a 0x1F self-sig tells the "global Policy for all UIDs", while one on a 0x13 tells further policy rules when the signature is made with this specific UID[0]. - It should be possible to select more key properties to be fixed (i.e. unchangable), like key expiration time, key usage. 3) UIDs respectively the data that others actually verify/sign should be completely overhauled. Right now we have User ID Packet (13) and User Attribute Packet (17), with the later having only one actual attribute (the image) defined. The UID is by convention a mail address, but even the standard already says that this is just "by convention", it doesn't even use SHOULD or RECOMMEND. I'd change this the following way: The UID is really just an ID for they key, which should be unique within the realm of they keys usage. That means, for globally public keys, we should make this a MUST to either a mail address (and I'd even say just the addr-spec) or a domain name. But for any non globally public usage, this could be something like as students ID number. It follows from that, that the UID would no longer be something what other really certify (in the sense that they've checked whether this is really my mail address or my students ID number). Of course they'd still sign it, but it wouldn't give the key any real trust. As said it would be more a technical ID, which can be used by applications in a given realm to easily distinguish/select keys. - Everything that really identifies the person behind the key (i.e. puts trust into the key) should be go into something like the attribute packet... but there things should be greatly extended. It shouldn't just be the name, picture or email address. Think of things like natural colour of hair/eyes, skin colour, body size, birthdate/place. All different forms of names, from the western first name(s), second names, middle names, family names, perhaps academic grades over e.g. Arabic style names maybe even to Tolkien's elven names where they have Epess=C3=AB, Essi and Amiless=C3=AB ;) . Ideally we'd have a separate and easily extensible registry for these fields, so that one can also easily add things like I don't know: "org.debian.developer=3DDDname" or "com.github.user=3Dfoo". People should be able to sign the personal information which they actually have from their peers (and github, for example, will probably never know my name for sure, but they know me by my account name). One could even think of different image types, starten from a face shot of the person (as we have now), over fringerprint or signature scans, perhaps even to heraldic devices of that person, or what they have in non-western cultures like the Japanese "inkan" respectively "hanko". Perhaps an example: family-name=3D"Mitterer" first-name=3D"Christoph" secondary-name=3D"Anton" secondary-name=3D"Foo" nicknames=3D"Chris" nicknames=3D"whatever" As you can see, for some fields it should be possible to give them multiple times. Since the rendering/usage of these separate naming fields is not universally defined, I'd probably suggest to add a mutliple usable field like: common-name=3D"Christoph Anton Mitterer" common-name=3D"Christoph Mitterer" The key owner could create whichever he things to be appropriate (e.g. someone might also add "Christoph A. Mitterer"). And people signing that key could in principle also choose which of the keys they want to sign. Perhaps one would also need qualifiers for some fields like people from Russia have also given and family names, but obviously in Cyrillic, but there might be an official transliteration to the Latin Alphabet, so the key could contain both. - It should be possible to connect these fields with a "valid from" date and it should be possible to revoke them later in a way that just means like "data superseded". E.g. people might merry and their family name changes, they may divorce and it changes again. Or one grows older and the image changes. 4) one of the IMHO most important things: It should be possible to connect a UID or something similar with specific subkeys. Right now, we have a key with multiple UIDs bound to the key via selfsigs. If I sign someone else's key or sign some text, regardless of which subkey I use,... I do this with all my identities, right? That's quite limiting. - As said before, one might one to do such act (e.g. the signing or certifying) with one specific role, e.g. I may want to sign someone else's key as mail@christoph.anton.mitterer.name, but not as christoph.anton.mitterer@physik.uni-muenchen.de. - Another typical use case: I have a primary key, which people sign and trust, plus several subkeys for encryption/signing. Now I may want to use some of the subkeys for certain "locations" only, e.g. my smartphone (which is pretty insecure),... or at work (which is perhaps more secure as my Google-friends-of-NSA=E2=84=A2 Android, but still= less secure as my home systems). So I give only the respective private subkeys to these locations nothing else. But since right now people only look at the UID, they typically won't notice whether my I've signed a message from my Android device (and therefore the information can only be trusted to some extent). I'm not really sure whether it should be a UID which can be connected to subkeys,... probably not. It should rather be something that is structurally similar to UIDs (i.e. extensible) and which contains other properties like "usage" or a trust indicator. Cheers, Chris. [0] Obviously this only makes sense, if a future OpenPGP version would allow to sign other keys specifically connected with one or more of the UIDs - e.g. I want to verify someone else in my role as worker of uni-muenchen.de, but not in my role as private person. --=-yhubnpTOUIi1tgIOd2g6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxMzAzNTI0 OFowTwYJKoZIhvcNAQkEMUIEQCe/7ty0zW4Fy/3lUUfj0+hHELwgrs8+sTQlCd5InaZ9+KPWWHgF 6B7z1JT7zfAO2390fxQRvsLIO25lkDlo8bkwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCLWBKqw/V/hUG8xbrFDwdH6nXdNGPa EJODkduMoV2+/6UyKp/dkS3M2Aj1VjDBMM9DnIdDoeVeVu992fAN7OksJ//rKSBeWE9i5pvLBp3l EWBW8B8HrPmnCj0hoEy4OfuApy0E6tUaUQD98lfjYy437A54ns6MW7sQTRQQmA6ouHeioMNBaSqe uuna+k3L835zsN6XHmnUSnIKkMXGmU5U+GSgTSZTGld663P7Mf1aXMP7ZrnuBcAWgH+p6XgQR3yG NmcWuOBbc70/G43RWZqd8oZemQlFOfpjhuIAvCuze7pk+cqm5GVI2p7biLPrqhbC3s/7F9GNihsT DtlieolbAAAAAAAA --=-yhubnpTOUIi1tgIOd2g6-- From nobody Fri Mar 13 00:11:23 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 0187C1AC43D for ; Fri, 13 Mar 2015 00:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 JV-Xn08mbk-m for ; Fri, 13 Mar 2015 00:11:20 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B561AC43B for ; Fri, 13 Mar 2015 00:11:20 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YWJkc-0008GQ-Ls for ; Fri, 13 Mar 2015 08:11:18 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YWJfy-00016k-JC; Fri, 13 Mar 2015 08:06:30 +0100 From: Werner Koch To: "Derek Atkins" References: <878uf2iehi.fsf@vigenere.g10code.de> <87zj7hvgzp.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 Date: Fri, 13 Mar 2015 08:06:30 +0100 In-Reply-To: (Derek Atkins's message of "Thu, 12 Mar 2015 21:24:02 -0400") Message-ID: <878uf1gyvd.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, Daniel Kahn Gillmor Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 07:11:22 -0000 On Fri, 13 Mar 2015 02:24, derek@ihtfp.com said: > Who will be in Dallas? Sorry, I won't be there. If there is a need I can attend IETF-93 in July. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 13 00:21:21 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 3760B1AC447 for ; Fri, 13 Mar 2015 00:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 5pQzHsyB4b8g for ; Fri, 13 Mar 2015 00:21:19 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184D91AC445 for ; Fri, 13 Mar 2015 00:21:19 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YWJuH-0008Qv-Jb for ; Fri, 13 Mar 2015 08:21:17 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YWJpU-00018j-Ib; Fri, 13 Mar 2015 08:16:20 +0100 From: Werner Koch To: Christoph Anton Mitterer References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.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 Date: Fri, 13 Mar 2015 08:16:20 +0100 In-Reply-To: <1426218768.22326.80.camel@scientia.net> (Christoph Anton Mitterer's message of "Fri, 13 Mar 2015 04:52:48 +0100") Message-ID: <874mppgyez.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] How to re-launch the OpenPGP WG 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, 13 Mar 2015 07:21:20 -0000 On Fri, 13 Mar 2015 04:52, calestyo@scientia.net said: > 1) More general things > - The WG should consider whether to just bring OpenPGP up to date... or > whether to completely overhaul or even re-design it. The please give the thing another name. Recall the outcry whn I removed PGP-2 support from 2.1. > - The basic meshed web of trust must obviously be retained, but apart OpenPGP does not define the Web of Trust. There is no standard for it. > - Since the X.509 PKI infrastructure in the internet is inherently > broken and since DANE would only partially improve things (one still > has several CA's above which could be evil), the time may come in > which at least some security conscious people would want to use TLS > or similar with a fully meshable PKI as OpenPGP. > For that we might need similar things as X.509 got eventually,... > things like SubjectAlternativeNames for IP, DNS, email, etc. We already have this. You may either use a plain user ID with signed attributes to implement this or, better, extend the attribute packet, which is currently only used for photo ids, but designed for what you want. You may already start with this using the 100--110 subpacket types. Regarding the rest of your mail, I think it is better to postpone a detailed discussion for now. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 13 05:34: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 06E681A0419 for ; Fri, 13 Mar 2015 05:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZbagElaPSeLV for ; Fri, 13 Mar 2015 05:34:41 -0700 (PDT) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5F41A037A for ; Fri, 13 Mar 2015 05:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1426250080; bh=n+fca2PTqu2LFkqzUqdtr5mrLiPBQrBc5rDUtvw2jSA=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=X3Lc71VRStA2EytFvPxoEpXhSXBZjo2oXz7LUnCXR3iex9WKiVTp7hbM+D+7MbLPehh33sDVfLCHOZAX2bGl7zCPWmaB3j14wmOX2BLiKwlI2qlM/LuV2n4DBMwx+qwRDdRHLEJERL6RNGrt+E4kqmljFewOB14IA4hFfenCOWb3V2qNNeVBZnj1gsmtCqSvZdMY+dE07lfTp5yOe+zSfniMgfxqZcScx60RgU2lXCsJ896GdgA0bvTQkOu4/aTHWd9VPt0jgFvHUTd7R4yTfjT14nHjU4XWGqhmjxI275fK9TCoak55k6Aa7LvgCglyZ5blfdntVOqcyw0EDkb9ZQ== Received: from [98.138.100.118] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 13 Mar 2015 12:34:40 -0000 Received: from [98.138.226.128] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 13 Mar 2015 12:34:40 -0000 Received: from [127.0.0.1] by smtp215.mail.ne1.yahoo.com with NNFMP; 13 Mar 2015 12:34:40 -0000 X-Yahoo-Newman-Id: 919718.22963.bm@smtp215.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RHw9sSUVM1lverniKDDaNFhsbkJRbmnbTRGG58Vq2CAYRjD k_2ru5BZuN7SUOhOE8_gdburpWKk7nTR_gEWFwOssNhAs8jdp7lRoKXSLCM7 Hl2dZjUI58RyTSxOCmeHFyT0X41Xh7y5obXQtD9Bkfe.JIBCyMsdniFIcgqN WEiXXvspfplLo2mXBR1Ni1S_vI8rzURqpPUZg9_Egkp.pa1LB0Eq5ImtPRyy cEhV358jtVXzCh1L_uXBwhDVv061h8568jDoWfONVpoZ3hMRcq2h8VN7vzUd PqkD5HmBgc.fatZzXBgKAlKpZm7ACuxIPl36Q90mNpYsU0jYU7rKDOWEcQX6 bKpWy8Guhn9F82YQrSXtGG7be29QuP.RZiybQIIwVpxU8YK13AARVPRtO1TD yS3pWnRMo9BmzjyXiDdIl6mT3nWWMFG1rdYRzxdMNRND48MLOBQJv1L7w8v6 I3IxS99yOejp4MEImsjZ8vFIRzR5oR_YliZIsCPNgQNtgm_R9v6x0.yuf7tw VfQ1gOydaC0sE X-Yahoo-SMTP: tx5KkYOswBB3x2oB9LVgZmnhIRPd9pA1SFT7Pns- Message-ID: <5502DBF1.50007@yahoo.com.au> Date: Fri, 13 Mar 2015 20:45:37 +0800 From: Franklin Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "openpgp@ietf.org" References: <878uf2iehi.fsf@vigenere.g10code.de> <20150312133846.GA2983@singpolyma-liberty> <87twxqgkmz.fsf@vigenere.g10code.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 12:34:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 It's very interesting for pure technical users. But do you want to help ISIS or other terrorists? Pls think over about that. Franklin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlUC2/EACgkQHNPJJKP5NjZBVwD8DWaJ+MifiDdlHmNWzE6tGRai Pv/6i9Sx/FopE8tuRN0A/0cfrKk6p/kplggI3+II0BKTj5qSwiA/IRc3aebqy+2J =3DSUK/ -----END PGP SIGNATURE----- From nobody Fri Mar 13 06:38:11 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 44E171A1F20 for ; Fri, 13 Mar 2015 06:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 1pAcqCZu2U2G for ; Fri, 13 Mar 2015 06:38:08 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946191A037A for ; Fri, 13 Mar 2015 06:38:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 32484E2038; Fri, 13 Mar 2015 09:38:07 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 07392-05; Fri, 13 Mar 2015 09:38:05 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5B4A6E2036; Fri, 13 Mar 2015 09:38:05 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2DDc4qe004179; Fri, 13 Mar 2015 09:38:04 -0400 From: Derek Atkins To: Franklin Wang References: <878uf2iehi.fsf@vigenere.g10code.de> <20150312133846.GA2983@singpolyma-liberty> <87twxqgkmz.fsf@vigenere.g10code.de> <5502DBF1.50007@yahoo.com.au> Date: Fri, 13 Mar 2015 09:38:04 -0400 In-Reply-To: <5502DBF1.50007@yahoo.com.au> (Franklin Wang's message of "Fri, 13 Mar 2015 20:45:37 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 13:38:10 -0000 Franklin Wang writes: > It's very interesting for pure technical users. But do you want to help > ISIS or other terrorists? Pls think over about that. I'm not sure if this was a joke of if you're serious. There's no smiley face, so I'll go under the assumption you were being serious. (If I'm mistaken, feel free to ignore the rest of this message).. I'm afraid the cat is well out of the bag on that one. The tools are out there, and have been out there for well over 20 years already. Tools, like anything, can be used for good or evil. The same tools that you are concerned about are actually being used by Human Rights Activists in countries with Apartheid-like oppressive goverments. Take away the tools and you remove the safety net those worker have! > Franklin -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Fri Mar 13 06:42: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 719D71A7012 for ; Fri, 13 Mar 2015 06:42:21 -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 lIIUlH6AhXTu for ; Fri, 13 Mar 2015 06:42:20 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9E21A700F for ; Fri, 13 Mar 2015 06:42:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 293F5E2038; Fri, 13 Mar 2015 09:42:18 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 07392-06; Fri, 13 Mar 2015 09:42:15 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id B2E63E2036; Fri, 13 Mar 2015 09:42:15 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2DDgEMI005132; Fri, 13 Mar 2015 09:42:14 -0400 From: Derek Atkins To: Werner Koch References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> Date: Fri, 13 Mar 2015 09:42:14 -0400 In-Reply-To: <874mppgyez.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 13 Mar 2015 08:16:20 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 13:42:21 -0000 Werner Koch writes: > On Fri, 13 Mar 2015 04:52, calestyo@scientia.net said: > >> 1) More general things >> - The WG should consider whether to just bring OpenPGP up to date... or >> whether to completely overhaul or even re-design it. > > The please give the thing another name. Recall the outcry whn I removed > PGP-2 support from 2.1. > >> - The basic meshed web of trust must obviously be retained, but apart > > OpenPGP does not define the Web of Trust. There is no standard for it. This was explicitly out of scope from the former OpenPGP WG. I think that was a GOOD THING, and I believe it should remain out of scope. IMHO we shouldn't define how OpenPGP is used, only what it inputs and outputs. >> - Since the X.509 PKI infrastructure in the internet is inherently >> broken and since DANE would only partially improve things (one still >> has several CA's above which could be evil), the time may come in >> which at least some security conscious people would want to use TLS >> or similar with a fully meshable PKI as OpenPGP. >> For that we might need similar things as X.509 got eventually,... >> things like SubjectAlternativeNames for IP, DNS, email, etc. > > We already have this. You may either use a plain user ID with signed > attributes to implement this or, better, extend the attribute packet, > which is currently only used for photo ids, but designed for what you > want. You may already start with this using the 100--110 subpacket > types. For the record, draft-atkins-openpgp-device-certificates already extends the Attribute Subpacket with a String ID (similar to the UserID). > Regarding the rest of your mail, I think it is better to postpone a > detailed discussion for now. > > > Shalom-Salam, > > Werner -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Fri Mar 13 06:46: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 C74711A870A for ; Fri, 13 Mar 2015 06:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 EHZEOILVUg41 for ; Fri, 13 Mar 2015 06:46:20 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCA41A8707 for ; Fri, 13 Mar 2015 06:46:20 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YWPus-0004jU-HQ for ; Fri, 13 Mar 2015 14:46:18 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YWPqo-0002Dz-4i; Fri, 13 Mar 2015 14:42:06 +0100 From: Werner Koch To: Franklin Wang References: <878uf2iehi.fsf@vigenere.g10code.de> <20150312133846.GA2983@singpolyma-liberty> <87twxqgkmz.fsf@vigenere.g10code.de> <5502DBF1.50007@yahoo.com.au> 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 Date: Fri, 13 Mar 2015 14:42:05 +0100 In-Reply-To: <5502DBF1.50007@yahoo.com.au> (Franklin Wang's message of "Fri, 13 Mar 2015 20:45:37 +0800") Message-ID: <87wq2ldnf6.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] How to re-launch the OpenPGP WG 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, 13 Mar 2015 13:46:21 -0000 On Fri, 13 Mar 2015 13:45, franklinwang21st@yahoo.com.au said: > It's very interesting for pure technical users. But do you want to help > ISIS or other terrorists? Pls think over about that. To quote PRZ "If privacy is outlawed, only outlaws will have privacy." Please use other media for such debates. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 13 07:27: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 390A51A01D6 for ; Fri, 13 Mar 2015 07:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cy_YlYrZBI-u for ; Fri, 13 Mar 2015 07:26:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E921A0195 for ; Fri, 13 Mar 2015 07:26:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7FAFEBEBC; Fri, 13 Mar 2015 14:26:55 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w8cCHKelfQR; Fri, 13 Mar 2015 14:26:55 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 491E4BEB5; Fri, 13 Mar 2015 14:26:55 +0000 (GMT) Message-ID: <5502F3AF.8030903@cs.tcd.ie> Date: Fri, 13 Mar 2015 14:26:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Kathleen Moriarty Subject: [openpgp] A new openpgp WG 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, 13 Mar 2015 14:27:01 -0000 Hiya, I've just now subscribed here because Derek sent a pointer to the recent discussion about chartering a new WG. FWIW, as one of the security area directors who might be involved in the chartering stuff, I'm happy to help out as I can, and I'm sure the same goes for Kathleen. But you seem to be doing all the right things already (discuss charter, focus on changes people would likely implement/deploy, meet in bar:-), which is great. A couple of other things to do might be to send a pointer to the general security area list (saag@ietf.org) asking interested folks to subscribe here, (e.g. I think I used be subscribed to the imc hosted list way back but I wasn't on this one) and if the bar-BoF goes ahead, it'd be good for one of you to grab the mic at the saag session in Dallas and report back on that. Please also note that there's no absolute need to have a BoF session (e.g. in Prague in July) before a WG is formed. If a whole bunch of people know that they all want to do a well-scoped useful thing then we may not need one. (The just-formed tokbind WG didn't have a BoF for example.) If OTOH, there's a need for face-to-face discussion about tricky scoping issues or about whether some work should be done at all then a BoF can be a fine thing. In this case, I'd not be surprised if no BoF were needed, in which case we could possibly form a WG before July and get going that much sooner. That said, please keep your focus on the getting the right proposed charter text and don't over-prioritise speed. (Since a lot of people still assume a BoF session and the associated delay are mandatory, I figured it worth pointing out that's not always the case.) Cheers, S. From nobody Fri Mar 13 07:40:13 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 21AED1A89A1 for ; Fri, 13 Mar 2015 07:40:11 -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 hk9-c5ffLbP4 for ; Fri, 13 Mar 2015 07:40:07 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA6B1A8993 for ; Fri, 13 Mar 2015 07:40:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id F3B82E2048; Fri, 13 Mar 2015 10:40:05 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 07696-08; Fri, 13 Mar 2015 10:40:04 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 01852E2049; Fri, 13 Mar 2015 10:40:03 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 13 Mar 2015 10:40:03 -0400 Message-ID: <044d80692c25f0741058d43684c371ac.squirrel@mail2.ihtfp.org> In-Reply-To: <5502F3AF.8030903@cs.tcd.ie> References: <5502F3AF.8030903@cs.tcd.ie> Date: Fri, 13 Mar 2015 10:40:03 -0400 From: "Derek Atkins" To: "Stephen Farrell" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Kathleen Moriarty , openpgp@ietf.org Subject: Re: [openpgp] A new openpgp WG 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, 13 Mar 2015 14:40:11 -0000 Thanks, Stephen, I'm happy to report on the Bar BOF in SAAG, assuming it happens before then. I have not heard any response yet to my proposed Monday-after-the-Plenary time for the Bar BOF. I'll go send mail to SAAG right now. Thanks! -derek On Fri, March 13, 2015 10:26 am, Stephen Farrell wrote: > > Hiya, > > I've just now subscribed here because Derek sent a pointer > to the recent discussion about chartering a new WG. > > FWIW, as one of the security area directors who might be > involved in the chartering stuff, I'm happy to help out as > I can, and I'm sure the same goes for Kathleen. But you seem > to be doing all the right things already (discuss charter, > focus on changes people would likely implement/deploy, > meet in bar:-), which is great. > > A couple of other things to do might be to send a pointer > to the general security area list (saag@ietf.org) asking > interested folks to subscribe here, (e.g. I think I used be > subscribed to the imc hosted list way back but I wasn't on > this one) and if the bar-BoF goes ahead, it'd be good for > one of you to grab the mic at the saag session in Dallas > and report back on that. > > Please also note that there's no absolute need to have a > BoF session (e.g. in Prague in July) before a WG is formed. > If a whole bunch of people know that they all want to do a > well-scoped useful thing then we may not need one. (The > just-formed tokbind WG didn't have a BoF for example.) If > OTOH, there's a need for face-to-face discussion about > tricky scoping issues or about whether some work should be > done at all then a BoF can be a fine thing. In this case, > I'd not be surprised if no BoF were needed, in which case > we could possibly form a WG before July and get going that > much sooner. That said, please keep your focus on the > getting the right proposed charter text and don't > over-prioritise speed. (Since a lot of people still > assume a BoF session and the associated delay are mandatory, > I figured it worth pointing out that's not always the > case.) > > Cheers, > S. > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 13 09:29:59 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 9F3B41A0099 for ; Fri, 13 Mar 2015 09:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xWkT4A9UNJvq for ; Fri, 13 Mar 2015 09:29:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265B31A0013 for ; Fri, 13 Mar 2015 09:29:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l3XYX4cBsz1KX; Fri, 13 Mar 2015 17:29:52 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=Q03jOkpi; dkim-adsp=pass X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2WpIP4MKdauw; Fri, 13 Mar 2015 17:29:39 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 13 Mar 2015 17:29:36 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4DD4280416; Fri, 13 Mar 2015 12:29:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426264175; bh=FeD4G10EwVgP8VComp+DMvFLlcWOQXu3LjH+EMyBcjg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Q03jOkpiz1QC6KQRoXkpb65XoIlRSDjtA3f8gVp8D2O/kYdJXGjz9KV3ad3mwDvMO UWBs9/e+6HIm9Ri7+ZmLUQU9oZjC7u+7BYqPBfk/7bBlxknUQtZCTP5aq23kf+f9Jj P5tQN7g28mpXB1NBbQ5bPw6kPcKIRpjhEelG/Kzs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2DGTYgO023656; Fri, 13 Mar 2015 12:29:34 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 13 Mar 2015 12:29:34 -0400 (EDT) From: Paul Wouters To: Derek Atkins In-Reply-To: Message-ID: References: <878uf2iehi.fsf@vigenere.g10code.de> <87zj7hvgzp.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: openpgp@ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 16:29:57 -0000 On Thu, 12 Mar 2015, Derek Atkins wrote: > Okay, there is clearly an interest in forming something, so... > > Who will be in Dallas? > When would be a good time to have a BAR BOF? > I propose we meet Monday after the plenary? I will be there and the time slot works for me. Paul From nobody Fri Mar 13 12:51:24 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 7A1371A1B1E for ; Fri, 13 Mar 2015 12:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNdI4vEk9kbm for ; Fri, 13 Mar 2015 12:51:22 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 07D3D1A1AA5 for ; Fri, 13 Mar 2015 12:51:22 -0700 (PDT) Received: by lbdu14 with SMTP id u14so25116498lbd.0 for ; Fri, 13 Mar 2015 12:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N/V3XE6/Yqv/3P0PFRW8P4qGEayXuOQzRfcJktVP0qE=; b=CQykGyBdjsmm4g1KFaFpuUWrvj7x5h25T6agSTmHzoO8NeXnjI+ck+Hmp78t1izoHq WiUBa8aKtZy5jgZZd2Yp0a0ELKoMjyrdENeNEE2jtxzVmDl0k09QjLvLZRpCpXIRSxrr qq4fvaOtxKDgXf/l2DK9bzIfps7betiFjRsOoOqRyeSDNzE9cRDIk6dr5VfM/ZKb2fkE Ox+5xfi8QXw64Ew1FATjTOPodp55osYIZwIeqAOEfrT2Ec1Wbob7eTpnmsB02TEtSNq6 tdMqVWyUiV1rc5wtNasB6nfE/XjQYX2AgwpxlNnevnETPiSrLhUpLMrDFNP6oCSP/WJ+ JBQQ== MIME-Version: 1.0 X-Received: by 10.112.51.35 with SMTP id h3mr35461608lbo.113.1426276280419; Fri, 13 Mar 2015 12:51:20 -0700 (PDT) Received: by 10.25.13.4 with HTTP; Fri, 13 Mar 2015 12:51:20 -0700 (PDT) In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> Date: Fri, 13 Mar 2015 15:51:20 -0400 Message-ID: From: DataPacRat To: Derek Atkins Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 19:51:23 -0000 On Fri, Mar 13, 2015 at 9:42 AM, Derek Atkins wrote: > Werner Koch writes: >> On Fri, 13 Mar 2015 04:52, calestyo@scientia.net said: >>> 1) More general things >>> - The WG should consider whether to just bring OpenPGP up to date... or >>> whether to completely overhaul or even re-design it. >> >> The please give the thing another name. Recall the outcry whn I removed >> PGP-2 support from 2.1. >> >>> - The basic meshed web of trust must obviously be retained, but apart >> >> OpenPGP does not define the Web of Trust. There is no standard for it. > > This was explicitly out of scope from the former OpenPGP WG. I think > that was a GOOD THING, and I believe it should remain out of scope. > IMHO we shouldn't define how OpenPGP is used, only what it inputs and > outputs. I'm interested in certain aspects of Webs of Trust, such as their potential to overcome certain problematic aspects of centralized Certificate Authorities. If this new OpenPGP WG won't be a suitable place to discuss such possibilities, then what will be? Thank you for your time, -- DataPacRat "Then again, I could be wrong." From nobody Fri Mar 13 13:00:09 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 0043D1A1A03 for ; Fri, 13 Mar 2015 13:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 wRkrDwfwR9r2 for ; Fri, 13 Mar 2015 13:00:08 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 ECD0D1A0019 for ; Fri, 13 Mar 2015 13:00:07 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so122903535iec.1 for ; Fri, 13 Mar 2015 13:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K+pQ+fE18DoHghY5a5cQd/aK3wvufaG32p7Mfr9XQN4=; b=lAawmqLlUq0WP9RcvqhQxDvBKaZg7PSn2lx4xvcbQOjC/0MHcwBt5ol1yE+7Q0zH/x ZkmdOXCQ/NJmXM1c9AzYm/XI3ZJEJQg9hqM3eRN4BzEbfjPx7DKIxL4hIzsVvUvT617R 9QWRBw6aDxXL+KRUArv7RY6l/XUIclEf2a1YQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=K+pQ+fE18DoHghY5a5cQd/aK3wvufaG32p7Mfr9XQN4=; b=gL3QlnhZB1pn5ej4yIYK+xoxdqsCwcCdGOocCHRrLuetdR7nWZqDBuz8PQdmo3EOkL H4ZhlMqGsNjXb5zSt09yU45vYaiMUvkuvL5NXBhL2fswWCet7dl074xj02ifro+WwRIY SJVA4rxFq7gFf9YjIz8/qAF5T7l5wrXK1dxTsX/yEMVTY94GE+2CUUiN6ux0DX1HQ2Ga sXLXRl6aS7EwwoG3+/KylWnEimJS+HcZ3SQVRXr7O8GTOl9arKJsGT7RPIVtvcFk/5kX koZxpKdcBuKgbpRku8TVE+ex1a0nI+G5YczwDeHkU5YR3dnul/YTzPooTHJqtH2UP6YS 8dGA== X-Gm-Message-State: ALoCoQnte6/LUHvNYoHBtBju9zxalfPNaOz3TKJNTL79jlws5Frc9l66796fEIJJnJf1t5NdJbUq X-Received: by 10.50.67.100 with SMTP id m4mr46797029igt.32.1426276802260; Fri, 13 Mar 2015 13:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.14.142 with HTTP; Fri, 13 Mar 2015 12:59:41 -0700 (PDT) In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> From: Tom Ritter Date: Fri, 13 Mar 2015 14:59:41 -0500 Message-ID: To: DataPacRat Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Derek Atkins , Werner Koch , Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 13 Mar 2015 20:00:09 -0000 On 13 March 2015 at 14:51, DataPacRat wrote: > I'm interested in certain aspects of Webs of Trust, such as their > potential to overcome certain problematic aspects of centralized > Certificate Authorities. If this new OpenPGP WG won't be a suitable > place to discuss such possibilities, then what will be? > > > Thank you for your time, https://www.ietf.org/mailman/listinfo/therightkey -tom From nobody Fri Mar 13 15:46:13 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 38DA81A872A for ; Fri, 13 Mar 2015 15:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q1JMLZtgQ13Z for ; Fri, 13 Mar 2015 15:46:08 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5606F1A0217 for ; Fri, 13 Mar 2015 15:46:08 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id DB9C25FB76 for ; Fri, 13 Mar 2015 22:46:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id ndSX3zqP1Ccm for ; Fri, 13 Mar 2015 22:46:03 +0000 (UTC) Received: from heisenberg.scientia.net (p579DF58E.dip0.t-ipconnect.de [87.157.245.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Fri, 13 Mar 2015 22:46:03 +0000 (UTC) Message-ID: <1426286762.4943.2.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Fri, 13 Mar 2015 23:46:02 +0100 In-Reply-To: <5502F3AF.8030903@cs.tcd.ie> References: <5502F3AF.8030903@cs.tcd.ie> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-puUSwAMxpdCcU45M510n" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] A new openpgp WG 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, 13 Mar 2015 22:46:12 -0000 --=-puUSwAMxpdCcU45M510n Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-03-13 at 14:26 +0000, Stephen Farrell wrote:=20 > A couple of other things to do might be to send a pointer > to the general security area list (saag@ietf.org) asking > interested folks to subscribe here I think the same should be done for other well known crypto lists like cryptography@metzdowd.com or the CFRG,... Cheers, Chris. --=-puUSwAMxpdCcU45M510n Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxMzIyNDYw MlowTwYJKoZIhvcNAQkEMUIEQH3U5Vb5nSV/e91o2AgUHihCvu0OwXRQFOaUv+t8RilbpGxRFS2b btGCi46NvZ47V/ghFrGdBeuQiDAdGG6Z/S4wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQADodc6X5bSX72jr9MQNFtEfQ7vNSb9 cxYJMrvs0teyV8cdUD+ZIC+o8KoAN8MPu1od55HgrZ2KlLMYracTfqHlpP5M6JGLSGGDhzPJaobL j1KXm5WGk/LxHGmylHCMD4p8asZHKYfJNIFASw4+9n6ZE/0mqReOU/qOEzWr5/taU0e+bVMXO9ir NrYzuGCMwX/smUqFTb8j4mwZGrIbAkI8OzcNcR8c0LOFLZh2uYiRwwr1ptr35KMbew2sW6G0va1f hDCpLMaaxe8vcZr2MYZ4f2TUHeWAp0DPSdhI9LAMmrtsWPI4LIp1WC1X4mDzYoUABQRdgDgK+06d UH2NA1xPAAAAAAAA --=-puUSwAMxpdCcU45M510n-- From nobody Fri Mar 13 16:37: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 685B91A87D7 for ; Fri, 13 Mar 2015 16:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_16=0.6, 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 2pwnQMHNSuwZ for ; Fri, 13 Mar 2015 16:37:00 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::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 E06BB1A87D2 for ; Fri, 13 Mar 2015 16:36:59 -0700 (PDT) Received: by yhch68 with SMTP id h68so842799yhc.1 for ; Fri, 13 Mar 2015 16:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aAVZpbfVmR5na/o2kGiDxKwZ6EASoG47Kfc8fJUdzSA=; b=yjyvwbMIfHkxSQkD1Yyy0t0oyD5Iag8DgaFI6r3bZJfUu6byN4PPcxPiPrDzgWtF4C LgqTZLis1+rEmwvqRJJkE8KGteKGOWb42bTb8zpXgClTNJs0U8HPuzZ1x/sSXqeMO1nF z4eVBsJLBxCfWd11zBNO/JAtPTmnkIu8hopaUfY2vpwP7GLz82gLc/8y87BiazIKTx6S iQPVzoh92g7ArQ/sbfPSP/wnursD63nqIFcALL8UbndPlzOZlEO8RvNZWI/IEmDeyrZO VmowOzxXjstlFLAjJt16SsvdtZHvwBZnk1z7iUta2mEcIiVhTTal87Hdtg9VYWqVU4TW X8tw== X-Received: by 10.170.113.130 with SMTP id f124mr56489804ykb.90.1426289819209; Fri, 13 Mar 2015 16:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.125.80 with HTTP; Fri, 13 Mar 2015 16:36:39 -0700 (PDT) In-Reply-To: <5502F3AF.8030903@cs.tcd.ie> References: <5502F3AF.8030903@cs.tcd.ie> From: David Leon Gil Date: Fri, 13 Mar 2015 16:36:39 -0700 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Kathleen Moriarty , "openpgp@ietf.org" Subject: Re: [openpgp] A new openpgp WG 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, 13 Mar 2015 23:37:01 -0000 It is unlikely I would be able to attend the March IETF with such short notice. (I also have other travel plans in this timeframe.) Therefore, Yahoo would request that the IETF defer action. (July sounds fine.) Both Yahoo and Google are presently planning deployment of a browser extension using OpenPGP. (Google's open-source branch is at https://github.com/google/end-to-end; our branch will be open-sourced soon at https://github.com/yahoo/end-to-end.) We would expect this to be one of the larger deployments of OpenPGP, and to face unique constraints (because of its implementation in JavaScript, and deployment via the Web Platform). I am hopeful that feedback on the open-source extensions will prove useful in whatever standards process may emerge. David Leon Gil Senior Paranoid Yahoo! PS. This is a statement of Yahoo's position. This message is sent from a Gmail account because Yahoo sets a strict DMARC policy, which may result in some recipients MTAs (e.g. Google's) dropping a message. See http://dmarc.org/faq.html#s_3 for things mailing lists can do to avoid this. There are also things webmail providers can do to mitigate this problem, but Google won't do them. The benefits to DKIM are tremendous, w.r.t. protection of users from phishing or other malicious emails. I strongly encourage mailing list owners and webmail providers to take steps to ensure that all users' messages are correctly handled with a DKIM p=reject. On Fri, Mar 13, 2015 at 7:26 AM, Stephen Farrell wrote: > > Hiya, > > I've just now subscribed here because Derek sent a pointer > to the recent discussion about chartering a new WG. > > FWIW, as one of the security area directors who might be > involved in the chartering stuff, I'm happy to help out as > I can, and I'm sure the same goes for Kathleen. But you seem > to be doing all the right things already (discuss charter, > focus on changes people would likely implement/deploy, > meet in bar:-), which is great. > > A couple of other things to do might be to send a pointer > to the general security area list (saag@ietf.org) asking > interested folks to subscribe here, (e.g. I think I used be > subscribed to the imc hosted list way back but I wasn't on > this one) and if the bar-BoF goes ahead, it'd be good for > one of you to grab the mic at the saag session in Dallas > and report back on that. > > Please also note that there's no absolute need to have a > BoF session (e.g. in Prague in July) before a WG is formed. > If a whole bunch of people know that they all want to do a > well-scoped useful thing then we may not need one. (The > just-formed tokbind WG didn't have a BoF for example.) If > OTOH, there's a need for face-to-face discussion about > tricky scoping issues or about whether some work should be > done at all then a BoF can be a fine thing. In this case, > I'd not be surprised if no BoF were needed, in which case > we could possibly form a WG before July and get going that > much sooner. That said, please keep your focus on the > getting the right proposed charter text and don't > over-prioritise speed. (Since a lot of people still > assume a BoF session and the associated delay are mandatory, > I figured it worth pointing out that's not always the > case.) > > Cheers, > S. > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Fri Mar 13 17:04:31 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 81E011A87CD for ; Fri, 13 Mar 2015 17:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYW0z5vjU5vm for ; Fri, 13 Mar 2015 17:04:28 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 573B61A89B5 for ; Fri, 13 Mar 2015 17:04:27 -0700 (PDT) Received: by ykft125 with SMTP id t125so54691ykf.1 for ; Fri, 13 Mar 2015 17:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=QLvf4ZmTejaoPVUdkKK5TBllZ9CbPAqupHwLGg3yeKI=; b=DlIONbDlYJpPO8G2RG30MQQSx+gyzULdAeOQ3GuL5i7nSqCxU2NnBMsb/cdvx8LJxx EP/t+4KttSP7jiygsc4hy8g4MflnfCob73wmQ2aKb6Jeuku4d+fquOF2Lj+5vySVkO/W E/MimC7HcXYzxvf4sPtPzlUzS90Ys6RoBoD/oiJa9dXa5chfGRHqmkWT36cn0YVjz2pe X2dywGQE3Ff6UFkfDWGA3JWVNoy0pdRTwskLSOWXHTqzuTBYHenusTp1B6XUtY5fwwWg 5owxMcpWNTWfg62Sw6cXeoeirblL1JRNjm7e+nLdDb5cCVUdGInN5DaskNq8P7xkjmI+ mM9w== X-Received: by 10.170.113.130 with SMTP id f124mr56571092ykb.90.1426291466735; Fri, 13 Mar 2015 17:04:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.125.80 with HTTP; Fri, 13 Mar 2015 17:04:06 -0700 (PDT) From: David Leon Gil Date: Fri, 13 Mar 2015 17:04:06 -0700 Message-ID: To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] The combinatorial complexity of OpenPGPv4 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, 14 Mar 2015 00:04:29 -0000 Suppose that I want to test whether an implementation handles all OpenPGPv4 signed-then-encrypted messages correctly. How many test cases do I need? Let's suppose, first, that I prove that handling of PTag formats is independent of the rest of the code. In that case, the packet composition is either: PKESK SEIPD COMPRESSED LITERAL SIGNATURE MDC Or: PKESK SE COMPRESSED LITERAL SIGNATURE How many different ways can I compose this message? 15 * 24 * 4 * 3 * 35 - 15: PKESK - RSA-ES - RSA-E - ELG-E - 12 ECDH combinations: - 3 curves - P-256 - P-384 - P-521 - 4 KDF hash algorithms - SHA2-224 - SHA2-256 - SHA2-384 - SHA2-512 - 24: SEIPD - 2 choices of packet type - SE - SEIPD - 12 encryption algorithms - Plaintext (prohibited) - IDEA - TripleDES - CAST5 - Blowfish - AES128 - AES192 - AES256 - Twofish - CAMELLIA128 - CAMELLIA192 - CAMELLIA256 - 4: Compressed - Uncompressed - ZLIB - DEFLATE - BZIP2 - 3: Literal - UTF-8 - Binary - Local - 35: Signature - 5 asymmetric algorithms: - RSA-ES - RSA-S - DSA - ECDSA - ED25519 (GnuPG) - 7 hash algorithms: - MD5 - SHA-1 - RIPEMD160 - SHA2-224 - SHA2-256 - SHA2-384 - SHA2-512 Or: 151,200 test cases. For the simplest message anyone wants to send. Not including any of the details of signature subpackets, or unusual (but valid) variants of PKESKs etc. I previously calculated that number, but it is so absurdly huge I won't bother. - David From nobody Fri Mar 13 17:41:45 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 C2E791A90A4 for ; Fri, 13 Mar 2015 17:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_IHmqWW53Dp for ; Fri, 13 Mar 2015 17:41:41 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 C8F161A9062 for ; Fri, 13 Mar 2015 17:41:39 -0700 (PDT) Received: by ykek76 with SMTP id k76so249540yke.0 for ; Fri, 13 Mar 2015 17:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=XPyj+i4WPwkxetUI5DLOM8IEv+L/Vmb/w3bJNuHV7Pc=; b=tRPELeUXEKdL2Cbu87yufhdkyHw1eFCTWCSk6Y60O1LuJovDJrSDTAoShEy5GgpiTW w5JVdyaBXOcTcsiNFbQvgFXaPpsTHMz6Z3fzF53jw/CNESYbgIKbDP1AYw9Mwx6Rbz0r mjAsV2ZrYtHy/eRWs027dVuNnlyqQ01gqDXxzVJfgoLPEjnr9Hs4Wuq5qzhuhhre8qZ+ l2ahVNlQHKndYiqLgEBbbq2J6Vba+W3qEt8TRPQvvJPXrQ6PQYsTHC4Xpu3TPafrG37h n9TNFm9OOERUkacUp3uWGIzN/OVK8/saKI5DYxCBEPZ/CG4Raoo+fLPX86vw0u3OcVSI X/4g== X-Received: by 10.236.105.210 with SMTP id k58mr49131941yhg.52.1426293699190; Fri, 13 Mar 2015 17:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.125.80 with HTTP; Fri, 13 Mar 2015 17:41:18 -0700 (PDT) From: David Leon Gil Date: Fri, 13 Mar 2015 17:41:18 -0700 Message-ID: To: "openpgp@ietf.org" , "dgil@yahoo-inc.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] New encryption formats for messaging 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, 14 Mar 2015 00:41:42 -0000 Some desiderata, generally: A0. Be as secure as possible by default. Do not offer options to fallback to doing unsafe things. "Experienced" users often think they want them; there are usually better solutions for their use-cases. A1. Only specify a single asymmetric encryption scheme and a single asymmetric signature scheme. This is critical: This is the second most dangerous and buggy code in any crypto scheme. A2. Clearly separate handling of various message and key metadata from the underlying encryption scheme. This is critical: Parsing code is the most dangerous and buggy code in any crypto scheme. A3. Do not specify things which are infeasible to thoroughly test. This implies avoiding combinatorial complexity, which the OpenPGPv4 spec doesn't. A4. All messages, including signed but unencrypted messages, should be indistinguishable from random to an adversary who does not know the public key of the signer. (This is, essentially, a Tor-style security requirement.) Some desiderata for symmetric primitive choices: B1. Only modern hash functions that provide a significant security margin against cryptanalysis. Let's not repeat the MD-5/SHA-1 disaster. (We only need two hash functions at most.) B2. Only block and stream ciphers that offer a significant margin of safety against cryptanalysis. (Or that, when composed, offer a significant margin of safety against cryptanalysis.) B3.. A single AEAD mode that is maximally misuse-resistant, in the sense of https://eprint.iacr.org/2014/793. (But probably not AEZ, or any other CAESAR competitor for that matter. I would prefer a scheme that uses generic composition of well-studied primitives.) Thus, what any proposal should specify, at the crypto level: C1. A single curve providing security above the 192-bit-equivalent level. (This is because the *tightest* security reductions for any concrete instantiation of EC primitives result in a security level of ~ 120-bits for a 384-bit curve.) C2. A single message format intended for use with signed and encrypted messages of length >> 128 bytes and << 2^24 bytes. (That is, something appropriate for email. I would consider encryption of large files and very short messages out of scope at this time.) I am agnostic as to whether encrypted-then-signed or signed-then-encrypted is preferable. I am curious if anyone else has strong views on this? C3. A single message format intended for detached signatures. This should target, specifically, the common use-case of OpenPGP signatures for code-signing. C4. Specify a mechanism for encapsulating a signature over the body of an HTML email in a way that is compatible with HTML email as commonly used. This signature should be indifferentiable from random for anyone who does not know the public key of the sender. (This last should be easy. A concrete proposal: If a "data-openpgp-sig" attribute is present on a tag, it contains a base64urlsafe-encoded signature over the contents of that tag, with no special normalization rules applied. This can be made more precise by reference to the HTML5 spec.) And what a proposal should specify, for various key and message metadata: D1. A standard format for encapsulating arbitrary key and message metadata. D2. Mappings from OpenPGPv3 metadata to that format, as appropriate. -- Final comment: I am, quite frankly, agnostic as to whether an IETF WG or another forum is the most appropriate place to specify something. The IETF lately has not seemed to be so much about canonizing "de facto" standards (which it was good at) as design-by-committee (which it isn't). And recent revelations have shown that design-by-committee is -- besides being irritating for implementors -- a boon to intelligence agencies. So: I would encourage anyone interested in seeing something standardized to make a complete proposal a la Hugo Krawycz's OP-TLS proposal for TLS1.3. But implement the proposal first. Working code &c. Taking a scattershot approach will lead to a shoddy, messy, unsafe result. Yahoo will not support a specification that, by sloppiness or untestability, makes our users unsafe. David Leon Gil Senior Paranoid Yahoo! From nobody Fri Mar 13 18:20:10 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 8EF201A8876 for ; Fri, 13 Mar 2015 18:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 NG_hf_CQniJM for ; Fri, 13 Mar 2015 18:20:03 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id AF6EC1A8871 for ; Fri, 13 Mar 2015 18:20:03 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id EADE013F42DF; Fri, 13 Mar 2015 19:20:02 -0600 (MDT) X-Spam-ASN: Received: from [192.168.0.5] (c-24-143-80-128.customer.broadstripe.net [24.143.80.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id E001C13F428C for ; Fri, 13 Mar 2015 19:20:00 -0600 (MDT) Message-ID: <55038CBE.7070608@iridiumlinux.org> Date: Fri, 13 Mar 2015 18:19:58 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010306010408020008060605" Archived-At: Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 14 Mar 2015 01:20:07 -0000 This is a cryptographically signed message in MIME format. --------------ms010306010408020008060605 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I feel like perhaps this type of exhaustive testing is neither necessary nor expected, and that a few end-to-end tests designed to exercise edge cases could be combined with more exhaustive unit tests to achieve reasonable results. Protocol modularity is not evil. --Falcon Darkstar Momot --Shadytel On 13/03/2015 17:04, David Leon Gil wrote: > Suppose that I want to test whether an implementation > handles all OpenPGPv4 signed-then-encrypted messages > correctly. How many test cases do I need? > > Let's suppose, first, that I prove that handling of > PTag formats is independent of the rest of the code. > > In that case, the packet composition is either: > > PKESK > SEIPD > COMPRESSED > LITERAL > SIGNATURE > MDC > > Or: > > PKESK > SE > COMPRESSED > LITERAL > SIGNATURE > > How many different ways can I compose this message? > > 15 * 24 * 4 * 3 * 35 > - 15: PKESK > - RSA-ES > - RSA-E > - ELG-E > - 12 ECDH combinations: > - 3 curves > - P-256 > - P-384 > - P-521 > - 4 KDF hash algorithms > - SHA2-224 > - SHA2-256 > - SHA2-384 > - SHA2-512 > - 24: SEIPD > - 2 choices of packet type > - SE > - SEIPD > - 12 encryption algorithms > - Plaintext (prohibited) > - IDEA > - TripleDES > - CAST5 > - Blowfish > - AES128 > - AES192 > - AES256 > - Twofish > - CAMELLIA128 > - CAMELLIA192 > - CAMELLIA256 > - 4: Compressed > - Uncompressed > - ZLIB > - DEFLATE > - BZIP2 > - 3: Literal > - UTF-8 > - Binary > - Local > - 35: Signature > - 5 asymmetric algorithms: > - RSA-ES > - RSA-S > - DSA > - ECDSA > - ED25519 (GnuPG) > - 7 hash algorithms: > - MD5 > - SHA-1 > - RIPEMD160 > - SHA2-224 > - SHA2-256 > - SHA2-384 > - SHA2-512 > > Or: 151,200 test cases. For the simplest message anyone > wants to send. > > Not including any of the details of signature subpackets, > or unusual (but valid) variants of PKESKs etc. I previously > calculated that number, but it is so absurdly huge I won't > bother. > > - David > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --------------ms010306010408020008060605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUjCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFMDCCBBigAwIBAgIRAN3sgt3ll/yQeOZPRId2L3IwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjEwMDAwMDAwWhcNMTUwNjEwMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhdmYWxjb25AaXJp ZGl1bWxpbnV4Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANFEuUdfP+wv X950Km0FMhQMuSGDWruO3Wy6Vxf4kgEcGqDl73zZzQ7vohYUEtUc3kyluw9qwk42FGqHSs5Y pW5CDWr85Ov167Z3DwjCHJ2cA9qtTCD0GwjW9MkYRDQpWs87pq9Ur51G0/mkiG4y4Xkif4Dl 28R2YM3QIvs1XL6bobjmcyt30eZrArkgNuBBmcAybuo0pqFlBaKud8HcgrOR91keU7mAqJIz MVnV+jBeFbX5Rs7RXAtJBM1n3u48w8v3V/2E034DBa0vjhyafpPDKv9LQ4LyJysBZ9uIArCk 7HJqzGO2kT/6cXFbwCphHY5C3IMPx0FdMboi2isoDsUCAwEAAaOCAecwggHjMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTmkI6vq81eszHm8NLf/xOfFPDl ozAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1Ud HwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEF BQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMA0GCSqGSIb3DQEB BQUAA4IBAQABMQFyXEQDcedRrbgAbhuMFztPeTMz+XuM/tybABL8aCzxyB3b7tiJ1kY5jMA1 2O7bydcen9XGfXI2RZM2btU2zoOSYqdh9SoLX1pSIL2P48b7PV7SYK/iruplh8S/s9+/ziav 2f1q2LT3aN4brT+QBDHLz0+/g6sYNg6nnNbHBGT3uTX4mSS9iP5IohKmKmHGCKFXXiWmcRCU 1CynAd9fmQroFXRpJYtbRbR1nEpUfJ2NGffKO7qLkA+X2H9ORvBQvuBa20P5Q4sjehTX87d+ zdbtA4lxOsA5/MSoeZ+LKlx1hXmY+i/qmjlZO42FpMBKGQYW9ioJ8vSiiSHjarAuMYIEHDCC BBgCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDd 7ILd5Zf8kHjmT0SHdi9yMAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxNDAxMTk1OFowIwYJKoZIhvcNAQkEMRYEFIuvYTWl KT7CKzQdAdwXxeAecSXHMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAN3sgt3ll/yQeOZPRId2L3IwgbwGCyqGSIb3 DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcG A1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEA3eyC3eWX/JB45k9Eh3YvcjANBgkqhkiG9w0BAQEFAASCAQA8Lo1NTCk9ezhgjtW9XkKd f/rVOz2PRpws9mPLEsgf/Zk1p7Tu1NppmRCNwEkFOupSTFcUCBJrC4746bsilNC4ppQUonjc NWMaOeKAdd6gTQHmkosuOpYuntN+fpgEoXVEqXCfqEbbQMxozNX+HeZKFXym5rWSJu3K8F+H kAAjb2VrqroKIsSMHsyWYirYSz3IAR8D3miVsMaTNA9Dj/C8goWaJ9oybHunBsK4Uakv+fwF gDlbiRa1sYLK1gtklQXp2DcUMhQDnvW0m7mZW4pCpBf+GjhA1dpfI1AoKXg68BW1ZSmU4rFr oxkVY9phrQ2bQ6G2DnqsZI/2TmKVWgAXAAAAAAAA --------------ms010306010408020008060605-- From nobody Fri Mar 13 18:22:59 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 E19041A88A3 for ; Fri, 13 Mar 2015 18:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqPRtZ9_k9NH for ; Fri, 13 Mar 2015 18:22:55 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 480E21A887B for ; Fri, 13 Mar 2015 18:22:55 -0700 (PDT) Received: by ykcn8 with SMTP id n8so449878ykc.3 for ; Fri, 13 Mar 2015 18:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ycxh0SsClOX8dsHMbH4C7VB/7N4N4c7ELuIVRjmtKe0=; b=MZKCTj5ZpBc0QL4z/zKZa4tWyOTmGJhWtEmAn73+Atd/cEugQnJZC+38VwKDjtrZQ4 GROM2PXvmXfn/1735C0FfxQj78jI7ETY+r1yr5j+GLcBKdn3Igf7ql4ZlxPXdQ3aBxNd LaGIy93sDRJPg8FUzddLQ4KCbg9KrvKeppeLk0vggNml2XAlfoQ6FVktfsoU+iQr5lXM SY8FxvXupz+SqZZyp7JDrM3myeds3Y3+XAoshOmVyoQ7O68AVlG0liukcNcwLNdJcnyY rkhesFjbCpAgd/h65oaohS9MAyr9sc0BgJ/jZCkVfL6x5VTsEYnxIAhudHlXnBCCTuJQ eIjQ== X-Received: by 10.236.209.35 with SMTP id r23mr49307849yho.26.1426296174638; Fri, 13 Mar 2015 18:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.125.80 with HTTP; Fri, 13 Mar 2015 18:22:34 -0700 (PDT) From: David Leon Gil Date: Fri, 13 Mar 2015 18:22:34 -0700 Message-ID: To: "openpgp@ietf.org" , "dgil@yahoo-inc.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] Intent to deprecate: Insecure primitives 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, 14 Mar 2015 01:22:58 -0000 First, the fait accompli: 1. Yahoo and Google have both already deprecated and removed support for the following packet type specified for use with OpenPGPv4: Tag 9 (symmetrically encrypted) packets These packets provide unauthenticated encryption and -- if supported -- can be used in a downgrade attack on senders who only use SEIPD packets. See https://github.com/coruus/cooperpair/tree/master/encrux for details. 2. Yahoo and GnuPG have both already deprecated V3 public keys for any use. We recommend that other implementations do the same. -- Second, the near future: Yahoo has deprecated, and intends to disable support for all uses, of the following primitives and packet types specified for use with OpenPGP v4: - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish - Asymmetric algorithms, generally: RSA-ES, DSA. - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, ELG-E. - Compression algorithms: ZLIB. (It provides no benefits over DEFLATE, and is more malleable.) - Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224. We do not, at present, support any of the CAMELLIA algorithms or BZIP2. It is unlikely that we will do so in future. At present, we anticipate removing support for these primitives no later than May 1, 2015. -- Third, other things that will be deprecated soonish: 1. Inconsistent combinations of primitives. In particular, it is likely that we will not support RFC 6637 keys or packets unless they conform to the 128-bit or 192-bit subprofiles specified in that document. (We do not at present support P-521, but if we add support for that, we would support an analogous "256-bit" subprofile.) 2. AES-128. The efficiency of multi-target attacks leaves no safety margin for cryptanalysis. The performance difference between AES-128 and AES-256 on typical messages is negligible. -- Finally, other things that may eventually result in messages or keys being treated as invalid: 1. A published public key that is more than 1 year old. (This is mainly taken care of by requiring > 3070 bit RSA keys...) 2. Signature by a public key which has ever signed a message or key using MD-5 or SHA-1. 3. A compressed or literal data packet tag that is unusually formatted. 4. A compression method other than "Uncompressed". David Leon Gil Senior Paranoid Yahoo! From nobody Fri Mar 13 18:30:47 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 CA9421A90F7 for ; Fri, 13 Mar 2015 18:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 mgN24gMfBXjQ for ; Fri, 13 Mar 2015 18:30:40 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id DCA161A88F8 for ; Fri, 13 Mar 2015 18:30:39 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 8665F13F42DF; Fri, 13 Mar 2015 19:30:39 -0600 (MDT) X-Spam-ASN: Received: from [192.168.0.5] (c-24-143-80-128.customer.broadstripe.net [24.143.80.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id BB89D13F428C for ; Fri, 13 Mar 2015 19:30:37 -0600 (MDT) Message-ID: <55038F3C.40207@iridiumlinux.org> Date: Fri, 13 Mar 2015 18:30:36 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080803000008080004060203" Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 14 Mar 2015 01:30:42 -0000 This is a cryptographically signed message in MIME format. --------------ms080803000008080004060203 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, I can get behind that. Make it so! Users should be presented with secure defaults and not given the opportunity to unknowingly decrease security. Deprecating lower-security but equivalently performant algorithms is especially commendable. That said, archived encrypted data may require decryption support well into the future. OpenPGP-encrypted data is not ephemeral like TLS-encrypted data. --Falcon Darkstar Momot --Shadytel On 13/03/2015 18:22, David Leon Gil wrote: > First, the fait accompli: > > 1. Yahoo and Google have both already deprecated and removed support > for the following packet type specified for use with OpenPGPv4: > > Tag 9 (symmetrically encrypted) packets > > These packets provide unauthenticated encryption and -- if supported > -- can be used in a downgrade attack on senders who only use SEIPD > packets. See https://github.com/coruus/cooperpair/tree/master/encrux > for details. > > 2. Yahoo and GnuPG have both already deprecated V3 public keys for any > use. We recommend that other implementations do the same. > > -- > > Second, the near future: > > Yahoo has deprecated, and intends to disable support for all uses, of > the following primitives and packet types specified for use with > OpenPGP v4: > > - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish > - Asymmetric algorithms, generally: RSA-ES, DSA. > - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, EL= G-E. > - Compression algorithms: ZLIB. (It provides no benefits over DEFLATE, > and is more malleable.) > - Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224. > > We do not, at present, support any of the CAMELLIA algorithms or > BZIP2. It is unlikely that we will do so in future. > > At present, we anticipate removing support for these primitives no > later than May 1, 2015. > --------------ms080803000008080004060203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUjCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFMDCCBBigAwIBAgIRAN3sgt3ll/yQeOZPRId2L3IwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjEwMDAwMDAwWhcNMTUwNjEwMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhdmYWxjb25AaXJp ZGl1bWxpbnV4Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANFEuUdfP+wv X950Km0FMhQMuSGDWruO3Wy6Vxf4kgEcGqDl73zZzQ7vohYUEtUc3kyluw9qwk42FGqHSs5Y pW5CDWr85Ov167Z3DwjCHJ2cA9qtTCD0GwjW9MkYRDQpWs87pq9Ur51G0/mkiG4y4Xkif4Dl 28R2YM3QIvs1XL6bobjmcyt30eZrArkgNuBBmcAybuo0pqFlBaKud8HcgrOR91keU7mAqJIz MVnV+jBeFbX5Rs7RXAtJBM1n3u48w8v3V/2E034DBa0vjhyafpPDKv9LQ4LyJysBZ9uIArCk 7HJqzGO2kT/6cXFbwCphHY5C3IMPx0FdMboi2isoDsUCAwEAAaOCAecwggHjMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTmkI6vq81eszHm8NLf/xOfFPDl ozAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1Ud HwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEF BQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMA0GCSqGSIb3DQEB BQUAA4IBAQABMQFyXEQDcedRrbgAbhuMFztPeTMz+XuM/tybABL8aCzxyB3b7tiJ1kY5jMA1 2O7bydcen9XGfXI2RZM2btU2zoOSYqdh9SoLX1pSIL2P48b7PV7SYK/iruplh8S/s9+/ziav 2f1q2LT3aN4brT+QBDHLz0+/g6sYNg6nnNbHBGT3uTX4mSS9iP5IohKmKmHGCKFXXiWmcRCU 1CynAd9fmQroFXRpJYtbRbR1nEpUfJ2NGffKO7qLkA+X2H9ORvBQvuBa20P5Q4sjehTX87d+ zdbtA4lxOsA5/MSoeZ+LKlx1hXmY+i/qmjlZO42FpMBKGQYW9ioJ8vSiiSHjarAuMYIEHDCC BBgCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDd 7ILd5Zf8kHjmT0SHdi9yMAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxNDAxMzAzNlowIwYJKoZIhvcNAQkEMRYEFFyLxdDm lagZBipC0Dk24oj3taxvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAN3sgt3ll/yQeOZPRId2L3IwgbwGCyqGSIb3 DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcG A1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEA3eyC3eWX/JB45k9Eh3YvcjANBgkqhkiG9w0BAQEFAASCAQBdIgQ6SGNr4gQn9Y3nzu6h 1Cv+h1rWW8sCIm/vifoyAh19BmWjYzKni4FYhyecBDEe/FIGd63lkjuCcv+QUjp79QejGlU6 /lP6TN7pRJD4tMXNpSNtum/Ld5aflkyra4YvyUeO4aFZrB3iwYqbCWUNHnd3kd5dUoT1T79f SMVi5cpUwhN3GLLeeFDIC9pr0aqYg780Xnk/nEyysR6oG+NfoGuLphgVQCe/2hhUy1RA3W71 QyFRBGNQTQ4L3XYzqWI8w2zMR6AriSNwFEvA2NpCWYG/uJlc8cq+eNmRD4/OFgdVcPUCcTTb JMnPLUABrsRydLf0EYAgRHiPz1SR8gVqAAAAAAAA --------------ms080803000008080004060203-- From nobody Fri Mar 13 20:57: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 BDFCE1A89FB for ; Fri, 13 Mar 2015 20:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.001 X-Spam-Level: X-Spam-Status: No, score=-17.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_WHITELIST=-15] 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 tLHQFBXd0jhJ for ; Fri, 13 Mar 2015 20:57:33 -0700 (PDT) Received: from mrout5.yahoo.com (mrout5.yahoo.com [216.145.54.154]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347491A88F8 for ; Fri, 13 Mar 2015 20:57:33 -0700 (PDT) Received: from omp1016.mail.ne1.yahoo.com (omp1016.mail.ne1.yahoo.com [98.138.89.160]) by mrout5.yahoo.com (8.14.9/8.14.9/y.out) with ESMTP id t2E3vJLO071898 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 13 Mar 2015 20:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1426305440; bh=W6B3Pqn8RZtJfIjZK1ulYJSgZqhqgJKcKwr1+8COzpg=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject; b=QBimWtoEP0KJBT8OgQs4ANNpIGjvKTOqcbChno7Ij31L0Z/ST/n0F3/PtnyO24aLR G8UMtn3x5DP3QLmQU3j5vIkHLGJLLkxPinh0VB9c2qwUR04HUNTi7zsUgVrY5s+zg8 gOx7hF3ofk/G/Vl+7iPaXT36Dq9qqhFMfViku1hc= Received: (qmail 61051 invoked by uid 1000); 14 Mar 2015 03:57:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1426305439; bh=TvA/gsyNiqje0F7o6iMGUo63NL/TCw3/9x69nXa4ABM=; h=Date:From:Reply-To:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FLHrB1juPkBw1FCU0vaWyZAyIMeyiiQabzMWtdkmDxr81CMQucDLiVIbOBOwcftvQ4XRS88AK/dwdJX/nm8nQUpMUM03HjyW6doCpWz3cI/kNGg32T5KfyTIYnuD9PzD9T3AqK7ILM7dLbZsuuex1w2LyN0r/dH7xrgKLmLxYHw= X-YMail-OSG: o3UMNowVM1mShPxxYhImC_zNWtd3vL.RKhxUp7bRdSHs8u26CfG.INIS8Uksp8S 7z5AWOwPSWWq0uVDg1AOdWd2zI9hRuGxYBY7UxTmP3dyBbIp4tn93q2gH8653StV6oFzjH4OGUxX wi7TyPzlkdBawVnsz70896Iuu_bHDWPOUeudKqt47uvlvLHyPPs2u_XVIF9XhP2CgqdSvlfH3g.a ANr8KUAQW3EZbyZscB5EPFvUQsV6_hE5kjkb76n8WSX0CV9U- Received: by 98.138.105.193; Sat, 14 Mar 2015 03:57:18 +0000 Date: Sat, 14 Mar 2015 03:57:17 +0000 (UTC) From: David Gil To: Falcon Darkstar Momot , "openpgp@ietf.org" , David Gil Message-ID: <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <55038CBE.7070608@iridiumlinux.org> References: <55038CBE.7070608@iridiumlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 305439001 Archived-At: Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Gil List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 03:57:35 -0000 On Friday, March 13, 2015 6:20 PM, Falcon Darkstar Momot wrote: > I feel like perhaps this type of exhaustive testing is neither necessary > nor expected, and that a few end-to-end tests designed to exercise edge > cases could be combined with more exhaustive unit tests to achieve > reasonable results. The difficulty, as always, is proving that an actual implementation is modular. In the case of OpenPGP, it really isn't: A lot of data has to get carried between each stage to ensure conformance with the high-level semantics. In contrast, suppose that I wanted to exhaustively test the different ways of doing authenticated encryption with TweetNaCl. That's exactly 1 test, which I can then test for 2^32 different parameter values or so quite easily. That type of exhaustive testing is routinely (though not routinely enough) done, and it is expected for critical software. > Protocol modularity is not evil. Modularity is neutral. "Agility", as folks like to call it, is evil. The name-sake article of Google and Yahoo's End-to-End project has some good arguments for avoiding redundancy in systems design: http://web.mit.edu/saltzer/www/publications/endtoend/endtoend.pdf (I'd note that I think the article argues for its position a bit too strongly. It's clear that transport-layer and message-level encryption are both necessary, for example, because they have fundamentally different semantics.) From nobody Fri Mar 13 21:55: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 8CC771AC3F0 for ; Fri, 13 Mar 2015 21:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8rQzNrX-X71 for ; Fri, 13 Mar 2015 21:54:58 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 951B31AC3EF for ; Fri, 13 Mar 2015 21:54:57 -0700 (PDT) Received: by ykfs63 with SMTP id s63so1351131ykf.2 for ; Fri, 13 Mar 2015 21:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OZUiTuXIVZvIJowMrfgHqmHBTgmPN/nde8suTCr5c3g=; b=AgIuCymMTT2hzsFsSXgBiiWHvBSMET6MNGQBRsy1qwXo/veGILIwky72EMVTAcUcaA XegSnJG2wHpYMNor91ZCmlle3OsCSzAQxoRrd68UEgs0PhqO+hZl4ih++mi/LEM+x+Le QKgcWcUhSO76Qt7bLVNnBow/ttaaJrgHYn7KBYkhhEnfkh/boMpBBCCctzYmDoLCENoo iNpdyLeSfF5abz5sVNiMuTrKvuJktqieWv3kaewH4iNB6OnWkUoWA3F21z7jJVm6QxK4 QNDyLK8oAGKKDorA08pvY3J4X8iX4NYbJCupni3RPH4NXga0d+E7HW4bNplsJ9klvWvC 5AWQ== X-Received: by 10.236.105.210 with SMTP id k58mr49889765yhg.52.1426308896942; Fri, 13 Mar 2015 21:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.125.80 with HTTP; Fri, 13 Mar 2015 21:54:36 -0700 (PDT) In-Reply-To: <55038F3C.40207@iridiumlinux.org> References: <55038F3C.40207@iridiumlinux.org> From: David Leon Gil Date: Fri, 13 Mar 2015 21:54:36 -0700 Message-ID: To: Falcon Darkstar Momot Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 14 Mar 2015 04:55:01 -0000 On Fri, Mar 13, 2015 at 6:30 PM, Falcon Darkstar Momot wrote: > Yes, I can get behind that. Make it so! Users should be presented with > secure defaults and not given the opportunity to unknowingly decrease > security. Deprecating lower-security but equivalently performant > algorithms is especially commendable. > > That said, archived encrypted data may require decryption support well > into the future. OpenPGP-encrypted data is not ephemeral like > TLS-encrypted data. I agree: But note that it's possible to run, for example, programs written for the Symbolics Lisp machine (c. 1982) on your Macbook Pro today: https://github.com/ynniv/opengenera And older versions of GnuPG are certainly still buildable! (As, I anticipate, older versions of any extension will be.) W.r.t. long-term storage of messages, however, I tend to think that storing them in their wire format is exactly the wrong thing to do. If you don't discard wire-format messages, you don't get PFS, even using ephemeral-static ECDH. From nobody Sat Mar 14 05:01:24 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 939031A00FF for ; Sat, 14 Mar 2015 05:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 wHc2g-ry6YkT for ; Sat, 14 Mar 2015 05:01:20 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03431A00E5 for ; Sat, 14 Mar 2015 05:01:20 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YWkkp-0004Dv-1w for ; Sat, 14 Mar 2015 13:01:19 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YWkgz-00062n-HP; Sat, 14 Mar 2015 12:57:21 +0100 From: Werner Koch To: DataPacRat References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> 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 Date: Sat, 14 Mar 2015 12:57:21 +0100 In-Reply-To: (datapacrat@gmail.com's message of "Fri, 13 Mar 2015 15:51:20 -0400") Message-ID: <877fujdc66.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: Derek Atkins , Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 14 Mar 2015 12:01:22 -0000 On Fri, 13 Mar 2015 20:51, datapacrat@gmail.com said: > I'm interested in certain aspects of Webs of Trust, such as their > potential to overcome certain problematic aspects of centralized Using this ML for discussin is IMHO okay but trust modells are not a goal of the OpenPGP standard. It might turn out that a certain feature would be useful and that would be something which can be put into the standard. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat Mar 14 05:06:24 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 C22CE1A00F6 for ; Sat, 14 Mar 2015 05:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 Jiso78Qkv6LG for ; Sat, 14 Mar 2015 05:06:22 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DE71A00E5 for ; Sat, 14 Mar 2015 05:06:20 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YWkpf-0004T4-5R for ; Sat, 14 Mar 2015 13:06:19 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YWko3-000640-Mu; Sat, 14 Mar 2015 13:04:39 +0100 From: Werner Koch To: David Leon Gil References: 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 Date: Sat, 14 Mar 2015 13:04:39 +0100 In-Reply-To: (David Leon Gil's message of "Fri, 13 Mar 2015 18:22:34 -0700") Message-ID: <873857dbu0.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: "dgil@yahoo-inc.com" , "openpgp@ietf.org" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 14 Mar 2015 12:06:23 -0000 On Sat, 14 Mar 2015 02:22, coruus@gmail.com said: > 2. Yahoo and GnuPG have both already deprecated V3 public keys for any > use. We recommend that other implementations do the same. Only for GnuPG-2. We keep on maintainog 1.4 so that existisng dat dan still be decrupted. > Yahoo has deprecated, and intends to disable support for all uses, of > the following primitives and packet types specified for use with > OpenPGP v4: This is what the preference system is all about. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wyllys@gmail.com Sat Mar 14 06:18:07 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 9988E1A038A for ; Sat, 14 Mar 2015 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 6BqRaPuOrsLC for ; Sat, 14 Mar 2015 06:18:05 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 3AC401A0382 for ; Sat, 14 Mar 2015 06:18:05 -0700 (PDT) Received: by oiaz123 with SMTP id z123so6742176oia.3 for ; Sat, 14 Mar 2015 06:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=jN+K/4N6qe3o68TX6eiMVOToyV6eyL4+mcwemQcKZcw=; b=juHG+rVTeggYacbBXj0QBkvRekt526EXtnz5Z1u8il1tcU5OJO3fV5eMzNazujcAbT cuJrM/LYM68Sz5rpZReEZ/ev58EmXfvZVJdpoYM57FH7CoRXKwOluOT7K3HAOrjy7Pn9 4UCUtKacFZRZ3EsMivuxfHI2Pt43dQsOER0CMJzz9I3WJFuwhUoMAji5zmb+5bKLuwzx gV0loSbl5WMyBOorSfnjGFqR4st3Q+vQ9qTqco2sDAnylTQZ26uBOOyDG3iJmWpIegeu AL/eK/mZsLYi3ZMyw12kndiRZTfvD0Ery1V54sRGR95TbUUG6C5nvCstgz1bKuWSHEOP 9YGw== X-Received: by 10.60.70.1 with SMTP id i1mr34985410oeu.44.1426339084671; Sat, 14 Mar 2015 06:18:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wyllys Ingersoll Date: Sat, 14 Mar 2015 13:18:03 +0000 Message-ID: To: David Leon Gil , "openpgp@ietf.org" , "dgil@yahoo-inc.com" Content-Type: multipart/alternative; boundary=001a1133477078a09705113f727d Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 14 Mar 2015 13:18:44 -0000 --001a1133477078a09705113f727d Content-Type: text/plain; charset=UTF-8 Im all for deprecating and/or outright dropping of support for older ciphers, it needlessly complicates the code and testing matrix, even if they are optional to implement. Frankly, very few people actually use, say, CAMELLIA, in the wild. I don't think anyone would notice if it disappeared tomorrow. However, if you get really restrictive (from your "eventual" list below) and cut off support for common key sizes like 2048-bit RSA or keys that are > 1 year old, you risk cutting off a huge chunk of the active OpenPGP user base. People are very reluctant to give up or create new keys once they have distributed they public key to others, even if said key is old and weak, unfortunately. Updating existing keys (revoking sigs/keys, adding new subkeys, etc) is considered black magic and far too complicated for most casual users. Though perhaps that issue could be solved by streamlining the process in the various implementations. Im not sure the usability issue can be solved by the standard itself. If the goal is to increase the use and popularity of OpenPGP, locking out a significant number of current users seems counterproductive. Obviously, that would be an implementation and business decision for Yahoo! and Google to make in their codebase and not really relevant debate for this WG... -Wyllys Ingersoll On Fri, Mar 13, 2015 at 9:23 PM David Leon Gil wrote: > First, the fait accompli: > > 1. Yahoo and Google have both already deprecated and removed support > for the following packet type specified for use with OpenPGPv4: > > Tag 9 (symmetrically encrypted) packets > > These packets provide unauthenticated encryption and -- if supported > -- can be used in a downgrade attack on senders who only use SEIPD > packets. See https://github.com/coruus/cooperpair/tree/master/encrux > for details. > > 2. Yahoo and GnuPG have both already deprecated V3 public keys for any > use. We recommend that other implementations do the same. > > -- > > Second, the near future: > > Yahoo has deprecated, and intends to disable support for all uses, of > the following primitives and packet types specified for use with > OpenPGP v4: > > - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish > - Asymmetric algorithms, generally: RSA-ES, DSA. > - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, ELG-E. > - Compression algorithms: ZLIB. (It provides no benefits over DEFLATE, > and is more malleable.) > - Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224. > > We do not, at present, support any of the CAMELLIA algorithms or > BZIP2. It is unlikely that we will do so in future. > > At present, we anticipate removing support for these primitives no > later than May 1, 2015. > > -- > > Third, other things that will be deprecated soonish: > > 1. Inconsistent combinations of primitives. In particular, it is > likely that we will not support RFC 6637 keys or packets unless they > conform to the 128-bit or 192-bit subprofiles specified in that > document. (We do not at present support P-521, but if we add support > for that, we would support an analogous "256-bit" subprofile.) > > 2. AES-128. The efficiency of multi-target attacks leaves no safety > margin for cryptanalysis. The performance difference between AES-128 > and AES-256 on typical messages is negligible. > > -- > > Finally, other things that may eventually result in messages or keys > being treated as invalid: > > 1. A published public key that is more than 1 year old. (This is > mainly taken care of by requiring > 3070 bit RSA keys...) > 2. Signature by a public key which has ever signed a message or key > using MD-5 or SHA-1. > 3. A compressed or literal data packet tag that is unusually formatted. > 4. A compression method other than "Uncompressed". > > David Leon Gil > Senior Paranoid > Yahoo! > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1133477078a09705113f727d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Im all for deprecating and/or outright dropping of support= for older ciphers, it needlessly complicates the code and testing matrix, = even if they are optional to implement. =C2=A0 Frankly, very few people act= ually use, say, CAMELLIA, in the wild.=C2=A0 I don't think anyone would= notice if it disappeared tomorrow.

However, if you get = really restrictive (from your "eventual" list below) and cut off = support for common key sizes like 2048-bit RSA or keys that are > 1 year= old, you risk cutting off a huge chunk of the active OpenPGP user base.=C2= =A0 People are very reluctant to give up or create new keys once they have = distributed they public key to others, even if said key is old and weak, un= fortunately.=C2=A0 Updating existing keys (revoking sigs/keys, adding new s= ubkeys, etc) is considered black magic and far too complicated for most cas= ual users.=C2=A0 Though perhaps that issue could be solved by streamlining = the process in the various implementations. Im not sure the usability issue= can be solved by the standard itself.

If the goal= is to increase the use and popularity of OpenPGP, locking out a significan= t number of current users seems counterproductive. =C2=A0 Obviously, that w= ould be an implementation and business decision for Yahoo! and Google to ma= ke in their codebase and not really relevant debate for this WG...

-Wyllys Ingersoll


On Fri, Mar 13, 2015 at 9:23 PM David Leon Gil <coruus@gmail.com> wrote:
First, the fait accompli:

1. Yahoo and Google have both already deprecated and removed support
for the following packet type specified for use with OpenPGPv4:

=C2=A0 =C2=A0 Tag 9 (symmetrically encrypted) packets

These packets provide unauthenticated encryption and -- if supported
-- can be used in a downgrade attack on senders who only use SEIPD
packets. See https://github.com/coruus/cooperpair/tree/ma= ster/encrux
for details.

2. Yahoo and GnuPG have both already deprecated V3 public keys for any
use. We recommend that other implementations do the same.

--

Second, the near future:

Yahoo has deprecated, and intends to disable support for all uses, of
the following primitives and packet types specified for use with
OpenPGP v4:

- Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish
- Asymmetric algorithms, generally: RSA-ES, DSA.
- Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, ELG= -E.
- Compression algorithms: ZLIB. (It provides no benefits over DEFLATE,
and is more malleable.)
- Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224.

We do not, at present, support any of the CAMELLIA algorithms or
BZIP2. It is unlikely that we will do so in future.

At present, we anticipate removing support for these primitives no
later than May 1, 2015.

--

Third, other things that will be deprecated soonish:

1. Inconsistent combinations of primitives. In particular, it is
likely that we will not support RFC 6637 keys or packets unless they
conform to the 128-bit or 192-bit subprofiles specified in that
document. (We do not at present support P-521, but if we add support
for that, we would support an analogous "256-bit" subprofile.)
2. AES-128. The efficiency of multi-target attacks leaves no safety
margin for cryptanalysis. The performance difference between AES-128
and AES-256 on typical messages is negligible.

--

Finally, other things that may eventually result in messages or keys
being treated as invalid:

1. A published public key that is more than 1 year old. (This is
mainly taken care of by requiring > 3070 bit RSA keys...)
2. Signature by a public key which has ever signed a message or key
using MD-5 or SHA-1.
3. A compressed or literal data packet tag that is unusually formatted.
4. A compression method other than "Uncompressed".

David Leon Gil
Senior Paranoid
Yahoo!

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a1133477078a09705113f727d-- From nobody Sat Mar 14 06:47:40 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 49D1B1A039F for ; Sat, 14 Mar 2015 06:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 nIHPcrR0eHaD for ; Sat, 14 Mar 2015 06:47:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD761A0393 for ; Sat, 14 Mar 2015 06:47:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC464BE8F; Sat, 14 Mar 2015 13:47:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riZBkTPImNPt; Sat, 14 Mar 2015 13:47:29 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.19.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D62C9BE8E; Sat, 14 Mar 2015 13:47:28 +0000 (GMT) Message-ID: <55043BF0.4010705@cs.tcd.ie> Date: Sat, 14 Mar 2015 13:47:28 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: David Leon Gil References: <5502F3AF.8030903@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Kathleen Moriarty , "openpgp@ietf.org" Subject: Re: [openpgp] A new openpgp WG 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, 14 Mar 2015 13:47:38 -0000 Hi David, On 13/03/15 23:36, David Leon Gil wrote: > It is unlikely I would be able to attend the March IETF with such > short notice. (I also have other travel plans in this timeframe.) > > Therefore, Yahoo would request that the IETF defer action. (July sounds fine.) I don't think you need worry - interested folks will hopefully manage to meet in Dallas, but any action will really happen here on the mailing list. So we're not deferring action, we're aiming to behave as usual, and work primarily via this list, with face to face meetings being used for higher bandwidth interactions etc. I'd also note that saying "Yahoo would request" and other uses of a company name like that tend to grate (as in "sound bad") in an IETF context. There are a bunch of good reasons why we recognise you David as a participant who can argue technical details and why we do not similarly recognise companies or other organisations. (And that's not something to discuss here, but I'm happy to follow up off list to explain more, as it is a different culture from most other organisations.) So that kind of appeal to authority is much better avoided in general, and also on this list. > Both Yahoo and Google are presently planning deployment of a browser > extension using OpenPGP. (Google's open-source branch is at > https://github.com/google/end-to-end; our branch will be open-sourced > soon at https://github.com/yahoo/end-to-end.) > > We would expect this to be one of the larger deployments of OpenPGP, > and to face unique constraints (because of its implementation in > JavaScript, and deployment via the Web Platform). Good stuff. I would really hope that one of the outcomes of whatever we end up doing is providing interoperability with the best security properties we can between the likely deployment of that fine bit of work and others on the Internet using the OpenPGP protocol. I really hope we all share that goal. Cheers, S. > > I am hopeful that feedback on the open-source extensions will prove > useful in whatever standards process may emerge. > > David Leon Gil > Senior Paranoid > Yahoo! > > PS. This is a statement of Yahoo's position. > > This message is sent from a Gmail account because Yahoo sets a strict > DMARC policy, which may result in some recipients MTAs (e.g. Google's) > dropping a message. > > See http://dmarc.org/faq.html#s_3 for things mailing lists can do to > avoid this. There are also things webmail providers can do to mitigate > this problem, but Google won't do them. > > The benefits to DKIM are tremendous, w.r.t. protection of users from > phishing or other malicious emails. I strongly encourage mailing list > owners and webmail providers to take steps to ensure that all users' > messages are correctly handled with a DKIM p=reject. > > On Fri, Mar 13, 2015 at 7:26 AM, Stephen Farrell > wrote: >> >> Hiya, >> >> I've just now subscribed here because Derek sent a pointer >> to the recent discussion about chartering a new WG. >> >> FWIW, as one of the security area directors who might be >> involved in the chartering stuff, I'm happy to help out as >> I can, and I'm sure the same goes for Kathleen. But you seem >> to be doing all the right things already (discuss charter, >> focus on changes people would likely implement/deploy, >> meet in bar:-), which is great. >> >> A couple of other things to do might be to send a pointer >> to the general security area list (saag@ietf.org) asking >> interested folks to subscribe here, (e.g. I think I used be >> subscribed to the imc hosted list way back but I wasn't on >> this one) and if the bar-BoF goes ahead, it'd be good for >> one of you to grab the mic at the saag session in Dallas >> and report back on that. >> >> Please also note that there's no absolute need to have a >> BoF session (e.g. in Prague in July) before a WG is formed. >> If a whole bunch of people know that they all want to do a >> well-scoped useful thing then we may not need one. (The >> just-formed tokbind WG didn't have a BoF for example.) If >> OTOH, there's a need for face-to-face discussion about >> tricky scoping issues or about whether some work should be >> done at all then a BoF can be a fine thing. In this case, >> I'd not be surprised if no BoF were needed, in which case >> we could possibly form a WG before July and get going that >> much sooner. That said, please keep your focus on the >> getting the right proposed charter text and don't >> over-prioritise speed. (Since a lot of people still >> assume a BoF session and the associated delay are mandatory, >> I figured it worth pointing out that's not always the >> case.) >> >> Cheers, >> S. >> >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp > From nobody Sat Mar 14 07:30:11 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 500121A03AA for ; Sat, 14 Mar 2015 07:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9h28Yntol-u for ; Sat, 14 Mar 2015 07:30:08 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 C76021A0161 for ; Sat, 14 Mar 2015 07:30:07 -0700 (PDT) Received: by lamx15 with SMTP id x15so9734672lam.3 for ; Sat, 14 Mar 2015 07:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wv3VLhWiFFjIncai5ljh4vIPANsULzgqE3edW/moB18=; b=PWOjWKEvjXuxp5zp/Cm8F1Ck0QI+WzHxkAhHy0AoJu3imuislhAE2t99fn3LfsN7V3 eFaxzS4V4eXQrrvF7yN0PRhed/Npa+BlC6xnGF7bjaA0MzeuX5JXQQSnpBmxC1V0NQxU nBihbj5JIBKAvzrRSXJuJy74SV4rHNchDM4pnM5wPGf+zspSlpLM4SBa/Pg/xydRuz/S VOwVJDWTqrLbrRtqw8B/f/FrsGHvudFe52Cr567bgJ/V+obcPzico/gN5Dzi8atf0ElX 6c+i9jKInxl4xqXqDwEvYfGOe1ufM2X5cLZsVYuOrQufKrywe83MGASSHssI/Kto4dC2 +9kw== MIME-Version: 1.0 X-Received: by 10.152.43.229 with SMTP id z5mr40366537lal.48.1426343406344; Sat, 14 Mar 2015 07:30:06 -0700 (PDT) Received: by 10.25.13.4 with HTTP; Sat, 14 Mar 2015 07:30:06 -0700 (PDT) In-Reply-To: <877fujdc66.fsf@vigenere.g10code.de> References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <877fujdc66.fsf@vigenere.g10code.de> Date: Sat, 14 Mar 2015 10:30:06 -0400 Message-ID: From: DataPacRat To: Werner Koch Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Derek Atkins , Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 14 Mar 2015 14:30:10 -0000 On Sat, Mar 14, 2015 at 7:57 AM, Werner Koch wrote: > On Fri, 13 Mar 2015 20:51, datapacrat@gmail.com said: > >> I'm interested in certain aspects of Webs of Trust, such as their >> potential to overcome certain problematic aspects of centralized > > Using this ML for discussin is IMHO okay but trust modells are not a > goal of the OpenPGP standard. It might turn out that a certain feature > would be useful and that would be something which can be put into the > standard. Will the new OpenPGP standard explicitly include some form of text-file (or XML, or JSON) format for keys, along the lines of the venerable 'BEGIN PGP PUBLIC KEY BLOCK'? If so, then as long as it includes at least one free-form-text comments field which can be used for arbitrary additional data, such as a score indicating exactly how much Bayesian trust the key-signer has that the listed key belongs to its indicated owner, then that would likely be sufficient to cover the cases I'm thinking of. (There is room for some further elaboration, such as cryptographically signing said comments, if the general idea meets approval.) Thank you for your time, -- DataPacRat "Then again, I could be wrong." From nobody Sat Mar 14 07:34:36 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 0B9581A037A for ; Sat, 14 Mar 2015 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 nWfxdL_TllrK for ; Sat, 14 Mar 2015 07:34:33 -0700 (PDT) Received: from byzantine.jameshoward.us (byzantine.jameshoward.us [IPv6:2607:fc50:1000:4100::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF361A0262 for ; Sat, 14 Mar 2015 07:34:33 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (authenticated bits=0) by byzantine.jameshoward.us (8.14.4/8.14.3) with ESMTP id t2EEYWoo080774 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sat, 14 Mar 2015 10:34:32 -0400 (EDT) (envelope-from jh@jameshoward.us) Received: by oier21 with SMTP id r21so7429779oie.1 for ; Sat, 14 Mar 2015 07:34:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.223.6 with SMTP id w6mr39087988oig.89.1426343667261; Sat, 14 Mar 2015 07:34:27 -0700 (PDT) Received: by 10.182.142.233 with HTTP; Sat, 14 Mar 2015 07:34:27 -0700 (PDT) In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <877fujdc66.fsf@vigenere.g10code.de> Date: Sat, 14 Mar 2015 10:34:27 -0400 Message-ID: From: "James P. Howard" To: DataPacRat Content-Type: multipart/alternative; boundary=001a113d631e9d6b1005114083fb Archived-At: Cc: Derek Atkins , Werner Koch , Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: jh@jameshoward.us List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 14:34:35 -0000 --001a113d631e9d6b1005114083fb Content-Type: text/plain; charset=UTF-8 Is there an upvote button for this? I even tweeted about this yesterday! https://twitter.com/howardjp/status/576473455949967360 The current signed-XML standard is an awful awful thing and having a usable standard for signed text formats (XML, JSON, whatever) would would make the implementation a de facto default. James Howard On Sat, Mar 14, 2015 at 10:30 AM, DataPacRat wrote: > On Sat, Mar 14, 2015 at 7:57 AM, Werner Koch wrote: > > On Fri, 13 Mar 2015 20:51, datapacrat@gmail.com said: > > > >> I'm interested in certain aspects of Webs of Trust, such as their > >> potential to overcome certain problematic aspects of centralized > > > > Using this ML for discussin is IMHO okay but trust modells are not a > > goal of the OpenPGP standard. It might turn out that a certain feature > > would be useful and that would be something which can be put into the > > standard. > > Will the new OpenPGP standard explicitly include some form of > text-file (or XML, or JSON) format for keys, along the lines of the > venerable 'BEGIN PGP PUBLIC KEY BLOCK'? If so, then as long as it > includes at least one free-form-text comments field which can be used > for arbitrary additional data, such as a score indicating exactly how > much Bayesian trust the key-signer has that the listed key belongs to > its indicated owner, then that would likely be sufficient to cover the > cases I'm thinking of. (There is room for some further elaboration, > such as cryptographically signing said comments, if the general idea > meets approval.) > > > Thank you for your time, > -- > DataPacRat > "Then again, I could be wrong." > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a113d631e9d6b1005114083fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there an upvote button for this?=C2=A0 I even tweeted a= bout this yesterday!

=C2=A0=C2=A0https://twitter.com/howardjp/st= atus/576473455949967360

The current signed-XML s= tandard is an awful awful thing and having a usable standard for signed tex= t formats (XML, JSON, whatever) would would make the implementation a de fa= cto default.

=
James Howard

On Sat, Mar 14, 2015 at 10:30 AM, DataPacRat= <datapacrat@gmail.com> wrote:
On Sat, Mar 14, 2015 at 7:57 AM, Werner Koch <wk@gnupg.org> wrote:
> On Fri, 13 Mar 2015 20:51, dat= apacrat@gmail.com said:
>
>> I'm interested in certain aspects of Webs of Trust, such as th= eir
>> potential to overcome certain problematic aspects of centralized >
> Using this ML for discussin is IMHO okay but trust modells are not a > goal of the OpenPGP standard.=C2=A0 It might turn out that a certain f= eature
> would be useful and that would be something which can be put into the<= br> > standard.

Will the new OpenPGP standard explicitly include some form of
text-file (or XML, or JSON) format for keys, along the lines of the
venerable 'BEGIN PGP PUBLIC KEY BLOCK'? If so, then as long as it includes at least one free-form-text comments field which can be used
for arbitrary additional data, such as a score indicating exactly how
much Bayesian trust the key-signer has that the listed key belongs to
its indicated owner, then that would likely be sufficient to cover the
cases I'm thinking of. (There is room for some further elaboration,
such as cryptographically signing said comments, if the general idea
meets approval.)


Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

--001a113d631e9d6b1005114083fb-- From nobody Sat Mar 14 13:49:45 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 BBE771A0204 for ; Sat, 14 Mar 2015 13:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 rL9Pf1VVII4g for ; Sat, 14 Mar 2015 13:49:43 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 1A0B51A0143 for ; Sat, 14 Mar 2015 13:49:43 -0700 (PDT) Received: by lbbzq9 with SMTP id zq9so9697944lbb.0 for ; Sat, 14 Mar 2015 13:49:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=0iah+D/e55FiG2yxX4WkhEuze2M2mEdH1ESYC7hGWJs=; b=U0PLfCdqIzGREub8qLMC/Ku5Ifk5QVUYzQ+1wceWON5oaS/Sdd6yrj8h+ygYOrRnOf XozklCUsG/pHX+83Wcb9Fpxgv8w6t+UdcZPF08CLpq4GU/4WRMZlF8CIACpIye/vkuXF rs/jQ2s0CGcoVCRgaBCN33TEjpfB3A+l88ntWc+RB+bUgKh0NJPJOZqwD4tXao+DX41S QUmi/w1yUTj/2QdvN1ul0tic2vQYDb8o8yJMG0Ri0ZWKPDt6LJ9yjA3A/P9Ia1y7Agik /tNMYdaGpYq0U/qtPl/9x9ZMkIueeP0w3fctSljplwukC1dRo0nZUNelU1PZLSW8f076 w07w== X-Gm-Message-State: ALoCoQnOCLhbjxjmk7yzM+U9cFvNecVO+q5DJsvyV0KigzUWKVwoCvr4zoghJuBYVcvJJUGHsZbw X-Received: by 10.112.188.163 with SMTP id gb3mr21839124lbc.10.1426366181246; Sat, 14 Mar 2015 13:49:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.242 with HTTP; Sat, 14 Mar 2015 13:49:21 -0700 (PDT) X-Originating-IP: [122.60.18.124] From: Tim Bray Date: Sun, 15 Mar 2015 09:49:21 +1300 Message-ID: To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=001a11c37a048d9e35051145c1c6 Archived-At: Subject: [openpgp] Work items for openpgp relaunch: Content-type equivalent 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, 14 Mar 2015 20:49:44 -0000 --001a11c37a048d9e35051145c1c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I did quite a bit of work on a PGP app last summer, OpenKeychain, which leverages the Android =E2=80=9Csharing=E2=80=9D system very effectively to = produce a pretty nice UX for encryption/signing/key-discovery/decryption/verification. See https://play.google.com/store/apps/details?id=3Dorg.sufficientlysecure.keyc= hain&hl=3Den There=E2=80=99s one missing piece, the equivalent of HTTP Content-type. Yo= u can easily encrypt anything - a message, a picture, a video - and send it off to anyone, and have them decrypt it straightforwardly with no user-visible crypto incantations. But then how does the receiver process it automatically unless it knows the payload data format? I=E2=80=99m aware that S/MIME does this, but that was not terribly relevant= in the Android-app context. I=E2=80=99m aware there have been proposals for a new packet type for this = purpose but I don't want to presuppose any conclusions; just noting that I've encountered a real actual need here in real actual software. I=E2=80=99d b= e able to invest some cycles on this if there=E2=80=99s interest among others. --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c37a048d9e35051145c1c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I d= id quite a bit of work on a PGP app last summer, OpenKeychain, which levera= ges the Android =E2=80=9Csharing=E2=80=9D system very effectively to produc= e a pretty nice UX for encryption/signing/key-discovery/decryption/verifica= tion.=C2=A0 See=C2=A0https://play.google.com/s= tore/apps/details?id=3Dorg.sufficientlysecure.keychain&hl=3Den

There=E2=80=99s one missing p= iece, the equivalent of HTTP Content-type.=C2=A0 You can easily encrypt any= thing - a message, a picture, a video - and send it off to anyone, and have= them decrypt it straightforwardly with no user-visible crypto incantations= .=C2=A0 But then how does the receiver process it automatically unless it k= nows the payload data format? =C2=A0

I=E2=80=99m aware that S/MIME does this, but that was not terri= bly relevant in the Android-app context.

I=E2=80=99m aware there have been proposals for a new packe= t type for this purpose but I don't want to presuppose any conclusions;= just noting that I've encountered a real actual need here in real actu= al software.=C2=A0 I=E2=80=99d be able to invest some cycles on this if the= re=E2=80=99s interest among others.

--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a11c37a048d9e35051145c1c6-- From nobody Sun Mar 15 10:57:43 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 B3A401A1B5E for ; Sun, 15 Mar 2015 10:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 06kLItsWvvdf for ; Sun, 15 Mar 2015 10:57:41 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 800431A1B27 for ; Sun, 15 Mar 2015 10:57:41 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id AFA4DF2126; Sun, 15 Mar 2015 17:57:40 +0000 (UTC) Date: Sun, 15 Mar 2015 12:57:44 -0500 From: Stephen Paul Weber To: openpgp@ietf.org Message-ID: <20150315175744.GG2978@singpolyma-liberty> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [openpgp] "OpenPGP Simple" 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: Sun, 15 Mar 2015 17:57:42 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable One of the big obstacles to OpenPGP deployments that I've faced over time i= s=20 the perception that it's "too complicated", mostly based on the sheer size= =20 of the current RFC. There are two things going on here: 1) Sections of the RFC define what you might call "extras", such as the=20 ASCII Armor (including a checksum unused elsewhere in the spec) 2) There are a lot of backwards-compatibility things (old-style lengths,=20 lots of different algorithms) One of the things I've tried to work on to help in some of my use cases is= =20 a modular description for a subset of OpenPGP that is (hopefully) easier to= =20 immediately grok and/or implement. It is at=20 Is there any prior art on IETF specs having a "full" and "simple" form wher= e=20 full implementations can read any output of simple ones, but not always=20 vice-versa? Given the (necessary) size of OpenPGP as a whole, it seems lik= e=20 this might be worth considering. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --9amGYk9869ThD9tj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIbBAEBCAAGBQJVBcgYAAoJENEcKRHOUZzelccP91EbqVaoaSZPfFYolQSQiWx7 Ku6inG1pUgIQnEDAk4y7BO4dWGGESGFmMfmVqxPblhCoRukd21lu4EeoW3U8BgeU nvbuArAL4EOxw6LHI8V8V2P+Dy5somZTL1kT2dMbdr+3z4E/WU1VWfXQOZqc3WMR 4r0llJk094CUr3z7VShGTRS+k6VG4hwUF0bVMgpVb5UAdLT5y6zI42NrwXyhDWcF rB6wMkKTAFvPzjmfnKvD5ew0WClPDYsgEpTlH1yEA1OsG4MIebrgx40pVRiyhUIS NIlCgka062Ke8Ga9hZZtEH4n7OLsTfIGmLMR5i3atZDIlDEbaSFv3hqJUrC9hwPe Msock0E4/wPNCAUbzCBcrpCwv/1vOeRAQpWOKb7Ij51OExJ0NhwD3bvslHmf+Q3T LY2LAlxI6R2AhHVC3QLiF3gokyDHHKmaaQv82xak5nIHwx3AVvdOe5kut40CoxAL J/vXwiGsfWEBDTMceSMNKdw5eiHEI5x5ZBo5UcfqI9n/loHOnXoONoFJBZ5wykOm yWb5THdOdNT+VnF6Pv4azwc90ByG9cA4VebHR/Ird6o1Sml4dVhuyCpIpHDddOrc Y6j5SJsZZkfRL8dIId4YPnI6YG2Y1ceVOQ2284JrRoos+b+ouCQoVW385eFewX9B AV/u2V3yIHE3D0KOs+s= =Mfic -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From nobody Sun Mar 15 12:41:24 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 3D9051A1B76 for ; Sun, 15 Mar 2015 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 Qjrq0zaRl42g for ; Sun, 15 Mar 2015 12:41:21 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBFF1A1B6D for ; Sun, 15 Mar 2015 12:41:21 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YXEPX-0007YD-Ep for ; Sun, 15 Mar 2015 20:41:19 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YXEMz-0002q0-Du; Sun, 15 Mar 2015 20:38:41 +0100 From: Werner Koch To: Stephen Paul Weber References: <20150315175744.GG2978@singpolyma-liberty> 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 Date: Sun, 15 Mar 2015 20:38:41 +0100 In-Reply-To: <20150315175744.GG2978@singpolyma-liberty> (Stephen Paul Weber's message of "Sun, 15 Mar 2015 12:57:44 -0500") Message-ID: <873856aw5a.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] "OpenPGP Simple" 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: Sun, 15 Mar 2015 19:41:23 -0000 On Sun, 15 Mar 2015 18:57, singpolyma@singpolyma.net said: > One of the big obstacles to OpenPGP deployments that I've faced over > time is the perception that it's "too complicated", mostly based on > the sheer size of the current RFC. There are two things going on FWIW, having implemented both OpenPGP and CMS/X.509 (aka S/MIME) I can only tell how easy it was to implement and maintain OpenPGP in contrast to the S/MIME. Up until ECC support, only one RFC and not several every few years changing huge RFCs with so much room for interpretation that you can't implement them without looking at older standards and actual implementations. > 2) There are a lot of backwards-compatibility things (old-style > lengths, lots of different algorithms) Actually there are not many algorithms. If you know two (with 64 bit and 128 block length) you know all of them ;-). CMS hides a lot of details by refering to BER or DER encoding and that is really hard to test. > Is there any prior art on IETF specs having a "full" and "simple" form > where full implementations can read any output of simple ones, but not > always vice-versa? Given the (necessary) size of OpenPGP as a whole, > it seems like this might be worth considering. You mean notes in the margin to easier see MAY parts? I doubt that the RFC format can provide this. Having two separate official documents raises the danger that they are not consistent. Your annotated/edited version of OpenPGP is likely the best thing to do. It is similar to reading a set of RFCs compared to reading Stevens - it is much easier to grok his books than to start from scratch with the RFCs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Mar 15 12:46:25 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 2C4681A1B80 for ; Sun, 15 Mar 2015 12:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 hvDXKH4_3bht for ; Sun, 15 Mar 2015 12:46:21 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211531A1B81 for ; Sun, 15 Mar 2015 12:46:21 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YXEUN-0007ci-JN for ; Sun, 15 Mar 2015 20:46:19 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YXERk-0002qp-Kh; Sun, 15 Mar 2015 20:43:36 +0100 From: Werner Koch To: Tim Bray References: 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 Date: Sun, 15 Mar 2015 20:43:36 +0100 In-Reply-To: (Tim Bray's message of "Sun, 15 Mar 2015 09:49:21 +1300") Message-ID: <87y4my9hcn.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Work items for openpgp relaunch: Content-type equivalent 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: Sun, 15 Mar 2015 19:46:24 -0000 On Sat, 14 Mar 2015 21:49, tbray@textuality.com said: > There=E2=80=99s one missing piece, the equivalent of HTTP Content-type. = You can > easily encrypt anything - a message, a picture, a video - and send it off What about using RFC-3156 PGP/MIME and set the Content-type?=20 IIRC, a new flag 'm' for the Literal Data Packet was once suggest to indicate the data has a MIME structure. That would allow to convey all kind of meta information using a matured standard. Salam-Shalom, Werner --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Mar 15 13:13: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 239C61A1B80 for ; Sun, 15 Mar 2015 13:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Vdh4Rf63EnRo for ; Sun, 15 Mar 2015 13:12:58 -0700 (PDT) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (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 AD0881A1B81 for ; Sun, 15 Mar 2015 13:12:53 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id A5ED240276; Sun, 15 Mar 2015 21:12:51 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id 0JCEBR2NgiFg; Sun, 15 Mar 2015 21:12:50 +0100 (CET) Message-ID: <5505E7BE.80100@dominikschuermann.de> Date: Sun, 15 Mar 2015 21:12:46 +0100 From: Dominik Schuermann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Werner Koch , Tim Bray References: <87y4my9hcn.fsf@vigenere.g10code.de> In-Reply-To: <87y4my9hcn.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BPaARGVcHbsPhS3IMIbm8AMqlLiiDea0h" Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Work items for openpgp relaunch: Content-type equivalent 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: Sun, 15 Mar 2015 20:13:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BPaARGVcHbsPhS3IMIbm8AMqlLiiDea0h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Werner, On 03/15/2015 08:43 PM, Werner Koch wrote: > On Sat, 14 Mar 2015 21:49, tbray@textuality.com said: >=20 >> There=E2=80=99s one missing piece, the equivalent of HTTP Content-type= =2E You can >> easily encrypt anything - a message, a picture, a video - and send it = off >=20 > What about using RFC-3156 PGP/MIME and set the Content-type?=20 If setting the Content-type to something different than "application/octet-stream" would leak the Content-type to others or do you have a different usage in mind? There are related problems to this: - RFC 3156 only considers the usage of ASCII armored data, we also like to share encrypted binary files. - Currently we "share" a blob with Content-type "application/octet-stream", while we actually want something more concrete that identifies OpenPGP-encrypted blobs. We don't use "application/pgp-encrypted" as it is specified to only hold the version number. >=20 > IIRC, a new flag 'm' for the Literal Data Packet was once suggest to > indicate the data has a MIME structure. That would allow to convey all= > kind of meta information using a matured standard. The related draft is here: http://tools.ietf.org/html/draft-moscaritolo-openpgp-literal-01 I like this approach as it hides the MIME type in the encrypted header. Having this and a MIME type for OpenPGP-encrypted blobs would solve the problem for us, what about "application/pgp-encryption"? Maybe I am overseeing something, so any pointers are appreciated :) Regards Dominik --BPaARGVcHbsPhS3IMIbm8AMqlLiiDea0h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVBefAAAoJEHGMBwEAASKCSZMH/3puCqYcVuTIytgNAPkvrBac sU9KZkMjNnrZtyDz+NxaooAo7Gl8l8ZcRoG8szOHiT1nbQLfMtwk8a/GwHUPcKf5 Gx/3QfXAzazP701PD4zycOo9JnGfXDiQPHkFkGicuDVRBcEUA7TuwTwVdQZ99ELd SNaLdp5F4AYbw+AeMLwFIIGFduppxzYFWW/asA8lRY5h97ZiUBT+LbGuRVLKsT1m XyCHMkHLZfDmV4HSakHdwP8tL6StNFFcbiKjX8JwDjH+8MGB8hx9shAWnDLBNeDK TG1BfI99lTYjUJM53jdvCOyrIdeUiCReJ4Dp3RVTSqry8YWkJlKH59mQk7tk/0w= =kt6X -----END PGP SIGNATURE----- --BPaARGVcHbsPhS3IMIbm8AMqlLiiDea0h-- From nobody Sun Mar 15 14:50:46 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 D9C021A1B8E for ; Sun, 15 Mar 2015 14:50:44 -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 b-uiMKqHp6Gw for ; Sun, 15 Mar 2015 14:50:43 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3867B1A1B8A for ; Sun, 15 Mar 2015 14:50:43 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1A6A4F984; Sun, 15 Mar 2015 17:50:40 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E5B6D20406; Sun, 15 Mar 2015 14:50:34 -0700 (PDT) From: Daniel Kahn Gillmor To: Werner Koch , Tim Bray In-Reply-To: <87y4my9hcn.fsf@vigenere.g10code.de> References: <87y4my9hcn.fsf@vigenere.g10code.de> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 15 Mar 2015 17:50:34 -0400 Message-ID: <878ueyszf9.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Work items for openpgp relaunch: Content-type equivalent 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: Sun, 15 Mar 2015 21:50:45 -0000 On Sun 2015-03-15 15:43:36 -0400, Werner Koch wrote: > On Sat, 14 Mar 2015 21:49, tbray@textuality.com said: > >> There’s one missing piece, the equivalent of HTTP Content-type. You can >> easily encrypt anything - a message, a picture, a video - and send it off > > What about using RFC-3156 PGP/MIME and set the Content-type? I agree that reusing PGP/MIME to get this functionality is better than re-inventing it elsewhere. > IIRC, a new flag 'm' for the Literal Data Packet was once suggest to > indicate the data has a MIME structure. That would allow to convey all > kind of meta information using a matured standard. I like this proposal, and i think it would make a useful extension to https://tools.ietf.org/html/rfc4880#section-5.9 --dkg From nobody Sun Mar 15 18:51:24 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 59D081A1EFE for ; Sun, 15 Mar 2015 18:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 08FJ6BAsUYjB for ; Sun, 15 Mar 2015 18:51:21 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684D81A1EF6 for ; Sun, 15 Mar 2015 18:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426470681; x=1458006681; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Pfb9DbvYKU3N8Nw8nWEYQub6yEfVqYdloGIjSvKHdg4=; b=txRXG4hS9sZL0SvfVOwbAv3F/fpUPBauQYefb1achyaiSm+O3TSTpTiR HfjAR7wSGMqVCNElXwBd6bJ/aJfc98ZukIj6RVkVJdzi8PBTAzLDYzEk7 1Fp5WNp5zUSjDTquwcKC8xECx9eyJoBAEpPx8Ln6sj0GwpwDytZc6tabn 8=; X-IronPort-AV: E=Sophos;i="5.11,407,1422874800"; d="scan'208";a="314023297" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Mar 2015 14:51:20 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Mon, 16 Mar 2015 14:51:20 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] "OpenPGP Simple" Thread-Index: AdBfi7JjxreSmfp7SbOIMH9w+K4H0A== Date: Mon, 16 Mar 2015 01:51:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB25D4@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 01:51:23 -0000 Stephen Paul Weber writes:=0A= =0A= >Is there any prior art on IETF specs having a "full" and "simple" form whe= re=0A= >full implementations can read any output of simple ones, but not always vi= ce-=0A= >versa? =0A= =0A= Yes and no. I've tried this with the great pile of spaghetti that is the S= SH=0A= protocol (see https://www.cs.auckland.ac.nz/~pgut001/pubs/simplessh.txt), b= ut=0A= SSH has the same problem as PGP does, there's a single dominant implementat= ion=0A= that defines what the protocol is, and everyone else codes to that rather t= han=0A= the spec (for SSH it's somewhat worse in that the client-side implementatio= n=0A= is Putty, which has bug-workarounds for all manner of broken implementation= s,=0A= as a result of which it'll accept any old rubbish while at the same time be= ing=0A= used as a validation suite by developers of further broken implementations)= .=0A= =0A= So even if you define a simple-PGP profile, I'm not sure how much (if any)= =0A= traction it'll get.=0A= =0A= Peter.= From nobody Sun Mar 15 18:56:01 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 4E8651A1EFE for ; Sun, 15 Mar 2015 18:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 fTj1LW69vnJ3 for ; Sun, 15 Mar 2015 18:55:58 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 D08061A1EF6 for ; Sun, 15 Mar 2015 18:55:57 -0700 (PDT) Received: by oier21 with SMTP id r21so26313512oie.1 for ; Sun, 15 Mar 2015 18:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=0WvuWacY1m2R3OmYyNGYsHE0pgQ4TTR36wP6g0NYmB0=; b=ZRdnW3O3LyPgxxCCheTm/T8CFc3uCESB5lx1Tk4KBBEmfDaTlXynOG4bkvoRuIhG44 QFyGW/UTf8VIC4BykxoPV0owVMIYAf8RSV4GgqKKKo+UyZwGYz0cEsK5eQ3qoZFNJvnj msGd34Hb69cINxFgeQeOkDLKdBqPQCnJ8s5jXsg9VlioTWafYffNqken3T0obWRt0+6Z ou4aUJTQJxRk193loVNMMTrpAPeM7GHSUCZyJGR/IKaTq3igbzsV/e1IcOVq6zsynvxO XylscdcnZP1Um8rUhpWLJu+JbdyytiQsIpGEy0iWWPhlo+oPt5Z55BvbNhZ/Ultp15Cp 4JJA== X-Received: by 10.202.207.68 with SMTP id f65mr15588038oig.29.1426470957355; Sun, 15 Mar 2015 18:55:57 -0700 (PDT) MIME-Version: 1.0 References: <20150315175744.GG2978@singpolyma-liberty> <873856aw5a.fsf@vigenere.g10code.de> In-Reply-To: <873856aw5a.fsf@vigenere.g10code.de> From: Wyllys Ingersoll Date: Mon, 16 Mar 2015 01:55:56 +0000 Message-ID: To: Werner Koch , Stephen Paul Weber Content-Type: multipart/alternative; boundary=001a113dea80b217a105115e2699 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 01:55:59 -0000 --001a113dea80b217a105115e2699 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 15, 2015 at 3:41 PM Werner Koch wrote: > On Sun, 15 Mar 2015 18:57, singpolyma@singpolyma.net said: > > One of the big obstacles to OpenPGP deployments that I've faced over > > time is the perception that it's "too complicated", mostly based on > > the sheer size of the current RFC. There are two things going on > > FWIW, having implemented both OpenPGP and CMS/X.509 (aka S/MIME) I can > only tell how easy it was to implement and maintain OpenPGP in contrast > to the S/MIME. Up until ECC support, only one RFC and not several every > few years changing huge RFCs with so much room for interpretation that > you can't implement them without looking at older standards and actual > implementations. > > > 2) There are a lot of backwards-compatibility things (old-style > > lengths, lots of different algorithms) > > Actually there are not many algorithms. If you know two (with 64 bit > and 128 block length) you know all of them ;-). CMS hides a lot of > details by refering to BER or DER encoding and that is really hard to > test. > Agree. RFC 4880 is not terribly hard to implement in code if you focus on the common use cases ("MUST" ciphers and modes) and ignore the optional edge cases that very few people use in real practice. CMS and ASN.1 are gross and painfully hard to implement by comparison. --001a113dea80b217a105115e2699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 15, 2015 at= 3:41 PM Werner Koch <wk@gnupg.org&g= t; wrote:
On Sun, 15 Mar 2015 18:57, singpolyma@singp= olyma.net said:
> One of the big obstacles to OpenPGP deployments that I've faced ov= er
> time is the perception that it's "too complicated", most= ly based on
> the sheer size of the current RFC.=C2=A0 There are two things going on=

FWIW, having implemented both OpenPGP and CMS/X.509 (aka S/MIME) I can
only tell how easy it was to implement and maintain OpenPGP in contrast
to the S/MIME.=C2=A0 Up until ECC support, only one RFC and not several eve= ry
few years changing huge RFCs with so much room for interpretation that
you can't implement them without looking at older standards and actual<= br> implementations.

> 2) There are a lot of backwards-compatibility things (old-style
> lengths, lots of different algorithms)

Actually there are not many algorithms.=C2=A0 If you know two (with 64 bit<= br> and 128 block length) you know all of them ;-).=C2=A0 CMS hides a lot of details by refering to BER or DER encoding and that is really hard to
test.


Agree.=C2=A0 RFC 4= 880 is not terribly hard to implement in code if you focus on the common us= e cases ("MUST" ciphers and modes) and ignore the optional edge c= ases that very few people use in real practice.=C2=A0 CMS and ASN.1 are gro= ss and painfully hard to implement by comparison.

=
=C2=A0
--001a113dea80b217a105115e2699-- From nobody Sun Mar 15 21:05: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 256161A09CF for ; Sun, 15 Mar 2015 21:05:21 -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 a6GMyH3YJfnI for ; Sun, 15 Mar 2015 21:05:16 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CAE9B1A0199 for ; Sun, 15 Mar 2015 21:05:15 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 2469EF984; Mon, 16 Mar 2015 00:05:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 16BBA202F8; Sun, 15 Mar 2015 21:05:07 -0700 (PDT) From: Daniel Kahn Gillmor To: David Leon Gil , "openpgp\@ietf.org" , "dgil\@yahoo-inc.com" In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 16 Mar 2015 00:05:07 -0400 Message-ID: <87sid5si30.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 04:05:21 -0000 Hi David-- Thanks for this detailed list. I agree with the intent to strip down OpenPGP into a manageable and sensible profile, and i think the choices you're documenting here are generally good. A few clarifications and questions below. On Fri 2015-03-13 21:22:34 -0400, David Leon Gil wrote: > 1. Yahoo and Google have both already deprecated and removed support > for the following packet type specified for use with OpenPGPv4: > > Tag 9 (symmetrically encrypted) packets > > These packets provide unauthenticated encryption and -- if supported > -- can be used in a downgrade attack on senders who only use SEIPD > packets. See https://github.com/coruus/cooperpair/tree/master/encrux > for details. Just to clarify: SEIPD packets are tag 18 packets, which have "integrity-protection" included: https://tools.ietf.org/html/rfc4880#section-5.13 > Yahoo has deprecated, and intends to disable support for all uses, of > the following primitives and packet types specified for use with > OpenPGP v4: > > - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish > - Asymmetric algorithms, generally: RSA-ES, DSA. Are you referring to Public Key Algorithms specifically here? in particular, this table: https://tools.ietf.org/html/rfc4880#section-9.1 If so, RSA-ES (pubkey algorithm 1) is very widely used, even for keys that are only marked for one usage (signatures or encryption). In fact, i don't think there are many RSA keys labeled RSA-E (algo 2) and RSA-S (algo 3) at all. Why treat RSA-ES separately for deprecation? On a relatively up-to-date keyring with a couple-thousand OpenPGP certificates, i did this check (the first column is the count, the second column is the algorithm ID): 0 foo@bar:~$ gpg2 --list-keys --with-colons | awk -F : '/^[ps]ub:/{ print $4 }' | sort | uniq -c 2955 1 1766 16 1648 17 2 18 3 19 19 20 2 22 0 foo@bar:~$ > - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, ELG-E. How did you choose this cutoff? I'm happy to see a high bar personally, but this is likely to invalidate many 2048-bit keys that people have been generating with (e.g.) the GnuPG defaults today. Do you think that GnuPG should change its defaults to the higher cutoff? > - Compression algorithms: ZLIB. (It provides no benefits over DEFLATE, > and is more malleable.) Why keep DEFLATE at all? quining seems to be possible with DEFLATE as well. what if we yanked all compression at this layer? (on openpgp quining due to compression, see the 2013-10-08 entry at http://mumble.net/~campbell/blag.txt) > - Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224. The OpenPGPv4 fingerprint uses SHA-1, in a way that doesn't appear to be cryptographically risky; i'm assuming you're not removing v4 fingerprints entirely, just SHA-1 as a digest algorithm for message signing. right? > 1. A published public key that is more than 1 year old. (This is > mainly taken care of by requiring > 3070 bit RSA keys...) Can you say more about this? Is this about a specific cutoff in time, or *anything* that is "more than 1 year old" at the present? If it's the latter, what effect do you expect this kind of regular key rollover will have? why is it warranted? > 2. Signature by a public key which has ever signed a message or key > using MD-5 or SHA-1. How would you tell if this is the case? Isn't ignoring MD5 and SHA1 signatures itself sufficient? --dkg From nobody Mon Mar 16 01:59:27 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 26E8B1A82E2 for ; Mon, 16 Mar 2015 01:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 FKyDVhSUBJFU for ; Mon, 16 Mar 2015 01:59:15 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 465731A8032 for ; Mon, 16 Mar 2015 01:59:15 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so15832255lbc.2 for ; Mon, 16 Mar 2015 01:59:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wmB0AuWWgnXkarAEzUBatXDpeOOOAXC+E+FkuGjktX4=; b=EhXMQ5TTFWvZ6uEueMX68Le50T7AxtdtikZ2oG+d4jTFUkjo37FiIvE/TPoZJp+uxf YfMZpizQkQ8/0n5JMqg/Sb/Rwy5RPJD72XsJVjDUD7K3oPYBoerexUcNgl3Ydw2vaZhD Vp/LSw4tccN2fIVaBE9ZUXkgnarQy3Z9VGOx6dBCoWB+Cy/0u33YFqaXZz7xHjnQqfDO l4B/jXE0Ez5SMl4W76xBJMkd5lyFjWTL7zNvSz9G/QHlPJH+a1FxbWLS9ElEQSsxByRg /3qwM5B0eTtYvblGCMeNf/fPbsOlh0CVSkVdau/tb6N1vkAJ6zSuNFa5a/N/gHuVgTHg 66dw== X-Gm-Message-State: ALoCoQkw2jHKdWQS+eeHyrXi6dYd/EfB2lJKiEjiNCs2ubVQrfOTA47fdyrsTw3puNMFcOQz/miZ X-Received: by 10.152.9.98 with SMTP id y2mr53867174laa.94.1426496353661; Mon, 16 Mar 2015 01:59:13 -0700 (PDT) Received: from [192.168.4.145] ([195.1.8.34]) by mx.google.com with ESMTPSA id n12sm2062424lbg.31.2015.03.16.01.59.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 01:59:12 -0700 (PDT) Message-ID: <55069B5E.6000404@sumptuouscapital.com> Date: Mon, 16 Mar 2015 09:59:10 +0100 From: Kristian Fiskerstrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <87sid5si30.fsf@alice.fifthhorseman.net> In-Reply-To: <87sid5si30.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 08:59:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/16/2015 05:05 AM, Daniel Kahn Gillmor wrote: > Hi David-- > >> >> - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, >> Twofish - Asymmetric algorithms, generally: RSA-ES, DSA. > > Are you referring to Public Key Algorithms specifically here? in > particular, this table: > > https://tools.ietf.org/html/rfc4880#section-9.1 > > If so, RSA-ES (pubkey algorithm 1) is very widely used, even for > keys that are only marked for one usage (signatures or encryption). > In fact, i don't think there are many RSA keys labeled RSA-E (algo > 2) and RSA-S (algo 3) at all. Why treat RSA-ES separately for > deprecation? > > On a relatively up-to-date keyring with a couple-thousand OpenPGP > certificates, i did this check (the first column is the count, the > second column is the algorithm ID): Just to add a bit more data to this, on a keyserver (a hockeypuck instance not supporting ECC) the corresponding figures (primary + subkey) for 3882360 primary keys and 3612096 subkeys shows. - -----------+--------- 16 | 2658039 1 | 2185612 3 | 627 17 | 2649388 0 | 196 2 | 594 (this is not adjusting for revoked / expired keys etc) On an older copy (around January 2014, this time dumped from SKS supporting ECC) with 3532268 primary keys and 3288749 subkeys, but it shows a bit of the trend +------+----------+ | algo | COUNT(1) | +------+----------+ | 0 | 352 | | 1 | 1552104 | | 2 | 341 | | 3 | 371 | | 16 | 2636715 | | 17 | 2629639 | | 18 | 37 | | 19 | 44 | | 20 | 1380 | | 101 | 2 | | 103 | 32 | +------+----------+ 11 rows in set (3.76 sec). If interesting I can always do a refreshed dump from SKS also adding support for Ed25519 (experimental), if tracking the development of number of keys here is of interest. >> - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, >> RSA-E, ELG-E. > > How did you choose this cutoff? I'm happy to see a high bar > personally, but this is likely to invalidate many 2048-bit keys > that people have been generating with (e.g.) the GnuPG defaults > today. Do you think that GnuPG should change its defaults to the > higher cutoff? And if believing so, what rationale is behind this? - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nosce te ipsum! Know thyself! -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVBptOAAoJEP7VAChXwav6VN0H/iGwKBSh1w47jaOf9pP9uEKL dV1Z4uHSjTTAMZAqWHiX6coRNtBtBzh00RqhFDVhsVm516Dsu0rcWwAQrg17r34w AMgxS/f6DY+TKQFM9jdrZVov2XKkLlOuqSDNlGLumy9X2k9I7HOg0FNt4yHuVLGJ glGPsGYRl9qXdq9e9aVPhzsYFNEkxukhrujgrAWRWm/8WJ1Wj7kO4EZ2cGK2RWzJ g4d+2kxqeuCS0U+i+Pn3S1RqntiEf1KGGLQPhSxAOgK6YYIUJm6k2PMOC+j75qph br4PPRysxAWC+c7+LdCzJH7cdjbRkGQ4ertbt9zRZ6Pksk+iTop7cHjWJ1f0094= =N/um -----END PGP SIGNATURE----- From nobody Mon Mar 16 03:46:53 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 CBA451A86F2 for ; Mon, 16 Mar 2015 03:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IQXqzRft62Jc for ; Mon, 16 Mar 2015 03:46:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8F81A86F0 for ; Mon, 16 Mar 2015 03:46:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2C65BE4C; Mon, 16 Mar 2015 10:46:45 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ_bUM5JKlOa; Mon, 16 Mar 2015 10:46:44 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8D237BE47; Mon, 16 Mar 2015 10:46:44 +0000 (GMT) Message-ID: <5506B493.5050209@cs.tcd.ie> Date: Mon, 16 Mar 2015 10:46:43 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , David Leon Gil , "openpgp@ietf.org" , "dgil@yahoo-inc.com" References: <87sid5si30.fsf@alice.fifthhorseman.net> In-Reply-To: <87sid5si30.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 10:46:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (with no hats) On 16/03/15 04:05, Daniel Kahn Gillmor wrote: > I'm happy to see a high bar personally, but this is likely to > invalidate many 2048-bit keys My experience is that it's far far easier to deprecate things that only have an effect in-line compared to wanting to invalidate long term things like key values, esp. public key values that are distributed around the Internet. So even if one would like to do the latter then I think it'd be a really good plan to separate that part of the argument as it's likely to be much trickier. We had a similar set of issues as we transitioned from DomainKeys to DKIM - in that case the proponents of DomainKeys were (correctly) extremely reluctant to break the few deployments that were then-current. And I think we got that right in that the WG changed the wire-formats and signature algorithm requirements but in such a way that already-deployed public keys continued to work. I'd also note that we ought be cognizant that the fall back here is e2e plaintext. If one considers RFC7435 then I think there's an argument to be considered for allowing crypto that is perhaps approaching it's sell-by date but that is clearly not yet past it's use-by date. (And of course one can have fine arguments about both dates;-) And if we wanted to invalidate current keys, then I think that also puts an onus on us to consider how to figure out the migration path from working->broken->working-again. Lastly, I'd note that e2e email security is a thing where we (IETF and the broader tech community) have failed pretty consistently because we made it too hard. By failed, I mean e2e security is not something that is commonly used by billions of folks. Part of that is UI, but some of it is IMO also because we chose to try to gold-plate security which made usability even worse. I think the classic example with smime was requiring a certificate before anything works - while such decisions may have made sense for the 1990's enterprise, they do not make sense in today's environment. So I think we should be very wary of failing again through attempting to gold-plate by mandating less commonly supported (by dev. environments) algorithms or keys. If there's a real need to invalidate old keys then let's see that technically justified and if we must, then try do that in a way that brings along the few million current users rather than in a way that locks those out. But I'm not yet convinced that there really is such a need. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVBrSTAAoJEC88hzaAX42i7+AH/ilxL3Yc9qnNRMEejGaAva+l JXBuR9yig1xipFeN3nB+5tI6MOjGkgsfv0HC6OmdaACfF3PZIlLQT9B2B0DUCALD EkmVUWCNGpiwduv3qMVnNb11Ryf/vr8KJMkAzAOqGwGHd1LjBOuMpIoOtDgcLnqq iWOXBwkCl+RIuGp3afXQKtcb6K329WnwewaC6rEA1rueVx25bbfQLAVpN8o92eGH sbroL7Ih4Wp3EM6oqoJTRvAUiKNEQ1mN/YaH0vRsmccbu1ekN+qvR13PW2GpOFj/ 8H4tWF52MxXxF7pOIP9nfZicBgPcrUwQ3MD4fxu7Rih3UbR8SDJM4p+xC5rge6s= =IDUt -----END PGP SIGNATURE----- From nobody Mon Mar 16 06:28:31 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 E0E4A1A872E for ; Mon, 16 Mar 2015 06:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 OvLmkJQj-X0K for ; Mon, 16 Mar 2015 06:28:28 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5651A8728 for ; Mon, 16 Mar 2015 06:28:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 93A02E2038; Mon, 16 Mar 2015 09:28:26 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28132-05; Mon, 16 Mar 2015 09:28:24 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 1F8A2E2036; Mon, 16 Mar 2015 09:28:24 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2GDSMQh023332; Mon, 16 Mar 2015 09:28:22 -0400 From: Derek Atkins To: jh@jameshoward.us References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <877fujdc66.fsf@vigenere.g10code.de> Date: Mon, 16 Mar 2015 09:28:22 -0400 In-Reply-To: (James P. Howard's message of "Sat, 14 Mar 2015 10:34:27 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , openpgp@ietf.org, DataPacRat Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 16 Mar 2015 13:28:30 -0000 "James P. Howard" writes: > Is there an upvote button for this?=C2=A0 I even tweeted about this yeste= rday! > > =C2=A0=C2=A0https://twitter.com/howardjp/status/576473455949967360 > > The current signed-XML standard is an awful awful thing and having a usab= le > standard for signed text formats (XML, JSON, whatever) would would make t= he > implementation a de facto default. Have you looked a JOSE? I think this would be out of scope for OpenPGP. > James Howard -derek > On Sat, Mar 14, 2015 at 10:30 AM, DataPacRat wrote: > > On Sat, Mar 14, 2015 at 7:57 AM, Werner Koch wrote: > > On Fri, 13 Mar 2015 20:51, datapacrat@gmail.com said: > > > >> I'm interested in certain aspects of Webs of Trust, such as their > >> potential to overcome certain problematic aspects of centralized > > > > Using this ML for discussin is IMHO okay but trust modells are not a > > goal of the OpenPGP standard.=C2=A0 It might turn out that a certai= n feature > > would be useful and that would be something which can be put into t= he > > standard. >=20=20=20=20 > Will the new OpenPGP standard explicitly include some form of > text-file (or XML, or JSON) format for keys, along the lines of the > venerable 'BEGIN PGP PUBLIC KEY BLOCK'? If so, then as long as it > includes at least one free-form-text comments field which can be used > for arbitrary additional data, such as a score indicating exactly how > much Bayesian trust the key-signer has that the listed key belongs to > its indicated owner, then that would likely be sufficient to cover the > cases I'm thinking of. (There is room for some further elaboration, > such as cryptographically signing said comments, if the general idea > meets approval.) > > Thank you for your time, > -- > DataPacRat > "Then again, I could be wrong." >=20=20=20=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Mon Mar 16 06:46:35 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 466621A8714 for ; Mon, 16 Mar 2015 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 INlFzHeQ0MMP for ; Mon, 16 Mar 2015 06:46:32 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222401A874E for ; Mon, 16 Mar 2015 06:46:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 17F82E2038; Mon, 16 Mar 2015 09:46:31 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28376-01; Mon, 16 Mar 2015 09:46:24 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 844ACE2036; Mon, 16 Mar 2015 09:46:24 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2GDkNxY024751; Mon, 16 Mar 2015 09:46:23 -0400 From: Derek Atkins To: David Leon Gil References: Date: Mon, 16 Mar 2015 09:46:23 -0400 In-Reply-To: (David Leon Gil's message of "Fri, 13 Mar 2015 17:04:06 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 16 Mar 2015 13:46:34 -0000 David Leon Gil writes: > Suppose that I want to test whether an implementation > handles all OpenPGPv4 signed-then-encrypted messages > correctly. How many test cases do I need? Generally? One per packet-trail (which is, effectively, only a handful). If all you're doing is changing out the crypto and not the packet structure then unit tests work perfectly for that. You only need to do integration tests for the packet formats! That's the amazing thing about how OpenPGP was designed. > Let's suppose, first, that I prove that handling of > PTag formats is independent of the rest of the code. > > In that case, the packet composition is either: > > PKESK > SEIPD > COMPRESSED > LITERAL > SIGNATURE > MDC > > Or: > > PKESK > SE > COMPRESSED > LITERAL > SIGNATURE > > How many different ways can I compose this message? TWO! See above. You can unit-test the crypto. Changing from AES to Blowfish doesn't change any of your processing code, the only change is the crypto within the decryptor module. But you've already validating that the crypto works, and you've validated that the decryption module works, so... you're done. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Mon Mar 16 06:49:40 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 DC9661A8753 for ; Mon, 16 Mar 2015 06:49:39 -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 RzeGGJjSY6e2 for ; Mon, 16 Mar 2015 06:49:38 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505111A8756 for ; Mon, 16 Mar 2015 06:49:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1D696E2038; Mon, 16 Mar 2015 09:49:37 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28376-04; Mon, 16 Mar 2015 09:49:35 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id E0631E2036; Mon, 16 Mar 2015 09:49:34 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2GDnWUc025000; Mon, 16 Mar 2015 09:49:32 -0400 From: Derek Atkins To: David Gil References: <55038CBE.7070608@iridiumlinux.org> <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 16 Mar 2015 09:49:31 -0400 In-Reply-To: <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> (David Gil's message of "Sat, 14 Mar 2015 03:57:17 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" , David Gil , Falcon Darkstar Momot Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 16 Mar 2015 13:49:40 -0000 David Gil writes: > On Friday, March 13, 2015 6:20 PM, Falcon Darkstar Momot > wrote: > >> I feel like perhaps this type of exhaustive testing is neither necessary >> nor expected, and that a few end-to-end tests designed to exercise edge >> cases could be combined with more exhaustive unit tests to achieve >> reasonable results. > > > The difficulty, as always, is proving that an actual implementation is > modular. In the case of OpenPGP, it really isn't: A lot of data has to > get carried between each stage to ensure conformance with the > high-level semantics. Having implemented it myself, I disagree completely. It is absolutely possible to create a modular implementation. See my Usenix Security Talk on the PGP Message Processing Pipeline from.... 1996?? [snip] >> Protocol modularity is not evil. > > Modularity is neutral. "Agility", as folks like to call it, is evil. Well, it's a damn good thing we've had agility otherwise we'd have been stuck with 3DES, SHA1 (or MD5!!), and probably either RSA or maybe DSA/Elgamal. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Mon Mar 16 06:51:42 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 E652E1A1A14 for ; Mon, 16 Mar 2015 06:51:40 -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 H-xrd1ojP3sX for ; Mon, 16 Mar 2015 06:51:39 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1C51A8714 for ; Mon, 16 Mar 2015 06:51:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 49F9DE2038; Mon, 16 Mar 2015 09:51:38 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28376-05; Mon, 16 Mar 2015 09:51:36 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 81EC7E2036; Mon, 16 Mar 2015 09:51:36 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2GDpZA9025217; Mon, 16 Mar 2015 09:51:35 -0400 From: Derek Atkins To: Werner Koch References: <873857dbu0.fsf@vigenere.g10code.de> Date: Mon, 16 Mar 2015 09:51:35 -0400 In-Reply-To: <873857dbu0.fsf@vigenere.g10code.de> (Werner Koch's message of "Sat, 14 Mar 2015 13:04:39 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "dgil@yahoo-inc.com" , "openpgp@ietf.org" , David Leon Gil Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 13:51:41 -0000 Werner Koch writes: > On Sat, 14 Mar 2015 02:22, coruus@gmail.com said: > >> 2. Yahoo and GnuPG have both already deprecated V3 public keys for any >> use. We recommend that other implementations do the same. > > Only for GnuPG-2. We keep on maintainog 1.4 so that existisng dat dan > still be decrupted. Yeah, I'm still a bit bitter about that.. ;-) It means I need to keep two versions around and somehow get my mailer to know which one to use when I want to go through my historical encrypted email archives. Oh, you expected me to decrypt/re-encrypt my encrypted email as I got it??? >> Yahoo has deprecated, and intends to disable support for all uses, of >> the following primitives and packet types specified for use with >> OpenPGP v4: > > This is what the preference system is all about. Indeed. > Shalom-Salam, > > Werner -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Mon Mar 16 06:55:29 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 3AC0A1A8769 for ; Mon, 16 Mar 2015 06:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 MJ_ioY5p4ujp for ; Mon, 16 Mar 2015 06:55:26 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE511A8756 for ; Mon, 16 Mar 2015 06:55:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 26B3AE203F for ; Mon, 16 Mar 2015 09:55:25 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28347-08 for ; Mon, 16 Mar 2015 09:55:23 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id E2A97E2036 for ; Mon, 16 Mar 2015 09:55:22 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2GDtMau025465; Mon, 16 Mar 2015 09:55:22 -0400 From: Derek Atkins To: openpgp@ietf.org Date: Mon, 16 Mar 2015 09:55:21 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [openpgp] OpenPGP Bar BOF in Dallas -- call for participation 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, 16 Mar 2015 13:55:27 -0000 Hi, I'd like to get an approximate head-count for who will be in Dallas and who would attend a Bar BOF on Monday after the Plenary? I'd like to get an approximate headcount so I can scope out a location. So far the only positive response I've seen in Paul W. If it's just Paul and I then I guess it'll be a quiet meeting ;) -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Mar 16 07:49:45 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 758B71A87E9 for ; Mon, 16 Mar 2015 07:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 A27XKHLFZsQ0 for ; Mon, 16 Mar 2015 07:49:36 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 175181A87D0 for ; Mon, 16 Mar 2015 07:49:36 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 0263AF2124; Mon, 16 Mar 2015 14:49:35 +0000 (UTC) Date: Mon, 16 Mar 2015 09:49:34 -0500 From: Stephen Paul Weber To: Daniel Kahn Gillmor Message-ID: <20150316144934.GC2944@singpolyma-liberty> References: <87sid5si30.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87sid5si30.fsf@alice.fifthhorseman.net> Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "dgil@yahoo-inc.com" , "openpgp@ietf.org" , David Leon Gil Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 14:49:44 -0000 >> - Asymmetric algorithms, generally: RSA-ES, DSA. > >Are you referring to Public Key Algorithms specifically here? in >particular, this table: > > https://tools.ietf.org/html/rfc4880#section-9.1 > >If so, RSA-ES (pubkey algorithm 1) is very widely used, even for keys >that are only marked for one usage (signatures or encryption). In fact, >i don't think there are many RSA keys labeled RSA-E (algo 2) and RSA-S >(algo 3) at all. Why treat RSA-ES separately for deprecation? In fact, aren't the RSA-E and RSA-S algorithms basically just historical / mostly deprecated in favour of marking keys for a particular use? From nobody Mon Mar 16 07:56:15 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 524D91A8829 for ; Mon, 16 Mar 2015 07:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 WFdRgszXzLJy for ; Mon, 16 Mar 2015 07:56:13 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC44B1A8821 for ; Mon, 16 Mar 2015 07:56:12 -0700 (PDT) Received: from dshaw.nasuni.net (50-202-126-134-static.hfc.comcastbusiness.net [50.202.126.134]) (authenticated bits=0) by mail.jabberwocky.com (8.14.4/8.14.4) with ESMTP id t2GEa8PI008509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 10:36:08 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: David Shaw In-Reply-To: <20150316144934.GC2944@singpolyma-liberty> Date: Mon, 16 Mar 2015 10:56:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3607A1BF-7696-4D5E-BC54-17ACD63ED48F@jabberwocky.com> References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316144934.GC2944@singpolyma-liberty> To: Stephen Paul Weber X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dgil@yahoo-inc.com" , "openpgp@ietf.org" , David Leon Gil , Daniel Kahn Gillmor Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 14:56:14 -0000 On Mar 16, 2015, at 10:49 AM, Stephen Paul Weber = wrote: >=20 >>> - Asymmetric algorithms, generally: RSA-ES, DSA. >>=20 >> Are you referring to Public Key Algorithms specifically here? in >> particular, this table: >>=20 >> https://tools.ietf.org/html/rfc4880#section-9.1 >>=20 >> If so, RSA-ES (pubkey algorithm 1) is very widely used, even for keys >> that are only marked for one usage (signatures or encryption). In = fact, >> i don't think there are many RSA keys labeled RSA-E (algo 2) and = RSA-S >> (algo 3) at all. Why treat RSA-ES separately for deprecation? >=20 > In fact, aren't the RSA-E and RSA-S algorithms basically just = historical / mostly deprecated in favour of marking keys for a = particular use? Yes. If I recall, they predate the "key flags" method of indicating the = intended purpose of a key. 4880 makes them SHOULD NOT generate, but = implementations are allowed to interpret them if they want to (I'd = assume as a type 1 RSA key with an implicit key flags saying = encrypt-only or sign-only, but that's just my reading). David From nobody Mon Mar 16 09:36:01 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 CC7A81A88B3 for ; Mon, 16 Mar 2015 09:35:59 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 I3Tq0gB4vPvd for ; Mon, 16 Mar 2015 09:35:58 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3D21A8892 for ; Mon, 16 Mar 2015 09:35:58 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YXXzg-0003OH-2Z; Mon, 16 Mar 2015 12:35:56 -0400 Date: Mon, 16 Mar 2015 09:35:55 -0700 From: Bill Frantz To: Derek Atkins X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79609515d3eb62d08a44183422ee343099350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Cc: dgil@yahoo-inc.com, Werner Koch , openpgp@ietf.org, David Leon Gil Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 16:35:59 -0000 On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote: >Oh, you expected me to decrypt/re-encrypt my encrypted email as I got it??= ? =46or many uses, decrypting from the wire format and re-encrypting=20 in the "data at rest" security format makes excellent sense.=20 Having only one encryption scheme for long-term storage allows=20 easy (relatively) upgrade and helps to ensure that the data is=20 still accessible, i.e. the decryption still works. I probably=20 have a bunch of old PGP encrypted email I can't read anymore=20 because I don't have the secret key, or its passphrase. If that=20 mail had been re-encrypted in a format that I decrypt every day,=20 I would still be able to read the mail. Encryption that isn't=20 regularly exercised gets rusty. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product. | 16345=20 Englewood Ave www.pwpconsult.com | | Los Gatos,=20 CA 95032 From nobody Mon Mar 16 10:18:36 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 2FC3E1A88F4 for ; Mon, 16 Mar 2015 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2tAz6viAu-wx for ; Mon, 16 Mar 2015 10:18:34 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) (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 21C6E1A88EE for ; Mon, 16 Mar 2015 10:18:34 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id C1F08C0207 for ; Mon, 16 Mar 2015 17:18:33 +0000 (UTC) X-hush-tls-connected: 1 Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS for ; Mon, 16 Mar 2015 17:18:32 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id D0C81E0451; Mon, 16 Mar 2015 17:18:32 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 16 Mar 2015 13:18:32 -0400 To: openpgp@ietf.org From: vedaal@nym.hush.com In-Reply-To: <87sid5si30.fsf@alice.fifthhorseman.net> References: <87sid5si30.fsf@alice.fifthhorseman.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20150316171832.D0C81E0451@smtp.hushmail.com> Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 17:18:35 -0000 On 3/15/2015 at 11:56 PM, "Daniel Kahn Gillmor" wrote: >> Yahoo has deprecated, and intends to disable support for all >uses, of >> the following primitives and packet types specified for use with >> OpenPGP v4: >> >> - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, >Twofish ----- All previous OpenPGP have had a MUST implement for 3DES. Is there any advantage in using only block 64 symmetric encryption primitives, to do away with 3 DES, IDEA and CAST 5? In general, won't removing these primitives make it difficult to decrypt past correspondences where people have used these primitives? (The default for symmmetrically encrypted GnuPG messages has been CAST5 for a long time in the past, -i.e. many many encrypted messages ...) vedaal From nobody Mon Mar 16 10:53:35 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 AB6D31A897D for ; Mon, 16 Mar 2015 10:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 0RwwUgR1j0_d for ; Mon, 16 Mar 2015 10:53:32 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id D68421A897C for ; Mon, 16 Mar 2015 10:53:32 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 865E6626075 for ; Mon, 16 Mar 2015 10:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=davidmitchel.com; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= davidmitchel.com; bh=qkgMIrT6Up4QCRGArzu32ZqLGP0=; b=ie8EIBsXP8O /PJ7R5A/KvincJYym3sthc2STikK1TOVP1WzmCuHbK/Mgl756QqarvIrOyji4YIO 8jjiz1rkOyJ6VcLVk15q4Su6HXPyzJ612/MBaBzhc+o8sH4ZjVgKG9ckxjaOahIQ moXPCTfEw5I1GcJ0DwNYx/C+DCBVf5F8= Received: from [192.168.1.207] (104-48-137-236.lightspeed.rcsntx.sbcglobal.net [104.48.137.236]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: catch-all@davidmitchel.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 4BB2B626074 for ; Mon, 16 Mar 2015 10:53:32 -0700 (PDT) Message-ID: <5507189B.4070504@davidmitchel.com> Date: Mon, 16 Mar 2015 12:53:31 -0500 From: David Mitchel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] OpenPGP Bar BOF in Dallas -- call for participation 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, 16 Mar 2015 17:53:33 -0000 On 03/16/2015 08:55 AM, Derek Atkins wrote: > I'd like to get an approximate head-count for who will be in Dallas and > who would attend a Bar BOF on Monday after the Plenary? I'd like to get > an approximate headcount so I can scope out a location. Count me in! The time slot and location of your choosing works for me. From nobody Mon Mar 16 10:57:45 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 CC9EE1A88F2 for ; Mon, 16 Mar 2015 10:57: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 MNrgvjt00X_N for ; Mon, 16 Mar 2015 10:57:42 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D71A1BC0 for ; Mon, 16 Mar 2015 10:57:42 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 50B5EF984; Mon, 16 Mar 2015 13:57:40 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 871A720322; Mon, 16 Mar 2015 10:57:25 -0700 (PDT) From: Daniel Kahn Gillmor To: Derek Atkins , openpgp@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 16 Mar 2015 13:57:25 -0400 Message-ID: <873854su4a.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] OpenPGP Bar BOF in Dallas -- call for participation 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, 16 Mar 2015 17:57:44 -0000 On Mon 2015-03-16 09:55:21 -0400, Derek Atkins wrote: > I'd like to get an approximate head-count for who will be in Dallas and > who would attend a Bar BOF on Monday after the Plenary? I'd like to get > an approximate headcount so I can scope out a location. > > So far the only positive response I've seen in Paul W. > > If it's just Paul and I then I guess it'll be a quiet meeting ;) I'll be there. --dkg From nobody Mon Mar 16 10:58: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 EEEAA1A896C for ; Mon, 16 Mar 2015 10:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RXPWzH36rc_i for ; Mon, 16 Mar 2015 10:58:40 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7023A1A8956 for ; Mon, 16 Mar 2015 10:58:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 208C76C926C5; Mon, 16 Mar 2015 10:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4XrRw-ioe2Z; Mon, 16 Mar 2015 10:58:09 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 63E226C926B3; Mon, 16 Mar 2015 10:58:08 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 16 Mar 2015 10:58:09 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 16 Mar 2015 10:58:09 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-Reply-To: <20150315175744.GG2978@singpolyma-liberty> Date: Mon, 16 Mar 2015 10:58:07 -0700 Message-Id: <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> References: <20150315175744.GG2978@singpolyma-liberty> To: Stephen Paul Weber X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 17:58:43 -0000 > 1) Sections of the RFC define what you might call "extras", such as = the ASCII Armor (including a checksum unused elsewhere in the spec) Certainly the ASCII Armor checksum is something that could go, since we = don't need to worry so much about modem line noise. :-) But you have to = know enough to ignore it. > 2) There are a lot of backwards-compatibility things (old-style = lengths, lots of different algorithms) >=20 > One of the things I've tried to work on to help in some of my use = cases is a modular description for a subset of OpenPGP that is = (hopefully) easier to immediately grok and/or implement. It is at = One of the things that I did once was to streamline an implementation my = receiving a number of things well, like old-style packets and lengths, = but only generating one thing (like five-byte lengths) on the grounds = that if you move to generating a simplified format, you can then start = doing usage surveys on when to phase out the old stuff. But yes, having a simplified profile would be a great thing to do, I = think. Jon From nobody Mon Mar 16 11:09:12 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 1040E1A89A1 for ; Mon, 16 Mar 2015 11:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 Q6acZY_S3J80 for ; Mon, 16 Mar 2015 11:09:08 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 959841A899A for ; Mon, 16 Mar 2015 11:09:08 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 1F2C226C0001; Mon, 16 Mar 2015 18:09:06 +0000 (UTC) Date: Mon, 16 Mar 2015 13:08:55 -0500 From: Stephen Paul Weber To: Wyllys Ingersoll Message-ID: <20150316180855.GE2944@singpolyma-liberty> References: <20150315175744.GG2978@singpolyma-liberty> <873856aw5a.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 18:09:10 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >Agree. RFC 4880 is not terribly hard to implement in code if you focus on >the common use cases ("MUST" ciphers and modes) and ignore the optional >edge cases that very few people use in real practice. I agree. I've implemented large parts of RFC4880 several times, with only= =20 a few catches. This is just feedback I've gotten from others I've tried to= =20 work with, especially specs where I've suggested they use OpenPGP instead o= f=20 inventing their own crypto (I think the first community I tried this with= =20 was Salmon/MagicSig). --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVBxw3AAoJENEcKRHOUZze0SwQAMAcE9zG1z9dybhMsIHHh79I 7SooDv4nYd9J/KWwFbMiyz/f34+UGjIIqVWNkL2td84Ftl4eMvOX+udupWjLLbS/ Hs0MK0y4Ysd+ch6gqcHxnV9gdDi96xH/yqjPMMb64J+0dmyULc+P1Dls9py6xHez nuDd0vkpdeZtIikFfXbsJPsWuVc9u51lQL5igrRB2TkZ1L00SoKOThwD/zwQMvWv NJinZl4by1WdCWNAEPhKAmr+Q6444/GplmqWuRkVtbpkav54HiUzGBr+y9NYhg3U FMpgfGJO/A/ufJP3Ixv/e93dh9MnpP8fcS3a8I2JmoQ7OFLaOT/HrAYn8vnr6iKL vqD9ZxTzdlvUwXFpO8fdAV1us/LUn/AIHPFpfGzZljDYKWiED961KrdG7qFnQBep a5xpzrao+bGG+pvfCIp+55nkpr5B+r1P8LvBJPmZXWws4jM8RvNwNW1wwSZ4lhrK SApNb8f5Q5CHB0M2irjSOiVPj0QEhSOgdGYOhdld8b5v+Y9z0xxIxxlwNpIVWALA YlG/6MIx62bx28W/d0iu7Ea4UqfD+OICU0+mMgUOgMgd+nIgu5D9R8qdw+wl4i6Z vH+A1BTynsVK+96y+w2p7FtBTOT+Rrnx9BjUaKu+E8dH054S6LqT0ie0hqpfoqVC XagSlniJ9K79dp3V5Qe9 =SEyf -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From nobody Mon Mar 16 11:12:20 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 91DE61A89B8 for ; Mon, 16 Mar 2015 11:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 5TmPO_XtZCVI for ; Mon, 16 Mar 2015 11:12:15 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD51A89AF for ; Mon, 16 Mar 2015 11:12:14 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 48DB8F2124; Mon, 16 Mar 2015 18:12:14 +0000 (UTC) Date: Mon, 16 Mar 2015 13:12:13 -0500 From: Stephen Paul Weber To: Jon Callas Message-ID: <20150316181213.GF2944@singpolyma-liberty> References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 18:12:16 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >One of the things that I did once was to streamline an implementation my= =20 >receiving a number of things well, like old-style packets and lengths, but= =20 >only generating one thing (like five-byte lengths) on the grounds that if= =20 >you move to generating a simplified format, you can then start doing usage= =20 >surveys on when to phase out the old stuff. Yes. Last time I checked, gnupg < 2 (which is still the default on most of= =20 my systems) only generates old-style headers, whereas my implementations=20 tend to only generate new-style. Of course, usually one wants to consume= =20 both, if creating even a fairly-complete implementation, because of gnupg. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVBxz9AAoJENEcKRHOUZze/E8P+wQcud6r6jcO40SOlBwXwkIf 55mwIhmGBKP2c6cIRkKuUwegGMwHIjLTr+o7COJdc76y9sIGLotM/HCRUBKMsIbd oQkuoooYkH53Opzk2GTfjImpJ9LAV4Gs08nDCAXRp2tsLHmdujTOi/5VR/thJndK c2yIlApMHNEio2jYt7vX1pW9WPymJ5nZSWExQe51gIrBxK+LbBKerUqUjrA4YUdO BVV/Am5tNvXYzlFJ+O8eNJJsQh6rYNR0x8HW/nhNSPMSua7YcMvAAx4RBpzXeSzy o6+EU5cvn9NKX/7jy0O4LrPDnM6KpeXVtfAeZen+nqzOmIY0YiOurM6VUecNa8iM 2B6lAFMzx/lgWme4EnXEk5DUeOtUcmDeqjBioWpP2sTH1HJsJDjMes6v98hs4xsT TQzx1fW65BJkqhjH7PGaF8ExPIeE0nWXfdcPX2sqh3kENTCwpIRCGDjLBYL39JGT 4ZseQT5O0qGuaU3bCR8R4T+E6ikJJkFqM9M4Y4XICpnGPYP0dg3AB5KyOhHC1YzP raq26SHjiWpQvOJS2H6KsF6i77rVtkYdpP+qCqiS3wLtkXxJzmWJTJWvOmjRYuhK ltXl3SOdtiuE3jU7IeD66DzadhQ/4pgKIwQgrbMi62NbTVupyMwl2s2movuVGI+Q FRPHJ/LT+eWAMY/ZKwt9 =u/+2 -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From nobody Mon Mar 16 12:51:46 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 538831A1B78 for ; Mon, 16 Mar 2015 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 W0nKwmfm4BsG for ; Mon, 16 Mar 2015 12:51:43 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468A41A904A for ; Mon, 16 Mar 2015 12:51:22 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YXb2m-0004N0-Qs for ; Mon, 16 Mar 2015 20:51:20 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YXaxP-00070n-UQ; Mon, 16 Mar 2015 20:45:47 +0100 From: Werner Koch To: Stephen Paul Weber References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> 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 Date: Mon, 16 Mar 2015 20:45:47 +0100 In-Reply-To: <20150316181213.GF2944@singpolyma-liberty> (Stephen Paul Weber's message of "Mon, 16 Mar 2015 13:12:13 -0500") Message-ID: <87d2484tg4.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, Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 19:51:45 -0000 On Mon, 16 Mar 2015 19:12, singpolyma@singpolyma.net said: > Yes. Last time I checked, gnupg < 2 (which is still the default on > most of my systems) only generates old-style headers, whereas my That depends on how you invoke gpg and whether the new packer headers are required. That is required for PGP-2 compatibility. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Mar 16 12:51:54 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 712471A905A for ; Mon, 16 Mar 2015 12:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zjhg2JmuY_Fb for ; Mon, 16 Mar 2015 12:51:51 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (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 1C2071A9058 for ; Mon, 16 Mar 2015 12:51:51 -0700 (PDT) Received: by ladw1 with SMTP id w1so49461735lad.0 for ; Mon, 16 Mar 2015 12:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/qHZ9t4FRUK5Y8sNexzqfqW4XE5sW6qT/1X3r1O2HoI=; b=wkak7q9hxG69rRT0y5+ha46ObwBz6c0e0v6bEDOFtpt8zLJyWpby5ms2KqYZPqib3O pq/gQ3cdiAPH9KYbyLDxv6A7BwrdweBrsRF6oQ/TffbSHMV5DSR7GlmDecbXq4q4m9NW tMM8CR4loXYxWH8Un2/7zngn9XHahrjPZyFzQaabQvbgMs9ye62GJEiVMftVLnldVn1D lh0slRntvR2ESnVuFROwCoULg5du68glP/r9I85buaFFjvq7LD/zuwP+PH8v5xTBGq6I VNjZqLGEjKAAlPz1eKJzqK6HHPmkb+hu72G3yEo9jpCfwZzwCV4LCZemPxveo6aYe3EN hZqQ== MIME-Version: 1.0 X-Received: by 10.112.78.37 with SMTP id y5mr55584455lbw.91.1426535509671; Mon, 16 Mar 2015 12:51:49 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Mon, 16 Mar 2015 12:51:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 15:51:49 -0400 X-Google-Sender-Auth: 8joqZvjLSkh7ZuVk_gR3hx8A5ig Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c3bb7050446a05116d2e45 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] OpenPGP Bar BOF in Dallas -- call for participation 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, 16 Mar 2015 19:51:53 -0000 --001a11c3bb7050446a05116d2e45 Content-Type: text/plain; charset=UTF-8 I will be there assuming that this does not conflict with ACME or DPRIV side meetings. On Mon, Mar 16, 2015 at 9:55 AM, Derek Atkins wrote: > Hi, > > I'd like to get an approximate head-count for who will be in Dallas and > who would attend a Bar BOF on Monday after the Plenary? I'd like to get > an approximate headcount so I can scope out a location. > > So far the only positive response I've seen in Paul W. > > If it's just Paul and I then I guess it'll be a quiet meeting ;) > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a11c3bb7050446a05116d2e45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I will be there assuming that this does not conflict with = ACME or DPRIV side meetings.

On Mon, Mar 16, 2015 at 9:55 AM, Derek Atkins <derek@ihtfp.= com> wrote:
Hi,

I'd like to get an approximate head-count for who will be in Dallas and=
who would attend a Bar BOF on Monday after the Plenary?=C2=A0 I'd like = to get
an approximate headcount so I can scope out a location.

So far the only positive response I've seen in Paul W.

If it's just Paul and I then I guess it'll be a quiet meeting ;)
-derek
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

--001a11c3bb7050446a05116d2e45-- From nobody Mon Mar 16 13:11:34 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 CFBC41A90A4 for ; Mon, 16 Mar 2015 13:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FXQzCvTyLV0E for ; Mon, 16 Mar 2015 13:11:31 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 72CFD1A908F for ; Mon, 16 Mar 2015 13:11:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 9DF6D6C96B9D; Mon, 16 Mar 2015 13:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO2udmfYhIeq; Mon, 16 Mar 2015 13:10:58 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 457B26C96B8C; Mon, 16 Mar 2015 13:10:58 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 16 Mar 2015 13:10:58 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 16 Mar 2015 13:10:58 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-Reply-To: <20150316144934.GC2944@singpolyma-liberty> Date: Mon, 16 Mar 2015 13:10:57 -0700 Message-Id: References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316144934.GC2944@singpolyma-liberty> To: Stephen Paul Weber X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 20:11:33 -0000 > On Mar 16, 2015, at 7:49 AM, Stephen Paul Weber = wrote: >=20 > In fact, aren't the RSA-E and RSA-S algorithms basically just = historical / mostly deprecated in favour of marking keys for a = particular use? >=20 Yes. They were essentially historical even in RFC 1991 days. Jon From nobody Mon Mar 16 14:01:01 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 A0A671A912C for ; Mon, 16 Mar 2015 14:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 SJ9pj7rMGQRq for ; Mon, 16 Mar 2015 14:00:58 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (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 F1FEC1A912B for ; Mon, 16 Mar 2015 14:00:57 -0700 (PDT) Received: by yhpt93 with SMTP id t93so21832405yhp.0 for ; Mon, 16 Mar 2015 14:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tXUgYKm+mAjne7F30fiHRzMU4PftT3UcUjSYklo3oVo=; b=Zf97Y5etn7HNqLHUW6iB13X8ixTnf/wV8eTfrf0PrY5l8VxJwTPqYhkXa1mZZnlaTx 8oFRtIfqyFOD7tqJn4qLpLGIOEmk1Q7S+rzQ0ShGP5/XhEXFYzfZ2FoQvYaYZMpEmry0 lr9ujpW2XWpA+VibCKEtMwXVkaSugLv6DyKP2vvNVNtvMTw9z1VPpmn1fc0INbIJ8dGj icFHARHvJZvjmh7Tf4f1/E+o9+PF0PVqENni1QGxIUY622/6Iy+VnAFSJ8HK8nL85ewj KIw5WiqCFflM8PB8BUv6LmE25xd1S16zMjxIJhTHrUMXabkt1BIHcolqABw9KvjbmEHV 4veQ== MIME-Version: 1.0 X-Received: by 10.236.27.72 with SMTP id d48mr63309010yha.60.1426539657290; Mon, 16 Mar 2015 14:00:57 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 14:00:57 -0700 (PDT) In-Reply-To: References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316144934.GC2944@singpolyma-liberty> Date: Mon, 16 Mar 2015 14:00:57 -0700 Message-ID: From: David Leon Gil To: Jon Callas Content-Type: multipart/alternative; boundary=089e0160ac6e87ea2605116e2594 Archived-At: Cc: Stephen Paul Weber , "openpgp@ietf.org" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 21:00:59 -0000 --089e0160ac6e87ea2605116e2594 Content-Type: text/plain; charset=UTF-8 On Monday, March 16, 2015, Jon Callas wrote: > > > On Mar 16, 2015, at 7:49 AM, Stephen Paul Weber < > singpolyma@singpolyma.net > wrote: > > > > In fact, aren't the RSA-E and RSA-S algorithms basically just historical > / mostly deprecated in favour of marking keys for a particular use? My impression was that many new implementations use the RSA-S and RSA-E algorithms for signing keys and encryption subkeys. But -- taking a look at SKS numbers --algorithm 1 is used quite a lot. I generally prefer domain separation, but I don't think there's a relevant security difference *so long as* implementations do not generate a single RSA key such that its key usage intersects only one of {certify, sign, authenticate} or {encrypt communications, encrypt bulk}. (And so, in the eventual I-D, I'll likely make that the requirement. I would be inclined, in that case, to state that implementations SHOULD accept any of algorithms 1, 2, 3 for any usage mask valid under the above criterion.) --089e0160ac6e87ea2605116e2594 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 16, 2015, Jon Callas <jon@callas.org> wrote:

> On Mar 16, 2015, at 7:49 AM, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
>
> In fact, aren't the RSA-E and RSA-S algorithms basically just hist= orical / mostly deprecated in favour of marking keys for a particular use?<= /blockquote>

My impression was that many new implementat= ions use the RSA-S and RSA-E algorithms for signing keys and encryption sub= keys. But --=C2=A0taking a look at SKS numbers --algorithm 1 is used quite = a lot.

I generally prefer domain separation, but I= don't think there's a relevant security difference *so long as* im= plementations do not generate a single RSA key such that its key usage inte= rsects only one of=C2=A0{certify, sign, authenticate} or {encrypt communica= tions, encrypt bulk}.

(And so, in the eventual=C2= =A0I-D, I'll likely make that the requirement. I would be inclined, in = that case, to state that implementations SHOULD accept=C2=A0any of algorith= ms=C2=A01, 2, 3 for any usage mask=C2=A0valid under the above=C2=A0criterio= n.)
--089e0160ac6e87ea2605116e2594-- From nobody Mon Mar 16 14:10:11 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 35FE41A90E9 for ; Mon, 16 Mar 2015 14:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 dBwk0HgtZ7AI for ; Mon, 16 Mar 2015 14:10:05 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 90AA41A90FE for ; Mon, 16 Mar 2015 14:09:59 -0700 (PDT) Received: by ykek76 with SMTP id k76so22825460yke.0 for ; Mon, 16 Mar 2015 14:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qp3uUyzI0q1Rxz4wXdowOyAuAQ7OTN2lNsitV34vhoI=; b=RLnUr1ot7TeXu9Hey+FNB+OpBeuLZTE5OZ8Q8vwb/PezunvQmr/yoOjmzWIzmiW123 kY7MjdNJECJiK90JKf/Br7sm2QZtqrEOTc5Grpz++nRpuB+tLPPl1kokU8L1ZMvM8Mp0 cX+4INMEZ2yddQiOGrMLo1w1cfCtJCQ9mzr82Hl6y/5CrKPhREsFmJMDrLIsJ0hjHLRS P+SCDtoJdk1kIVjoNCSbyJE437VH/SWUHiRWabKHdUebXZA8uYeEZRMuHif5MoTbEbXn B3IgRuE7O+n9J1WWu5HrQ9w0gv5AswaiM9TEg9t26/Dc/UNFXefO6B5cSAIaMnT6TqpX Jnag== MIME-Version: 1.0 X-Received: by 10.170.46.3 with SMTP id 3mr71259150yko.24.1426540199013; Mon, 16 Mar 2015 14:09:59 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 14:09:58 -0700 (PDT) In-Reply-To: <20150316171832.D0C81E0451@smtp.hushmail.com> References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316171832.D0C81E0451@smtp.hushmail.com> Date: Mon, 16 Mar 2015 14:09:58 -0700 Message-ID: From: David Leon Gil To: "vedaal@nym.hush.com" Content-Type: multipart/alternative; boundary=001a11437dcad1f39105116e45be Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 21:10:10 -0000 --001a11437dcad1f39105116e45be Content-Type: text/plain; charset=UTF-8 On Monday, March 16, 2015, wrote: > On 3/15/2015 at 11:56 PM, "Daniel Kahn Gillmor" > wrote: > > >> Yahoo has deprecated, and intends to disable support for all > >uses, of > >> the following primitives and packet types specified for use with > >> OpenPGP v4: > >> > >> - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, > >Twofish > > ----- > > All previous OpenPGP have had a MUST implement for 3DES. > Is there any advantage in using only block 64 symmetric encryption > primitives, to do away with 3 DES, IDEA and CAST 5? Yes re block size (I'm assuming you meant 128-bit blocksize ciphers). A 64-bit blocksize is small enough that there is a significant probability of (some user) encrypting a message with two blocks the same. CAST5 (CAST128), however, is a 128-bit blocksize cipher. In general, won't removing these primitives make it difficult to decrypt > past correspondences where people have used these primitives? > (The default for symmmetrically encrypted GnuPG messages has been CAST5 > for a long time in the past, -i.e. many many encrypted messages ...) > Yes. GnuPG's use of CAST5 is problematic. We won't support this usage for encryption or decryption. (Mainly because it did so if you didn't set a 'modern' cipher, and thus didn't use the SEIPD+MDC packet.) Other implementations are free to; they really shouldn't be encrypting new messages using it. I will note that the Canadian government still permits the use of CAST5 for the encryption of data at a 128-bit security level, but requires a cryptoperiod of < 7 days. (Which is not terrribly reassuring.) See https://www.cse-cst.gc.ca/en/node/227/html/15164 --001a11437dcad1f39105116e45be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 16, 2015, <veda= al@nym.hush.com> wrote:
On 3/15/= 2015 at 11:56 PM, "Daniel Kahn Gillmor" <= dkg@fifthhorseman.net> wrote:

>> Yahoo has deprecated, and intends to disable support for all
>uses, of
>> the following primitives and packet types specified for use with >> OpenPGP v4:
>>
>> - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish,
>Twofish

-----

All previous OpenPGP have had a MUST implement for 3DES.
Is there any advantage in using only block 64 symmetric encryption primitiv= es, to do away with 3 DES, IDEA and CAST 5?

Yes = re block size=C2=A0=C2=A0(I'm assuming you meant 128-bit blocksize ciph= ers). A 64-bit blocksize is small enough that there is a significant probab= ility of (some user) encrypting a message with two blocks the same.
=C2=A0
CAST5 (CAST128), however, is a 128-bit blocksize cipher.<= /div>

In general, won't removing these primitives make it difficult to decryp= t past correspondences where people have used these primitives?
(The default for symmmetrically encrypted GnuPG messages has been CAST5 for= a long time in the past, -i.e. many many encrypted messages ...)

Yes. GnuPG's use of CAST5 is problemat= ic. We won't support this usage for encryption or decryption.=C2=A0(Mai= nly because it did so if you didn't set a 'modern' cipher, and = thus didn't use the SEIPD+MDC packet.)

Other i= mplementations are free to; they really shouldn't be encrypting new mes= sages using it.

I will note that the Canadian gove= rnment still permits the use of CAST5 for the encryption of data at a 128-b= it security level, but requires a cryptoperiod of < 7 days. (Which is no= t terrribly reassuring.)

--001a11437dcad1f39105116e45be-- From nobody Mon Mar 16 14:11:39 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 42A751A90FA for ; Mon, 16 Mar 2015 14:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 5mD6qXYkSTq0 for ; Mon, 16 Mar 2015 14:11:35 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (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 78CAF1A90FD for ; Mon, 16 Mar 2015 14:11:34 -0700 (PDT) Received: by yhct68 with SMTP id t68so21913529yhc.2 for ; Mon, 16 Mar 2015 14:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=liN0F47qrxBMdDkigdvpDP44lZWkVzYjaYT+qnB+Kio=; b=b1tM7FTj7V1fZVOsOXzHAyNk1noBEve+HkLr7KdcUqmRFOa8HmYTBVZP6ufcuTQOUe TyyLh5iTMUwVMfWlCX9/INT0fzRaP754HTPH0e2iiHoYwsyQi0RgL7ERSlZAmhizdeif MOFpRRW5WPumOujsYN9Ke4277MgNxrn0KbaeSjqhiRDrQ8C6234PLCu5S6lGZw219/G7 v+0Q2eWnEmq2tAGat3m3Fjowi2S54RL7WjtgVVOZ5nzp9XZQB6Rw9gI/S5EA19i+/QO1 1/rYOMcW7qD1v+CrlqqDTmEaRhrI53XzcEZoq/56BZc5pOOj/H6O5ET7v9hb07w2GS0X En5w== MIME-Version: 1.0 X-Received: by 10.236.221.228 with SMTP id r94mr64222551yhp.127.1426540293850; Mon, 16 Mar 2015 14:11:33 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 14:11:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 14:11:33 -0700 Message-ID: From: David Leon Gil To: Bill Frantz Content-Type: multipart/alternative; boundary=001a11c2cc42790dca05116e4b83 Archived-At: Cc: Derek Atkins , Werner Koch , "openpgp@ietf.org" , "dgil@yahoo-inc.com" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 21:11:37 -0000 --001a11c2cc42790dca05116e4b83 Content-Type: text/plain; charset=UTF-8 On Monday, March 16, 2015, Bill Frantz wrote: > On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote: > > Oh, you expected me to decrypt/re-encrypt my encrypted email as I got >> it??? >> > > [...] I probably have a bunch of old PGP encrypted email I can't read > anymore because I don't have the secret key, or its passphrase. If that > mail had been re-encrypted in a format that I decrypt every day, I would > still be able to read the mail. Yep. Same boat here, actually. I think this is something that is better for security and better for usability. --001a11c2cc42790dca05116e4b83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 16, 2015, Bill Frantz <frantz@pwpconsult.com> wrote:
On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote:
Oh, you expected me to decrypt/re-encrypt my encrypted email as I got it???=

[...] I probably have a bunch of old PGP encrypted email I can't re= ad anymore because I don't have the secret key, or its passphrase. If t= hat mail had been re-encrypted in a format that I decrypt every day, I woul= d still be able to read the mail.=C2=A0

Yep= . Same boat here, actually. I think this is something that is=C2=A0better f= or security and better for usability.
--001a11c2cc42790dca05116e4b83-- From nobody Mon Mar 16 14:15: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 44A071A9102 for ; Mon, 16 Mar 2015 14:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 CwfSWMjCglvC for ; Mon, 16 Mar 2015 14:15:20 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 050981A90FA for ; Mon, 16 Mar 2015 14:15:20 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 57D33F211F; Mon, 16 Mar 2015 21:15:19 +0000 (UTC) Date: Mon, 16 Mar 2015 16:15:18 -0500 From: Stephen Paul Weber To: David Leon Gil Message-ID: <20150316211518.GL2944@singpolyma-liberty> References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316144934.GC2944@singpolyma-liberty> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M/SuVGWktc5uNpra" Content-Disposition: inline In-Reply-To: Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 21:15:21 -0000 --M/SuVGWktc5uNpra Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >My impression was that many new implementations use the RSA-S and RSA-E The opposite is true. RSA-S and RSA-E are from old implementations. These= =20 days there are more robust ways to specify what a key is for. >I generally prefer domain separation, but I don't think there's a relevant >security difference *so long as* implementations do not generate a single >RSA key such that its key usage intersects only one of {certify, sign, >authenticate} or {encrypt communications, encrypt bulk}. For sure, but this seperation is done in metadata, not in the algorithm=20 identifier. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --M/SuVGWktc5uNpra Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVB0fmAAoJENEcKRHOUZzepFsQAI7R7mQbdhVqT62BZNHa217j vuS149DfeYv07rCoVFyku3xWMoOxTLIkjuQTcE3KiXa35/34eZyW1WN0M/+yxNpC Obplq6OfY+Y6KaEsFWr6MoVg5KrgVlQaS58ysEl1zLfCF2qrZF09kEcPGewly1c1 1sV4lOlJqvHto2caqj3Fhhye8RaEr52XMoVyXfblYYjZ8cD6kZ4oZOAGqZIzBdhl 3dUygeI5+PwF8G+nfRaaFC5gcfU1nCxiVBcafAXbmld/v06wvcl11sdGVq0P19W5 gegRFi3o+AHPSjAliNtTPqfRMQ8Gw5CMFX8nTgGCp3zB8/JXlLGP0paiDfg89MPo PtGP1jdUcuN+z535NPTMt0aDFXbIvMUOY7iE6nE+J65nWsd+yVcZsGtqtA04PCQX nG7mevSlC7IORKIzqujVRE4G0InnbYWRwLTuUAcKCh0hHBnTgbs6R32crH5WB10u 8hJ0HDi+1pBHpLKZ244tm7B1wzf5DuIDvJn7F0XYwYWGOK2+04SoSGxHXNVPri0u +bqZ/ylKMIJBOVbuWZOoNIv1O8rXaprd6Sor2vJSP6iYkZ1GXHdwH0U6UOneEHxU ra/7lhQ1UY60Tu64cF26atDwUR+mi8y/sZ/Ot87J2aZcxOZ0/Ak9HittzMWRBUBp q0+TUlG93GBtOxP0RLJw =XWkb -----END PGP SIGNATURE----- --M/SuVGWktc5uNpra-- From nobody Mon Mar 16 14:15:41 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 8FF311A912F for ; Mon, 16 Mar 2015 14:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 a2MfL4V7e8lY for ; Mon, 16 Mar 2015 14:15:30 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 D689E1A9130 for ; Mon, 16 Mar 2015 14:15:28 -0700 (PDT) Received: by ykcn8 with SMTP id n8so22796077ykc.3 for ; Mon, 16 Mar 2015 14:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W8i7qdwnl4kCo52mMn5PxWyOZdvUJLRmfwn5MAsi9a0=; b=vhl8JHjuABSRJ/hukz+PLaItDaezgj0gDLKSUgGD0V7QYd1XinPjN/rGRD9csvbnEK c6p6Oq9jz3Z8HflTLCzMbVDC4EZRwmZuOXfmwIU6FjUmZzDoVdhxywzRUbkX+n6y7ZZn ykxHSHM4IqA2+tyAIB95LNh8B4L7Evx8lwDgl9wbCZRbAIwfJbwCSLj4LzEDradVy1Nv TW6xSiNho0Jt5nAtZavn4OgvLJnfHpgwXSKe8LHoljj8tVsdftvYr6bF0ipQgLnJYylq e6/fOoqMmy6cSKOuQEY1E73XJ82zmCRsddF37HmS/4n/GTzEfw6PfryKeMhALRrbI+UM cz6w== MIME-Version: 1.0 X-Received: by 10.170.133.206 with SMTP id z197mr18149040ykb.18.1426540528292; Mon, 16 Mar 2015 14:15:28 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 14:15:28 -0700 (PDT) In-Reply-To: <87d2484tg4.fsf@vigenere.g10code.de> References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Date: Mon, 16 Mar 2015 14:15:28 -0700 Message-ID: From: David Leon Gil To: Werner Koch Content-Type: multipart/alternative; boundary=001a1139787472579505116e59e1 Archived-At: Cc: Stephen Paul Weber , gnupg-devel@gnupg.org, "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 21:15:35 -0000 --001a1139787472579505116e59e1 Content-Type: text/plain; charset=UTF-8 Re Jon's comment above: The five-octet, new-format thing is what the End-to-End extension does. On Monday, March 16, 2015, Werner Koch wrote: > On Mon, 16 Mar 2015 19:12, singpolyma@singpolyma.net said: > > > Yes. Last time I checked, gnupg < 2 (which is still the default on > > most of my systems) only generates old-style headers, whereas my > > That depends on how you invoke gpg and whether the new packer headers > are required. That is required for PGP-2 compatibility. > Is there an option to completely disable this? Relatedly, is there any option to not use new-format partial lengths? Partial lengths are really a nuisance to parse. --001a1139787472579505116e59e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Re Jon's comment above: The five-octet, new-format thing is what t= he End-to-End extension does.

On Monday, March 16, 2015= , Werner Koch <wk@gnupg.org> wrot= e:
On Mon, 16 Mar 2015 19:12, singpolyma@singpolyma.net said:

> Yes.=C2=A0 Last time I checked, gnupg < 2 (which is still the defau= lt on
> most of my systems) only generates old-style headers, whereas my

That depends on how you invoke gpg and whether the new packer headers
are required.=C2=A0 That is required for PGP-2 compatibility.

Is there an option to completely disable this? Relatedly,= is there any option to not use new-format partial lengths?

Partial lengths are really a nuisance to parse.
--001a1139787472579505116e59e1-- From nobody Mon Mar 16 14:17:54 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 AED441A9142 for ; Mon, 16 Mar 2015 14:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 RH5olD7vpiVA for ; Mon, 16 Mar 2015 14:17:42 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473D01A913B for ; Mon, 16 Mar 2015 14:17:28 -0700 (PDT) Received: from dshaw.nasuni.net (50-202-126-134-static.hfc.comcastbusiness.net [50.202.126.134]) (authenticated bits=0) by mail.jabberwocky.com (8.14.4/8.14.4) with ESMTP id t2GKvHD4018393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 16:57:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: David Shaw In-Reply-To: Date: Mon, 16 Mar 2015 17:17:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316144934.GC2944@singpolyma-liberty> To: David Leon Gil X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Stephen Paul Weber , "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 21:17:46 -0000 On Mar 16, 2015, at 5:00 PM, David Leon Gil wrote: >=20 > On Monday, March 16, 2015, Jon Callas wrote: >=20 > > On Mar 16, 2015, at 7:49 AM, Stephen Paul Weber = wrote: > > > > In fact, aren't the RSA-E and RSA-S algorithms basically just = historical / mostly deprecated in favour of marking keys for a = particular use? >=20 > My impression was that many new implementations use the RSA-S and = RSA-E algorithms for signing keys and encryption subkeys. But -- taking = a look at SKS numbers --algorithm 1 is used quite a lot. Having a lot of algorithm 1 makes sense: RSA-S and RSA-E are deprecated, = and were made "SHOULD NOT" create in 4880, in favor of using the key = flags subpacket to indicate usage. I don't know of any current = implementations that use RSA-S or RSA-E for new keys. David From nobody Mon Mar 16 14:19: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 0233B1A9102 for ; Mon, 16 Mar 2015 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 TObTBs5WwFIY for ; Mon, 16 Mar 2015 14:19:00 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 2B9E21A913D for ; Mon, 16 Mar 2015 14:19:00 -0700 (PDT) Received: by ykfs63 with SMTP id s63so22904923ykf.2 for ; Mon, 16 Mar 2015 14:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gjhF2W/2GfBVPVgXgkuF3NygtFD6+JoSIK4/fCmH5dA=; b=HhXdluiICEjMxJTsP2UZsO4lt3hVCVhlIMf7M7M/sosgAk4v4IPHeOL23EQU2TI3ik rw6/mNbbkGclpJbK4KYf+X8U15RgU3UsE+Y3yxd8uJursAkP7+cL2/j+DLtSKdi2O4do XsTMrBsCfAxoakOJJWhU8fqTUwwYc1i9ENaDbQ+xmUhOr0F+UETtPiqRWYjzTeTpeWCl 6rMSYvOKfNmFI5XzRrH4yvEKav3EOqZfYjz80G35AIZFmkega8Er9sDjtVnARMFM1v4p xWcFCo86bu+etNeUH5e/UsXZzDVAYiNrU0bDiPKCZEf7sdGypK3ULvoMphTlNBaQKQZA gJKA== MIME-Version: 1.0 X-Received: by 10.170.46.3 with SMTP id 3mr71297338yko.24.1426540739488; Mon, 16 Mar 2015 14:18:59 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 14:18:59 -0700 (PDT) In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <877fujdc66.fsf@vigenere.g10code.de> Date: Mon, 16 Mar 2015 14:18:59 -0700 Message-ID: From: David Leon Gil To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11437dca08f11105116e6612 Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , "openpgp@ietf.org" , DataPacRat , "jh@jameshoward.us" Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 16 Mar 2015 21:19:02 -0000 --001a11437dca08f11105116e6612 Content-Type: text/plain; charset=UTF-8 On Monday, March 16, 2015, Derek Atkins wrote: > "James P. Howard" > writes: > > > Is there an upvote button for this? I even tweeted about this yesterday! > > > > https://twitter.com/howardjp/status/576473455949967360 > > > > The current signed-XML standard is an awful awful thing and having a > usable > > standard for signed text formats (XML, JSON, whatever) would would make > the > > implementation a de facto default. > > Have you looked a JOSE? > > I think this would be out of scope for OpenPGP. > > > James Howard > > -derek > One, quite viable, option might be to use a subset of JOSE for OpenPGPv5. --001a11437dca08f11105116e6612 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 16, 2015, Derek Atkins <warlord@mit.edu> wrote:
"= James P. Howard" <jh@jameshoward.us> writes= :

> Is there an upvote button for this?=C2=A0 I even tweeted about this ye= sterday!
>
> =C2=A0=C2=A0https://twitter.com/howardjp/status/576473455949= 967360
>
> The current signed-XML standard is an awful awful thing and having a u= sable
> standard for signed text formats (XML, JSON, whatever) would would mak= e the
> implementation a de facto default.

Have you looked a JOSE?

I think this would be out of scope for OpenPGP.

> James Howard

-derek

One, quite=C2=A0viable, option might be to use a subset of= JOSE for OpenPGPv5.
=C2=A0
--001a11437dca08f11105116e6612-- From nobody Mon Mar 16 14:31:12 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 3316D1A9240 for ; Mon, 16 Mar 2015 14:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 h4uSaU3M3ZM3 for ; Mon, 16 Mar 2015 14:31:10 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264AB1A924C for ; Mon, 16 Mar 2015 14:31:05 -0700 (PDT) Received: from dshaw.nasuni.net (50-202-126-134-static.hfc.comcastbusiness.net [50.202.126.134]) (authenticated bits=0) by mail.jabberwocky.com (8.14.4/8.14.4) with ESMTP id t2GLAkuO018691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 17:10:46 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: David Shaw In-Reply-To: Date: Mon, 16 Mar 2015 17:30:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> To: David Leon Gil X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Stephen Paul Weber , Werner Koch , "openpgp@ietf.org" , gnupg-devel@gnupg.org, Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 21:31:11 -0000 On Mar 16, 2015, at 5:15 PM, David Leon Gil wrote: >=20 > Re Jon's comment above: The five-octet, new-format thing is what the = End-to-End extension does. >=20 > On Monday, March 16, 2015, Werner Koch wrote: > On Mon, 16 Mar 2015 19:12, singpolyma@singpolyma.net said: >=20 > > Yes. Last time I checked, gnupg < 2 (which is still the default on > > most of my systems) only generates old-style headers, whereas my >=20 > That depends on how you invoke gpg and whether the new packer headers > are required. That is required for PGP-2 compatibility. >=20 > Is there an option to completely disable this? Not in the current code, but you can of course patch it. > Relatedly, is there any option to not use new-format partial lengths? A partial length is needed to handle content as a stream - say some = program that generates gigabytes of data (like a backup). Something = large enough that you really don't want to have to buffer the whole = thing before encrypting it. > Partial lengths are really a nuisance to parse. No argument there... David From nobody Mon Mar 16 14:40:59 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 3BD591A9234 for ; Mon, 16 Mar 2015 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 dlvzn0UbHgnQ for ; Mon, 16 Mar 2015 14:40:55 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (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 BA8381A924C for ; Mon, 16 Mar 2015 14:40:52 -0700 (PDT) Received: by yhpt93 with SMTP id t93so22170811yhp.0 for ; Mon, 16 Mar 2015 14:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TA7/V62UPCt12MUUtHqljpT+AbSe4zjbih91Hsmv7gU=; b=ycQnnco6r5bRt02CnD5cRg+ogWfY5wVRmdJ7Fs6WzDtyxj/do7uKefBh8GMs0ftLZt Z23ZfG6wDQjrAhgBvnf6hkv23hDOf2ZeJTAA0KY14n9JF1euvT+CKhmWdp7k3VFKJdpY luw9gb5SqFgTHwVEDq+bLtTD/OHL59Y+QN4gxzuBLmDW283+B3+UYos9Rzv50D5sVNcN UQ1l9nuwcJnEW9Webg9PfDwTixUjUWc8rt76ortD1C+kQqR6pPJkGZ0mR6XMu6gRYLJr foTldWdIuYM90IwL0jvfZFUr2JkBzpCCbq1n30GW5pbQEMgZgqyG9A0+CPibBJRSfpiS 3hDA== MIME-Version: 1.0 X-Received: by 10.236.30.233 with SMTP id k69mr62296937yha.123.1426542052092; Mon, 16 Mar 2015 14:40:52 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 14:40:52 -0700 (PDT) In-Reply-To: <87sid5si30.fsf@alice.fifthhorseman.net> References: <87sid5si30.fsf@alice.fifthhorseman.net> Date: Mon, 16 Mar 2015 14:40:52 -0700 Message-ID: From: David Leon Gil To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a11c2027645ae9005116eb41b Archived-At: Cc: "dgil@yahoo-inc.com" , "openpgp@ietf.org" Subject: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 21:40:58 -0000 --001a11c2027645ae9005116eb41b Content-Type: text/plain; charset=UTF-8 On Sunday, March 15, 2015, Daniel Kahn Gillmor > wrote: > > > Yahoo has deprecated, and intends to disable support for all uses, of > > the following primitives and packet types specified for use with > > OpenPGP v4: > > > > - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish > > - Asymmetric algorithms, generally: RSA-ES, DSA. > > Are you referring to Public Key Algorithms specifically here? in > particular, this table: > > https://tools.ietf.org/html/rfc4880#section-9.1 > > If so, RSA-ES (pubkey algorithm 1) is very widely used, even for keys > that are only marked for one usage (signatures or encryption). In fact, > i don't think there are many RSA keys labeled RSA-E (algo 2) and RSA-S > (algo 3) at all. Why treat RSA-ES separately for deprecation? You're quite right; this was a mistake. > - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E, > ELG-E. > > How did you choose this cutoff? I'm happy to see a high bar personally, > but this is likely to invalidate many 2048-bit keys that people have > been generating with (e.g.) the GnuPG defaults today. Do you think that > GnuPG should change its defaults to the higher cutoff? > > Page 22 of the ENISA key-length report has a summary of recommendations. The (NSA-written) NIST standard in this area requires 3072-bit keysize for 128-bit security. Other sources require much longer keys. Yes, I think that GnuPG should change its defaults; I think that 128-bit security is the bare minimum threshold for security. > > - Compression algorithms: ZLIB. (It provides no benefits over DEFLATE, > > and is more malleable.) > > Why keep DEFLATE at all? quining seems to be possible with DEFLATE as > well. what if we yanked all compression at this layer? > I'd be happy to. > (on openpgp quining due to compression, see the 2013-10-08 entry at > http://mumble.net/~campbell/blag.txt) Thanks for the link. There are a lot of problems with doing compression and encryption, especially with a block-chaining mode... I'd be quite happy to deprecate everything but uncompressed. > > - Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224. > > The OpenPGPv4 fingerprint uses SHA-1, in a way that doesn't appear to be > cryptographically risky; i'm assuming you're not removing v4 > fingerprints entirely, just SHA-1 as a digest algorithm for message > signing. right? > Well, I'm not a great fan of v4 fingerprints or the SEIPD+MDC mode, but yes: That list only refers to usage for signatures. > > 1. A published public key that is more than 1 year old. (This is > > mainly taken care of by requiring > 3070 bit RSA keys...) > > Can you say more about this? Is this about a specific cutoff in time, > or *anything* that is "more than 1 year old" at the present? If it's > the latter, what effect do you expect this kind of regular key rollover > will have? why is it warranted? > Sure. How many days since the last zero-day security vulnerability on the computer you are using? (Hopefully you're using something awesome with grsecurity etc., but most users aren't.) It will be a rolling cut-off. (In future, it is possible that there may be some non-user-circumventable prohibition on reusing RSA moduli, in particular.) (This applies, but with somewhat less force, to most hardware-protected keys: It is likely that they have been used often enough that more sophisticated attacks are likely to have been able to recover the key. And if you're using hardware protection, you are probably a likely target of attackers with these capabilities.) > > 2. Signature by a public key which has ever signed a message or key > > using MD-5 or SHA-1. > > How would you tell if this is the case? Isn't ignoring MD5 and SHA1 > signatures itself sufficient? > An exported key, for example, may have a subkey which it has signed using MD5. I consider this to invalidate the signing key. A brief description of the (tentative) algorithm: Attempt to import an importable public key. If any signature packet in the composition uses a weak hash algorithm, reject the importable key in its entirety. --001a11c2027645ae9005116eb41b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, March 15, 2015, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> Yahoo has deprecated, and intends to disable support for all uses, of<= br> > the following primitives and packet types specified for use with
> OpenPGP v4:
>
> - Symmetric cipher algorithms: IDEA, TDES, CAST5, Blowfish, Twofish > - Asymmetric algorithms, generally: RSA-ES, DSA.

Are you referring to Public Key Algorithms specifically here?=C2=A0 in
particular, this table:

=C2=A0https://tools.ietf.org/html/rfc4880#section-9.1

If so, RSA-ES (pubkey algorithm 1) is very widely used, even for keys
that are only marked for one usage (signatures or encryption).=C2=A0 In fac= t,
i don't think there are many RSA keys labeled RSA-E (algo 2) and RSA-S<= br> (algo 3) at all.=C2=A0 Why treat RSA-ES separately for deprecation?

You're quite right; this was=C2=A0a mistake.= =C2=A0


> - Asymmetric algorithms, unless > 3070 bit key length: RSA-S, RSA-E= , ELG-E.

How did you choose this cutoff?=C2=A0 I'm happy to see a high bar perso= nally,
but this is likely to invalidate many 2048-bit keys that people have
been generating with (e.g.) the GnuPG defaults today.=C2=A0 Do you think th= at
GnuPG should change its defaults to the higher cutoff?


Page 22 of the ENISA key-length report= has a summary of recommendations. The (NSA-written)=C2=A0NIST standard in = this area requires 3072-bit keysize for 128-bit security. Other sources req= uire much longer keys.

Yes, I think that GnuPG sho= uld change its defaults; I think that 128-bit security is the bare=C2=A0min= imum threshold for security.
=C2=A0
> - Compression algorithms: ZLIB. (It provides no benefits over DEFLATE,=
> and is more malleable.)

Why keep DEFLATE at all?=C2=A0 quining seems to be possible with DEFLATE as=
well.=C2=A0 what if we yanked all compression at this layer?

I'd be happy to.
=C2=A0
=C2=A0(on openpgp quining due to compression, see the 2013-10-08 entry at =C2=A0 h= ttp://mumble.net/~campbell/blag.txt)

Th= anks for the link. There are a lot of problems with doing compression and e= ncryption, especially with a block-chaining mode...

I'd be quite=C2=A0happy to deprecate everything but uncompressed.
=C2=A0
> - Hash algorithms: MD5, SHA-1, RIPEMD160, SHA-2-224.

The OpenPGPv4 fingerprint uses SHA-1, in a way that doesn't appear to b= e
cryptographically risky; i'm assuming you're not removing v4
fingerprints entirely, just SHA-1 as a digest algorithm for message
signing.=C2=A0 right?

Well, I'm not a gr= eat fan of v4 fingerprints or the SEIPD+MDC mode, but yes: That list only r= efers to usage for signatures.
=C2=A0
> 1. A published public key that is more than 1 year old. (This is
> mainly taken care of by requiring > 3070 bit RSA keys...)

Can you say more about this?=C2=A0 Is this about a specific cutoff in time,=
or *anything* that is "more than 1 year old" at the present?=C2= =A0 If it's
the latter, what effect do you expect this kind of regular key rollover
will have?=C2=A0 why is it warranted?

S= ure. How many days since the last zero-day security vulnerability=C2=A0on t= he computer you are using? (Hopefully you're using something awesome wi= th grsecurity etc., but most users aren't.)

It= will be a rolling cut-off. (In future, it is possible that there may be so= me non-user-circumventable prohibition on reusing RSA moduli, in particular= .)

(This applies, but with somewhat less force, to= most hardware-protected keys: It is likely that they have been used often = enough that more sophisticated attacks are likely to=C2=A0have been able to= recover the key. And if you're using hardware protection, you are prob= ably a likely target of attackers with these capabilities.)
=C2= =A0
> 2. Signature by a public key which has ever signed a message or key > using MD-5 or SHA-1.

How would you tell if this is the case?=C2=A0 Isn't ignoring MD5 and SH= A1
signatures itself sufficient?

An exported=C2=A0key, for example, may hav= e a subkey which it has signed using MD5. I=C2=A0consider this to invalidat= e the signing key.

A brief description of the (ten= tative)=C2=A0algorithm: Attempt to import an importable=C2=A0public key. If= any signature packet in the composition uses=C2=A0a weak hash algorithm, r= eject the importable=C2=A0key in its entirety.
--001a11c2027645ae9005116eb41b-- From nobody Mon Mar 16 14:58:17 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 7FCDB1A9245 for ; Mon, 16 Mar 2015 14:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 W8oJk79SLQes for ; Mon, 16 Mar 2015 14:58:13 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 4A0FA1A92E8 for ; Mon, 16 Mar 2015 14:58:09 -0700 (PDT) Received: by ykcn8 with SMTP id n8so23179742ykc.3 for ; Mon, 16 Mar 2015 14:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G3uZzNxUF27ixV8zTc5slf3fY+2wMfURpJ+fBH1jc8s=; b=DO1kAHLvYkSbtpQ0BEOT3u2nopIuhnlRi9IFkntjkuk+Ygcx7E0yAtcBmxInE63u0l oyUPj4DP/tlnHNsQXP+O2WBQRVBaQfZfWOLbDIW0Px3+cl7Zwhmo+JKgDjVOQHWB/y2I vZP+RsRnaq6GKAYksHuIlxZgwMqaFeaQOjgDVyzowwSwJGxDrA2rZRJaMdoOFiEihN1i 7UGLG9CuXixbsLSOz+r+EoctJ2DO0L77ZsK8y1dTzUaGRpyisdUgEycwGZvkfmXUXD0K yk0Bt7hnFsQhcea6l6QzOyQXK6YsR170xmYzuooUlG5X9BF8fi9eqLnFGBtjnAlpDwe/ B8bw== MIME-Version: 1.0 X-Received: by 10.170.133.206 with SMTP id z197mr18323871ykb.18.1426543088742; Mon, 16 Mar 2015 14:58:08 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 14:58:08 -0700 (PDT) In-Reply-To: References: <55038CBE.7070608@iridiumlinux.org> <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> Date: Mon, 16 Mar 2015 14:58:08 -0700 Message-ID: From: David Leon Gil To: Derek Atkins Content-Type: multipart/alternative; boundary=001a113978740fb71b05116ef2d3 Archived-At: Cc: David Gil , "openpgp@ietf.org" , Falcon Darkstar Momot Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 16 Mar 2015 21:58:15 -0000 --001a113978740fb71b05116ef2d3 Content-Type: text/plain; charset=UTF-8 On Monday, March 16, 2015, Derek Atkins wrote: > David Gil > writes: > > > On Friday, March 13, 2015 6:20 PM, Falcon Darkstar Momot > > > wrote: > > > >> I feel like perhaps this type of exhaustive testing is neither necessary > >> nor expected, and that a few end-to-end tests designed to exercise edge > >> cases could be combined with more exhaustive unit tests to achieve > >> reasonable results. > > > > > > The difficulty, as always, is proving that an actual implementation is > > modular. In the case of OpenPGP, it really isn't: A lot of data has to > > get carried between each stage to ensure conformance with the > > high-level semantics. > > Having implemented it myself, I disagree completely. It is absolutely > possible to create a modular implementation. See my Usenix Security > Talk on the PGP Message Processing Pipeline from.... 1996?? > Well, first: You're Derek Atkins. Not everyone is as good of a coder. Second: It is hard to *prove* modularity, because of how complicated the semantics are. (I have been trying, off-and-on, using Frama-C, for a while.) > [snip] > >> Protocol modularity is not evil. > > > > Modularity is neutral. "Agility", as folks like to call it, is evil. > > Well, it's a damn good thing we've had agility otherwise we'd have been > stuck with 3DES, SHA1 (or MD5!!), and probably either RSA or maybe > DSA/Elgamal. > No: The reason there hasn't been any urgency to fix things like the CFB mode problems, or the MDC, is that the current standard is too flexible. I hate to use TLS as an exemplar of anything, but they have done a much better job in this regard recently. Where it is easy to provide flexibility, it is rarely useful. Where it is useful, it is rarely feasible to provide. (E.g., a parameter to choose SIV, encrypt-then-MAC, or robust AE.) --001a113978740fb71b05116ef2d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 16, 2015, Derek Atkins <warlord@mit.edu> wrote:
David = Gil <dgil@yahoo-inc.com> writes:

> On Friday, March 13, 2015 6:20 PM, Falcon Darkstar Momot
> <falcon@iridiumlinux.org> wrote:
>
>> I feel like perhaps this type of exhaustive testing is neither nec= essary
>> nor expected, and that a few end-to-end tests designed to exercise= edge
>> cases could be combined with more exhaustive unit tests to achieve=
>> reasonable results.
>
>
> The difficulty, as always, is proving that an actual implementation is=
> modular. In the case of OpenPGP, it really isn't: A lot of data ha= s to
> get carried between each stage to ensure conformance with the
> high-level semantics.

Having implemented it myself, I disagree completely.=C2=A0 It is absolutely=
possible to create a modular implementation.=C2=A0 See my Usenix Security Talk on the PGP Message Processing Pipeline from.... 1996??

Well, first: You're Derek Atkins. Not everyone is as go= od of a coder.

Second: It is=C2=A0hard to *prove* modula= rity, because of how complicated the semantics are. (I have been trying, of= f-and-on, using Frama-C, for a while.)
=C2=A0
[snip]
>> Protocol modularity is not evil.
>
> Modularity is neutral. "Agility", as folks like to call it, = is evil.

Well, it's a damn good thing we've had agility otherwise we'd h= ave been
stuck with 3DES, SHA1 (or MD5!!), and probably either RSA or maybe
DSA/Elgamal.

No: The reason there hasn't been any u= rgency to fix things like the CFB mode problems, or the MDC, is that the cu= rrent=C2=A0standard is too flexible.

I hate = to use TLS as an exemplar of anything, but they have done a much better job= in this regard recently.

Where it is easy to provide f= lexibility, it is rarely useful. Where it is useful, it is rarely feasible = to=C2=A0provide. (E.g., a parameter to choose=C2=A0SIV, encrypt-then-MAC, o= r robust AE.) --001a113978740fb71b05116ef2d3-- From nobody Mon Mar 16 15:03:48 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 A7C0E1A9245 for ; Mon, 16 Mar 2015 15:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 qrwdQGkKuGHr for ; Mon, 16 Mar 2015 15:03:45 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (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 A928B1A9236 for ; Mon, 16 Mar 2015 15:03:45 -0700 (PDT) Received: by yhjf44 with SMTP id f44so22374163yhj.3 for ; Mon, 16 Mar 2015 15:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3E3g9kD7bdeyqoFivmXFtUi/JWze/1iu+4eFxq8z0aI=; b=qfmcnW3Q8YG6DzoTMGuHJF3EuCfe/Nsj2h+dboBbZUfmhgktmbQSxXI4u4tjbtsYyW Fo/I+w0aQsOBIt0WcftqpffNLPHDhIO6h5K0q5QbBEGmIf/vFpKMoV1BTcsfmLSerKmI 4PdlYefQAbaNF+o7+g+oqp/oS0i9btP2Z0avsSPQcnwAHAyNa5R0EIiZsSuVlx/nudET ZZ23+GKw6Nsh33WBvLaS61/bU2Gc+OEjBaqOYB5b6ktDu9NNdSVRCaYCMsHY/brd9GQs ncFixQ+gZLMLPZ1uoWmU6P7gZ3KOQCmR1qlJHvx+JXQSs/vL0XqNBWMD214ku3yQ47sI WQyA== MIME-Version: 1.0 X-Received: by 10.170.187.5 with SMTP id d5mr70699049yke.20.1426543425130; Mon, 16 Mar 2015 15:03:45 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 15:03:45 -0700 (PDT) In-Reply-To: References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Date: Mon, 16 Mar 2015 15:03:45 -0700 Message-ID: From: David Leon Gil To: David Shaw Content-Type: multipart/alternative; boundary=001a113a67861c98f105116f0613 Archived-At: Cc: Stephen Paul Weber , Werner Koch , "openpgp@ietf.org" , "gnupg-devel@gnupg.org" , Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 16 Mar 2015 22:03:47 -0000 --001a113a67861c98f105116f0613 Content-Type: text/plain; charset=UTF-8 On Monday, March 16, 2015, David Shaw wrote: > On Mar 16, 2015, at 5:15 PM, David Leon Gil > wrote: > > > > Re Jon's comment above: The five-octet, new-format thing is what the > End-to-End extension does. > > > > On Monday, March 16, 2015, Werner Koch > > wrote: > > On Mon, 16 Mar 2015 19:12, singpolyma@singpolyma.net > said: > > > > > Yes. Last time I checked, gnupg < 2 (which is still the default on > > > most of my systems) only generates old-style headers, whereas my > > > > That depends on how you invoke gpg and whether the new packer headers > > are required. That is required for PGP-2 compatibility. > > > > Is there an option to completely disable this? > > Not in the current code, but you can of course patch it. > > > Relatedly, is there any option to not use new-format partial lengths? > > A partial length is needed to handle content as a stream - say some > program that generates gigabytes of data (like a backup). Something large > enough that you really don't want to have to buffer the whole thing before > encrypting it. > I agree on that. But I think this really requires a different mode of operation / standard. See, e.g., https://www.imperialviolet.org/2014/06/27/streamingencryption.html I'm not sure that an OpenPGP WG is the right place to do this. (Which is why I said that the scope should be limited to email-length messages.) -- But, e.g., GnuPG (always?) emits partial lengths, even for data it already knows the length of (and is << even 2^20 bytes). --001a113a67861c98f105116f0613 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 16, 2015, David Shaw <dshaw@jabberwocky.com> wrote:
On Mar 16, 2015, at 5:15 PM, David Leon Gil <coruus@= gmail.com> wrote:
>
> Re Jon's comment above: The five-octet, new-format thing is what t= he End-to-End extension does.
>
> On Monday, March 16, 2015, Werner Koch <wk@gnupg.org> wrote:
> On Mon, 16 Mar 2015 19:12, singpolyma@singpol= yma.net said:
>
> > Yes.=C2=A0 Last time I checked, gnupg < 2 (which is still the = default on
> > most of my systems) only generates old-style headers, whereas my<= br> >
> That depends on how you invoke gpg and whether the new packer headers<= br> > are required.=C2=A0 That is required for PGP-2 compatibility.
>
> Is there an option to completely disable this?

Not in the current code, but you can of course patch it.

> Relatedly, is there any option to not use new-format partial lengths?<= br>
A partial length is needed to handle content as a stream - say some program= that generates gigabytes of data (like a backup).=C2=A0 Something large en= ough that you really don't want to have to buffer the whole thing befor= e encrypting it.

I agree on that. But I think this really r= equires a different mode of operation / standard.=C2=A0See, e.g.,=C2=A0= https://www.imperialviolet.org/2014/06/27/streamingencryption.html=C2= =A0I'm not sure that an OpenPGP WG is the right place to do this.
=

(Which is why I said that the scope should be limited t= o=C2=A0email-length messages.)

--

But, e.g., GnuPG (always?) emits partial lengths, even for data it alre= ady knows the length of (and is << even 2^20 bytes). --001a113a67861c98f105116f0613-- From nobody Mon Mar 16 15:14:19 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 6E1A51AC3A5 for ; Mon, 16 Mar 2015 15:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 6vHrNTJ9VjMS for ; Mon, 16 Mar 2015 15:14:16 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::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 91A851AC39E for ; Mon, 16 Mar 2015 15:14:16 -0700 (PDT) Received: by yhjf44 with SMTP id f44so22457091yhj.3 for ; Mon, 16 Mar 2015 15:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cbtVFlSDVz6713JlzCUZXMhGZCgjCZhofMUkP2DHwjI=; b=JFs7wKNmH6Wo4NwCFY7pqgKhtQoA2IcGFEKqsY7LlAjR9R2yeFIOUS8abUkTaj+cN+ mBHFa8QpalUnM5cIOse6UeakEWMH7KdplJWCnmieIadnJ3iFv3k0kaRq/0q1/AG/HpxS oSZrnVad0Xs0WJrLBCKr+17TBBefh8kHL0GajJqrWE13G1X+KH4oTHOOLVcK/HlpRcyP hbxDUDDP9ESuauYRMhZ+Tto6Ilnni3xOhcLCozFLvHC6ErFvJD/VtfHKTYLSgflah/j9 CIgxsAilXXSCT4ZpxC+wRA2TMAuqV11BLTyrHFkE9PhrC4tR5lWaDbyKcrzfr4/oKXji kjVA== MIME-Version: 1.0 X-Received: by 10.236.221.228 with SMTP id r94mr64454421yhp.127.1426544055890; Mon, 16 Mar 2015 15:14:15 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 15:14:15 -0700 (PDT) In-Reply-To: <87zj7hvgzp.fsf@alice.fifthhorseman.net> References: <878uf2iehi.fsf@vigenere.g10code.de> <87zj7hvgzp.fsf@alice.fifthhorseman.net> Date: Mon, 16 Mar 2015 15:14:15 -0700 Message-ID: From: David Leon Gil To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a11c2cc42b53af805116f2b44 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 16 Mar 2015 22:14:18 -0000 --001a11c2cc42b53af805116f2b44 Content-Type: text/plain; charset=UTF-8 On Thursday, March 12, 2015, Daniel Kahn Gillmor wrote: > On Thu 2015-03-12 09:50:19 -0400, Paul Wouters wrote: > > On Thu, 12 Mar 2015, Werner Koch wrote: > fwiw, i'd consider a re-chartered wg to cover possible revisions or > extensions to several RFCs, not just 4880: > > https://tools.ietf.org/html/rfc4880 -- OpenPGPv4 > https://tools.ietf.org/html/rfc3156 -- PGP/MIME > https://tools.ietf.org/html/rfc6637 -- ECC in OpenPGP > > To add an item to Werner's earlier list: > > * i'd like to spec out an adjustment to PGP/MIME that provides > signature and encryption protection for RFC 822 headers. > As a note: I consider figuring out something for RFC 822 headers a very high priority. It is particularly difficult, because many '822' headers are mainly intended for servers. (And are important for spam control.) So it may be necessary, in some cases, to encrypt some of the 822 headers only to the ultimate recipient, and some of them to the server as well. --001a11c2cc42b53af805116f2b44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, March 12, 2015, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Thu 2015-03-12 09:50:19 -0400, Paul Wouters wrote:
> On Thu, 12 Mar 2015, Werner Koch wrote:
fwiw, i'd consider a re-chartered wg to cover possible revisions or
extensions to several RFCs, not just 4880:

=C2=A0 ht= tps://tools.ietf.org/html/rfc4880=C2=A0 =C2=A0-- OpenPGPv4
=C2=A0 ht= tps://tools.ietf.org/html/rfc3156=C2=A0 =C2=A0-- PGP/MIME
=C2=A0 ht= tps://tools.ietf.org/html/rfc6637=C2=A0 =C2=A0-- ECC in OpenPGP

To add an item to Werner's earlier list:

=C2=A0* i'd like to spec out an adjustment to PGP/MIME that provides =C2=A0 =C2=A0signature and encryption protection for RFC 822 headers.

=C2=A0As a note: I consider figuring out s= omething for RFC 822 headers a very high priority. It is particularly diffi= cult, because many '822' headers are mainly intended for servers. (= And are important for spam control.)

So it may be = necessary, in some cases, to encrypt some=C2=A0of the 822 headers only to t= he ultimate recipient, and some of them to the server as well.
--001a11c2cc42b53af805116f2b44-- From nobody Mon Mar 16 15:17: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 8DBAE1A8715 for ; Mon, 16 Mar 2015 15:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, HTML_MESSAGE=0.001, MANGLED_BACK=2.3, 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 JBy1oTK2za19 for ; Mon, 16 Mar 2015 15:17:11 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::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 AE5401ABD36 for ; Mon, 16 Mar 2015 15:17:11 -0700 (PDT) Received: by yhch68 with SMTP id h68so22477656yhc.1 for ; Mon, 16 Mar 2015 15:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=woPdnrhlkQetAUZAzAkWhW4vDGPkpX8tdu2XCITd2eg=; b=skVPwWs0N7532lAWXvs5/MQnGLlC+8JO0RsJ/S3ea2nqbXoQHZ8YHAIQMpK2pCynYo ZTu000zLfQ/riezQYYzYJizf9MeYEvfFBuduFWpaqfpso7588ELSCC9PIYVYtFToSy7v uAcZooPEsAS6ldLAKp3ge+/067n3iBxBQkuLVMIwbwJlfq0zfL3TmZVXHqCudlxdGIMU bZmGCm+tZ0PUwPA7IhALx/GsuVcq6HCQW+A94126H4lPtQApUp/TR0idj/BOlSlm0Zhe fxVgR7HfydfEx8EGxD1zvKd49JPbCGrwvSsUPbsMkBBniMZLXYrSHlpEoJwTuQ91Vrhb PgYg== MIME-Version: 1.0 X-Received: by 10.170.187.5 with SMTP id d5mr70754394yke.20.1426544231027; Mon, 16 Mar 2015 15:17:11 -0700 (PDT) Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 15:17:10 -0700 (PDT) In-Reply-To: <87mw5ixyee.fsf@alice.fifthhorseman.net> References: <20150116134324.6d918b4e@pc> <87mw5ixyee.fsf@alice.fifthhorseman.net> Date: Mon, 16 Mar 2015 15:17:10 -0700 Message-ID: From: David Leon Gil To: "openpgp@ietf.org" Content-Type: multipart/mixed; boundary=001a113a678625c34c05116f3696 Archived-At: Subject: [openpgp] Fwd: Encrypting / Signing the mail subject? 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, 16 Mar 2015 22:17:14 -0000 --001a113a678625c34c05116f3696 Content-Type: multipart/alternative; boundary=001a113a678625c34605116f3694 --001a113a678625c34605116f3694 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (And, actually, as I assume DKG won't mind me noting his proposal on gnupg-devel here.) ---------- Forwarded message ---------- From: *Daniel Kahn Gillmor* Date: Friday, January 16, 2015 Subject: Encrypting / Signing the mail subject? To: Hanno B=C3=B6ck , gnupg-devel@gnupg.org despite the fact that the IETF's OpenPGP WG is closed, i think that openpgp@ietf.org mailing list is still active. It may be worth discussing issues like this in that forum as well, to get a wider range of buy-in. . . . Embedded Header Proposal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here's a counter-proposal to consider, which relies on PGP/MIME. PGP/MIME messages are the only reliably structured mail OpenPGP e-mail messages anyway [0]. A normal PGP/MIME signed text/plain message structure looks like this (Content-Type of each part is shown) [1]: A =E2=94=94=E2=94=AC=E2=95=B4multipart/signed B =E2=94=9C=E2=94=80=E2=95=B4text/plain C =E2=94=94=E2=94=80=E2=95=B4application/pgp-signature [signature.asc] I propose sending a message with an additional text/rfc822-headers [2] part injected as a sub-part in the message, like this: D =E2=94=94=E2=94=AC=E2=95=B4multipart/signed E =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed F =E2=94=82=E2=94=9C=E2=94=80=E2=95=B4text/rfc822-headers inline [header] G =E2=94=82=E2=94=94=E2=94=80=E2=95=B4text/plain H =E2=94=94=E2=94=80=E2=95=B4application/pgp-signature [signature.asc] the text/rfc822-headers mime type is defined here: In this case, only select headers would be embedded (those headers that are to be signed/encrypted. The embedded header part (F, above) should be Content-Disposition: inline, and should be subject to all the usual rules of parsing mail message headers. This allows senders to sign arbitrary headers (not just Subject:), and it works for both signing and encryption. For sending and receiving MUAs unaware of this convention, no changes need to be made; at worst, a receiving MUA can simply ignore the text/rfc822-headers MIME part. But since it's of type text/* and Content-Disposition: inline, they may choose to just render it directly at the top of the message, which would look very similar to your proposal. This e-mail message contains a signed set of embedded headers in the way i've proposed. How does it render in your unaware MUA? feel free to send me a private report if you like. for aware MUAs, we'd need to spec out the detailed rules: Message handling guidelines for embedded-header-aware MUAs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D composing (sending) MUAs (signed messages) ------------------------------------------ the composing MUA, when crafting a signed message, needs to know which header fields should be included. By default, this might just be Subject:, though maybe it's worth including Date: as well. This could be represented in MUA configuration as a simple list of headers: signed_headers: * Subject * Date * From * To * Cc composing (sending) MUAs (encrypted messages) --------------------------------------------- the composing MUA, when crafting an encrypted message, needs to know which header fields should be encrypted, and what the default replacement for that field should be. This could be represented in MUA configuration as a list of (header,value) pairs: Some headers may have a value marked as , to indicate that the header should not be exposed publicly at all, but should only be present in the embedded header. encrypted_headers: * (Subject,"ENCRYPTED SUBJECT") * (In-Reply-To,) * (References,) Ideally, these lists would be shared across clients and would have sane defaults, since shared configuration increases ambiguity to an attacker. (note that the choices described above would hide threading information >From an attacker) composing (sending) MUAs (encrypted+signed messages) ---------------------------------------------------- some messages are both signed and encrypted. an MUA which composes such a message should craft the embedded headers using the union of all headers in both signed_headers and encrypted_headers, sign and encrypt the message, and only then replace or omit the external header fields as directed by the encrypted_headers configuration. receiving MUAs (encrypted messages) ----------------------------------- An MUA that receives an encrypted message with a text/rfc822-headers part should loop through the embedded headers. for each embedded header, it should compare it with the external header of the same label. If they differ, the MUA should treat the message as though the embedded header is the correct value. receiving MUAs (signed messages) -------------------------------- An MUA that receives a signed message with a text/rfc822-headers part should loop through the embedded headers. for each embedded header, it should compare it with the external header of the same label. If they differ, the MUA should treat the message as though the embedded header is the correct value. The MUA may want to expose the unsigned value of that header to the user with a warning that it is unsigned. Whether they differ or not, the MUA should indicate to the user that the signed parts are signed, and should make a visible distinction between signed and unsigned headers. ------- open questions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D redundant header parts? ----------------------- We'd also need to define what happens if more than one text/rfc822-headers part shows up in a multipart message -- most simply, we could say that we only process text/rfc822-headers if it happens to be the first non-multipart part within the multipart/signed or multipart/encrypted part. This prevents the receiving MUA from applying text/rfc822-headers from a forwarded (attached) signed/encrypted message. disallowed headers? ------------------- Are there any headers that *should not* be permitted to be rewritten in this way? For example, what would it mean if someone were to embed a Received: header? a Message-ID header? If some are unacceptable, should we have a blocklist (allow arbitrary headers by default, only reject certain ones) or an allowlist (block arbitrary headers by default, only accept certain ones like Subject and date)? redundant headers ----------------- within a single header block, there could still be more than one instance of a given header. The message itself could also have multiple copies of a given header (e.g. the Comments and Keywords fields [3]). If multiple copies of a given header appear in either the exposed header or the embedded header, and their values differ, how should we resolve the difference? ------- [0] https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ [1] MIME message structure representations shown here are generated from actual messages via devel/printmimestructure from the notmuch git repository at git://notmuchmail.org/git/notmuch [2] text/rfc822-headers: https://tools.ietf.org/html/rfc6522#section-4 [3] Comments and Keywords: https://tools.ietf.org/html/rfc5322#section-3.6.= 5 --001a113a678625c34605116f3694 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (And, actually, as I assume DKG won't mind me noting his proposal on gn= upg-devel here.)

---------- Forwarded message ----------
From: Daniel Kahn Gillmor <dkg@f= ifthhorseman.net>
Date: Friday, January 16, 2015
Subject: Encr= ypting / Signing the mail subject?
To: Hanno B=C3=B6ck <hanno@hboeck.de>, gnupg-devel@gnupg.org

despite the fact that the IETF's OpenPGP WG is closed, i think that
openpgp@ietf.org=C2=A0mailing list is still active.=C2= =A0 It may be worth
discussing issues like this in that forum as well, to get a wider range
of buy-in.

. . .=C2=A0

Embedded Header Proposal
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Here's a counter-proposal to consider, which relies on PGP/MIME.
PGP/MIME messages are the only reliably structured mail OpenPGP e-mail
messages anyway [0].

A normal PGP/MIME signed text/plain message structure looks like this
(Content-Type of each part is shown) [1]:

A =E2=94=94=E2=94=AC=E2=95=B4multipart/signed
B=C2=A0 =E2=94=9C=E2=94=80=E2=95=B4text/plain
C=C2=A0 =E2=94=94=E2=94=80=E2=95=B4application/pgp-signature [signature.asc= ]

I propose sending a message with an additional text/rfc822-headers [2] part=
injected as a sub-part in the message, like this:

D =E2=94=94=E2=94=AC=E2=95=B4multipart/signed
E=C2=A0 =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed
F=C2=A0 =E2=94=82=E2=94=9C=E2=94=80=E2=95=B4text/rfc822-headers inline [hea= der]
G=C2=A0 =E2=94=82=E2=94=94=E2=94=80=E2=95=B4text/plain
H=C2=A0 =E2=94=94=E2=94=80=E2=95=B4application/pgp-signature [signature.asc= ]

the text/rfc822-headers mime type is defined here:


In this case, only select headers would be embedded (those headers that
are to be signed/encrypted.=C2=A0 The embedded header part (F, above) shoul= d
be Content-Disposition: inline, and should be subject to all the usual
rules of parsing mail message headers.

This allows senders to sign arbitrary headers (not just Subject:), and
it works for both signing and encryption.

For sending and receiving MUAs unaware of this convention, no changes
need to be made; at worst, a receiving MUA can simply ignore the
text/rfc822-headers MIME part.=C2=A0 But since it's of type text/* and<= br> Content-Disposition: inline, they may choose to just render it directly
at the top of the message, which would look very similar to your
proposal.

This e-mail message contains a signed set of embedded headers in the way i've proposed.=C2=A0 How does it render in your unaware MUA?=C2=A0 feel= free to
send me a private report if you like.



for aware MUAs, we'd need to spec out the detailed rules:

Message handling guidelines for embedded-header-aware MUAs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D


composing (sending) MUAs (signed messages)
------------------------------------------

the composing MUA, when crafting a signed message, needs to know which
header fields should be included.=C2=A0 By default, this might just be
Subject:, though maybe it's worth including Date: as well.

This could be represented in MUA configuration as a simple list of
headers:

signed_headers:
=C2=A0* Subject
=C2=A0* Date
=C2=A0* From
=C2=A0* To
=C2=A0* Cc

composing (sending) MUAs (encrypted messages)
---------------------------------------------

the composing MUA, when crafting an encrypted message, needs to know
which header fields should be encrypted, and what the default
replacement for that field should be.

This could be represented in MUA configuration as a list of
(header,value) pairs:

Some headers may have a value marked as <omit>, to indicate that the<= br> header should not be exposed publicly at all, but should only be present in the embedded header.

encrypted_headers:
=C2=A0* (Subject,"ENCRYPTED SUBJECT")
=C2=A0* (In-Reply-To,<omit>)
=C2=A0* (References,<omit>)

Ideally, these lists would be shared across clients and would have sane
defaults, since shared configuration increases ambiguity to an attacker.
(note that the choices described above would hide threading information
>From an attacker)


composing (sending) MUAs (encrypted+signed messages)
----------------------------------------------------

some messages are both signed and encrypted.=C2=A0 an MUA which composes su= ch
a message should craft the embedded headers using the union of all
headers in both signed_headers and encrypted_headers, sign and encrypt
the message, and only then replace or omit the external header fields as directed by the encrypted_headers configuration.


receiving MUAs (encrypted messages)
-----------------------------------

An MUA that receives an encrypted message with a text/rfc822-headers
part should loop through the embedded headers.=C2=A0 for each embedded
header, it should compare it with the external header of the same label.
If they differ, the MUA should treat the message as though the embedded
header is the correct value.

receiving MUAs (signed messages)
--------------------------------

An MUA that receives a signed message with a text/rfc822-headers part
should loop through the embedded headers.=C2=A0 for each embedded header, i= t
should compare it with the external header of the same label.

If they differ, the MUA should treat the message as though the embedded
header is the correct value.=C2=A0 The MUA may want to expose the unsigned<= br> value of that header to the user with a warning that it is unsigned.

Whether they differ or not, the MUA should indicate to the user that the signed parts are signed, and should make a visible distinction between
signed and unsigned headers.


-------

open questions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

redundant header parts?
-----------------------

We'd also need to define what happens if more than one
text/rfc822-headers part shows up in a multipart message -- most simply, we could say that we only process text/rfc822-headers if it happens to
be the first non-multipart part within the multipart/signed or
multipart/encrypted part.=C2=A0 This prevents the receiving MUA from
applying text/rfc822-headers from a forwarded (attached)
signed/encrypted message.


disallowed headers?
-------------------

Are there any headers that *should not* be permitted to be rewritten in
this way?=C2=A0 For example, what would it mean if someone were to embed a<= br> Received: header?=C2=A0 a Message-ID header?

If some are unacceptable, should we have a blocklist (allow arbitrary
headers by default, only reject certain ones) or an allowlist (block
arbitrary headers by default, only accept certain ones like Subject and
date)?


redundant headers
-----------------

within a single header block, there could still be more than one
instance of a given header.=C2=A0 The message itself could also have multip= le
copies of a given header (e.g. the Comments and Keywords fields [3]).
If multiple copies of a given header appear in either the exposed header or the embedded header, and their values differ, how should we resolve
the difference?

-------

[0] https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/<= br>
[1] MIME message structure representations shown here are generated from =C2=A0 =C2=A0 actual messages via devel/printmimestructure from the notmuch= git
=C2=A0 =C2=A0 repository at git://notmuchmail.org/git/notmuch

[2] text/rfc822-headers:=C2=A0 =C2=A0https://tools.ietf.org/html/rfc6522#s= ection-4

[3] Comments and Keywords: https://tools.ietf.org/html/rfc5322#section= -3.6.5

--001a113a678625c34605116f3694-- --001a113a678625c34c05116f3696 Content-Type: text/rfc822-headers; charset=utf-8; name=header Content-Disposition: attachment; filename=header Content-Transfer-Encoding: base64 X-Attachment-Id: 2057c5923a8a440e_0.0.0.0 U3ViamVjdDogUmU6IEVuY3J5cHRpbmcgLyBTaWduaW5nIHRoZSBtYWlsIHN1YmplY3Q/DQpGcm9t OiBEYW5pZWwgS2FobiBHaWxsbW9yIDxka2dAZmlmdGhob3JzZW1hbi5uZXQ+DQpUbzogSGFubm8g QsO2Y2sgPGhhbm5vQGhib2Vjay5kZT4sIGdudXBnLWRldmVsQGdudXBnLm9yZw0KSW4tUmVwbHkt VG86IDwyMDE1MDExNjEzNDMyNC42ZDkxOGI0ZUBwYz4NCg== --001a113a678625c34c05116f3696 Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 X-Attachment-Id: 2057c5923a8a440e_0.0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxDQoNCmlRSjhC QUVCQ2dCbUJRSlV1WFNhWHhTQUFBQUFBQzRBS0dsemMzVmxjaTFtY0hKQWJtOTBZWFJwYjI1ekxt OXcNClpXNXdaM0F1Wm1sbWRHaG9iM0p6WlcxaGJpNXVaWFJGUWprMk9URXlPRGRCTjBGRVJFVXpO elUzUkRreE1VVkINCk5USTBNREZDTVRGQ1JrUkdRVFZEQUFvSkVLVWtBYkViL2ZwY1FDd1FBSkRs R3hHSEtzYmdlc1hkL2UzTk9nOWgNCjB2WGdNZWlseEp1WkNWd09JYTdrSTdQOG50LzJlMGJFTWxs VlVPTFNUc0I5T21TdzUyMHdCMWlYeERGRDd4OWwNClZxcStyd3VITG4yN0NKSmxTWlJLRGFkZnAy dFhTZnVPNzVISktHMy9RMU1RdDk0bFgyWnNGd3hkY3FNRzdkYlINCmpHYWlnQUJRbHVHTVhpQlRy UktlNmNSNGRGU3FYSTBNdUZNK0J2aXBmcnA0U0FvNk9vWW5heGc1U3loRkN0OSsNCmdXNEpieWor SFBiUjNRN3d3ZXY2SC9HZTBTNWNPUUc4Z24wdWJSODBpRlFONWNHdlBXdlhrQUR1NmZKcUUxK2cN CmU0VWdCK1ZjdlJyaU9maHFmdXZFblF6RW5HdTJpRCtWQjMwd0VMNlJXRGd2bnBsbXJYbFRUR3g5 d1hyYVdaVnINCjE4RmRNS3F4UnIxbWdQK2xlNllJMjRnVnpzSjZkWWhtUHNYWlF4dVV4ZTROMmd1 d0FnRkhoMXFxbThNN3RxU0sNCnB6dTVyZmdBeUFiaWRjYXV1ZlRmVXAzakFZNlZPTjJvS0dmMVhS RjdwM1o3MTJCbVVJeGV4SGhKV2VUU1VmOXUNCmp0YjBIaWhpSUo3SGpwYUhxQW9ZTlJ5Y2w2ajZ4 b2JYK3FFUGhtZ09vYkVSU3F1WmkxQTZZdENHVFJHN3VCWFUNCjVRWHFBWUJiT1g2Y2ZNOTJ0bjVw cW1IVDNwUHVqUjJ0eVJrN2dGZjRVWHI1MHdDbUJVbi9rTGtaeFMwM05hcSsNCmo4ZGFuN2dLV3hw VjhZNmsrK3ZBbXhXcHlKbUk5SnpNaCtGc2RDcG84N0dkWjBIaFFxWkZzYWVXSG5ubk01WXkNCmVE ajBSanJrTmtvY1c4OEpVWDlDDQo9MGVIWQ0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0t --001a113a678625c34c05116f3696-- From nobody Mon Mar 16 15:25:40 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 857F01AC3C1 for ; Mon, 16 Mar 2015 15:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 o8RWIF135COg for ; Mon, 16 Mar 2015 15:25:38 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (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 258A91AC3C0 for ; Mon, 16 Mar 2015 15:25:38 -0700 (PDT) Received: by wetk59 with SMTP id k59so48353894wet.3 for ; Mon, 16 Mar 2015 15:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+OK/mlZU+P5vJYVlwJAtPjCUsIU3LDyxs4Wmhj0HuNs=; b=gCI8aC0FbR3x8qIycWSoKNgsBiAsxr7wbDI5z6qSre+T2VHRf4nIWAjK6DoprCMtM6 HOjwCErkQGKW/rS5zSzXFKgDY3cOKNaBKRt4VXi/a7QD3tAl/wVzYNo28HmZRyU9xsf8 5ApuK7f0N5umx13C7IP/L920//YCEJUlJoPtGBRopPt/caSQR6p3ofyoKuIdHsNJPbkw cgWgSS/CIFwBCFzlVaX2+5RFVdJAsFk5BGpVL4Xg5/oJGTw4CIUFnmZc1MeGr1Y/uZTo /43KkOD2Y51+9p+v7z1NTDE0R9/NyPN7ClYHdJYFfAMeMvybf0MAbipt669QX8A/k7hR 0rbQ== X-Received: by 10.194.223.103 with SMTP id qt7mr121589710wjc.35.1426544736800; Mon, 16 Mar 2015 15:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.35.3 with HTTP; Mon, 16 Mar 2015 15:24:56 -0700 (PDT) In-Reply-To: References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316171832.D0C81E0451@smtp.hushmail.com> From: Ryan Carboni Date: Mon, 16 Mar 2015 15:24:56 -0700 Message-ID: To: David Leon Gil Content-Type: multipart/alternative; boundary=001a11c3b7c44b14db05116f548d Archived-At: Cc: "openpgp@ietf.org" , "vedaal@nym.hush.com" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 22:25:39 -0000 --001a11c3b7c44b14db05116f548d Content-Type: text/plain; charset=UTF-8 I suggest Threefish. It is (practically) immune to the risk of collisions revealing plaintext in CFB mode, and is slightly more secure. It's probably best to use the version of Threefish before they increased the number of rounds to deal with collisions. --001a11c3b7c44b14db05116f548d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I suggest Threefish. It is (practically) immune to the ris= k of collisions revealing plaintext in CFB mode, and is slightly more secur= e. It's probably best to use the version of Threefish before they incre= ased the number of rounds to deal with collisions.
--001a11c3b7c44b14db05116f548d-- From nobody Mon Mar 16 15:48: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 AB3821ACC87 for ; Mon, 16 Mar 2015 15:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tbUKc1PE8RHQ for ; Mon, 16 Mar 2015 15:48:40 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 449251AC7E8 for ; Mon, 16 Mar 2015 15:48:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id C4BAA6C9B6E5; Mon, 16 Mar 2015 15:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSF-qP1aJD-L; Mon, 16 Mar 2015 15:48:07 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id C3CDE6C9B6CC; Mon, 16 Mar 2015 15:48:07 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 16 Mar 2015 15:48:07 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 16 Mar 2015 15:48:07 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-Reply-To: Date: Mon, 16 Mar 2015 15:48:03 -0700 Message-Id: <3B2BD87B-C353-4D4C-9EE6-076E019AEBA6@callas.org> References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316171832.D0C81E0451@smtp.hushmail.com> To: Ryan Carboni X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" , Jon Callas , David Leon Gil , "vedaal@nym.hush.com" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 16 Mar 2015 22:48:41 -0000 > On Mar 16, 2015, at 3:24 PM, Ryan Carboni wrote: >=20 > I suggest Threefish. It is (practically) immune to the risk of = collisions revealing plaintext in CFB mode, and is slightly more secure. = It's probably best to use the version of Threefish before they increased = the number of rounds to deal with collisions. As a Threefish co-author, thank you for your vote of confidence. We never increased the number of rounds. We tweaked constants, but = that's all. Threefish is a wide-block, tweakable block cipher and would need a small = bit of description of how to use it; it's not a drop-in replacement for = something like AES. But I'd be happy to do that, myself, and could make suggestions in less = than a paragraph. Jon From nobody Mon Mar 16 16:28:52 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 13FF61ACD39 for ; Mon, 16 Mar 2015 16:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 JFnX0TUkr2yg for ; Mon, 16 Mar 2015 16:28:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCC61ACD28 for ; Mon, 16 Mar 2015 16:28:49 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3AB4DF984; Mon, 16 Mar 2015 19:28:45 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 45C9620255; Mon, 16 Mar 2015 16:28:31 -0700 (PDT) From: Daniel Kahn Gillmor To: Albrecht =?utf-8?Q?Dre=C3=9F?= In-Reply-To: <1424628876.3637.1@deneb.(none)> References: <1424628876.3637.1@deneb.(none)> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Mail-Followup-to: IETF OpenPGP Date: Mon, 16 Mar 2015 19:28:31 -0400 Message-ID: <87fv94r080.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: gnupg-devel@gnupg.org, IETF OpenPGP , Hanno =?utf-8?Q?B=C3=B6ck?= Subject: Re: [openpgp] Encrypting / Signing the mail subject? 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, 16 Mar 2015 23:28:51 -0000 Hi Albrecht-- Sorry for the late followup -- this has now been raised on openpgp@ietf.org, so i'm moving the follow up there. On Sun 2015-02-22 13:14:36 -0500, Albrecht Dreß wrote: > I am currently working on the implementation of your proposal for Balsa [1], and would like to add a few comments. I'm glad to hear this! > Am 16.01.15 21:29 schrieb(en) Daniel Kahn Gillmor: >> PGP/MIME messages are the only reliably structured mail OpenPGP e-mail messages anyway [0]. > > As your proposal is fully transparent, I think it could also be used > for RFC 2633 S/MIME (i.e. multipart/signed; > application/pkcs7-signature as well as for application/pkcs7-mime). yep, this seems correct to me, but i don't know enough about the S/MIME world to take the proposal there. Maybe we should find some S/MIME folks to chime in on this. >> The embedded header part (F, above) should be Content-Disposition: >> inline, and should be subject to all the usual rules of parsing mail >> message headers. > > In your example, you added a "charset" parameter to the mime type. > IMHO, this contradicts the RFC 6522 statement that it shall have > neither required nor optional parameters. I think it's unneeded > anyway, as all headers shall be encoded as required by RFC 2047. > Applying the "usual" header parsing rules will of course decode them > properly. yep, you're right about this. > The whole part /should/ be encoded quoted-printable, though, as > required by RFC 3156, sect. 3. The headers /should/ be 7-bit clean, > but you never know for sure... I think this also makes sense. >> This e-mail message contains a signed set of embedded headers in the >> way i've proposed. How does it render in your unaware MUA? feel >> free to send me a private report if you like. > > What do you think about always adding a header, > e.g. "X-Protected-Headers", which includes a short info about the > purpose of that part (as in this example)? Otherwise, it might be > somewhat confusing if such a MUA displays the header twice. If we can > agree on a standard name, it also assists MUA's to detect the block. Are you thinking of having this line in the embedded header or in the external header? I'm not sure that this is useful to have in the external header at all. In particular, it won't be cryptographically authenticated, and it won't be encrypted. So an attacker could (for example) strip out the external header and cause the MUA to ignore the embedded part. As for the embedded header, i'm not sure it's useful there either. it seems like a bit of a chicken-and-egg problem. >> signed_headers: >> * Subject >> * Date >> * From >> * To >> * Cc > > As including more headers doesn't cost much, I propose to also add the following: > - Reply-To: and Disposition-Notification-To:. Rationale: an attacker might tamper them as to provoke sending information to arbitrary recipients (at least for inattentive users, or for MUA's sending MDN's automatically). > - References: and In-Reply-To:. Rationale: avoids breaking the threading information by an attacker. I agree about the ones you mention here. Mail-Followup-To also seems relevant. >> encrypted_headers: >> * (Subject,"ENCRYPTED SUBJECT") >> * (In-Reply-To,) >> * (References,) > > IMHO, the list of encrypted headers could be the same as above. i think the list of encrypted headers might arguably be *all* of the headers except for some dummy block that is generated per-message. >> We'd also need to define what happens if more than one >> text/rfc822-headers part shows up in a multipart message -- most >> simply, we could say that we only process text/rfc822-headers if it >> happens to be the first non-multipart part within the >> multipart/signed or multipart/encrypted part. > > I think this should read: "if the text/rfc822-headers part is > * the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or > * the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages." That seems more narrowly scoped, which is probably a good thing, but it might be more brittle too; are there specific cases that you're trying to carve out from my broader suggestion? >> This prevents the receiving MUA from applying text/rfc822-headers from a forwarded (attached) signed/encrypted message. > > It would make sense, though, to verify if the headers of forwarded and > signed message/rfc822 parts against the (embedded) text/rfc822-headers > parts. what kind of verification should an MUA do? Is there any reason for an MUA to prefer the external headers where the embedded headers and external headers differ? For encrypted headers, we'd *assume* that they would differ, right, otherwise, there's nothing to gain from stuffing them inside the encrypted section. --dkg From nobody Mon Mar 16 17:48:54 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 EFB061ACD8C for ; Mon, 16 Mar 2015 17:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sbcFaaD3HBFf for ; Mon, 16 Mar 2015 17:48:50 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 7EEEF1A1BEC for ; Mon, 16 Mar 2015 17:48:50 -0700 (PDT) Received: by ladw1 with SMTP id w1so54453160lad.0 for ; Mon, 16 Mar 2015 17:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iUUCk1k4jI/rxqoGE9jOrMvpsZDLTtGjc1y0I2lA5FA=; b=v3sQo0Aa5KWaIpcqxuL6fYAqhIDOBFuDIYImQpzI+Kqm08LKECcw2uQuphge+BxtCR Gxg24nnnM8U/+UnmWj6RxC7ikquDycn9zZ1Dd4tbi+eAatz9MGCXSvjKxmRcU3FF1xNV eVx3mKzFPDus/obXWX4SxaX/VbwYNXacgQ5ly7JVXBwpBraavTfXD07UXsR32rrTJ63J YRgdolD7DjEkbVSBXfT9Kfh/lwUYkZh95gVJlooeo9SC/m1abnd1Uxhncl0ZWFSGihIr sXDXERDIE3EVV4S/uTxReEeaOT/dRRH+MNRlkfTQqNqR00Tn8P+Yb/0XyNOXqI4M0q/y CXBw== MIME-Version: 1.0 X-Received: by 10.112.97.228 with SMTP id ed4mr43390242lbb.79.1426553329051; Mon, 16 Mar 2015 17:48:49 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Mon, 16 Mar 2015 17:48:48 -0700 (PDT) In-Reply-To: <87fv94r080.fsf@alice.fifthhorseman.net> References: <87fv94r080.fsf@alice.fifthhorseman.net> Date: Mon, 16 Mar 2015 20:48:48 -0400 X-Google-Sender-Auth: rgD355SwyjTZEZiQDhmrHXuZsp0 Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: multipart/alternative; boundary=001a1133979a6e6e2d0511715480 Archived-At: Cc: gnupg-devel@gnupg.org, =?UTF-8?Q?Albrecht_Dre=C3=9F?= , =?UTF-8?Q?Hanno_B=C3=B6ck?= Subject: Re: [openpgp] Encrypting / Signing the mail subject? 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, 17 Mar 2015 00:48:52 -0000 --001a1133979a6e6e2d0511715480 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 16, 2015 at 7:28 PM, Daniel Kahn Gillmor wrote: > Hi Albrecht-- > > Sorry for the late followup -- this has now been raised on > openpgp@ietf.org, so i'm moving the follow up there. > > On Sun 2015-02-22 13:14:36 -0500, Albrecht Dre=C3=9F wrote: > > I am currently working on the implementation of your proposal for Balsa > [1], and would like to add a few comments. > > I'm glad to hear this! > > > Am 16.01.15 21:29 schrieb(en) Daniel Kahn Gillmor: > >> PGP/MIME messages are the only reliably structured mail OpenPGP e-mail > messages anyway [0]. > > > > As your proposal is fully transparent, I think it could also be used > > for RFC 2633 S/MIME (i.e. multipart/signed; > > application/pkcs7-signature as well as for application/pkcs7-mime). > > yep, this seems correct to me, but i don't know enough about the S/MIME > world to take the proposal there. Maybe we should find some S/MIME > folks to chime in on this. > I am not sure I am an S/MIME person. But I would like to see this sort of problem fixed in decently layered fashion that allows the same approach to be used in either. SMTP and HTTP share a problem of mixing up routing information (From, To, Path) and Content meta data. If we could untangle the two in a repeatable fashion, we can use the same approach to encrypt stored data blobs. So one approach would be to take the content-metadata headers out of the STMP section of the message and push them into the body of the message. That would then make possible approaches where the subject line is encrypted under one key and the content payload is encrypted under another. --001a1133979a6e6e2d0511715480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 16, 2015 at 7:28 PM, Daniel Kahn Gillmor = <dkg@fifthhor= seman.net> wrote:
Hi Albre= cht--

Sorry for the late followup -- this has now been raised on
openpgp@ietf.org, so i'm moving= the follow up there.

On Sun 2015-02-22 13:14:36 -0500, Albrecht Dre=C3=9F wrote:
> I am currently working on the implementation of your proposal for Bals= a [1], and would like to add a few comments.

I'm glad to hear this!

> Am 16.01.15 21:29 schrieb(en) Daniel Kahn Gillmor:
>> PGP/MIME messages are the only reliably structure= d mail OpenPGP e-mail messages anyway [0].
>
> As your proposal is fully transparent, I think it could also be= used
> for RFC 2633 S/MIME (i.e. multipart/signed;
> application/pkcs7-signature as well as for application/pkcs7-mime).
yep, this seems correct to me, but i don't know enough about the S/MIME=
world to take the proposal there.=C2=A0 Maybe we should find some S/MIME folks to chime in on this.

I am not sur= e I am an S/MIME person. But I would like to see this sort of problem fixed= in decently layered fashion that allows the same approach to be used in ei= ther.

SMTP and HTTP share a problem of mixing up r= outing information (From, To, Path) and Content meta data. If we could unta= ngle the two in a repeatable fashion, we can use the same approach to encry= pt stored data blobs.

So one approach would be to = take the content-metadata headers out of the STMP section of the message an= d push them into the body of the message.=C2=A0

Th= at would then make possible approaches where the subject line is encrypted = under one key and the content payload is encrypted under another.
--001a1133979a6e6e2d0511715480-- From nobody Mon Mar 16 18:36:37 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 7FF7D1ACDCD for ; Mon, 16 Mar 2015 18:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 MoNLcsOdBdgm for ; Mon, 16 Mar 2015 18:36:31 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AECC1ACDCC for ; Mon, 16 Mar 2015 18:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426556191; x=1458092191; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qrMZqvjGfq6oR+U0wEU20mIpau40iiFuNrJWDa2IIBs=; b=nc5QaWw63qcVKqarQmR8hjNmvU8V+t/fz4G3Q7eqS23wdcJIe1KOL8Cl PlvFP3mmP40rbUc77hJ+QSBmGtE3ebOMUJN/GsgTmSU95W1SlmU9x+clb gq4ik09C6bYyggH4X9BxmoDZo/3PI0iXyjn4pt/cn7pWkWbt3QZvcgVFZ Y=; X-IronPort-AV: E=Sophos;i="5.11,412,1422874800"; d="scan'208";a="314324765" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Mar 2015 14:36:30 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 14:36:29 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] Intent to deprecate: Insecure primitives Thread-Index: AdBgUspPxivdl9tFQe6s2v6MCtngAw== Date: Tue, 17 Mar 2015 01:36:29 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB37CE@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 17 Mar 2015 01:36:35 -0000 David Leon Gil writes:=0A= =0A= >A 64-bit blocksize is small enough that there is a significant probability= of=0A= >(some user) encrypting a message with two blocks the same.=0A= =0A= Yet another wildly inaccurate claim of cryptographic weakness, alongside=0A= "triple DES is totally insecure" and "1K RSA can factored in a week or two"= =0A= (both on the cryptography list, the latter only week or so back). If you'r= e=0A= going to deprecate a crypto mechanism then, if there really is a problem, b= y=0A= all means do so, but don't just invent claims about its "weakness".=0A= =0A= Peter.=0A= From nobody Mon Mar 16 18:50: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 6538E1ACDDD for ; Mon, 16 Mar 2015 18:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 Ncmhm3KFt9FN for ; Mon, 16 Mar 2015 18:50:37 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9471ACDDC for ; Mon, 16 Mar 2015 18:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426557037; x=1458093037; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=3WHwX7QkkZFe+JmMLMhkgCIM+YxGXnyBBM9gBsS089w=; b=EdBkS31YuDnJCtyndGx+uix3Ezo/3TzaZr8cDcPEPIPqvJ2+kIkuR7xZ jBqJvnNCY/d3r5lo9qiXV/An6azAAFuwz2/Bd5Rjmi4JD5dHQG+C+mUxh TB0WmOliyHxWl78fYR9U47FNh2Kt8njLE9CbS7cpGEB0mUkstuQJPX87n w=; X-IronPort-AV: E=Sophos;i="5.11,412,1422874800"; d="scan'208";a="314328994" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Mar 2015 14:50:21 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 14:50:19 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] The combinatorial complexity of OpenPGPv4 Thread-Index: AdBgVLlMiakK1BR3S2ih3nLQ0aC7OQ== Date: Tue, 17 Mar 2015 01:50:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB37EF@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 17 Mar 2015 01:50:39 -0000 Derek Atkins writes:=0A= =0A= >Having implemented it myself, I disagree completely. It is absolutely=0A= >possible to create a modular implementation. See my Usenix Security Talk = on=0A= >the PGP Message Processing Pipeline from.... 1996??=0A= =0A= PGP message processing isn't hard (apart from the *&*^#&*# partial-lengths= =0A= kludge), I've done the same, I have retargetable code that does either S/MI= ME=0A= or PGP depending on which encoding/decoding functions you point to.=0A= =0A= The killer with PGP is keyrings, which are impossible to process in any kin= d=0A= of nontrivial API (in other words a library) because there's no concept of= =0A= "single blob containing a key + name" as there is for X.509 certs. Instead= ,=0A= you have a mass of packets concatenated together, deeply bound in a spaghet= ti=0A= of implicit cross-references (some of the following packets apply to a=0A= previous packet, and some are signatures that tie other bits together, and= =0A= then there's trust packets that change the semantics or earlier packets, an= d=0A= so on).=0A= =0A= It's pretty much impossible to create any clean API to handle this, you nee= d=0A= an interactive app that keeps going back to the user and asking "I've just= =0A= found some X here, what shall I do now?". Similarly, storing these things = in=0A= something like a key/value store for fast lookup is nearly impossible becau= se=0A= you end up having a more or less open-ended number of index fields and cros= s-=0A= references that need to be maintained.=0A= =0A= If anyone wants to challenge that, please provide in your reply an outline = of:=0A= =0A= - An "add a key API" that takes a newly-received PGP key and adds it to a= =0A= keyring, along with a clear description of its semantics.=0A= =0A= - A schema for storing PGP keys in a key/value store.=0A= =0A= (This is to pre-empt a flamefest. If you think it's possible, prove it :-)= .=0A= =0A= Peter.= From nobody Mon Mar 16 19:04:59 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 9110B1A92F6 for ; Mon, 16 Mar 2015 19:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 IQ9jSFaj1XK3 for ; Mon, 16 Mar 2015 19:04:56 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2E71A1E0F for ; Mon, 16 Mar 2015 19:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426557896; x=1458093896; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sr5H4v+WqM3BS+zC+MvjtaJr7eohCzJB2KCwV44R9CU=; b=bDKEMEHPbT4jUqiacRx0KsR6XccUNYJaN92ogO5d6yBvqpDe9bbQHyis c9SNR3x3uomIGf06qmU5OP4WxnBICNWRQHhhfTafdKD+x5ceuEkFePrnF OAWrTNZd/rVnfcLMVVTE4CgoI6tomp1Xkcd3lcJMGQtQsSi5AzaD37K9I w=; X-IronPort-AV: E=Sophos;i="5.11,412,1422874800"; d="scan'208";a="314333235" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Mar 2015 15:04:34 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 15:04:33 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] "OpenPGP Simple" Thread-Index: AdBgVrXDDtt5MnMkRreeHsLDjkZPLA== Date: Tue, 17 Mar 2015 02:04:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 02:04:57 -0000 Jon Callas writes:=0A= =0A= >Certainly the ASCII Armor checksum is something that could go, since we do= n't=0A= >need to worry so much about modem line noise. :-) But you have to know eno= ugh=0A= >to ignore it.=0A= =0A= It's not just the checksum, the entire ASCII armoring should have been=0A= discarded years, no decades, ago. The whole thing was originally implement= ed=0A= because facilities like FidoNet and Usenet didn't handle binary messages, a= nd=0A= the checksum was because things like 2400bps modems (pre-MNP) on the DOS PC= s=0A= that PGP 1 was written for wouldn't cancel out line noise, so it was useful= to=0A= check for inadvertent message corruption before you warned about invalid=0A= signatures.=0A= =0A= The MIME standard (going back to RFC 1341) is over 20 years old and pretty= =0A= much everything supports it, but PGP persists with something from even earl= ier=0A= (PEM, from 1987, that's nearly 30 years ago). It's not just "a museum of= =0A= 1990s crypto" (thanks to Matthew Green for the great quote), it's also a=0A= museum of 1980s and 1990s everything-else. The entire discussion of "ASCII= =0A= armour" should have been replaced with "use a mechanism like MIME" years ag= o.=0A= =0A= (Oh, and by "MIME" I mean proper use of MIME, not "wrap PGP-PEM in MIME=0A= headers and pretend it's MIME", RFC 2015/3156).=0A= =0A= Peter.= From nobody Mon Mar 16 19:10:32 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 8BF441ACDE7 for ; Mon, 16 Mar 2015 19:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 NhZ3S2hl0x11 for ; Mon, 16 Mar 2015 19:10:18 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1254E1ACDE0 for ; Mon, 16 Mar 2015 19:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426558219; x=1458094219; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=b4Qc4/VXHRrKTtmfRNUUVN/z/ZJA2e51FE/laIcDhHc=; b=WHFQr04V6QbJdNaQ/yTOX/uApXrlNpBimHlix3u0L2uxxlflICn+ria7 eC/2x/a7ygZXj4ZTsNAiMCx+O7v9XxATgVYn28aHlOBI0ZFJc9423ML6o rl+//Kc/vi2FoeOC+B3YaejLFoz5JNEJkc3vKIHlhn7HI++rSmlrjlsdT o=; X-IronPort-AV: E=Sophos;i="5.11,413,1422874800"; d="scan'208";a="314335379" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Mar 2015 15:10:17 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 15:10:16 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] "OpenPGP Simple" Thread-Index: AdBgV4KGYKmsrw3ZR5OHrnJhCvQhDA== Date: Tue, 17 Mar 2015 02:10:16 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 02:10:23 -0000 David Shaw writes:=0A= >On Mar 16, 2015, at 5:15 PM, David Leon Gil wrote:=0A= >> Partial lengths are really a nuisance to parse.=0A= >=0A= >No argument there...=0A= =0A= The whole bizarro sort-of-fixed-point encoding of lengths is a pain (this i= s a=0A= cue for Jon to do his "every bit is sacred" dance). If the format is revis= ed,=0A= there should be only two lengths, a 16-bit one for almost everything (keyri= ng=0A= data, signatures, etc), and a 32-bit one for payloads and partial lengths t= hat=0A= are going to exceed 16-bit lengths. Length-decoding shouldn't be any more= =0A= complicated than:=0A= =0A= read tag;=0A= if( tag & length_32_flag )=0A= length =3D read32();=0A= else=0A= length =3D read16();=0A= =0A= While I'm venting, shall I get started on the MDC kludge?=0A= =0A= Peter.= From nobody Mon Mar 16 20:05:52 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 A42AD1A914B for ; Mon, 16 Mar 2015 20:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 oBF3XON0RG48 for ; Mon, 16 Mar 2015 20:05:49 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681E51ACD86 for ; Mon, 16 Mar 2015 20:05:49 -0700 (PDT) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by mail.jabberwocky.com (8.14.4/8.14.4) with ESMTP id t2H2jVdh025105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 22:45:32 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: David Shaw In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 16 Mar 2015 23:05:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 03:05:50 -0000 On Mar 16, 2015, at 10:10 PM, Peter Gutmann = wrote: >=20 > David Shaw writes: >> On Mar 16, 2015, at 5:15 PM, David Leon Gil wrote: >>> Partial lengths are really a nuisance to parse. >>=20 >> No argument there... >=20 > The whole bizarro sort-of-fixed-point encoding of lengths is a pain = (this is a > cue for Jon to do his "every bit is sacred" dance). If the format is = revised, > there should be only two lengths, a 16-bit one for almost everything = (keyring > data, signatures, etc), and a 32-bit one for payloads and partial = lengths that > are going to exceed 16-bit lengths. Length-decoding shouldn't be any = more > complicated than: >=20 > read tag; > if( tag & length_32_flag ) > length =3D read32(); > else > length =3D read16(); I'm fine with that, but I do want to keep the concept of partial = lengths, as you did above. People do encrypt things without knowing how = large they are ahead of time. I'm fine with a restriction (which = already exists today) that only payloads can use partial lengths. David From nobody Mon Mar 16 20:46:46 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 0A03D1A1BED for ; Mon, 16 Mar 2015 20:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RMD-FNbCOADl for ; Mon, 16 Mar 2015 20:46:42 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E2F1ACDF9 for ; Mon, 16 Mar 2015 20:46:40 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw01.dd24.net (Postfix) with ESMTP id 2F9965FB09 for ; Tue, 17 Mar 2015 03:46:39 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id gSV0Y0OSqtl3 for ; Tue, 17 Mar 2015 03:46:37 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Tue, 17 Mar 2015 03:46:36 +0000 (UTC) Message-ID: <1426563996.18487.24.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 17 Mar 2015 04:46:36 +0100 In-Reply-To: <874mppgyez.fsf@vigenere.g10code.de> References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-vf/jIA8c07ONZM+fYpwK" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 17 Mar 2015 03:46:45 -0000 --=-vf/jIA8c07ONZM+fYpwK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-03-13 at 08:16 +0100, Werner Koch wrote: > > - The WG should consider whether to just bring OpenPGP up to date... or > > whether to completely overhaul or even re-design it. > The please give the thing another name. Recall the outcry whn I removed > PGP-2 support from 2.1. Well I guess it happens very often that one has a very loud minority and a silent majority. Removing the support was definitely the right thing, especially since it's still in the other branches. All these very old keys are likely lather small (and thus weak) and shouldn't be used therefore anymore. IMO, security business can't really afford to always comfort those living in the past and/or not doing their homework. This model (leaving legacy stuff in for compatibility reasons) blew up so often recently (RC4, SSL3, the export cipher suites, problematic CBC mode usage in e.g. SSH)... these things should have been phased out long ago, instead, people waited for questionable compatibility reasons way too long until 5 past 12. Someone who really wants security should have to suffer because of those who want to keep old systems/alogs/etc., since the later anyway do not really want security.=20 > We already have this. You may either use a plain user ID with signed > attributes to implement this or, better Well, as I've written before, using the plain UID packets in such ways should IMHO be given up. > extend the attribute packet, > which is currently only used for photo ids, but designed for what you > want. You may already start with this using the 100--110 subpacket > types. Sure, just no one ever specified it, and thus no one every used it that way > Regarding the rest of your mail, I think it is better to postpone a > detailed discussion for now. Fine,... it's now in the archives for the records =3D) Cheers, Chris. --=-vf/jIA8c07ONZM+fYpwK Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxNzAzNDYz NlowTwYJKoZIhvcNAQkEMUIEQJhzLWuKxd8LMlW4yFWtBtragT+VWevytV6HdCVIrgbnBNKrOFtw 2iHglSe4YdX1Q9wNa1xp7nJJHTh6L8iR3HcwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDL8A4ZSulcsq/hJi/J9M4wBb3+bgSW 6+ZfBKENRDIv9y7Bc/grSrZPQfxYhLwGIZTzQ4uAPjWhPOudGUPP4OzG/UfR1vqEEOdi4x+18Hu8 svxt1X1sy64cJC9K6aCX7MXIa/2d/hZzSccHN8bhzpdPs7/BrRTa4Af6LkahE/WqVc4p7rPBcHpF 4c5cx42JceuqiGG5/GT9tkEG7gfUmX3yjmeD1oeqsFkorIjYpkoT0QfS7xoxeuH58BWxPFGcaggB sChudIlTeguc/jWFICKgA21tETCoVHGdSd1Sx5IaGebw+tIjOovRAXqwVzCbeK+uHxXx4f0d00pV TcYQaEsaAAAAAAAA --=-vf/jIA8c07ONZM+fYpwK-- From nobody Mon Mar 16 20:59:21 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 25CE41ACE01 for ; Mon, 16 Mar 2015 20:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dJJKeBqPYX7S for ; Mon, 16 Mar 2015 20:59:17 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8091ACDFF for ; Mon, 16 Mar 2015 20:59:17 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 8FE805FB8A; Tue, 17 Mar 2015 03:59:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id l5V_h14sz4hc; Tue, 17 Mar 2015 03:59:13 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA; Tue, 17 Mar 2015 03:59:13 +0000 (UTC) Message-ID: <1426564752.18487.35.camel@scientia.net> From: Christoph Anton Mitterer To: Derek Atkins Date: Tue, 17 Mar 2015 04:59:12 +0100 In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-jVemCJWGxu7dFFr3x9Sc" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 17 Mar 2015 03:59:19 -0000 --=-jVemCJWGxu7dFFr3x9Sc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also to answer Werner's comment ("OpenPGP does not define the Web of Trust. There is no standard for it.") On Fri, 2015-03-13 at 09:42 -0400, Derek Atkins wrote:=20 > This was explicitly out of scope from the former OpenPGP WG. I think > that was a GOOD THING, and I believe it should remain out of scope. I was probably a bit unclear in what I wrote. I've mainly meant: The functionality of OpenPGP shouldn't be limited in such a way that what we can do now with it (e.g. the web of trust, or trust hierarchies via the trust signatures) would no longer be possible. Apart from that I basically agree that OpenPGP itself (i.e. the RFC for the message format) shouldn't define a trust system (e.g. the web of trust), BUT: a) it might(!) make sense for another RFC to do this on an informal basis b) currently we have several things (well at least the different levels of user signatures 0x10-0x13) which are pretty much undefined, useless, ambiguous and therefore even dangerous. 0x10 and 0x11 have at least some "proper" definition, but they don't tell how implementations should react on them (=3D> dangerous). 0x12 and 0x13 are quite vague and ambiguous. > IMHO we shouldn't define how OpenPGP is used, only what it inputs and > outputs. Phew... well... perhaps not how it's used, but it should be always clear how a message is to be interpreted - I think I've mentioned some examples where this is not really the case, and these obviously also affect the trust and usage model. > For the record, draft-atkins-openpgp-device-certificates already extends > the Attribute Subpacket with a String ID (similar to the UserID). *If* attributes are to be extended (e.g. in ways as I've proposed in my previous mail) than I think this is really something that needs considerable effort to be spent upon. Properties should be well defined, there shouldn't be too many properties for actually same things but OTOH one shouldn't be to reluctant to add new ones when it makes sense. Stuffing everything in a few generic attributes would be quite bad. Cheers, Chris. --=-jVemCJWGxu7dFFr3x9Sc Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxNzAzNTkx MlowTwYJKoZIhvcNAQkEMUIEQJfpkTH153MSZmAtB4BoWqNaCDArkDRLS/O4ot2tOb9+JQX3iben 6zrO8PIKjBRbLfmw3soaMmApWZdtojZSlCcwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBtrU+7ywtFXTCHX/NyX+qOilQ8LLof yAsMfojA9+GtFNvSuvocFwXb5i9aAa8cpcezo5HHxaC9EbaeWW4rol3PXrlHhtsKe4VH1JxLHiqp aPYOqwVHMJdWSolYBSDScPbBp6y1NlGF/pgQkBs3iVZzeY4vYQ374LX4hYQL2UDBnR9v8OsVgq8n PTG0GVzqUWreTUWRCZB0m2IoSUNyid8JEjtfrVqNslz7ynU1h0TxiCCLxtuY1Gl06RiiOVUI09XT NPIcswpXvCgK/cDZoCLBBSqrRcAce8V9Ghy6a/IYh4tDsfMImIuuWRLovh3fWT2oA46c2F41mMzc 9jEv6DfMAAAAAAAA --=-jVemCJWGxu7dFFr3x9Sc-- From nobody Mon Mar 16 21:08:48 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 2583B1A0018 for ; Mon, 16 Mar 2015 21:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Aea-WuQm2Mfe for ; Mon, 16 Mar 2015 21:08:44 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802941A000E for ; Mon, 16 Mar 2015 21:08:44 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw02.dd24.net (Postfix) with ESMTP id 5E3F25FB8B for ; Tue, 17 Mar 2015 04:08:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id Y00oxLthRiKC for ; Tue, 17 Mar 2015 04:08:41 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Tue, 17 Mar 2015 04:08:41 +0000 (UTC) Message-ID: <1426565320.18487.45.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 17 Mar 2015 05:08:40 +0100 In-Reply-To: <20150315175744.GG2978@singpolyma-liberty> References: <20150315175744.GG2978@singpolyma-liberty> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-heDZ34uL9OPGp1+QOS2k" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 04:08:46 -0000 --=-heDZ34uL9OPGp1+QOS2k Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2015-03-15 at 12:57 -0500, Stephen Paul Weber wrote:=20 > One of the big obstacles to OpenPGP deployments that I've faced over time= is=20 > the perception that it's "too complicated", mostly based on the sheer siz= e=20 > of the current RFC. Uhm? Compared to other standards it seems to be rather simple. Apart from that, not everyone needs to (neither should one) re-invent the wheel. I don't say that there should be no more than one implementation of OpenPGP, but having too many is just bad for security. That being said - we already have a number of implementations which cover the standard quite well - what's wrong with [contributing to| using] them? > 1) Sections of the RFC define what you might call "extras", such as the= =20 > ASCII Armor (including a checksum unused elsewhere in the spec) As some others already said, using e.g. MIME would be better - but ASCII armors aren't just used when sending mail (people use it e.g. to post their raw key on a website or things like that). So if ASCII Armors are dropped, the standard should refer to something else that is used instead - just to prevent that people are using all different froms of base64 encoding, uuencode, etc. > 2) There are a lot of backwards-compatibility things (old-style lengths,= =20 > lots of different algorithms) Agree with that. > Is there any prior art on IETF specs having a "full" and "simple" form wh= ere=20 > full implementations can read any output of simple ones, but not always= =20 > vice-versa? I'd say that this is rather a bad idea. For many standards where this was done it caused more troubles than good. It's also security-wise a problem: Who decides what's not critical enough for the base standard? Is it guaranteed that implementations that don't implement the "full" standard are still secure? And often it just means that simply no one ever implements the extensions to the base standard (think of the dozens of JPEG2000 profiles). If something is so special that it wouldn't be needed in the base standard, one should perhaps question whether it's needed at all. Cheers, Chris. --=-heDZ34uL9OPGp1+QOS2k Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxNzA0MDg0 MFowTwYJKoZIhvcNAQkEMUIEQPqE4bVEIYL0DwDEn+Q1XJD7Zt5rG1zBC7ZGo9FP58rabcFxcs4v YDNsaoT5qdCKuHMXVftXIphX5EENj89OY6IwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCI2KMwVZWd3HXXjbGHj4Ep02yzME92 59BPXzffwQEF9Ogm2bbLmMUJRC8oNfQNGyNZPSqy/hqzEDqN2oPW2COeZDORuzEt55asVXcyNGxQ E/FgsnqtR2no/j2p63rK55rIcSsLkb0kbCAbnF32Zab6YZq2BZuOpdeInpERRes3sksz6xW62T11 wLI8W6Qg6DG/jIGyDl2ETuVS1UBf6lK4iODmg0NgSHmAIM9CeSidP07Rn8Yk1ng4GcXfweKkq2G0 xvfnWS5QCJOxLTIRA9k0L3aqnDgx426U9K9Mmmp6c1ErDJmk4exWWf1WlaaTjVfjM4Jt0rzxZK4g RPRPF6p9AAAAAAAA --=-heDZ34uL9OPGp1+QOS2k-- From nobody Mon Mar 16 23:49:25 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 E008B1A00B7 for ; Mon, 16 Mar 2015 23:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9k8M-gM-DMMc for ; Mon, 16 Mar 2015 23:49:21 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 062BF1A00B5 for ; Mon, 16 Mar 2015 23:49:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 5013E6CA5D05; Mon, 16 Mar 2015 23:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap03m3tmdu8H; Mon, 16 Mar 2015 23:48:48 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 44BE16CA5CEE; Mon, 16 Mar 2015 23:48:46 -0700 (PDT) Received: from [10.0.23.34] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 16 Mar 2015 23:48:48 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 16 Mar 2015 23:48:48 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 16 Mar 2015 23:48:46 -0700 Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 06:49:23 -0000 > On Mar 16, 2015, at 7:04 PM, Peter Gutmann = wrote: >=20 > Jon Callas writes: >=20 >> Certainly the ASCII Armor checksum is something that could go, since = we don't >> need to worry so much about modem line noise. :-) But you have to = know enough >> to ignore it. >=20 > It's not just the checksum, the entire ASCII armoring should have been > discarded years, no decades, ago. The whole thing was originally = implemented > because facilities like FidoNet and Usenet didn't handle binary = messages, and > the checksum was because things like 2400bps modems (pre-MNP) on the = DOS PCs > that PGP 1 was written for wouldn't cancel out line noise, so it was = useful to > check for inadvertent message corruption before you warned about = invalid > signatures. >=20 > The MIME standard (going back to RFC 1341) is over 20 years old and = pretty > much everything supports it, but PGP persists with something from even = earlier > (PEM, from 1987, that's nearly 30 years ago). It's not just "a museum = of > 1990s crypto" (thanks to Matthew Green for the great quote), it's also = a > museum of 1980s and 1990s everything-else. The entire discussion of = "ASCII > armour" should have been replaced with "use a mechanism like MIME" = years ago. >=20 > (Oh, and by "MIME" I mean proper use of MIME, not "wrap PGP-PEM in = MIME > headers and pretend it's MIME", RFC 2015/3156). >=20 Maybe not decades. ASCII armor as it exists now uses the same encoding as MIME for base64, = purely by chance. It is one of the things that makes me least crazy = because it=E2=80=99s mostly standard and actually kinda useful. There = are a lot of semantic places where it=E2=80=99s nice to know that = something is an OpenPGP object in human-readable form. Something that seems to be forgotten all over the place is that email is = actually one of the least interesting places to use OpenPGP. ASCII armor = ends up being a nice way to encode something so you don=E2=80=99t have = to play "guess the binary format." Relatively recently, I was opining to someone that it would be useful to = come up with a JSON encoding for OpenPGP that would give an = easy-to-parse thing that=E2=80=99s not just ASCII armor. But some years = ago, I said the same thing but it was XML, not JSON. And a few years = before that, it was S-Expressions, most recently in SPKI format, and = more Common LISP-ish before that even. JSON is what the cool kids are = using this decade, don=E2=80=99t you know. And *that* is the reason to just stick with ASCII armor. Jon From nobody Tue Mar 17 00:00:48 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 EFD7A1A00D8 for ; Tue, 17 Mar 2015 00:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mg9dXG0u_m5z for ; Tue, 17 Mar 2015 00:00:38 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2822A1A00D0 for ; Tue, 17 Mar 2015 00:00:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 9380B6CA6042; Tue, 17 Mar 2015 00:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUM4XwcoCB8k; Tue, 17 Mar 2015 00:00:01 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id D9D836CA602D; Tue, 17 Mar 2015 00:00:00 -0700 (PDT) Received: from [10.0.23.34] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Tue, 17 Mar 2015 00:00:00 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 17 Mar 2015 00:00:00 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 16 Mar 2015 23:59:59 -0700 Message-Id: <73CB47A4-B158-4EDB-9884-9F92B1AAF6F5@callas.org> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 07:00:42 -0000 > On Mar 16, 2015, at 7:10 PM, Peter Gutmann = wrote: >=20 > The whole bizarro sort-of-fixed-point encoding of lengths is a pain = (this is a > cue for Jon to do his "every bit is sacred" dance). If the format is = revised, > there should be only two lengths, a 16-bit one for almost everything = (keyring > data, signatures, etc), and a 32-bit one for payloads and partial = lengths that > are going to exceed 16-bit lengths. =20 Okay... NOOOOOOOOO!!!!! For the love of God, Montressor, only *one* type = of length. You=E2=80=99re spending more space in the parsing code and = sooner or later, someone=E2=80=99s going to screw it up and there will = be a stupid ass security problem that could have been solved by just = spending the two damned extra bytes. > While I'm venting, shall I get started on the MDC kludge? Sure. Go right ahead. But when you do, take into account that MDC pre-dates HMAC and at the = time, one of the major objections was a "why would you want to have = symmetric crypto protection when you could just sign it" whine, and the = other was excessive worry about single-pass processing that got so = irrational we couldn=E2=80=99t work through it. Standards are compromises, and a good compromise leaves everyone a bit = grumpy. Since those days, I=E2=80=99ve developed an affection for MDC = because it sits in a nether world where related concepts like deniable = encryption that also sound good until you think about them for long = enough. And it doesn=E2=80=99t hurt anything, because if you really want = it protected, just sign the darned thing. But please, please, go right ahead. Jon= From nobody Tue Mar 17 00:03:17 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 037431A00E9 for ; Tue, 17 Mar 2015 00:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 C4ceJ0JrwPUR for ; Tue, 17 Mar 2015 00:03:12 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 8AC3D1A000D for ; Tue, 17 Mar 2015 00:03:11 -0700 (PDT) Received: by ladw1 with SMTP id w1so607374lad.0 for ; Tue, 17 Mar 2015 00:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EIhvilHzOXkw1Pnw/lwWbh44bVfVD5BbTYkB/rYx3Vw=; b=kXImHL8igaYU3NnJZ02YRLZDomTDZ0KTNyT72eEYH2cAMoB25hX2IZXvf/arPzNSKI jwHcqKL+ZiCJs4ODWcKe1P+ilObflLDGY7HW57wqa26bGQIVdb01Y2+HjmnEvs1qCY8f 1TINYSq19eUsKtvaB0G5XupIDJviqnOnlbooD4UIcZ9ns9DtTFDN1PgszXJUnVOxunAw rQ3e4kmU0eZh8sBu0ZUvaNiM7LmMqZwALWMZWYA5PCoEfwwijm1AMYEFCnEgHnszIqYv 3pio7aYskAIin76KHwSvdfYJ0vwi4Eced50fS57y9sPC8VpDC5xXRS+/ix/VLZA1NJX8 GPeg== X-Gm-Message-State: ALoCoQkL+Efg5IAxOohsvb9hTycikspJ5kdxkaIKDPYMUGhqY/rmIsJM6iI0CcacDGmZuMIp0dZk MIME-Version: 1.0 X-Received: by 10.112.144.41 with SMTP id sj9mr58507173lbb.3.1426575789849; Tue, 17 Mar 2015 00:03:09 -0700 (PDT) Received: by 10.114.3.242 with HTTP; Tue, 17 Mar 2015 00:03:09 -0700 (PDT) X-Originating-IP: [122.56.232.225] Received: by 10.114.3.242 with HTTP; Tue, 17 Mar 2015 00:03:09 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 17 Mar 2015 20:03:09 +1300 Message-ID: From: Tim Bray To: Peter Gutmann Content-Type: multipart/alternative; boundary=047d7b3a82de3313770511768f42 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 07:03:14 -0000 --047d7b3a82de3313770511768f42 Content-Type: text/plain; charset=UTF-8 I have repeatedly found it useful, even in recent times, to cut/paste ASCII-armored messages on my mobile. Am I a Neanderthal? On Mar 17, 2015 3:05 PM, "Peter Gutmann" wrote: > Jon Callas writes: > > >Certainly the ASCII Armor checksum is something that could go, since we > don't > >need to worry so much about modem line noise. :-) But you have to know > enough > >to ignore it. > > It's not just the checksum, the entire ASCII armoring should have been > discarded years, no decades, ago. The whole thing was originally > implemented > because facilities like FidoNet and Usenet didn't handle binary messages, > and > the checksum was because things like 2400bps modems (pre-MNP) on the DOS > PCs > that PGP 1 was written for wouldn't cancel out line noise, so it was > useful to > check for inadvertent message corruption before you warned about invalid > signatures. > > The MIME standard (going back to RFC 1341) is over 20 years old and pretty > much everything supports it, but PGP persists with something from even > earlier > (PEM, from 1987, that's nearly 30 years ago). It's not just "a museum of > 1990s crypto" (thanks to Matthew Green for the great quote), it's also a > museum of 1980s and 1990s everything-else. The entire discussion of "ASCII > armour" should have been replaced with "use a mechanism like MIME" years > ago. > > (Oh, and by "MIME" I mean proper use of MIME, not "wrap PGP-PEM in MIME > headers and pretend it's MIME", RFC 2015/3156). > > Peter. > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --047d7b3a82de3313770511768f42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have repeatedly found it useful, even in recent times, to = cut/paste ASCII-armored messages on my mobile. Am I a Neanderthal?

On Mar 17, 2015 3:05 PM, "Peter Gutmann&quo= t; <pgut001@cs.auckland.ac.= nz> wrote:
Jo= n Callas <jon@callas.org> write= s:

>Certainly the ASCII Armor checksum is something that could go, since we= don't
>need to worry so much about modem line noise. :-) But you have to know = enough
>to ignore it.

It's not just the checksum, the entire ASCII armoring should have been<= br> discarded years, no decades, ago.=C2=A0 The whole thing was originally impl= emented
because facilities like FidoNet and Usenet didn't handle binary message= s, and
the checksum was because things like 2400bps modems (pre-MNP) on the DOS PC= s
that PGP 1 was written for wouldn't cancel out line noise, so it was us= eful to
check for inadvertent message corruption before you warned about invalid signatures.

The MIME standard (going back to RFC 1341) is over 20 years old and pretty<= br> much everything supports it, but PGP persists with something from even earl= ier
(PEM, from 1987, that's nearly 30 years ago).=C2=A0 It's not just &= quot;a museum of
1990s crypto" (thanks to Matthew Green for the great quote), it's = also a
museum of 1980s and 1990s everything-else.=C2=A0 The entire discussion of &= quot;ASCII
armour" should have been replaced with "use a mechanism like MIME= " years ago.

(Oh, and by "MIME" I mean proper use of MIME, not "wrap PGP-= PEM in MIME
headers and pretend it's MIME", RFC 2015/3156).

Peter.
_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp
--047d7b3a82de3313770511768f42-- From nobody Tue Mar 17 01:19:10 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 5FE641A010E for ; Tue, 17 Mar 2015 01:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 q-I1e9nkSsOj for ; Tue, 17 Mar 2015 01:18:12 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C331A0105 for ; Tue, 17 Mar 2015 01:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426580259; x=1458116259; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dWdL3Z7SAZ5HU6txzJWJnXxxv3pOd4c5tzo5hLweZjw=; b=CPfD2jL+mMCrqEeZLlqERuhuuW7Unyc0ks5EtcbyTeIa3A2lYOwBDCVf fKNh8S5LwUh4N9dDzJySQOjulOXcb3/fi6YddeWtchw/McCQOi11E21LL dyUdUMDkrTBOiVRs6Gu6S3BYj9Uanu3oLoXaX53z+7rnO1iUqVf3PXLzN k=; X-IronPort-AV: E=Sophos;i="5.11,415,1422874800"; d="scan'208";a="314410774" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Mar 2015 21:17:36 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 17 Mar 2015 21:17:35 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] "OpenPGP Simple" Thread-Index: AdBgitMQjfm+plu2RpuPH0dl7KWjRg== Date: Tue, 17 Mar 2015 08:17:35 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB3C04@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 08:18:25 -0000 Jon Callas writes:=0A= =0A= >But when you do, take into account that MDC pre-dates HMAC =0A= =0A= "Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG" was=0A= published at ISC'02, the MDC mechanism appeared in OpenPGP drafts around=0A= 2000-2001. "Keying Hash Functions for Message Authentication" dates from= =0A= 1996, predating even the original OpenPGP spec (RFC 2440 from 1998, which= =0A= doesn't mention MDC).=0A= =0A= >Standards are compromises, and a good compromise leaves everyone a bit=0A= >grumpy. Since those days, I=92ve developed an affection for MDC because it= sits=0A= >in a nether world where related concepts like deniable encryption that als= o=0A= >sound good until you think about them for long enough.=0A= =0A= See "The Order of Encryption and Authentication for Protecting Communicatio= ns=0A= (Or: How Secure is SSL?)?" from Crypto'01.=0A= =0A= Peter.=0A= From nobody Tue Mar 17 01:43:52 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 CA6F61A0161 for ; Tue, 17 Mar 2015 01:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 PYdVtwdQJ9hm for ; Tue, 17 Mar 2015 01:43:09 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.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 068C51A0162 for ; Tue, 17 Mar 2015 01:43:07 -0700 (PDT) Received: by lbbsy1 with SMTP id sy1so1960446lbb.1 for ; Tue, 17 Mar 2015 01:43:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bv7mn2+Zj6YLCtc+mOWGUkm1w6/xDrT9NkUMQpSyorc=; b=fgBD/UpN9Fr0UDHyxhGoLdU3NIlABOtOJ6Oth3LXoRf4Q3YbMNZwLBHQMev4CTo5HI 64GVhRrpsioivHWHIGbAt3MaH2uJg+Rf9j8PAVDYOT5qcdMZaC8IRpiUIi+smwnEqWgZ j7sTh8vbQzfEVEDGOvoWY748p1MUNH019nHK9+PA/whH1TuZ0wuNN7V6hJ2oxJU3OAMn oaMIhvAv6eV2y2x2k2BSlzmYFXXkY9pGPZlUf1AaR/wYv67QxwSBut7OKPKwAnJamkOv 8Ko2JsNbgGCcAs5a9EutOi3IyM6PcOkgLtm/QgQUoA39W2tSr2Zw7BWifcM9lYAuDrxH Bimg== X-Gm-Message-State: ALoCoQlhM8Swg/J3llPDGWteQ+Kx1cTIJsApD0Yo3MYgYsvRx5U1a0mBXqhmCrZRkTQix1ihrE76 X-Received: by 10.112.133.225 with SMTP id pf1mr59265303lbb.33.1426581785417; Tue, 17 Mar 2015 01:43:05 -0700 (PDT) Received: from [192.168.4.145] ([195.1.8.34]) by mx.google.com with ESMTPSA id zo8sm2670037lbc.37.2015.03.17.01.43.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 01:43:04 -0700 (PDT) Message-ID: <5507E916.4040307@sumptuouscapital.com> Date: Tue, 17 Mar 2015 09:43:02 +0100 From: Kristian Fiskerstrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christoph Anton Mitterer References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> In-Reply-To: <1426564752.18487.35.camel@scientia.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 17 Mar 2015 08:43:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/17/2015 04:59 AM, Christoph Anton Mitterer wrote: > Also to answer Werner's comment ("OpenPGP does not define the Web > of Trust. There is no standard for it.") > > On Fri, 2015-03-13 at 09:42 -0400, Derek Atkins wrote: >> This was explicitly out of scope from the former OpenPGP WG. I >> think that was a GOOD THING, and I believe it should remain out >> of scope. > I was probably a bit unclear in what I wrote. I've mainly meant: > The functionality of OpenPGP shouldn't be limited in such a way > that what we can do now with it (e.g. the web of trust, or trust > hierarchies via the trust signatures) would no longer be possible. > > Apart from that I basically agree that OpenPGP itself (i.e. the RFC > for the message format) shouldn't define a trust system (e.g. the > web of trust), BUT: a) it might(!) make sense for another RFC to do > this on an informal basis b) currently we have several things (well > at least the different levels of user signatures 0x10-0x13) which > are pretty much undefined, useless, ambiguous and therefore even > dangerous. 0x10 and 0x11 have at least some "proper" definition, > but they don't tell how implementations should react on them (=> > dangerous). 0x12 and 0x13 are quite vague and ambiguous. I fail to see how this behaviour is either dangerous, nor how it can be automated in a system with delegated certificate authorities. The signatures (except for 0x11) are treated the same by the implementations, which is fine. The information is still useful as metadata when performing manual analysis of a certification network and depends on a published certification policy by the issuer. The uses not being explicit in the RFC does not mean they are vague and ambiguous, just that they are defined on a per-context / per-CA basis, and the RFC allows provides a mechanism to distinguish , although most users should normally always use 0x10. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "History repeats itself; historians repeat each other" (Philip Guedalla) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVB+kSAAoJEP7VAChXwav6IMkIAIv0UMqyXAiGFq6/sNsC8auF 4luyWuwig1eatV6dkLovhIXVyD4hTERFCmEO3DwDu6O7Mg0MN888c4Obm+TXyWY5 4HSIqY7WvbFkOHt9qqmvVCf/JRRNzTRTz8ift2cpseiQGu8k0DsFqVMdXXG/QXUY Y2ze3mE6hcqqKVszZ4yD4h7hPo+zpdzDwMFilsM90et/z8AE39T3NwLpsONGqKZl xWTYlZ2CD+T+ZK6QpQ7cY+RWDRA3xKSijHlG4uGHooYSUPaq+EQqyT7SRs1gn5h9 EEabo1bzCfb/PliCiZNQpQ+Hh+KaMszflQ8HXIar0JKzYOQVB+B2v7bRfiDNTzQ= =MjpA -----END PGP SIGNATURE----- From nobody Tue Mar 17 04:21:34 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 ABD861A036C for ; Tue, 17 Mar 2015 04:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 6VZocCuglcOQ for ; Tue, 17 Mar 2015 04:21:22 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F361A0266 for ; Tue, 17 Mar 2015 04:21:22 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YXpYm-0004RE-Ri for ; Tue, 17 Mar 2015 12:21:20 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YXpVs-0001Gh-NT; Tue, 17 Mar 2015 12:18:20 +0100 From: Werner Koch To: David Shaw References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> 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: David Shaw , David Leon Gil , Stephen Paul Weber , "openpgp\@ietf.org" , gnupg-devel@gnupg.org, Jon Callas Date: Tue, 17 Mar 2015 12:18:20 +0100 In-Reply-To: (David Shaw's message of "Mon, 16 Mar 2015 17:30:55 -0400") Message-ID: <87zj7b3m9v.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: Stephen Paul Weber , gnupg-devel@gnupg.org, "openpgp@ietf.org" , Jon Callas , David Leon Gil Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 11:21:26 -0000 On Mon, 16 Mar 2015 22:30, dshaw@jabberwocky.com said: > A partial length is needed to handle content as a stream - say some program that generates gigabytes of data (like a backup). Something large enough that you really don't want to have to buffer the whole thing before encrypting it. And to support > 4GiB files on systems without LFS support. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Mar 17 04:41: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 A08DE1A0366 for ; Tue, 17 Mar 2015 04:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 UhEgGo_WhBXH for ; Tue, 17 Mar 2015 04:41:22 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9FE1A032D for ; Tue, 17 Mar 2015 04:41:22 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YXps8-0004cx-TU for ; Tue, 17 Mar 2015 12:41:20 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YXpmx-0001Jz-6R; Tue, 17 Mar 2015 12:35:59 +0100 From: Werner Koch To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFB37EF@uxcn10-5.UoA.auckland.ac.nz> 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 Date: Tue, 17 Mar 2015 12:35:59 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB37EF@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Tue, 17 Mar 2015 01:50:19 +0000") Message-ID: <87vbhz3lgg.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] The combinatorial complexity of OpenPGPv4 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, 17 Mar 2015 11:41:23 -0000 On Tue, 17 Mar 2015 02:50, pgut001@cs.auckland.ac.nz said: > The killer with PGP is keyrings, which are impossible to process in any kind > of nontrivial API (in other words a library) because there's no concept of > "single blob containing a key + name" as there is for X.509 certs. Instead, Better don't compare it to X.509. Think only of stripped down root certificates and the attribute certificates. How to decide which attribute to prioritize over another is also often not easy. But I don't have to tell you what's wrong with X.509. > found some X here, what shall I do now?". Similarly, storing these things in > something like a key/value store for fast lookup is nearly impossible because > you end up having a more or less open-ended number of index fields and cross- > references that need to be maintained. There are just N user ids and M fingerprints for each keyblock and one of these fingerprints identifies the entire keyblock. Why do you want any more indices (unless you keep on supporting v3 keys)? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Mar 17 04:47:17 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 1D7861A0366 for ; Tue, 17 Mar 2015 04:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 GbvSbObhVYbp for ; Tue, 17 Mar 2015 04:46:22 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF041A0372 for ; Tue, 17 Mar 2015 04:46:22 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YXpwy-0004gf-Ta for ; Tue, 17 Mar 2015 12:46:20 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YXpvU-0001LI-HR; Tue, 17 Mar 2015 12:44:48 +0100 From: Werner Koch To: David Leon Gil References: <87sid5si30.fsf@alice.fifthhorseman.net> <20150316171832.D0C81E0451@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 Date: Tue, 17 Mar 2015 12:44:48 +0100 In-Reply-To: (David Leon Gil's message of "Mon, 16 Mar 2015 14:09:58 -0700") Message-ID: <87r3sn3l1r.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" , "vedaal@nym.hush.com" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 17 Mar 2015 11:46:26 -0000 On Mon, 16 Mar 2015 22:09, coruus@gmail.com said: > CAST5 (CAST128), however, is a 128-bit blocksize cipher. Nope. CAST5-128 as used by OpenPGP is a 64 bit block size cipher. > Yes. GnuPG's use of CAST5 is problematic. We won't support this usage for Must be a pretty old version which defaults to CAST5. But what is problematic with CAST 5 given that it is one of the two SHOULD ciphers in OpenPGP? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Mar 17 05:53: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 097071A03A1 for ; Tue, 17 Mar 2015 05:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 5ESakmmGt3z9 for ; Tue, 17 Mar 2015 05:53:41 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 535481A00BE for ; Tue, 17 Mar 2015 05:53:41 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so6119360obd.3 for ; Tue, 17 Mar 2015 05:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Hqp3n7HIm3Eo5e/Qzej9ZTcDLiNNwFAD2Ns0kcInneo=; b=tqnVHZTUQsEG02HqpJubqb0Q1/qOpt/5qycTwyp5BSCOxJTA8KJyB2X1p2XOhBt46h RI87KBoygL9UmyzUP1tYf6YMyrYd5R2taw1QARHIL3slEL2lrIbnlf7SVoz8qiv51Wil DqcOFSOaeP3f0K0yNRP3yPSVFzmloRADEsRaFWmcv5gebofRKRr7GYtFBOPRiFvJiM3v Zn3M7RrlZFdrM1OT8I8QdIsFQq92YsRvn0SLGyC6fnsOZlqUXXSXfJ2b2xjfr2+wsMfD jFmSkl+l+Pvld9aBWs4pnbaKvFAn5uo4JX1alUO7TbGidoBbmwzs725VrLPYxIZ5EN0v jalQ== X-Received: by 10.60.63.39 with SMTP id d7mr33265844oes.72.1426596820764; Tue, 17 Mar 2015 05:53:40 -0700 (PDT) MIME-Version: 1.0 References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: From: Wyllys Ingersoll Date: Tue, 17 Mar 2015 12:53:39 +0000 Message-ID: To: Tim Bray , Peter Gutmann Content-Type: multipart/alternative; boundary=001a11c21ff0bd4ec605117b74e9 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 12:53:43 -0000 --001a11c21ff0bd4ec605117b74e9 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 3:03 AM Tim Bray wrote: > I have repeatedly found it useful, even in recent times, to cut/paste > ASCII-armored messages on my mobile. Am I a Neanderthal? > No! This was exactly my first thought also. ASCII Armor format is extremely useful for passing the messages from app-to-app via the system clipboard using copy-and-paste. As a mobile PGP developer, there are situations where this is the most convenient way to move the PGP message/key from a non-PGP enabled app (like most standard mobile mail clients) and into an app that can decode/decrypt it correctly. If ASCII Armor is to be deprecated, I would hope that we at least replace it with something else that can be easily copied-and-pasted. --001a11c21ff0bd4ec605117b74e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at= 3:03 AM Tim Bray <tbray@textual= ity.com> wrote:

I h= ave repeatedly found it useful, even in recent times, to cut/paste ASCII-ar= mored messages on my mobile. Am I a Neanderthal?


<= /div>
No!=C2=A0 This was exactly my first thought also. ASCII Armor for= mat is extremely useful for passing the messages from app-to-app via the sy= stem clipboard using copy-and-paste.=C2=A0 As a mobile PGP developer, there= are situations where this is the most convenient way to move the PGP messa= ge/key from a non-PGP enabled app (like most standard mobile mail clients) = and into an app that can decode/decrypt it correctly.=C2=A0

<= /div>
If ASCII Armor is to be deprecated, I would hope that we at least= replace it with something else that can be easily copied-and-pasted.
=



--001a11c21ff0bd4ec605117b74e9-- From nobody Tue Mar 17 06:41:50 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 BBE3C1A03A8 for ; Tue, 17 Mar 2015 06:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwRKTP6zHTkx for ; Tue, 17 Mar 2015 06:41:46 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 774241A00BE for ; Tue, 17 Mar 2015 06:41:46 -0700 (PDT) Received: by wibg7 with SMTP id g7so63595109wib.1 for ; Tue, 17 Mar 2015 06:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BqpPNlio5SPmp11H2vP74T3Yv1uFjnx/ey7rj+SIUQY=; b=wXwmpM+FMWKDNk4XqMo3RtNIRfAF5l6oKSHqM9b9CaxplVemecXPc5Ms3kqbt8SdDU 3NSNj5l6m7lmPd5ZO4V9GldpNOmJh5Xaoo2/qENCVfYgBVu9gPEAg5UhGLyy8q6i9e5u ZXd+eJlOclP2BUBH9JleoY+DCFTJnlJHUDpLHDEO7k9d6ZjE3fn7IWIx3bQjGtgeQLLN 03LICJFiC0wtCF/lJ6Adr8bi+srr4NWXATOJVvoEWjEbYxCrSxmnympbShZdLyhHp8Ly tIFGrIa7DE+3+or94VXfYPOjqUvUotT6hukgk+kx9Wi7CQqgRzKF2xibPoyNWSVPn5TI tccg== MIME-Version: 1.0 X-Received: by 10.194.222.197 with SMTP id qo5mr130575048wjc.142.1426599705267; Tue, 17 Mar 2015 06:41:45 -0700 (PDT) Received: by 10.194.162.6 with HTTP; Tue, 17 Mar 2015 06:41:45 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 17 Mar 2015 13:41:45 +0000 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 13:41:47 -0000 On Tue, Mar 17, 2015 at 12:53 PM, Wyllys Ingersoll wrote: > > > On Tue, Mar 17, 2015 at 3:03 AM Tim Bray wrote: >> >> I have repeatedly found it useful, even in recent times, to cut/paste >> ASCII-armored messages on my mobile. Am I a Neanderthal? > > > No! This was exactly my first thought also. ASCII Armor format is extremely > useful for passing the messages from app-to-app via the system clipboard > using copy-and-paste. As a mobile PGP developer, there are situations where > this is the most convenient way to move the PGP message/key from a non-PGP > enabled app (like most standard mobile mail clients) and into an app that > can decode/decrypt it correctly. > > If ASCII Armor is to be deprecated, I would hope that we at least replace it > with something else that can be easily copied-and-pasted. I do hope (more generally) that this new spec does not seek change for change's sake. Things that are (or are likely to be) a security flaw should be corrected, and some things that make the spec hard to implement should be streamlined. Features that are no longer used should be removed. That's all. From nobody Tue Mar 17 07:30:20 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 49D621A1AA1 for ; Tue, 17 Mar 2015 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9-CMzRY-R9o for ; Tue, 17 Mar 2015 07:30:18 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (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 EE8F11A1A9B for ; Tue, 17 Mar 2015 07:30:17 -0700 (PDT) Received: by qcto4 with SMTP id o4so9724254qct.3 for ; Tue, 17 Mar 2015 07:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A1vQV/ILalSgwtUvQsXLdGTrX+FzqamOOgufVxzDdgQ=; b=M3+XixBkTbiBWdM9VRIbznbdJnNZ7X2yvwFWvt1Mbeyx+593mdL1XjnC2uVTyoqS7D VbpPcUxJK9oXW0NNL6BO54M2o2PS6SdFG7neknISOIOlyqkdmEIhGZ5BQJ8UlkgtqkWP rlib4Ilp2NQDB+LxHK1FJ3x6pe3qcWCCgPcheJpLyfgdru9KSuA9V9CkRJXm3lHIEjPs xN7EgmEV+znH/6QBb/xMCgb/M7Wtt3LV8ucKy6kPhq7pgC/J0vcMr/krW1/QpLiDdgkD Yf0wbMt1qVn+X0pcBPc+x8Lod6qyRhCJ16WBQ1H8Kv+VVp2aat3GslsViI4oapVv6yGv ik8A== X-Received: by 10.140.98.227 with SMTP id o90mr80773280qge.96.1426602617063; Tue, 17 Mar 2015 07:30:17 -0700 (PDT) Received: from [192.168.1.29] (pool-71-174-213-210.bstnma.fios.verizon.net. [71.174.213.210]) by mx.google.com with ESMTPSA id 23sm9680650qkr.41.2015.03.17.07.30.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 07:30:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phill In-Reply-To: <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> Date: Tue, 17 Mar 2015 10:30:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> To: David Shaw X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 14:30:19 -0000 > On Mar 16, 2015, at 11:05 PM, David Shaw = wrote: >=20 > On Mar 16, 2015, at 10:10 PM, Peter Gutmann = wrote: >>=20 >> David Shaw writes: >>> On Mar 16, 2015, at 5:15 PM, David Leon Gil = wrote: >>>> Partial lengths are really a nuisance to parse. >>>=20 >>> No argument there... >>=20 >> The whole bizarro sort-of-fixed-point encoding of lengths is a pain = (this is a >> cue for Jon to do his "every bit is sacred" dance). If the format is = revised, >> there should be only two lengths, a 16-bit one for almost everything = (keyring >> data, signatures, etc), and a 32-bit one for payloads and partial = lengths that >> are going to exceed 16-bit lengths. Length-decoding shouldn't be any = more >> complicated than: >>=20 >> read tag; >> if( tag & length_32_flag ) >> length =3D read32(); >> else >> length =3D read16(); >=20 > I'm fine with that, but I do want to keep the concept of partial = lengths, as you did above. People do encrypt things without knowing how = large they are ahead of time. I'm fine with a restriction (which = already exists today) that only payloads can use partial lengths. >=20 +1=20 But that 32 bit length really worries me. Just because people can=E2=80=99= t send 4GB messages today does not mean that they can=E2=80=99t or = won=E2=80=99t in the future. Do not build OpenPGP around assumptions = based on SMTP continuing forever. Use today is not limited to mail in = any case. If I have a 1TB archive file I am not going to want to break it into = chunks just to encrypt it. I am not convinced a complete overhaul of the messaging format is = desirable. But if people were going to completely revise the message = format, the field is moving towards JSON for almost everything. The only thing JSON does not do that is essential for crypto is length = prefixed binary encoding of binary blobs. Base64 encoding is not so bad = if you do it only once. But a 33% penalty for each time a file is = wrapped starts to add up. When folk were suggesting yet another data = encoding, several of us who only want one data model suggested just = adding code points for binary blobs to JSON. It does get the job done. Again, I am not sure that a complete overhaul is desirable. Just pruning = back the unnecessary features is probably sufficient. But if a change is = made, best to pick something that looks as much like the standard the = rest of the protocol stack above layer 5 is converging on as possible. From nobody Tue Mar 17 08:04: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 A9FD71A1B39 for ; Tue, 17 Mar 2015 08:04:55 -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 j71-Eq_LXEXR for ; Tue, 17 Mar 2015 08:04:54 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FE21A1B28 for ; Tue, 17 Mar 2015 08:04:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 9EEA8E2048; Tue, 17 Mar 2015 11:04:52 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 03865-05; Tue, 17 Mar 2015 11:04:50 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C013CE2039; Tue, 17 Mar 2015 11:04:50 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2HF4kgi025909; Tue, 17 Mar 2015 11:04:46 -0400 From: Derek Atkins To: Bill Frantz References: Date: Tue, 17 Mar 2015 11:04:46 -0400 In-Reply-To: (Bill Frantz's message of "Mon, 16 Mar 2015 09:35:55 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: dgil@yahoo-inc.com, Werner Koch , openpgp@ietf.org, David Leon Gil Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 17 Mar 2015 15:04:55 -0000 Bill Frantz writes: > On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote: > >>Oh, you expected me to decrypt/re-encrypt my encrypted email as I got it??? > > For many uses, decrypting from the wire format and re-encrypting in > the "data at rest" security format makes excellent sense. Having only > one encryption scheme for long-term storage allows easy (relatively) > upgrade and helps to ensure that the data is still accessible, > i.e. the decryption still works. I probably have a bunch of old PGP > encrypted email I can't read anymore because I don't have the secret > key, or its passphrase. If that mail had been re-encrypted in a format > that I decrypt every day, I would still be able to read the > mail. Encryption that isn't regularly exercised gets rusty. Show me an MUA that does this, please? None of the OpenPGP-aware MUAs I've ever used have this feature, as far as I know. I suppose I could go out of my way to replace the encrypted email with a re-encrypted/plaintext email. But frankly I'd like my encryption software to just maintain the ability to decrypt it later. > Cheers - Bill -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Tue Mar 17 08:11:13 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 F2A161A1BAA for ; Tue, 17 Mar 2015 08:11:11 -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 94WkJFEIip_1 for ; Tue, 17 Mar 2015 08:11:10 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F461A1BAF for ; Tue, 17 Mar 2015 08:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D15CAE2048; Tue, 17 Mar 2015 11:11:08 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 03865-06; Tue, 17 Mar 2015 11:11:06 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D98AFE2039; Tue, 17 Mar 2015 11:11:05 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2HFB4pw026403; Tue, 17 Mar 2015 11:11:04 -0400 From: Derek Atkins To: David Shaw References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> Date: Tue, 17 Mar 2015 11:11:04 -0400 In-Reply-To: (David Shaw's message of "Mon, 16 Mar 2015 17:30:55 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" , Jon Callas , gnupg-devel@gnupg.org, Stephen Paul Weber , Werner Koch , David Leon Gil Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:11:12 -0000 David Shaw writes: > Not in the current code, but you can of course patch it. > >> Relatedly, is there any option to not use new-format partial lengths? > > A partial length is needed to handle content as a stream - say some > program that generates gigabytes of data (like a backup). Something > large enough that you really don't want to have to buffer the whole > thing before encrypting it. This is exactly what it was created for, when you cannot know the size ahead of time. Sometimes you *can* know the size, even for large objects (e.g. you could stat() the file to get the filesize), but obviously that doesn't work in all cases. >> Partial lengths are really a nuisance to parse. > > No argument there... I'm sorry. I blame Colin for trying to be too clever, and me not working hard enough to talk him out of it. ;) > David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Tue Mar 17 08:13:59 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 D0B671A1BC8 for ; Tue, 17 Mar 2015 08:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 uyqgVuHEeudA for ; Tue, 17 Mar 2015 08:13:57 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id C95E81A1B46 for ; Tue, 17 Mar 2015 08:13:57 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 9264AF210D; Tue, 17 Mar 2015 15:13:56 +0000 (UTC) Date: Tue, 17 Mar 2015 10:13:55 -0500 From: Stephen Paul Weber To: Peter Gutmann Message-ID: <20150317151355.GC2983@singpolyma-liberty> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:13:59 -0000 >It's not just the checksum, the entire ASCII armoring should have been >discarded years, no decades, ago. Maybe. I mostly just think it could be relegated to a seperate RFC that's just refereced from the main one as optional. -- Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph From nobody Tue Mar 17 08:15:14 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 2652E1A1B46 for ; Tue, 17 Mar 2015 08:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 4oMimNjIyRf9 for ; Tue, 17 Mar 2015 08:15:12 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id DAAE31A1BC6 for ; Tue, 17 Mar 2015 08:15:11 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 61ED0F210D; Tue, 17 Mar 2015 15:15:11 +0000 (UTC) Date: Tue, 17 Mar 2015 10:15:10 -0500 From: Stephen Paul Weber To: Wyllys Ingersoll Message-ID: <20150317151510.GD2983@singpolyma-liberty> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline In-Reply-To: Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: openpgp@ietf.org, Tim Bray , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:15:13 -0000 --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >If ASCII Armor is to be deprecated, I would hope that we at least replace >it with something else that can be easily copied-and-pasted. I don't think it needs to be deprecated, but certainly not all=20 implementations / uses of OpenPGP in various applications need to support= =20 it, or even know about it. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVCET+AAoJENEcKRHOUZze/i0P/RjPB39KVldtYW4IRWzOXsWF mthWAQvXM4JfWsUo5Ll/Y0efwtW96EfkPh3oVWrmbFjTLsY8jls1aO56EUDeZHsz lWotqL9Nqy+SpF262jn5HfcoYO8FpDOa4EKvAOsTcr5i2gMIO4IC4y0ATVk8OBIZ 8cbKhwey6r8G6tM7rtRCwVYqZyAFJt6Wbz2zVQ4zKo+wTrsD/Ro46qcsaqWBOTBu AA2XZxAB/deVbhEkMyOLrQetvpSprEJEsfQ3SL92sMtt2OMFyLqsa3eJ6kEgF5At f744HlfAHMF7N6twnSXzbvTFYJe9ibC55PFRfz25j9OP7zTIZUVKfR8MfuJjMC+e VmOZsvDivAN4HfkI4TJQHQf0edvqeJpw7febbyNi7v+ImbHBtpcgjkq8uEPIJ7Uj My7HUGTkhhVgXWeZDMfIhCPYOvI+v3E7DYc1Bq8Ecsu+h2xzqOUOdsL+Z2Fndl2Q d66K4NNj5u79urz+9QRniRLWjZ826VWZmW07SPwwB7coLgnwJX3JoRz8BdEPX+aw ZZ/Dwvu9Ct18yRrHdadf+3YOa2k99LBD6/Bupc82URmvlcAuPyM4mXj3XERzrBe6 rlLQm9mpWBl2yM2+hkiPCSmyZk6Tca2iDpAgBOldm+vy74J1EzvFEmv6G89L7lrl MNP4pLzCqqG/1Zty7dIa =3mTP -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- From nobody Tue Mar 17 08:21:24 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 0E38C1A1EEA for ; Tue, 17 Mar 2015 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 OyeMTckmlw5A for ; Tue, 17 Mar 2015 08:21:15 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id E89D41A1BE7 for ; Tue, 17 Mar 2015 08:21:14 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id A47B6F210D; Tue, 17 Mar 2015 15:21:14 +0000 (UTC) Date: Tue, 17 Mar 2015 10:21:13 -0500 From: Stephen Paul Weber To: Phill Message-ID: <20150317152113.GE2983@singpolyma-liberty> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline In-Reply-To: Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: David Shaw , "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:21:22 -0000 --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >I am not convinced a complete overhaul of the messaging format is=20 >desirable. I agree. >the field is moving towards JSON for almost everything. *shudders* >Again, I am not sure that a complete overhaul is desirable. Just pruning= =20 >back the unnecessary features is probably sufficient. Yes. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVCEZpAAoJENEcKRHOUZzej9EQAMI4NlQN+mU0Z9eAknLdbzyf 7P450kHDRduV8x0xkcAkbjg7K/uoq3ojj81JYZ9RFzzIrUqjR3K2tI8A9Z9lJIeh kNLakQAVNtsGrLgpIqztVJalpiCx/xttOvUeLVi5hb+ZxqF+U3ivT6e270VBJ9f/ Nsj7p54z/CtlVBCzS0pBN0ltrNCgHVOtZkUR34ZSeN2zsEpXAiZ2yP3UB0ufBiAQ io/v1JmvBFUsUSbT76ojfC87BgTdKjq5d/kZwRIQ1ZTNp0hPJeXTXRi2fXE4BtHP yWYreVBQfz5iE1SU3xhLRogqB9bGfSk5f3of2pLMLYYH7sTWblpLjYeuwT9Dn0xB zqSc3RImpBVv25zD/zMxffydbz3c+LjB2nQk8czqjS314QVK7m/WLAW/6wTPqMt1 6mIJE+ZXw28QRRSMkZUStbEiVYOQgU9ISWjnBfCntCCm+kDpwq9fbJLtMHkmAz7n LHLCC6/hxsuwRSXr6YcptociZI90x8lEU3nnACz8/eIfE/3dqvuNILHSbVXjF4Zu a8ebYBYcRMuVa/mOLiO+AnTir/He8KuOYE6If+r/qNxkNl65pzRYfk1xzoYFU8Lc mekiM7c8fNmlk9Zp6+mHlmsEgB1f5u8sr71mSfNf87N05DljAZb+lNPtWRhy1lgf xk4Uxv3BXw+9pddimEQi =irxD -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From nobody Tue Mar 17 08:24:14 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 285621A1EF7 for ; Tue, 17 Mar 2015 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 ZMS82FsFdE5x for ; Tue, 17 Mar 2015 08:24:11 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 71EC11A1C06 for ; Tue, 17 Mar 2015 08:24:11 -0700 (PDT) Received: by oibu204 with SMTP id u204so11204278oib.0 for ; Tue, 17 Mar 2015 08:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=OHEO284aK4tGqmjBQ5CVxPFjPcYtACGV1RKHTdsYSvw=; b=PNlrq3lHTm6/IFP9GMpbqH2LPjx06WJOlB+MJrJ5BOE5/kwNlo6aG9EQvgb1BWAaHz AjTWMm+BqhzJuNPJpsO84G9xsyi62KwzSMfJCgjDO/psfqo2GS7sZ/cD0MEXf7wF+Uc6 5GQss/vaBJ4Kmlrf+fJpcRDogJLKeupfojoALhPT/Cvt23tPeMDK3YKcR2jaQo5wzN5H 2HdvOi3F9dy73S35SnHdCeTtJzEyFGKMAcQuUqAXdeZUQAV9iN3/Xrb2WPh3NyFzXspu GWUSnLlBzN073Ilc3cNPQ/mal5L03d7qGHSMrrvPk7nDak20BEYucGkQYmNMU0g+Ay+E muPQ== X-Received: by 10.202.196.135 with SMTP id u129mr9893261oif.69.1426605850865; Tue, 17 Mar 2015 08:24:10 -0700 (PDT) MIME-Version: 1.0 References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> <20150317151510.GD2983@singpolyma-liberty> In-Reply-To: <20150317151510.GD2983@singpolyma-liberty> From: Wyllys Ingersoll Date: Tue, 17 Mar 2015 15:24:10 +0000 Message-ID: To: Stephen Paul Weber Content-Type: multipart/alternative; boundary=001a113e2bb8f9b61a05117d8ef4 Archived-At: Cc: openpgp@ietf.org, Tim Bray , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:24:13 -0000 --001a113e2bb8f9b61a05117d8ef4 Content-Type: text/plain; charset=UTF-8 Agree. Perhaps there could multiple optional-to-implement formats - ASCII Armor, JSON, pure base64, XML (*ugh*), etc - each specified separately. 4880 section 6 has a very detailed description of the ASCII format - should that be pulled out into a separate document and just referenced in the core spec? On Tue, Mar 17, 2015 at 11:15 AM Stephen Paul Weber < singpolyma@singpolyma.net> wrote: > >If ASCII Armor is to be deprecated, I would hope that we at least replace > >it with something else that can be easily copied-and-pasted. > > I don't think it needs to be deprecated, but certainly not all > implementations / uses of OpenPGP in various applications need to support > it, or even know about it. > > -- > Stephen Paul Weber, @singpolyma > See for how I prefer to be contacted > edition right joseph > --001a113e2bb8f9b61a05117d8ef4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Agree.=C2=A0 Perhaps there could multiple optional-to-= implement formats - ASCII Armor, JSON, pure base64, XML (*ugh*), etc - each= specified separately.

4880 section 6 has a very detaile= d description of the ASCII format - should that be pulled out into a separa= te document and just referenced in the core spec?

=


On= Tue, Mar 17, 2015 at 11:15 AM Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
>If ASCII Armor is to be deprecated, I would hop= e that we at least replace
>it with something else that can be easily copied-and-pasted.

I don't think it needs to be deprecated, but certainly not all
implementations / uses of OpenPGP in various applications need to support it, or even know about it.

--
Stephen Paul Weber, @singpolyma
See <http://singpoly= ma.net> for how I prefer to be contacted
edition right joseph
--001a113e2bb8f9b61a05117d8ef4-- From nobody Tue Mar 17 08:27:40 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 4FDD01A1BF3 for ; Tue, 17 Mar 2015 08:27:38 -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 d5Ux_aFPw1as for ; Tue, 17 Mar 2015 08:27:36 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE081A1B8B for ; Tue, 17 Mar 2015 08:27:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3E1EBE2039; Tue, 17 Mar 2015 11:27:35 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04074-01; Tue, 17 Mar 2015 11:27:32 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5F31FE2038; Tue, 17 Mar 2015 11:27:32 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2HFRTgm027284; Tue, 17 Mar 2015 11:27:29 -0400 From: Derek Atkins To: David Leon Gil References: <55038CBE.7070608@iridiumlinux.org> <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 17 Mar 2015 11:27:29 -0400 In-Reply-To: (David Leon Gil's message of "Mon, 16 Mar 2015 14:58:08 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: David Gil , "openpgp@ietf.org" , Falcon Darkstar Momot Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 17 Mar 2015 15:27:38 -0000 David Leon Gil writes: > On Monday, March 16, 2015, Derek Atkins wrote: [snip] > Having implemented it myself, I disagree completely.=C2=A0 It is abso= lutely > possible to create a modular implementation.=C2=A0 See my Usenix Secu= rity > Talk on the PGP Message Processing Pipeline from.... 1996?? > > Well, first: You're Derek Atkins. Not everyone is as good of a coder. *blush* > Second: It is=C2=A0hard to *prove* modularity, because of how complicated= the > semantics are. (I have been trying, off-and-on, using Frama-C, for a whil= e.) Yes, the structure is complicated (my parser state machine had something like 150-200 states). But the processing itself is completely modular. You just need concepts like split and join along the pipeline to handle it. Proof by existance? > [snip] > >> Protocol modularity is not evil. > > > > Modularity is neutral. "Agility", as folks like to call it, is evil. >=20=20=20=20 > Well, it's a damn good thing we've had agility otherwise we'd have be= en > stuck with 3DES, SHA1 (or MD5!!), and probably either RSA or maybe > DSA/Elgamal. > > No: The reason there hasn't been any urgency to fix things like the CFB m= ode > problems, or the MDC, is that the current=C2=A0standard is too flexible. I don't agree with this statement. It wasn't flexibility that stopped changing CFB, it was that CTR mode was relatively new when the group was working on 4880 (I'm not sure it even existed when we did 2440). And compatibility was always (generally) paramount. I.e., if it ain't completely broke let's not fix it.. and where it is broke, let's fix it in the most compatible way. Were I do start from scratch today then yes, I'd just use GCM. We could certainly add a GCM mode and a preference to specify support for it. But for interop I don't think we could drop CFB support completely from implementations. I'll also point out that CFB vs "something else" (i.e., "mode agility") is completely orthogonal to algorithm agility. OpenPGP does NOT have decent mode agility; we would need to add a new packet type for that. > I hate to use TLS as an exemplar of anything, but they have done a much b= etter > job in this regard recently. > > Where it is easy to provide flexibility, it is rarely useful. Where it is > useful, it is rarely feasible to=C2=A0provide. (E.g., a parameter to choo= se=C2=A0SIV, > encrypt-then-MAC, or robust AE.) It's easy to add it if you think about it ahead of time (and put in the parameterization). It's harder to add it after-the-fact. This is true in both TLS and OpenPGP. -derek --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Tue Mar 17 08:33:11 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 4A4E01A1C06 for ; Tue, 17 Mar 2015 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 VUctFI6K1c05 for ; Tue, 17 Mar 2015 08:33:10 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B2A1A1F04 for ; Tue, 17 Mar 2015 08:33:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A8BE1E2039; Tue, 17 Mar 2015 11:33:06 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04074-03; Tue, 17 Mar 2015 11:33:03 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id A26B0E2038; Tue, 17 Mar 2015 11:33:03 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2HFX2WK027709; Tue, 17 Mar 2015 11:33:02 -0400 From: Derek Atkins To: Phill References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> Date: Tue, 17 Mar 2015 11:33:02 -0400 In-Reply-To: (Phill's message of "Tue, 17 Mar 2015 10:30:00 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: David Shaw , "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:33:11 -0000 Phill writes: > But that 32 bit length really worries me. Just because people can=E2=80= =99t > send 4GB messages today does not mean that they can=E2=80=99t or won=E2= =80=99t in the > future. Do not build OpenPGP around assumptions based on SMTP > continuing forever. Use today is not limited to mail in any case. > > If I have a 1TB archive file I am not going to want to break it into > chunks just to encrypt it. That's what partial (indefinite) lengths are for. But the point is that each "size" parameter is 32 bits, always, instead of having a 1, 2, or 5-byte length parameter. [snip] > Again, I am not sure that a complete overhaul is desirable. Just > pruning back the unnecessary features is probably sufficient.=20 +1 -derek --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Tue Mar 17 08:34:57 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 7FC4A1A3BA0 for ; Tue, 17 Mar 2015 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 Cn3jiFZUJkfj for ; Tue, 17 Mar 2015 08:34:55 -0700 (PDT) Received: from mail.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EB71A6F20 for ; Tue, 17 Mar 2015 08:34:54 -0700 (PDT) Received: from dshaw.nasuni.net (50-202-126-134-static.hfc.comcastbusiness.net [50.202.126.134]) (authenticated bits=0) by mail.jabberwocky.com (8.14.4/8.14.4) with ESMTP id t2HFENKA005912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2015 11:14:23 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: David Shaw In-Reply-To: <87zj7b3m9v.fsf@vigenere.g10code.de> Date: Tue, 17 Mar 2015 11:34:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3A820350-6B24-4735-965A-7D8265578BAC@jabberwocky.com> References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> <87zj7b3m9v.fsf@vigenere.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Stephen Paul Weber , gnupg-devel@gnupg.org, "openpgp@ietf.org" , Jon Callas , David Leon Gil Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:34:56 -0000 On Mar 17, 2015, at 7:18 AM, Werner Koch wrote: >=20 > On Mon, 16 Mar 2015 22:30, dshaw@jabberwocky.com said: >=20 >> A partial length is needed to handle content as a stream - say some = program that generates gigabytes of data (like a backup). Something = large enough that you really don't want to have to buffer the whole = thing before encrypting it. >=20 > And to support > 4GiB files on systems without LFS support. Right, good point. I think it's safe to say there are enough uses for = partial length / streaming that it should be kept. Not all the world is = email. What if the encoding was really simple - something like 4 bytes always, = and the leftmost bit would mean "partial". So any packet 2^31 or less = could be encoded in one piece, but we could still do partial for those = situations that needed it. We could have any number of partial lengths, = but it would always end with a non-partial final length. David From nobody Tue Mar 17 08:35:15 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 C60141A1BF5 for ; Tue, 17 Mar 2015 08:35:13 -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 wSc0MxCzRwDU for ; Tue, 17 Mar 2015 08:35:12 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CFA11A6F7B for ; Tue, 17 Mar 2015 08:35:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 25770E2039; Tue, 17 Mar 2015 11:35:05 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04074-05; Tue, 17 Mar 2015 11:35:03 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 65CE5E2038; Tue, 17 Mar 2015 11:35:03 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2HFZ2rm027853; Tue, 17 Mar 2015 11:35:02 -0400 From: Derek Atkins To: Wyllys Ingersoll References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> <20150317151510.GD2983@singpolyma-liberty> Date: Tue, 17 Mar 2015 11:35:02 -0400 In-Reply-To: (Wyllys Ingersoll's message of "Tue, 17 Mar 2015 15:24:10 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Stephen Paul Weber , openpgp@ietf.org, Tim Bray , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:35:13 -0000 Wyllys Ingersoll writes: > Agree.=C2=A0 Perhaps there could multiple optional-to-implement formats -= ASCII > Armor, JSON, pure base64, XML (*ugh*), etc - each specified separately. > > 4880 section 6 has a very detailed description of the ASCII format - shou= ld > that be pulled out into a separate document and just referenced in the co= re > spec? It could, but that actually *adds* complexity instead of reducing it. IMHO it's much nicer, from an implementation point of view, to have everything in one document instead of having to go off and reference a dozen or more documents. If you don't want to implement section 6 in your implementation then just skip section 6. -derek --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Tue Mar 17 08:38:39 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 096351A6EF9 for ; Tue, 17 Mar 2015 08:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 v6omt0-SSW8P for ; Tue, 17 Mar 2015 08:38:33 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 CD2A41A1C06 for ; Tue, 17 Mar 2015 08:38:32 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so10158012obd.3 for ; Tue, 17 Mar 2015 08:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=g3QOrZYOak8nwn+dJdy8XUsq3Y+tjESe9gqGTCLA6bk=; b=JYv35tys5GOhUozjKuA6KXnroj+PG/+k0h2Q1cnauo1KpaB8ZI4LDPMbsdAn1rYV4R YZ/JzbQRQCnsikcQmgus/43lRHJ5FuwjtyWBm2fVXL1I6iZE4fSaFDetfr/AGAoRFcld wWqz5/mDyoKmwxkE+//QTCdlzqNZW3yDVYVHZ8CwNwoY11VdeUsUC/j6z8BLus/2mUW4 JrUn6VhLy7bwyyHoLVL1NMbvkXzgQggggh1r82LUDaQjQISpLiAlTXJ2hg2ggw4EwCfc wIveGlzhCWcOC99ktYQN6u0EQbMbwEMdXgA6NSc6u1yrZd017qojoKorGuNONtOGM+tp 6pcQ== X-Received: by 10.202.196.135 with SMTP id u129mr9977553oif.69.1426606712232; Tue, 17 Mar 2015 08:38:32 -0700 (PDT) MIME-Version: 1.0 From: Wyllys Ingersoll Date: Tue, 17 Mar 2015 15:38:31 +0000 Message-ID: To: "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=001a113e2bb851205105117dc21e Archived-At: Subject: [openpgp] Character encodings 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, 17 Mar 2015 15:38:38 -0000 --001a113e2bb851205105117dc21e Content-Type: text/plain; charset=UTF-8 One area that I think needs some attention is the character encoding and charsets for encrypted text messages. 4880 says that everything should be UTF-8. However, the reality is that UTF8 is not used everywhere and there are lots of clients that compose messages in their native preferred character set (Latin5, Greek, Kanji, etc) and its very difficult as an implementor to figure it out after the fact without some indication from the sender. The literal packet format only specifies 3 possible values - binary, UTF8, or plain. The ASCII Armor header may specify a different charset (though unfortunately very few agents add the "Charset" PGP header). Additionally, if the message had MIME headers, there may be yet another charset indicated in MIME that differs from the ASCII Armor charset and the literal packet data format byte. If the encrypting PGP software knows what character encoding was used to compose the original message, there should be some way to communicate this in the message that would be definitive so that the decrypting software can present it the way it was originally intended. As an implementor, this is one of the trickiest areas to get right so that the end user sees the messages as it was originally intended. --001a113e2bb851205105117dc21e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One area that I think needs some attention is the characte= r encoding and charsets for encrypted text messages.

488= 0 says that everything should be UTF-8.=C2=A0 However, the reality is that = UTF8 is not used everywhere and there are lots of clients that compose mess= ages in their native preferred character set (Latin5, Greek, Kanji, etc) an= d its very difficult as an implementor to figure it out after the fact with= out some indication from the sender.

The literal p= acket format only specifies 3 possible values - binary, UTF8, or plain.=C2= =A0 The ASCII Armor header may specify a different charset (though unfortun= ately very few agents add the "Charset" PGP header). =C2=A0 Addit= ionally, if the message had MIME headers, there may be yet another charset = indicated in MIME that differs from the ASCII Armor charset and the literal= packet data format byte.

If the encrypting PGP so= ftware knows what character encoding was used to compose the original messa= ge, there should be some way to communicate this in the message that would = be definitive so that the decrypting software can present it the way it was= originally intended.=C2=A0 As an implementor, this is one of the trickiest= areas to get right so that the end user sees the messages as it was origin= ally intended.




<= /div>

--001a113e2bb851205105117dc21e-- From nobody Tue Mar 17 08:41:05 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 630CD1A6FCB for ; Tue, 17 Mar 2015 08:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 rfWcsNjaYPmA for ; Tue, 17 Mar 2015 08:41:03 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 F015D1A6F22 for ; Tue, 17 Mar 2015 08:41:02 -0700 (PDT) Received: by oier21 with SMTP id r21so11695542oie.1 for ; Tue, 17 Mar 2015 08:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=ZkPlB4F7E4xl5/nSghncvzuX0gOIsDTF37YgSsUVWOU=; b=Lr9J9mPI9rkjL0ARPf0ggLKbWk770TlybgkjyYZOU6ad2oAZqObBx5Rv0sJSPQmePK zAQSxpl7Vf1oJAtRw41qeNu5uz0MdBk+M8mVbHg1NjBxZ6PMd+3+bTrDCSDfziDznFl4 EV4WgrYoM5opnpzivrRjpnJ8z5dZxszIiDdVtjYnPeB7OUvvV9U0IMdYzZdQ/HDreqEj +fc40xgUe2r7AmkLPIJx0t+aT6lAoBF5U0Gsvbg4NN3KhrqcsN46SxlNyLLKqagEaGOM XX7pvdBO0UuH+A3ziQMxCJPTaweGQlUQzA/tLDyXH+mMvuqlsYqIyGHbTIF2CDbs2pc7 6TSQ== X-Received: by 10.60.63.39 with SMTP id d7mr34269199oes.72.1426606862545; Tue, 17 Mar 2015 08:41:02 -0700 (PDT) MIME-Version: 1.0 References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> <20150317151510.GD2983@singpolyma-liberty> In-Reply-To: From: Wyllys Ingersoll Date: Tue, 17 Mar 2015 15:41:02 +0000 Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c21ff046bbbd05117dcb97 Archived-At: Cc: Stephen Paul Weber , openpgp@ietf.org, Tim Bray , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:41:04 -0000 --001a11c21ff046bbbd05117dcb97 Content-Type: text/plain; charset=UTF-8 Im fine with leaving it in since it is the most commonly used format. As you say, it isnt mandatory anyway. On Tue, Mar 17, 2015 at 11:35 AM Derek Atkins wrote: > Wyllys Ingersoll writes: > > > Agree. Perhaps there could multiple optional-to-implement formats - > ASCII > > Armor, JSON, pure base64, XML (*ugh*), etc - each specified separately. > > > > 4880 section 6 has a very detailed description of the ASCII format - > should > > that be pulled out into a separate document and just referenced in the > core > > spec? > > It could, but that actually *adds* complexity instead of reducing it. > > IMHO it's much nicer, from an implementation point of view, to have > everything in one document instead of having to go off and reference a > dozen or more documents. > > If you don't want to implement section 6 in your implementation then > just skip section 6. > > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > --001a11c21ff046bbbd05117dcb97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Im fine with leaving it in since it is the most commonly u= sed format.=C2=A0 As you say, it isnt mandatory anyway.


On Tue, Mar 17, 2015 at 11:35 AM Derek Atkins <= warlord@mit.edu> wrote:
Wyllys Ingersoll <wyllys@gmail.com> writes:

> Agree.=C2=A0 Perhaps there could multiple optional-to-implement format= s - ASCII
> Armor, JSON, pure base64, XML (*ugh*), etc - each specified separately= .
>
> 4880 section 6 has a very detailed description of the ASCII format - s= hould
> that be pulled out into a separate document and just referenced in the= core
> spec?

It could, but that actually *adds* complexity instead of reducing it.

IMHO it's much nicer, from an implementation point of view, to have
everything in one document instead of having to go off and reference a
dozen or more documents.

If you don't want to implement section 6 in your implementation then just skip section 6.

-derek
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins, SB '93 MIT EE, SM '95 MIT = Media Laboratory
=C2=A0 =C2=A0 =C2=A0 =C2=A0Member, MIT Student Information Processing Board= =C2=A0 (SIPB)
=C2=A0 =C2=A0 =C2=A0 =C2=A0URL: http://web.mit.edu/warlord/=C2=A0 =C2=A0 PP-ASEL-IA=C2= =A0 =C2=A0 =C2=A0N1NWH
=C2=A0 =C2=A0 =C2=A0 =C2=A0warlord@MIT.EDU=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PGP key available
--001a11c21ff046bbbd05117dcb97-- From nobody Tue Mar 17 08:48:36 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 08BC11A6FF6 for ; Tue, 17 Mar 2015 08:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 Th4k_R5ibRFm for ; Tue, 17 Mar 2015 08:48:34 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id DB3401A6FF1 for ; Tue, 17 Mar 2015 08:48:33 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 67400F210D; Tue, 17 Mar 2015 15:48:33 +0000 (UTC) Date: Tue, 17 Mar 2015 10:48:32 -0500 From: Stephen Paul Weber To: Derek Atkins Message-ID: <20150317154832.GF2983@singpolyma-liberty> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> <20150317151510.GD2983@singpolyma-liberty> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kvUQC+jR9YzypDnK" Content-Disposition: inline In-Reply-To: Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Peter Gutmann , Wyllys Ingersoll , Tim Bray , openpgp@ietf.org Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 15:48:35 -0000 --kvUQC+jR9YzypDnK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >IMHO it's much nicer, from an implementation point of view, to have >everything in one document instead of having to go off and reference a >dozen or more documents. This is true if you're building a complete implentation like GnuPG, but les= s=20 true if you just want a way to verify signatures sent to you. I mean, not that I find the spec that complex, but the webby people I deal= =20 with seem to. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --kvUQC+jR9YzypDnK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVCEzQAAoJENEcKRHOUZzesk4QAKOAl/+3EJpf6HCyNDR1Hhur otOHz+oNtSCQ9gX8afVOAUV/NXo18s0Zduc2fV2iCGTWUnt8JC3yBwR0LBys56EP M2/tUkPyvBBsI2M2b95uSiX1hlqhq0P9Gtn5IzN9kvjr79aKTDgi4/BnqpDVVJme WPzrboTFQes0mX7ARHEBkmgpbpGv+5lYS5j834M/jPWiZDOgFQitxnfTd1nlLKKT DNjnUiLLPHTDasMHomtcIKDPosQNB+lqAYj4Rsk+cHzj30t78nYL3TR/3sMGHbS3 TxAjYv8meZKnA6PjCDFGrMrsrkOfKlgyJ6LYT8kwCXgxO4DA1mobHS6PLfpXJX7s QudUVVPLHxtg9u21uPrWzGrUxqDW34kM+r+q0nYIC3JgowW8akYkCbeum2/c4WVO B2niY1pDnb1CtEQZB7iVHeyIGhPA6+a/jZq5dSHBYX4Cjcw2AOml3HGJcIW9fjqA 4F57LJXOsaG9GBTJD+nVyXEPDtiBNSUwWpnHmfNOk+M7xrXr22OAPAATpfcfFrk4 Sq0oLErdvieDEaJpdKxv3G+mfS1UPdDAw0s6X+MXtjY7eVDO40mfaGN2icY27Wh5 uTUh2VEKFg9KSUgZdJt/huEuK+ueqPIhvjQumG1OwI9FCumFxuRTIhwlu9RVyt+r 8oIHnU6lkZLPIgMgRO1H =XCJ/ -----END PGP SIGNATURE----- --kvUQC+jR9YzypDnK-- From nobody Tue Mar 17 08:50:27 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 D3AC11A6FF6 for ; Tue, 17 Mar 2015 08:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 9zGn6miY5iOZ for ; Tue, 17 Mar 2015 08:50:24 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF21A7032 for ; Tue, 17 Mar 2015 08:50:24 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 247D0F210D; Tue, 17 Mar 2015 15:50:24 +0000 (UTC) Date: Tue, 17 Mar 2015 10:50:23 -0500 From: Stephen Paul Weber To: Wyllys Ingersoll Message-ID: <20150317155023.GG2983@singpolyma-liberty> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zaRBsRFn0XYhEU69" Content-Disposition: inline In-Reply-To: Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Character encodings 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, 17 Mar 2015 15:50:26 -0000 --zaRBsRFn0XYhEU69 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >4880 says that everything should be UTF-8. However, the reality is that >UTF8 is not used everywhere and there are lots of clients that compose >messages in their native preferred character set (Latin5, Greek, Kanji, >etc) But a conforming OpenPGP implementation should convert this to UTF-8 before= =20 encrypt/sign if using text packets. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --zaRBsRFn0XYhEU69 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVCE0+AAoJENEcKRHOUZzef0sQAJSLSDKdCpSNrMmz6mzSNkFI 2YpV8wc8AD3Ew4pxtSCbJjNxaSoU68tVZXrGBYOfiWoljrl2d18tuRvW9gMVcPZU wXCxWsnYs8laAZ1n1uYiNIJrI8SJOm73Xwqk/r1dqavnQz4K6++P/NhuPSJDiANO u7DYfA/60WHX1ZelRIeikpMbdMM3zyIr8yqSP6gHO+G1APMQWEqv/CUY9cD9Uzrd IfJgpBcu4yDMGoeTPnkmjcuFljzoeFmfylWwicVggGOESU1x89G52cKf2P2CPoV3 P3VyNqRC7Nb0ih5pBPdenQVCSEkjF8hk9LdlbIj1dgwiYxiregHvSQACWEk6qMQy euy2pMQu/2tVHzf1BQCsG3QnMlXEagz4fMtSMWCL/H0Y9JCy2aQllPk/+xl93gtn kjtW+6sYHDpThZGMF7Drd4Bp3I1BAaii4s6XQYCTQboEgi6lkd5JkCzHmXDjeoKw CbYaqvnC4s29uWST4YFJpryMDnEMBFa0RH8eyR3idv+JT4oXLNfJEduDp2kKsdeF nNVD3S26ZMxlD0ceOXRXMM1tJTaIjlNkr1r/1kZwQkhE5xC28wlfhAz23bhWNkbb KSWf0Pw1xngJNp+92y30TNn/vJyZBierl3F4YxmMFKXTxjbPLI3a6qcIDcR6N8g2 ptKL+bc2naOfke1eSZft =2a2h -----END PGP SIGNATURE----- --zaRBsRFn0XYhEU69-- From nobody Tue Mar 17 08:55: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 DD2FC1A8028 for ; Tue, 17 Mar 2015 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 7uAl56ayU9VZ for ; Tue, 17 Mar 2015 08:55:35 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 4CE881A7D84 for ; Tue, 17 Mar 2015 08:55:35 -0700 (PDT) Received: by oibu204 with SMTP id u204so12104979oib.0 for ; Tue, 17 Mar 2015 08:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=xXumgTPwR/hpPOu0vqM+PWNSi1P637mZ/Pr8sAVMm3w=; b=ddpauM5OOL+CWr/oA3SRcSS8NVzujWfAM6NoFRPZFis9v3sx+xGtx6nfD9nDMupNYi uiYb0U0+4DJIiIAS4/Ppi1sOuk/a7urzd2+Ktv1+kbWBLOL6LZ/LXUJP7rcQeUqbAEAk PT9So3ae/5vu0jLuv55LXH+it8L4Z54s2pb+zt67q95V1xdxdjESxgVHX9AV95ow74z0 aNmUp4wCR2UXyKMXXscV6EH9S+zpSTiHOOcWPLWkaFVQo3JK/huvYEOJwL1wNoyUoom/ yEVx//8bFn/DObZHr65NAw0Nz+XUjI4qvAoYnFdKEaED+gIncyhvzN37ObkRphV3k6pX HI7Q== X-Received: by 10.60.222.71 with SMTP id qk7mr53721617oec.37.1426607734743; Tue, 17 Mar 2015 08:55:34 -0700 (PDT) MIME-Version: 1.0 References: <20150317155023.GG2983@singpolyma-liberty> In-Reply-To: <20150317155023.GG2983@singpolyma-liberty> From: Wyllys Ingersoll Date: Tue, 17 Mar 2015 15:55:33 +0000 Message-ID: To: Stephen Paul Weber Content-Type: multipart/alternative; boundary=001a11c2a08043693905117dffe2 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Character encodings 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, 17 Mar 2015 15:55:37 -0000 --001a11c2a08043693905117dffe2 Content-Type: text/plain; charset=UTF-8 Right, but they don't. The application doing the encryption really doesn't know what the original character encoding was, so doing the conversion can result in lost or corrupted messages. I think the only way to get it right is if the message composer (i.e. mail client usually) is tightly coupled with the PGP engine so that it can pass along the character encoding when the encryption request is made. On Tue, Mar 17, 2015 at 11:50 AM Stephen Paul Weber < singpolyma@singpolyma.net> wrote: > >4880 says that everything should be UTF-8. However, the reality is that > >UTF8 is not used everywhere and there are lots of clients that compose > >messages in their native preferred character set (Latin5, Greek, Kanji, > >etc) > > But a conforming OpenPGP implementation should convert this to UTF-8 before > encrypt/sign if using text packets. > > -- > Stephen Paul Weber, @singpolyma > See for how I prefer to be contacted > edition right joseph > --001a11c2a08043693905117dffe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, but they don't.=C2=A0 The application doing the= encryption really doesn't know what the original character encoding wa= s, so doing the conversion can result in lost or corrupted messages. =C2=A0=

I think the only way to get it right is if the mess= age composer (i.e. mail client usually) is tightly coupled with the PGP eng= ine so that it can pass along the character encoding when the encryption re= quest is made.



On Tue, Mar 17, 2015 at 11:50 AM Stephen Paul Weber <singpolyma@singpolyma.net> wro= te:
>4880 says that everything should = be UTF-8.=C2=A0 However, the reality is that
>UTF8 is not used everywhere and there are lots of clients that compose<= br> >messages in their native preferred character set (Latin5, Greek, Kanji,=
>etc)

But a conforming OpenPGP implementation should convert this to UTF-8 before=
encrypt/sign if using text packets.

--
Stephen Paul Weber, @singpolyma
See <http://singpoly= ma.net> for how I prefer to be contacted
edition right joseph
--001a11c2a08043693905117dffe2-- From nobody Tue Mar 17 09:30:09 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 CFE2E1A1B71 for ; Tue, 17 Mar 2015 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ACbjlx3ddpBZ for ; Tue, 17 Mar 2015 09:30:05 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 34CCB1A1B4B for ; Tue, 17 Mar 2015 09:30:05 -0700 (PDT) Received: by lbbzq9 with SMTP id zq9so11136010lbb.0 for ; Tue, 17 Mar 2015 09:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=obI61cl3Yrl7qsaHjeiZ+gMKj1r9wxxaalByW0NoJUU=; b=xuGCm6bCUItW0dZZSi/AjqWXco6A2Z0Bh41hSCtnPce+qFgGhZFwtueaVi3DmH4ga9 z9IUx57XgoRFGSZpei/Ed779PKqgA/8j0UHRm+dA/8zW4tWNIkoBkHtOC6haCYQ6akPW d1bU7c34zscHNgHW2ySljSfv+d7THfkY7g0uGymoOMUW+4PtiHfYDxPWixEjUjJJMDcR oO6Fc6XnZVjJnOkxttDSZs7x6eHDkrc63UG4k/Q44++ZWCUClcmIcewwc0qgUDusyKFd /l/ZC47eMa07BQoJZJJqbiTTeqzbxYAdFIq1u5iXrC2FCOq9erWD6FJfgAzh37FltImp fqWA== MIME-Version: 1.0 X-Received: by 10.112.151.226 with SMTP id ut2mr42027082lbb.55.1426609803598; Tue, 17 Mar 2015 09:30:03 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Tue, 17 Mar 2015 09:30:03 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 17 Mar 2015 12:30:03 -0400 X-Google-Sender-Auth: A7fyQXk1XfpLIoLmVVNlbBpDYnQ Message-ID: From: Phillip Hallam-Baker To: Jon Callas Content-Type: multipart/alternative; boundary=047d7bf0c03693a39c05117e7a0e Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 16:30:08 -0000 --047d7bf0c03693a39c05117e7a0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 17, 2015 at 2:48 AM, Jon Callas wrote: > > > On Mar 16, 2015, at 7:04 PM, Peter Gutmann > wrote: > > > > Jon Callas writes: > > > >> Certainly the ASCII Armor checksum is something that could go, since w= e > don't > >> need to worry so much about modem line noise. :-) But you have to know > enough > >> to ignore it. > > > > It's not just the checksum, the entire ASCII armoring should have been > > discarded years, no decades, ago. The whole thing was originally > implemented > > because facilities like FidoNet and Usenet didn't handle binary > messages, and > > the checksum was because things like 2400bps modems (pre-MNP) on the DO= S > PCs > > that PGP 1 was written for wouldn't cancel out line noise, so it was > useful to > > check for inadvertent message corruption before you warned about invali= d > > signatures. > > > > The MIME standard (going back to RFC 1341) is over 20 years old and > pretty > > much everything supports it, but PGP persists with something from even > earlier > > (PEM, from 1987, that's nearly 30 years ago). It's not just "a museum = of > > 1990s crypto" (thanks to Matthew Green for the great quote), it's also = a > > museum of 1980s and 1990s everything-else. The entire discussion of > "ASCII > > armour" should have been replaced with "use a mechanism like MIME" year= s > ago. > > > > (Oh, and by "MIME" I mean proper use of MIME, not "wrap PGP-PEM in MIME > > headers and pretend it's MIME", RFC 2015/3156). > > > > Maybe not decades. > > ASCII armor as it exists now uses the same encoding as MIME for base64, > purely by chance. It is one of the things that makes me least crazy becau= se > it=E2=80=99s mostly standard and actually kinda useful. There are a lot o= f semantic > places where it=E2=80=99s nice to know that something is an OpenPGP objec= t in > human-readable form. > > Something that seems to be forgotten all over the place is that email is > actually one of the least interesting places to use OpenPGP. ASCII armor > ends up being a nice way to encode something so you don=E2=80=99t have to= play > "guess the binary format." > We have been having a similar discussion in ACME which is for issue of certificates for use in TLS, email, etc. The body of the message is going to be JSON. But the message needs to be signed. After a number of proposals we seem to have settled on a scheme in which the start of the message is a JSON header carrying the signature which is followed by a JSON message carrying the transaction request or response. > Relatively recently, I was opining to someone that it would be useful to > come up with a JSON encoding for OpenPGP that would give an easy-to-parse > thing that=E2=80=99s not just ASCII armor. But some years ago, I said the= same > thing but it was XML, not JSON. And a few years before that, it was > S-Expressions, most recently in SPKI format, and more Common LISP-ish > before that even. JSON is what the cool kids are using this decade, don= =E2=80=99t > you know. > > And *that* is the reason to just stick with ASCII armor. > Well you go to MIT, you get S-Expressions... I am kind of surprised the code made it out of 545 tech square without them. When I was backing XML it was essentially just S-expressions with angle brackets and the initial tag duplicated on the end. JSON gets us back to what we were sold when XML was first offered before the namespace prefix idiocy was introduced and the schema was botched. I think I will actually disagree with you Jon, even though I started thinking I was in agreement. I think that the IT world has in fact picked winners and stuck with them. But for different purposes. There is least convergence at the lower levels of the stack. I can't imagine any new protocol using ASN.1 unless it is directly coupled to PKIX. The IETF has converged on using the TLS notation and approach. It works. Above that XML is the only viable choice for a document format, JSON is emerging as the natural choice for Web Services. There is no consensus on a binary version of JSON but there are many applications making use of them. Given where we are today, there are two approaches that make sense. One is to stay with the current approach, the other is to pick an existing approach, adding essential features if absolutely required. To be avoided at all costs is to abandon the current approach and instead invent a new encoding. Yes, JSON does have limitations that make it unsuited for some applications and it is therefore inevitable that there will be some other encoding at some point in the future. But that does not mean that there will be a new format that looks completely different to JSON and we can be virtually certain that a new format proposed for PGP that looks completely different to JSON and the TLS encoding is not going to be picked up anywhere else. --047d7bf0c03693a39c05117e7a0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 2:48 AM, Jon Callas <jon@callas.org> wrote:

> On Mar 16, 2015, at 7:04 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>
> Jon Callas <jon@callas.org>= ; writes:
>
>> Certainly the ASCII Armor checksum is something that could go, sin= ce we don't
>> need to worry so much about modem line noise. :-) But you have to = know enough
>> to ignore it.
>
> It's not just the checksum, the entire ASCII armoring should have = been
> discarded years, no decades, ago.=C2=A0 The whole thing was originally= implemented
> because facilities like FidoNet and Usenet didn't handle binary me= ssages, and
> the checksum was because things like 2400bps modems (pre-MNP) on the D= OS PCs
> that PGP 1 was written for wouldn't cancel out line noise, so it w= as useful to
> check for inadvertent message corruption before you warned about inval= id
> signatures.
>
> The MIME standard (going back to RFC 1341) is over 20 years old and pr= etty
> much everything supports it, but PGP persists with something from even= earlier
> (PEM, from 1987, that's nearly 30 years ago).=C2=A0 It's not j= ust "a museum of
> 1990s crypto" (thanks to Matthew Green for the great quote), it&#= 39;s also a
> museum of 1980s and 1990s everything-else.=C2=A0 The entire discussion= of "ASCII
> armour" should have been replaced with "use a mechanism like= MIME" years ago.
>
> (Oh, and by "MIME" I mean proper use of MIME, not "wrap= PGP-PEM in MIME
> headers and pretend it's MIME", RFC 2015/3156).
>

Maybe not decades.

ASCII armor as it exists now uses the same encoding as MIME for base64, pur= ely by chance. It is one of the things that makes me least crazy because it= =E2=80=99s mostly standard and actually kinda useful. There are a lot of se= mantic places where it=E2=80=99s nice to know that something is an OpenPGP = object in human-readable form.

Something that seems to be forgotten all over the place is that email is ac= tually one of the least interesting places to use OpenPGP. ASCII armor ends= up being a nice way to encode something so you don=E2=80=99t have to play = "guess the binary format."

We= have been having a similar discussion in ACME which is for issue of certif= icates for use in TLS, email, etc.

The body of the= message is going to be JSON. But the message needs to be signed. After a n= umber of proposals we seem to have settled on a scheme in which the start o= f the message is a JSON header carrying the signature which is followed by = a JSON message carrying the transaction request or response.

=
=C2=A0
Relatively recently, I was opining to someone that it would be useful to co= me up with a JSON encoding for OpenPGP that would give an easy-to-parse thi= ng that=E2=80=99s not just ASCII armor. But some years ago, I said the same= thing but it was XML, not JSON. And a few years before that, it was S-Expr= essions, most recently in SPKI format, and more Common LISP-ish before that= even. JSON is what the cool kids are using this decade, don=E2=80=99t you = know.

And *that* is the reason to just stick with ASCII armor.

Well you go to MIT, you get S-Expressions... I am kind of= surprised the code made it out of 545 tech square without them.
=
When I was backing XML it was essentially just S-expressions= with angle brackets and the initial tag duplicated on the end. JSON gets u= s back to what we were sold when XML was first offered before the namespace= prefix idiocy was introduced and the schema was botched.

I think I will actually disagree with you Jon, even though I starte= d thinking I was in agreement. I think that the IT world has in fact picked= winners and stuck with them. But for different purposes.

There is least convergence at the lower levels of the stack. I can&= #39;t imagine any new protocol using ASN.1 unless it is directly coupled to= PKIX. The IETF has converged on using the TLS notation and approach. It wo= rks. Above that XML is the only viable choice for a document format, JSON i= s emerging as the natural choice for Web Services. There is no consensus on= a binary version of JSON but there are many applications making use of the= m.


Given where we are today, there = are two approaches that make sense. One is to stay with the current approac= h, the other is to pick an existing approach, adding essential features if = absolutely required.

To be avoided at all costs is= to abandon the current approach and instead invent a new encoding. Yes, JS= ON does have limitations that make it unsuited for some applications and it= is therefore inevitable that there will be some other encoding at some poi= nt in the future. But that does not mean that there will be a new format th= at looks completely different to JSON and we can be virtually certain that = a new format proposed for PGP that looks completely different to JSON and t= he TLS encoding is not going to be picked up anywhere else.
--047d7bf0c03693a39c05117e7a0e-- From nobody Tue Mar 17 09:45:05 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 4C9CD1A8792 for ; Tue, 17 Mar 2015 09:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 4BcsmsmkX0B8 for ; Tue, 17 Mar 2015 09:44:54 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 BEAA11A8788 for ; Tue, 17 Mar 2015 09:44:53 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so11416585lbc.2 for ; Tue, 17 Mar 2015 09:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZcB8deBTFwhDHSz0fe8FUj/Y1w4d4H8ZAxhbiCloEqo=; b=yVUplZSIAoNlTN35Wv4IBW7PvXaPjtwqcOYgTloXrLxzXKQb6yXx4vkHjt8ISGcuRe XbLAan6GXt7LYREEEDap7gH7pgpiItRT1e6PecASh7WldxBGrdKFC5PXiO/ck3FTiacu s13zmi4alXemUBiLE4aI5/OjgGanFAQhCgkrihcIf7gY/uCurmvWI39PDo+trsd65lM7 sH9HnJ+QwDfMQqJgi0K/TSbq7xkjncg5mXXIKHX5MDO3MYUkgSTebzKxPMaBMFz0c6i6 pOsCj+5vmH2hyFGpD9q7q8r4nzaorNepMZMnK5a96zhij2QnWiJAIhkhbKKrKWXPRwtv bfaA== MIME-Version: 1.0 X-Received: by 10.112.133.2 with SMTP id oy2mr8709160lbb.124.1426610692204; Tue, 17 Mar 2015 09:44:52 -0700 (PDT) Received: by 10.112.45.203 with HTTP; Tue, 17 Mar 2015 09:44:52 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> Date: Tue, 17 Mar 2015 12:44:52 -0400 Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=047d7b3a8c9c8aaff105117eaf17 Archived-At: Cc: David Shaw , "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 16:45:01 -0000 --047d7b3a8c9c8aaff105117eaf17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 17, 2015 at 11:33 AM, Derek Atkins wrote: > Phill writes: > > > But that 32 bit length really worries me. Just because people can=E2=80= =99t > > send 4GB messages today does not mean that they can=E2=80=99t or won=E2= =80=99t in the > > future. Do not build OpenPGP around assumptions based on SMTP > > continuing forever. Use today is not limited to mail in any case. > > > > If I have a 1TB archive file I am not going to want to break it into > > chunks just to encrypt it. > > That's what partial (indefinite) lengths are for. Having to cut the dinner up into bite sized portions is a bit of a pain. It also means that special code is required to do pass along data that has already been encrypted in a different format. Partial lengths are necessary to support streaming where the length is indefinite. They can be used for large chunks but that is a hack. > But the point is that > each "size" parameter is 32 bits, always, instead of having a 1, 2, or > 5-byte length parameter. > This is 2015, either make the size 64 bits or if you really think that the space is a critical issue then use a self describing length format. The body of any modern email is going to be UTF8 after all. Even 64 bits starts to become an issue in exabyte stores. But only the NSA and possibly Google have got one of those to date. > [snip] > > Again, I am not sure that a complete overhaul is desirable. Just > > pruning back the unnecessary features is probably sufficient. > > +1 --=20 Website: http://hallambaker.com/ --047d7b3a8c9c8aaff105117eaf17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 11:33 AM, Derek Atkins <warlord@mit.edu><= /span> wrote:
Phill <= hallam@gmail.com> writes:

> But that 32 bit length really worries me. Just because people can=E2= =80=99t
> send 4GB messages today does not mean that they can=E2=80=99t or won= =E2=80=99t in the
> future. Do not build OpenPGP around assumptions based on SMTP
> continuing forever. Use today is not limited to mail in any case.
>
> If I have a 1TB archive file I am not going to want to break it into > chunks just to encrypt it.

That's what partial (indefinite) lengths are for.=C2=A0

Having to cut the dinner up into bite sized portion= s is a bit of a pain.

It also means that special c= ode is required to do pass along data that has already been encrypted in a = different format.

Partial lengths are necessary to= support streaming where the length is indefinite. They can be used for lar= ge chunks but that is a hack.=C2=A0
=C2=A0
But the point is that
each "size" parameter is 32 bits, always, instead of having a 1, = 2, or
5-byte length parameter.

This is 2015, = either make the size 64 bits or if you really think that the space is a cri= tical issue then use a self describing length format. The body of any moder= n email is going to be UTF8 after all.

Even 64 bit= s starts to become an issue in exabyte stores. But only the NSA and possibl= y Google have got one of those to date.

=C2=A0
[snip]
> Again, I am not sure that a complete overhaul is desi= rable. Just
> pruning back the unnecessary features is probably sufficient.

+1


--
--047d7b3a8c9c8aaff105117eaf17-- From nobody Tue Mar 17 12:01:11 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 6D1DF1A8884 for ; Tue, 17 Mar 2015 12:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 A6rhSqi9Bec2 for ; Tue, 17 Mar 2015 12:01:07 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 589CC1A88E8 for ; Tue, 17 Mar 2015 12:00:58 -0700 (PDT) Received: by lbbzq9 with SMTP id zq9so14175385lbb.0 for ; Tue, 17 Mar 2015 12:00:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H5PbA7JBwrytCkKHSPfpfDdY41E6tt5AvTyX8jGfPJA=; b=Z5gP1p9anlsQUumuUcH8w3YaAxw+M1WnEU9uOCEAxuzKbYIvpD7qZd14dsJHi5mA1x i5tC0lOFZjkgh8GiA15slj1jX6rkBpokKyKJvke2Ubc42ER2LPkxqC5g1vXlg5m6zuuT DXpzFIKQlKED3Dx7VmVQNaDx+t2JBOqB/NT4TXvW6tIBERWbxts7jWCGMJc72yXkB/b+ UC9t9iQ9c9jpYzkLSsdx7Nv9b1MQYUpL5TPae9wN+LkKiiUtmnOPyrOyHMtNMQ5cXwzP oKwRtA2CjH3Do00SC4HGEU3N9q60PREomIJlqdRgtYl9T0djEbi7aW4lyne7jcCl2dR/ EIzg== X-Gm-Message-State: ALoCoQlcyrFqvxYIujSnorVsnfCUZcLPUs9DUcAPZ2I50PBDEcn7sguRC77Qo6/6Ot0iNGfaZAwk MIME-Version: 1.0 X-Received: by 10.112.144.41 with SMTP id sj9mr61126305lbb.3.1426618856797; Tue, 17 Mar 2015 12:00:56 -0700 (PDT) Received: by 10.114.3.242 with HTTP; Tue, 17 Mar 2015 12:00:56 -0700 (PDT) X-Originating-IP: [122.56.232.225] Received: by 10.114.3.242 with HTTP; Tue, 17 Mar 2015 12:00:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 08:00:56 +1300 Message-ID: From: Tim Bray To: Wyllys Ingersoll Content-Type: multipart/alternative; boundary=047d7b3a82de30912e05118096d5 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Character encodings 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, 17 Mar 2015 19:01:09 -0000 --047d7b3a82de30912e05118096d5 Content-Type: text/plain; charset=UTF-8 This would be a huge step backward. The proportion of text on the internet that is UTF-8 is monotonically increasing toward 100%. Thank goodness. On Mar 18, 2015 4:38 AM, "Wyllys Ingersoll" wrote: > One area that I think needs some attention is the character encoding and > charsets for encrypted text messages. > > 4880 says that everything should be UTF-8. However, the reality is that > UTF8 is not used everywhere and there are lots of clients that compose > messages in their native preferred character set (Latin5, Greek, Kanji, > etc) and its very difficult as an implementor to figure it out after the > fact without some indication from the sender. > > The literal packet format only specifies 3 possible values - binary, UTF8, > or plain. The ASCII Armor header may specify a different charset (though > unfortunately very few agents add the "Charset" PGP header). > Additionally, if the message had MIME headers, there may be yet another > charset indicated in MIME that differs from the ASCII Armor charset and the > literal packet data format byte. > > If the encrypting PGP software knows what character encoding was used to > compose the original message, there should be some way to communicate this > in the message that would be definitive so that the decrypting software can > present it the way it was originally intended. As an implementor, this is > one of the trickiest areas to get right so that the end user sees the > messages as it was originally intended. > > > > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > > --047d7b3a82de30912e05118096d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This would be a huge step backward. The proportion of text o= n the internet that is UTF-8 is monotonically increasing toward 100%. Thank= goodness.

On Mar 18, 2015 4:38 AM, "Wyllys Ingersoll&= quot; <wyllys@gmail.com> wrot= e:
= One area that I think needs some attention is the character encoding and ch= arsets for encrypted text messages.

4880 says that every= thing should be UTF-8.=C2=A0 However, the reality is that UTF8 is not used = everywhere and there are lots of clients that compose messages in their nat= ive preferred character set (Latin5, Greek, Kanji, etc) and its very diffic= ult as an implementor to figure it out after the fact without some indicati= on from the sender.

The literal packet format only= specifies 3 possible values - binary, UTF8, or plain.=C2=A0 The ASCII Armo= r header may specify a different charset (though unfortunately very few age= nts add the "Charset" PGP header). =C2=A0 Additionally, if the me= ssage had MIME headers, there may be yet another charset indicated in MIME = that differs from the ASCII Armor charset and the literal packet data forma= t byte.

If the encrypting PGP software knows what = character encoding was used to compose the original message, there should b= e some way to communicate this in the message that would be definitive so t= hat the decrypting software can present it the way it was originally intend= ed.=C2=A0 As an implementor, this is one of the trickiest areas to get righ= t so that the end user sees the messages as it was originally intended.






_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

--047d7b3a82de30912e05118096d5-- From nobody Tue Mar 17 12:27:05 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 792A91A88A6 for ; Tue, 17 Mar 2015 12:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 92VeQOS7KBcV for ; Tue, 17 Mar 2015 12:26:57 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 A882D1A8888 for ; Tue, 17 Mar 2015 12:26:57 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so15603740obc.0 for ; Tue, 17 Mar 2015 12:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=nc2BATI+sLiNNWKMHW+CYqu/xME7VdC+AhCWkeAezSA=; b=odlNfpsICf1LxmgpMVsIamrfGpL6NCIXl+MzY0mQZ7Elagfd1jYnAUATqIMfXSBmni xZ79cKILpzLHIkQ/t4zFbqBbPWWXMWmBaMZArqcTUHxoW8xhCqjxpam1//+ik1PYpYXZ DuWWfa9eFpca2Ex58eWaV2nhlJ8pSAg7kgab2TAweAoTyqCmlpoPyv/Au5zk2n3qr1TB 94d0UuupLkKiCus+S+gRM7m4cyV6oFon/ZsEmddMuN/uvq131SGp4P0RDbJPjSAHu4/t B56Po5Vfnpds+lY2X9wBBMmhaSh7iCcGHVIZoPJP9lwj+KYmwkpuhqrTtclgcRzgce8r JKlA== X-Received: by 10.60.160.236 with SMTP id xn12mr24845519oeb.53.1426620417113; Tue, 17 Mar 2015 12:26:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wyllys Ingersoll Date: Tue, 17 Mar 2015 19:26:55 +0000 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=089e011603e431030a051180f328 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Character encodings 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, 17 Mar 2015 19:27:03 -0000 --089e011603e431030a051180f328 Content-Type: text/plain; charset=UTF-8 In my experience it's not getting any better for PGP messages that are not composed in a basic text editor. Users composing messages on a mobile devices, for example, do not always default to UTF8, they use the system-wide character encoding setting (or the charset encoding specified by the composing app itself). For example, iOS Apple basically says if you don't know the original encoding, you have to basically "guess" by trying various encodings until you find one that works. https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Strings/Articles/readingFiles.html#//apple_ref/doc/uid/TP40003459-SW4 Fortunately, it usually only takes a few tries to get it right if its not UTF8. I agree that UTF-8 should be preferred and enforced wherever possible. But in cases where it is not, it would help if the sender was able to provide a hint as to what the encoding actually is, and do so in a standardized manner that can be easily implemented. On Tue, Mar 17, 2015 at 3:00 PM Tim Bray wrote: > This would be a huge step backward. The proportion of text on the internet > that is UTF-8 is monotonically increasing toward 100%. Thank goodness. > On Mar 18, 2015 4:38 AM, "Wyllys Ingersoll" wrote: > >> One area that I think needs some attention is the character encoding and >> charsets for encrypted text messages. >> >> 4880 says that everything should be UTF-8. However, the reality is that >> UTF8 is not used everywhere and there are lots of clients that compose >> messages in their native preferred character set (Latin5, Greek, Kanji, >> etc) and its very difficult as an implementor to figure it out after the >> fact without some indication from the sender. >> >> The literal packet format only specifies 3 possible values - binary, >> UTF8, or plain. The ASCII Armor header may specify a different charset >> (though unfortunately very few agents add the "Charset" PGP header). >> Additionally, if the message had MIME headers, there may be yet another >> charset indicated in MIME that differs from the ASCII Armor charset and the >> literal packet data format byte. >> >> If the encrypting PGP software knows what character encoding was used to >> compose the original message, there should be some way to communicate this >> in the message that would be definitive so that the decrypting software can >> present it the way it was originally intended. As an implementor, this is >> one of the trickiest areas to get right so that the end user sees the >> messages as it was originally intended. >> >> >> >> >> >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >> >> --089e011603e431030a051180f328 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

In my experience it's not getting any better for P= GP messages that are not composed in a basic text editor.=C2=A0 Users compo= sing messages on a mobile devices, for example, do not always default to UT= F8, they use the system-wide character encoding setting (or the charset enc= oding specified by the composing app itself).

For exampl= e, iOS=C2=A0Apple basically says if you don't know the original encodi= ng, you have to basically "guess" by trying various encodings unt= il you find one that works.=C2=A0=C2=A0https://developer.apple.com/library/ios/= documentation/Cocoa/Conceptual/Strings/Articles/readingFiles.html#//apple_r= ef/doc/uid/TP40003459-SW4
Fortunately, it usually only= takes a few tries to get it right if its not UTF8.

I agree that UTF-8 should be preferred and enforced wherever possible. Bu= t in cases where it is not, it would help if the sender was able to provide= a hint as to what the encoding actually is, and do so in a standardized ma= nner that can be easily implemented.



On Tue, Mar 17, 2015 at 3:00 PM Tim Bray = <tbray@textuality.com> wr= ote:

This would be a huge = step backward. The proportion of text on the internet that is UTF-8 is mono= tonically increasing toward 100%. Thank goodness.

On Mar 18, 2015= 4:38 AM, "Wyllys Ingersoll" <wyllys@gmail.com> wrote:
One area that I think needs some attention is the character encodi= ng and charsets for encrypted text messages.

4880 says t= hat everything should be UTF-8.=C2=A0 However, the reality is that UTF8 is = not used everywhere and there are lots of clients that compose messages in = their native preferred character set (Latin5, Greek, Kanji, etc) and its ve= ry difficult as an implementor to figure it out after the fact without some= indication from the sender.

The literal packet fo= rmat only specifies 3 possible values - binary, UTF8, or plain.=C2=A0 The A= SCII Armor header may specify a different charset (though unfortunately ver= y few agents add the "Charset" PGP header). =C2=A0 Additionally, = if the message had MIME headers, there may be yet another charset indicated= in MIME that differs from the ASCII Armor charset and the literal packet d= ata format byte.

If the encrypting PGP software kn= ows what character encoding was used to compose the original message, there= should be some way to communicate this in the message that would be defini= tive so that the decrypting software can present it the way it was original= ly intended.=C2=A0 As an implementor, this is one of the trickiest areas to= get right so that the end user sees the messages as it was originally inte= nded.






_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp

--089e011603e431030a051180f328-- From nobody Tue Mar 17 12:45:07 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 A40871A88D5 for ; Tue, 17 Mar 2015 12:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 b4dRznJJ3JyT for ; Tue, 17 Mar 2015 12:45:04 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id C7FC81A88D0 for ; Tue, 17 Mar 2015 12:45:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 2A67D6CB33DC for ; Tue, 17 Mar 2015 12:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnKYCd0x4Vch for ; Tue, 17 Mar 2015 12:44:32 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 04A896CB33CA for ; Tue, 17 Mar 2015 12:44:31 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Tue, 17 Mar 2015 12:44:32 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 17 Mar 2015 12:44:32 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jon Callas In-Reply-To: Date: Tue, 17 Mar 2015 12:44:31 -0700 Message-Id: References: To: "openpgp@ietf.org" X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] Character encodings 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, 17 Mar 2015 19:45:06 -0000 One of the things that OpenPGP doesn't do very well that needs to be = fixed is layering. We have the notion of text versus binary because at one time that kinda = made sense. Back when FTP was high-tech, you could get better usability = by knowing that something was text so that you could translate between = SIXBIT, EBCDIC, RAD50, ASCII, and other codings that only used upper = case in their names (because lower-case was also high-tech in those = days). We don't have those problems any more. We have slightly different = problems, but we also have solutions to those. If you want to send a = text message that has a strange encoding, there are ways to do that. = Wyllys Ingersoll and others have noted this. Just get rid of the notion of text. Make it be all binary. Push the = problem up a layer in the software stack -- they have to deal with it = anyway, and all OpenPGP can do is make it worse. Jon From nobody Tue Mar 17 13:51: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 1DB761A88EA for ; Tue, 17 Mar 2015 13:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 u9zECX2yhqzo for ; Tue, 17 Mar 2015 13:51:23 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372D91A88E4 for ; Tue, 17 Mar 2015 13:51:23 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YXySP-0000DD-Da for ; Tue, 17 Mar 2015 21:51:21 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YXyOo-0002wc-Mm; Tue, 17 Mar 2015 21:47:38 +0100 From: Werner Koch To: David Leon Gil References: <20150315175744.GG2978@singpolyma-liberty> <34C550CB-11A0-4D25-A5CF-78D265FE2435@callas.org> <20150316181213.GF2944@singpolyma-liberty> <87d2484tg4.fsf@vigenere.g10code.de> 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: David Leon Gil , Stephen Paul Weber , gnupg-devel@gnupg.org, "openpgp\@ietf.org" , Jon Callas Date: Tue, 17 Mar 2015 21:47:38 +0100 In-Reply-To: (David Leon Gil's message of "Mon, 16 Mar 2015 14:15:28 -0700") Message-ID: <87pp871hcl.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: Stephen Paul Weber , gnupg-devel@gnupg.org, "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] "OpenPGP Simple" 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, 17 Mar 2015 20:51:25 -0000 On Mon, 16 Mar 2015 22:15, coruus@gmail.com said: > Is there an option to completely disable this? Relatedly, is there any > option to not use new-format partial lengths? No. In fact I started with GnuPG before OpenPGP and one of the first additions to the RFC-1991 PGP-2 format was my own version of partial lengths. This has been removed in favor of the OpenPGP and PGP-5 partial length format. You really really want partial length. A major problem with PGP-2 was that it required large temporary files for certain operations - you can't do backups this way. Up until DKIM all Internet protocols have been carefully designed to allow streaming of data (ie. the Unix way) and the IETF should continue to stress the importance of this. > Partial lengths are really a nuisance to parse. Yeah the OpenPGP encoding is a bit over-engineered to save octets. But even its partial format is easier to implement than the HTTP counterpart. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Mar 17 15:12: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 96E5F1A8931 for ; Tue, 17 Mar 2015 15:12:04 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 e0GuQJ-dncQ1 for ; Tue, 17 Mar 2015 15:12:03 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0B71A8939 for ; Tue, 17 Mar 2015 15:12:02 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YXziU-00018Z-9k; Tue, 17 Mar 2015 18:12:02 -0400 Date: Tue, 17 Mar 2015 15:11:57 -0700 From: Bill Frantz To: Derek Atkins X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79ef5f926f608a3b3f4321b2696a622071350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 17 Mar 2015 22:12:04 -0000 On 3/17/15 at 8:04 AM, warlord@MIT.EDU (Derek Atkins) wrote: >Bill Frantz writes: > >>On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote: >> >>>Oh, you expected me to decrypt/re-encrypt my encrypted email as I got it= ??? >> >>For many uses, decrypting from the wire format and re-encrypting in >>the "data at rest" security format makes excellent sense. Having only >>one encryption scheme for long-term storage allows easy (relatively) >>upgrade and helps to ensure that the data is still accessible, >>i.e. the decryption still works. I probably have a bunch of old PGP >>encrypted email I can't read anymore because I don't have the secret >>key, or its passphrase. If that mail had been re-encrypted in a format >>that I decrypt every day, I would still be able to read the >>mail. Encryption that isn't regularly exercised gets rusty. > >Show me an MUA that does this, please? None of the OpenPGP-aware MUAs >I've ever used have this feature, as far as I know. I suppose I could >go out of my way to replace the encrypted email with a >re-encrypted/plaintext email. I was thinking of the system level disk encryption for the data=20 at rest. It is available for most systems these days. >But frankly I'd like my encryption software to just maintain the ability >to decrypt it later. Well, the problem isn't the software. It is the user. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | I don't have high-speed | Periwinkle (408)356-8506 | internet. I have DSL. | 16345=20 Englewood Ave www.pwpconsult.com | | Los Gatos,=20 CA 95032 From nobody Tue Mar 17 16:17: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 BE9C61A6FE7 for ; Tue, 17 Mar 2015 16:17:13 -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 tfDKFe9ZWa5m for ; Tue, 17 Mar 2015 16:17:10 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB91A6F0B for ; Tue, 17 Mar 2015 16:17:09 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id BE50AF984; Tue, 17 Mar 2015 19:17:07 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id E2AC4201D3; Tue, 17 Mar 2015 16:17:02 -0700 (PDT) From: Daniel Kahn Gillmor To: Wyllys Ingersoll , Stephen Paul Weber In-Reply-To: References: <20150317155023.GG2983@singpolyma-liberty> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 17 Mar 2015 19:17:02 -0400 Message-ID: <871tknnrip.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Character encodings 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, 17 Mar 2015 23:17:13 -0000 On Tue 2015-03-17 11:55:33 -0400, Wyllys Ingersoll wrote: > Right, but they don't. The application doing the encryption really doesn't > know what the original character encoding was, so doing the conversion can > result in lost or corrupted messages. Character encodings are a problem for message signatures too. The fact that the messages don't embed any knowledge of this means that it's possible to subtly alter some textual content. See the "message tampering through header substitution" section here for a quickly-contrived example (someone with better knowledge of existing character sets can probably craft a more clever substitution): https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ > I think the only way to get it right is if the message composer (i.e. mail > client usually) is tightly coupled with the PGP engine so that it can pass > along the character encoding when the encryption request is made. Or have the composer only send well-structured data that includes framing information (and have the reciever know how to parse the framing information). This has to happen *inside* the signature (and inside the encryption, for that matter). For PGP/MIME, that work has already been done: the MIME structure is the framing information. If you pick some other sort of framing, you're kind of on your own afaict -- i don't know how many other standards there are out there. --dkg From nobody Tue Mar 17 16:33:13 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 92AA31A1BD2 for ; Tue, 17 Mar 2015 16:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RDbMIINt9KWw for ; Tue, 17 Mar 2015 16:33:11 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 BECF91A1BCF for ; Tue, 17 Mar 2015 16:33:10 -0700 (PDT) Received: by lbbsy1 with SMTP id sy1so18326970lbb.1 for ; Tue, 17 Mar 2015 16:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jzgJm/b2PRAaZFTwmhXrurLGyiaPZFl5ZlUQOTbMURg=; b=XhUad1M0x1jmGSMME3wnrVSFK/rq243+0NqOSq2CHgOl/3x9iiPNd9DyegWMGJ92Qe 0pXqgRZToAFzxTG+olsiMT/y75aPIkv980zDGdr0mMT1cs/F3td2XYn9TRQofsRp340t iQhafb6UZZSSlHHk4jn0FHRBzPknowigsYOwDT9t6dRBDzoz0uGiir1iMfmjWOaGpoaI 8PE9shW6Z5ZFX+Ub414Kr2PObC9AvRqGofqMrbOkqUrDSPb+S1JK3/6VcA9chcgbkq5r H+6j+lZM3Wm9oAON25lmnpgBR+AEV6k7zkGlrc32Lw5oIxS+xnubHAoUxsumYHj9Ysiu 7I/Q== MIME-Version: 1.0 X-Received: by 10.152.4.136 with SMTP id k8mr62102070lak.103.1426635189315; Tue, 17 Mar 2015 16:33:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Tue, 17 Mar 2015 16:33:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Mar 2015 19:33:09 -0400 X-Google-Sender-Auth: 6Q4UQJhmDsq0xVTFB6EuK6CI7bM Message-ID: From: Phillip Hallam-Baker To: Jon Callas Content-Type: multipart/alternative; boundary=089e013d119aaeedf60511846322 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Character encodings 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, 17 Mar 2015 23:33:12 -0000 --089e013d119aaeedf60511846322 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 3:44 PM, Jon Callas wrote: > One of the things that OpenPGP doesn't do very well that needs to be fixed > is layering. > > We have the notion of text versus binary because at one time that kinda > made sense. Back when FTP was high-tech, you could get better usability by > knowing that something was text so that you could translate between SIXBIT, > EBCDIC, RAD50, ASCII, and other codings that only used upper case in their > names (because lower-case was also high-tech in those days). > > We don't have those problems any more. We have slightly different > problems, but we also have solutions to those. If you want to send a text > message that has a strange encoding, there are ways to do that. Wyllys > Ingersoll and others have noted this. > > Just get rid of the notion of text. Make it be all binary. Push the > problem up a layer in the software stack -- they have to deal with it > anyway, and all OpenPGP can do is make it worse. > +1 It is all just binary blobs for the end-to-end crypto layer. The biggest mistakes in the Internet are all due to naive attempts to solve problems for the end user by converting their bits from one format to another. Remember when every time you used FTP you had to do every file transfer twice because the first time you forgot to set the flag to Binary transport? The main reason email is a problem is that mail gateways do idiot character transformations like line wrapping and get things wrong. The layering issue is key. SMTP and HTTP both conflate the application layer headers and content metadata. These should be separated out. Now it is too late to do that for regular mail but we can start fixing it for encrypted. The content-type, character set, subject line etc. should all be considered content metadata. In fact From, To, CC should as well because those are not what SMTP uses to route on, the SMTP values are used. This also solves the problem of not leaking unnecessary information. Yes, I understand that using SMTP in its current form will leak information as well. But there are ways to start fixing that. --089e013d119aaeedf60511846322 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 3:44 PM, Jon Callas <jon@callas.org> wrote:
One of the things that OpenPGP d= oesn't do very well that needs to be fixed is layering.

We have the notion of text versus binary because at one time that kinda mad= e sense. Back when FTP was high-tech, you could get better usability by kno= wing that something was text so that you could translate between SIXBIT, EB= CDIC, RAD50, ASCII, and other codings that only used upper case in their na= mes (because lower-case was also high-tech in those days).

We don't have those problems any more. We have slightly different probl= ems, but we also have solutions to those. If you want to send a text messag= e that has a strange encoding, there are ways to do that. Wyllys Ingersoll = and others have noted this.

Just get rid of the notion of text. Make it be all binary. Push the problem= up a layer in the software stack -- they have to deal with it anyway, and = all OpenPGP can do is make it worse.

+1= =C2=A0

It is all just binary blobs for the end-to-= end crypto layer.=C2=A0

The biggest mistakes in th= e Internet are all due to naive attempts to solve problems for the end user= by converting their bits from one format to another.

<= div>Remember when every time you used FTP you had to do every file transfer= twice because the first time you forgot to set the flag to Binary transpor= t? The main reason email is a problem is that mail gateways do idiot charac= ter transformations like line wrapping and get things wrong.=C2=A0

The layering issue is key. SMTP and HTTP both conflate the= application layer headers and content metadata. These should be separated = out. Now it is too late to do that for regular mail but we can start fixing= it for encrypted.

The content-type, character set= , subject line etc. should all be considered content metadata. In fact From= , To, CC should as well because those are not what SMTP uses to route on, t= he SMTP values are used.

This also solves the prob= lem of not leaking unnecessary information.


Yes, I understand that using SMTP in its current form will leak in= formation as well. But there are ways to start fixing that.

<= /div>

--089e013d119aaeedf60511846322-- From nobody Tue Mar 17 18:06:19 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 47E281A1BE4 for ; Tue, 17 Mar 2015 18:06:19 -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 kvBGzc5CE6Lj for ; Tue, 17 Mar 2015 18:06:17 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C99A11A1BBD for ; Tue, 17 Mar 2015 18:06:16 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 5E392F984; Tue, 17 Mar 2015 21:06:14 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7183020296; Tue, 17 Mar 2015 18:05:59 -0700 (PDT) From: Daniel Kahn Gillmor To: David Leon Gil In-Reply-To: References: <87sid5si30.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 17 Mar 2015 21:05:59 -0400 Message-ID: <87egonm7wo.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "dgil@yahoo-inc.com" , "openpgp@ietf.org" Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 18 Mar 2015 01:06:19 -0000 Thanks for the response and the clarifications, David! More discussion below... On Mon 2015-03-16 17:40:52 -0400, David Leon Gil wrote: > On Sunday, March 15, 2015, Daniel Kahn Gillmor wrote: >> [David Leon Gil wrote:] >> > 1. A published public key that is more than 1 year old. (This is >> > mainly taken care of by requiring > 3070 bit RSA keys...) >> >> Can you say more about this? Is this about a specific cutoff in time, >> or *anything* that is "more than 1 year old" at the present? If it's >> the latter, what effect do you expect this kind of regular key rollover >> will have? why is it warranted? > > Sure. How many days since the last zero-day security vulnerability on the > computer you are using? (Hopefully you're using something awesome with > grsecurity etc., but most users aren't.) > > It will be a rolling cut-off. (In future, it is possible that there may be > some non-user-circumventable prohibition on reusing RSA moduli, in > particular.) > > (This applies, but with somewhat less force, to most hardware-protected > keys: It is likely that they have been used often enough that more > sophisticated attacks are likely to have been able to recover the key. And > if you're using hardware protection, you are probably a likely target of > attackers with these capabilities.) This threat analysis might be too narrow: it focuses only on exploitable software flaws and cryptanalytic attacks, but it omits human factors. I worry that acting on it might open up new vectors of attack. Key continuity is valuable, and understanding how to deal with key transitions is hard for most end users. If key transitions happen regularly and we have no way of surfacing them to the user in a meaningful, then we have introduced a simple key replacement attack opportunity for *every* user that comes up at least once a year. That's quite a bit cheaper to carry out than factoring a 3072-bit RSA modulus ;) I can strawman a few approaches to address this without requiring users to become experts in distinguishing legitimate from fraudulent key transitions: 0) subkeys: allow older primary keys, but expect subkeys to be rotated regularly, and do not accept regular message signatures from primary keys (make them certification-only). This yields a known key migration pattern that can be cryptographically checked. Cryptographic certifications by third-parties are made to the primary key itself, so those certifications will last (for users who want to rely on them) even across subkey rotation. This approach also encourages the use of offline primary keys, which might help UI/UX people focus on improving that workflow. It also works entirely with the specs as we know them. 1) chained primary keys: in this approach, we'd have a primary key that gets used for a limited time period (your "one year" cutoff, say), but at the end of that time period can certify a replacement primary key. This is a bit more awkward with current tools, but we can always build extra tooling. It also seems unclear how to find the new key after a two-period gap: that is, if i know you have key X_0, you then replace it with X_1 (certified by X_0, among others), and then again with X_2 (certified with X_1, among others), what tooling do i use to build the chain? How do third-party certifications persist in this context? (or do we give up on persistent third-party certifications entirely?) 2) expose key transitions in a way that people can easily understand them and distinguish "legit" from "fraudulent"? I don't even know what this would look like, but it smells like it would create a serious support burden for any large organization that tried to roll it out, as some vocal minority of users will misunderstand and freak out thinking that they've been targeted somehow during a standard key transition. We've discussed this situation on the messaging@moderncrypto.org list some, with no good proposals i've seen other than "rely on your e-mail provider for key continuity". But if your provider can swap out your key every year for some other key and everyone will accept it, then the "e2e" principle seems to be weaker than we'd like. 3) hope that key transitions somehow won't be an issue or a point of weakness? Not sure how to justify this, but if someone can paint this picture convincingly, i'd be a happy camper... Any other thoughts? >> > 2. Signature by a public key which has ever signed a message or key >> > using MD-5 or SHA-1. >> >> How would you tell if this is the case? Isn't ignoring MD5 and SHA1 >> signatures itself sufficient? > > An exported key, for example, may have a subkey which it has signed using > MD5. I consider this to invalidate the signing key. Why does this invalidate the signing key? I wouldn't be willing to rely on the MD5 *signature*, but I don't see why it would invalidate the entire key, or any signature made over a better algorithm. The implication seems to be that there is some sort of cross-hash attack against signatures, like: if you can convince me to sign something with MD5, then you can craft some phoney signature over an SHA256 digest. But if this is true (i'm unaware of such an attack), then maybe it's also true the other way around: if you can convince me to sign something with SHA256, then maybe you can craft some phoney signature over an MD5 digest. If this is possible, then you can invalidate my key by demonstrating an MD5 signature. this is a surprising outcome! I think it makes more sense to just ignore signatures over weak digests than to discard a key that uses a weak digest. > A brief description of the (tentative) algorithm: Attempt to import an > importable public key. If any signature packet in the composition uses a > weak hash algorithm, reject the importable key in its entirety. This algorithm sounds very risky. Not every signature in an importable public key (i prefer the term "OpenPGP certificate") is made by the public key in the certificate. I don't think you'd want to reject a key on the basis of a third-party certification that happens to be in the certificate. Also, what if a certification uses an unknown digest algorithm -- this could be a good algorithm or a bad algorithm, but you don't know which. It's safest to treat the certification as a bad algorithm, but the right thing to do in either case is to ignore the certification, but not to ditch the certificate entirely. An OpenPGP certificate, once stripped of certifications made over weak algorithms, still needs to have certain properties (like a self-certification from the primary key over itself and a User ID). If those properties aren't met, then yes: ditch the certificate entirely. Otherwise, keep the pruned certificate. wdyt? --dkg From nobody Tue Mar 17 20:48:15 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 B4B8D1A8A61 for ; Tue, 17 Mar 2015 20:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 d-BslswiQEOy for ; Tue, 17 Mar 2015 20:48:13 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F86E1A8A60 for ; Tue, 17 Mar 2015 20:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426650493; x=1458186493; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/LDJISlHjWlKEztD9Gx9p8k0xyUkAJOKs/Tsxgl3RGQ=; b=PoKPlztMcqc2sRopG9Dew7LEOWA2TgvLcIlA8fnul+vPEnONscPsZbqu 3GsMz4t3DUyVogcvOthWf++Wb3XWbDnoSK/r3893yLFb4rcn2vEep8DM9 Ri3txBMb47uOe8qSorswPunLqBoW2VJptK+HrTvUtZYXFzZ1gml1hljXr Q=; X-IronPort-AV: E=Sophos;i="5.11,420,1422874800"; d="scan'208";a="314652390" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Mar 2015 16:48:12 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 18 Mar 2015 16:48:11 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] Character encodings Thread-Index: AdBhLlrSd+YzmKyiQrKRRzeiatxtvg== Date: Wed, 18 Mar 2015 03:48:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Character encodings 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, 18 Mar 2015 03:48:14 -0000 Phillip Hallam-Baker writes:=0A= >On Tue, Mar 17, 2015 at 3:44 PM, Jon Callas wrote:=0A= >> One of the things that OpenPGP doesn't do very well that needs to be fix= ed=0A= >> is layering.=0A= >>[...]=0A= >> Just get rid of the notion of text. Make it be all binary. Push the=0A= >> problem up a layer in the software stack -- they have to deal with it=0A= >> anyway, and all OpenPGP can do is make it worse.=0A= >=0A= >+1=0A= =0A= +2. The rest of the world has made do with the existing infrastructure for= =0A= getting data from A to B, one way or another, without civilisation collapsi= ng.=0A= PGP isn't a universal character-format translator, it's an encryption app, = and=0A= should restrict itself to that. Leave the character-set issues to other=0A= layers where they belong.=0A= =0A= (If all else fails, make the contents of the PGP message a MIME body like= =0A= S/MIME does, so the processing-flow is "MIME message" (S/MIME data) -> filt= er=0A= implementing the crypto (in decoded, binary form) -> "MIME message"=0A= (plaintext) back out to the mail app).=0A= =0A= Peter.= From nobody Tue Mar 17 20:55:47 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 C59781A8A57 for ; Tue, 17 Mar 2015 20:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 9isS_46t9NG1 for ; Tue, 17 Mar 2015 20:55:43 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5721A8A56 for ; Tue, 17 Mar 2015 20:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426650943; x=1458186943; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=nq1q7mEL+TBc7VJuCZlmnaQpFFa3EWLfi9kbtZYrUM0=; b=mG2521sPQOSXynfyK7pn50DKnqrO65EN+psqi+N2/kJyg5Adc8sMmw2N FHDtEV32PN59xqssEweHi9R9X5UWu63oQCKX98B1RXESdpzdfkMkGEJiR M965A8bAzsQuViENl1miKJMrCyZXyEr8kpwOxAKobTgxmpV+4nX3yQm7M A=; X-IronPort-AV: E=Sophos;i="5.11,420,1422874800"; d="scan'208";a="314654746" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Mar 2015 16:55:42 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 18 Mar 2015 16:55:41 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] "OpenPGP Simple" Thread-Index: AdBhL2cBqnrHj4pqT7e5wax+px8tlw== Date: Wed, 18 Mar 2015 03:55:41 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B47@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 18 Mar 2015 03:55:45 -0000 David Shaw writes:=0A= =0A= >What if the encoding was really simple - something like 4 bytes always, an= d=0A= >the leftmost bit would mean "partial". So any packet 2^31 or less could b= e=0A= >encoded in one piece, but we could still do partial for those situations t= hat=0A= >needed it. We could have any number of partial lengths, but it would alwa= ys=0A= >end with a non-partial final length.=0A= =0A= That's kind of ugly because now you're stuffing metadata into the length=0A= field. A better approach is the one used in BER indefinite-length encoding= s,=0A= you have a flag at the start saying "lengths are indefinite", then a series= of=0A= partial lengths followed by an end-of-contents value, tag 0 and length 0. = In=0A= other words it's something like:=0A= =0A= |len| data |len| data |len| data |0|=0A= =0A= So once you hit a partial length of zero you know you're done.=0A= =0A= Peter.=0A= From nobody Wed Mar 18 00:22:27 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 483DF1A0021 for ; Wed, 18 Mar 2015 00:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 pxfMukG5x2zH for ; Wed, 18 Mar 2015 00:22:21 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id D96741A00A8 for ; Wed, 18 Mar 2015 00:22:20 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id E55E513F404A; Wed, 18 Mar 2015 01:21:49 -0600 (MDT) X-Spam-ASN: Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 172A513F400D for ; Wed, 18 Mar 2015 01:21:48 -0600 (MDT) Message-ID: <5509277D.1080100@iridiumlinux.org> Date: Wed, 18 Mar 2015 01:21:33 -0600 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010109080303060703070807" Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 18 Mar 2015 07:22:25 -0000 This is a cryptographically signed message in MIME format. --------------ms010109080303060703070807 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not sure this approach scales. More importantly, I'm not sure it's common practice. The IETF is at its best when it is codifying existing practice to promote interop, not when it's trying to radically change practice with fairly onerous new recommendations. Perhaps if anyone desires to modify practice, they should start by promoting their new approach so that multiple software platforms and the reference implementation support it. Perhaps modifications to open-source mail clients to support a distinction between "wire format" and "data at rest" and an encryption rollover format would be useful. On 16/03/2015 10:35, Bill Frantz wrote: > On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote: > >> Oh, you expected me to decrypt/re-encrypt my encrypted email as I got >> it??? > > For many uses, decrypting from the wire format and re-encrypting in > the "data at rest" security format makes excellent sense. Having only > one encryption scheme for long-term storage allows easy (relatively) > upgrade and helps to ensure that the data is still accessible, i.e. > the decryption still works. I probably have a bunch of old PGP > encrypted email I can't read anymore because I don't have the secret > key, or its passphrase. If that mail had been re-encrypted in a format > that I decrypt every day, I would still be able to read the mail. > Encryption that isn't regularly exercised gets rusty. > > Cheers - Bill > > -----------------------------------------------------------------------= > Bill Frantz | If the site is supported by | Periwinkle > (408)356-8506 | ads, you are the product. | 16345 Englewood Ave= > www.pwpconsult.com | | Los Gatos, CA 95032= > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --------------ms010109080303060703070807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICNVIwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMzA2MjAxNzE3NTha Fw0xNTA2MjExODIxNDFaMHkxCzAJBgNVBAYTAkNBMRAwDgYDVQQIEwdBbGJlcnRhMRAwDgYD VQQHEwdDYWxnYXJ5MR4wHAYDVQQDExVGYWxjb24gRGFya3N0YXIgTW9tb3QxJjAkBgkqhkiG 9w0BCQEWF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxXTJbSY0rw4+Q/er78YCHZOoIjCcYmEvk5CnO7NxHpIH/jbWQa//6wBY3eLr PX8bbG5c3ACGgrdjkP2SYQ+j4hdG7cOq+mLu0xIIEpwc4mIMBujlOOkabF1rHhf1lR8Vu05v 6wBRmOGfPjt9DensP5cKCn2hmWjWzymtu4M6tX9PylMJ2EBl+8oYigwde8W/72L1o7hbeGeR lYYSFEMVjCAeTxh6ItBGsUsu45CaxOAGpviPim4dUce6JBULaY8WAuGBYsSHyjIQVrxBfBQt 7mplOEeSicJQ0OG5b8p+IxBYviR7B+GJFtM1rJe16FfNR8QRKsZWp+DpPmFzO7/t3QIDAQAB o4IC3TCCAtkwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBSk4cfjJtHGA2MHBl57yq9p4oXB4TAfBgNVHSMEGDAWgBSu VYNv7DHKufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYWxjb25AaXJpZGl1bWxpbnV4Lm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB AIes2lmV2V9vJ2jVpWsKESGdAP2zbFYRoISNzfqrI2ZtMOYtK88vux7X/i97rAQN+U/4/+h8 /nAI2ohvhO1SZV04HKbJHBAZNbv9z+fj9UeNgGnYffcfDTHAidZnivsS/rPyUgOqzjGBl+HN giLqKSn8PIFGazc7Rg0H1ZDbjvcVdiPcO3xdhBRsiHbZ3sn/ni24L9B9oKmvpGqkvHUvgZ28 o+4xyoDQZjalTS5OHV4piRmTJfObKT86ptl0dE6VZ/ImWUPea9enEd83gnYz+dAE7Nhrn7Eo VpI8o5A4oPdR7+XsQuiouC3TSdPf3BE+3I1OPvrUapRII/oz05WQsaIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgI1UjAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMTgwNzIx MzNaMCMGCSqGSIb3DQEJBDEWBBSSp/1Tv9rZv4Cd7Co6HzJz1KgrTjBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICNVIwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAjVS MA0GCSqGSIb3DQEBAQUABIIBADXFykCdE1a7qxRtPBoCE+tVmT+dFwbe8V5gXFJheok7ciLq BNcc00d3LjiNOs4aFc2W7j92fUC8D4kuclrgEDEm1IuOCH+c49dSFJr3zWvn237yEWCsSwBE t6Pe/YU9GB6k6LntvK2cLTv/qZtLexWzXUDIBOK0qD9wZq3XcKdibe2VA6KBm8m2ecbE+yPB ZGMbsVUZxLyAN0AE8HBgBgZu3fy/dFcqdLtxxZHBhQNCWBSwPZQlvzObwqZozztAxeRRkLcM 7GOytwswjJsJ9yLuz9HChYxPwbVhKhuZDkZKvYGrLqxyEQFVDeG711WEYjrJVNCW0EGM2YGU aveVJuEAAAAAAAA= --------------ms010109080303060703070807-- From nobody Wed Mar 18 00:23:53 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 682441A0021 for ; Wed, 18 Mar 2015 00:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 87ISdIQn9k3I for ; Wed, 18 Mar 2015 00:23:47 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id C0C301A00E6 for ; Wed, 18 Mar 2015 00:23:46 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 6FA3A13F404A; Wed, 18 Mar 2015 01:23:46 -0600 (MDT) X-Spam-ASN: Received: from [192.168.1.135] (unknown [96.53.15.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 7A73113F400D for ; Wed, 18 Mar 2015 01:23:45 -0600 (MDT) Message-ID: <550927F8.7080504@iridiumlinux.org> Date: Wed, 18 Mar 2015 01:23:36 -0600 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030600000009080006010000" Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 18 Mar 2015 07:23:51 -0000 This is a cryptographically signed message in MIME format. --------------ms030600000009080006010000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No! This is the kind of attitude that got OpenPGP into its current usability mess! On 17/03/2015 16:11, Bill Frantz wrote: >> But frankly I'd like my encryption software to just maintain the abili= ty >> to decrypt it later. > > Well, the problem isn't the software. It is the user. > > Cheers - Bill > > -----------------------------------------------------------------------= > Bill Frantz | I don't have high-speed | Periwinkle > (408)356-8506 | internet. I have DSL. | 16345 Englewood Ave= > www.pwpconsult.com | | Los Gatos, CA 95032= > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --------------ms030600000009080006010000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICNVIwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMzA2MjAxNzE3NTha Fw0xNTA2MjExODIxNDFaMHkxCzAJBgNVBAYTAkNBMRAwDgYDVQQIEwdBbGJlcnRhMRAwDgYD VQQHEwdDYWxnYXJ5MR4wHAYDVQQDExVGYWxjb24gRGFya3N0YXIgTW9tb3QxJjAkBgkqhkiG 9w0BCQEWF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAxXTJbSY0rw4+Q/er78YCHZOoIjCcYmEvk5CnO7NxHpIH/jbWQa//6wBY3eLr PX8bbG5c3ACGgrdjkP2SYQ+j4hdG7cOq+mLu0xIIEpwc4mIMBujlOOkabF1rHhf1lR8Vu05v 6wBRmOGfPjt9DensP5cKCn2hmWjWzymtu4M6tX9PylMJ2EBl+8oYigwde8W/72L1o7hbeGeR lYYSFEMVjCAeTxh6ItBGsUsu45CaxOAGpviPim4dUce6JBULaY8WAuGBYsSHyjIQVrxBfBQt 7mplOEeSicJQ0OG5b8p+IxBYviR7B+GJFtM1rJe16FfNR8QRKsZWp+DpPmFzO7/t3QIDAQAB o4IC3TCCAtkwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBSk4cfjJtHGA2MHBl57yq9p4oXB4TAfBgNVHSMEGDAWgBSu VYNv7DHKufcd+q9rMfPIHeOsuzAiBgNVHREEGzAZgRdmYWxjb25AaXJpZGl1bWxpbnV4Lm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB AIes2lmV2V9vJ2jVpWsKESGdAP2zbFYRoISNzfqrI2ZtMOYtK88vux7X/i97rAQN+U/4/+h8 /nAI2ohvhO1SZV04HKbJHBAZNbv9z+fj9UeNgGnYffcfDTHAidZnivsS/rPyUgOqzjGBl+HN giLqKSn8PIFGazc7Rg0H1ZDbjvcVdiPcO3xdhBRsiHbZ3sn/ni24L9B9oKmvpGqkvHUvgZ28 o+4xyoDQZjalTS5OHV4piRmTJfObKT86ptl0dE6VZ/ImWUPea9enEd83gnYz+dAE7Nhrn7Eo VpI8o5A4oPdR7+XsQuiouC3TSdPf3BE+3I1OPvrUapRII/oz05WQsaIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgI1UjAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMTgwNzIz MzZaMCMGCSqGSIb3DQEJBDEWBBTddIZrOThQDxGBsHfz9OY5DpIeYjBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICNVIwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAjVS MA0GCSqGSIb3DQEBAQUABIIBAJA2wH5b7/pJxpM1mEbA9SAnsgZfoIcRxGN4gE4KhC+Oygxo epjyQD7j0z/lQQwblok88vNnMYUzWU6ztw1zb23K6BHggKKzzm+fayu78s+Ng195p5mZt0KE xvZ0ve07i+67CAFEOEE84zBz+SQAE22oPp0k21AQ+vcyEo04+29j1M7WlBdK66f3x3kfD5y/ IAWBoDKdehaba8c0sqH5EbN+o1VFzwUme2Id5QFMqIrPPyNY7dhmYc7Nkbg7tMNN8/uGwK5H lD2qZ4ohU3Us5vg4G75qnz01EyYFDHeaajfbYG5mVDZmn2hFpeO1ujODk81XM2c4tft7fLGL clcoZqcAAAAAAAA= --------------ms030600000009080006010000-- From nobody Wed Mar 18 02:06:27 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 D2C141A1A4F for ; Wed, 18 Mar 2015 02:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 risPuhkcWOiD for ; Wed, 18 Mar 2015 02:06:23 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041B21A00F3 for ; Wed, 18 Mar 2015 02:06:23 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YY9vh-0006dv-DW for ; Wed, 18 Mar 2015 10:06:21 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YY9rT-0005AJ-0W; Wed, 18 Mar 2015 10:01:59 +0100 From: Werner Koch To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B47@uxcn10-5.UoA.auckland.ac.nz> 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 Date: Wed, 18 Mar 2015 10:01:58 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B47@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 18 Mar 2015 03:55:41 +0000") Message-ID: <87a8za1xx5.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] "OpenPGP Simple" 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, 18 Mar 2015 09:06:26 -0000 On Wed, 18 Mar 2015 04:55, pgut001@cs.auckland.ac.nz said: > |len| data |len| data |len| data |0| > > So once you hit a partial length of zero you know you're done. That would indeed make the code easier and is what my pre-OpenPGP implementation did. However we need to support the current huffman like length encoding anyway and thus any easier method benefits only the sender's implementation. I am in favor of simplifying the packet header. The question is how to encode such a new method. The obvious choice is to use bit 7 of the CTB which is currently always set. Using new packet numbers would also be possible but that would extend the already weird encoding. Salam-Shalom, Werner ps. Here is a description of the pre-OpenPGP partial length format: In the old packet header format CTB bits 1 and 0 encode "packet-length length" which these values: the following table: 0 - 1-byte packet-length field 1 - 2-byte packet-length field 2 - 4-byte packet-length field 3 - no packet length supplied, unknown packet length As indicated in this table, depending on the packet-length length bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field are a "packet-length field". The packet-length field is a whole number field. The value of the packet-length field is defined to be the value of the whole number field. A value of 3 is currently used in one place: on compressed data. That is, a compressed data block currently looks like , where , binary 10 1000 11, is an indefinite-length packet. The proper interpretation is "until the end of the enclosing structure", although it should never appear outermost (where the enclosing structure is a file). [Old GPG extension:] A value of 3 for other packets enables a special length encoding, which is used in case, where the length of the following packet can not be determined prior to writing the packet; especially this will be used if large amounts of data are processed in filter mode. It works like this: After the CTB (with a length field of 3) a marker field is used, which gives the length of the following datablock. This is a simple 2 byte field (MSB first) containing the amount of data following this field, not including this length field. After this datablock another length field follows, which gives the size of the next datablock. A value of 0 indicates the end of the packet. The maximum size of a data block is limited to 65534, thereby reserving a value of 0xffff for future extensions. These length markers must be inserted into the data stream just before writing the data out. This 2 byte field is large enough, because the application must buffer this amount of data to prepend the length marker before writing it out. Data block sizes larger than about 32k doesn't make any sense. Note that this may also be used for compressed data streams, but we must use another packet version to tell the application that it can not assume, that this is the last packet. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Mar 18 02:21:34 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 EEBCF1A8788 for ; Wed, 18 Mar 2015 02:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 R4pZwhV4Tv_A for ; Wed, 18 Mar 2015 02:21:23 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BC81A1A4F for ; Wed, 18 Mar 2015 02:21:22 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YYAAC-0006pq-RT for ; Wed, 18 Mar 2015 10:21:20 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YYA4i-0005DB-JF; Wed, 18 Mar 2015 10:15:40 +0100 From: Werner Koch To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> 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 Date: Wed, 18 Mar 2015 10:15:40 +0100 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> (Peter Gutmann's message of "Wed, 18 Mar 2015 03:48:11 +0000") Message-ID: <87619y1xab.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] Character encodings 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, 18 Mar 2015 09:21:29 -0000 On Wed, 18 Mar 2015 04:48, pgut001@cs.auckland.ac.nz said: >>> Just get rid of the notion of text. Make it be all binary. Push the >>> problem up a layer in the software stack -- they have to deal with it >>> anyway, and all OpenPGP can do is make it worse. >> >>+1 > > +2. The rest of the world has made do with the existing infrastructure for +3. The text mode and the different interpretation on how to handle line endings has likely been the most troublesome experience for any implementation. And it still does not work universally (the last LF problem). The drawback will be the loss of the easy to c+p clearsign method. It might be replaced by something MIMEish to still allow for c+p. > (If all else fails, make the contents of the PGP message a MIME body like > S/MIME does, so the processing-flow is "MIME message" (S/MIME data) -> filter > implementing the crypto (in decoded, binary form) -> "MIME message" i.e. PGP/MIME without the requirement of using an armored message. Should be easy to implement in any MUA. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Mar 18 02:23:31 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 5281C1A1A4F for ; Wed, 18 Mar 2015 02:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 Y3IpIw0ypjwM for ; Wed, 18 Mar 2015 02:23:28 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DFB1A0154 for ; Wed, 18 Mar 2015 02:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426670607; x=1458206607; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yLOu1mxNsrbElgWRgHefhkCL1r+pD8fPHBZ/NfCLq9s=; b=lVcwUckewxoQPuKZGI8ytgug1Skj2qSqLFwSxef/C1l8bT65a5eTFQJW kmojBTjJEOHtcfuojzGlhy7IZogx9nhrNVqF/n+Vc7fZv8YtaEQKeGwl3 9Bt+TLfmaQGjOMItrSZZSdUaPVjctu8NhgOGBfW0voZwt8o2w0lNFEGHM k=; X-IronPort-AV: E=Sophos;i="5.11,421,1422874800"; d="scan'208";a="314699606" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Mar 2015 22:23:25 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 18 Mar 2015 22:23:25 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] Character encodings Thread-Index: AdBhXS+Do89mM9OcQseE93V8DbJF4w== Date: Wed, 18 Mar 2015 09:23:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB65C4@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Character encodings 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, 18 Mar 2015 09:23:29 -0000 Werner Koch writes:=0A= =0A= >i.e. PGP/MIME without the requirement of using an armored message. Should = be=0A= >easy to implement in any MUA.=0A= =0A= Precisely.=0A= =0A= Peter.= From nobody Wed Mar 18 02:42:13 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 6D3831A0162 for ; Wed, 18 Mar 2015 02:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs39PiIvSw7b for ; Wed, 18 Mar 2015 02:42:11 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (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 1C2EB1A0103 for ; Wed, 18 Mar 2015 02:42:11 -0700 (PDT) Received: by wggv3 with SMTP id v3so30157984wgg.1 for ; Wed, 18 Mar 2015 02:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kzodZLzRJSX+xjK67IUKJRhCaSbGZMY1oSGGd6hvkZ8=; b=BhkGrY5tQIJuMcJMxldYLviiyAyOSzOUFJ541mhjl+mdWQyY4USOVvdc0d4FSblg1r 6XM7LsKA/JQtHYV06hFLWIhjhSiL4NKbFPJQWoyKqdyAy0AcJbOyPHyzUuX/nl9hnrkk F9SoNjVLnM2/y9UzKvg8deXxS6VM0CKCdzdKN9u+kKRpMyqf9LehRGR1n4pmXH7NAoHM iHTRTjx87tppBrt1q27tZHX/0Ay2nFJ8+4C78i4fbT3/2RfJQpbBqz3769664lako4Gu xMUh8WkSJaNXMLkXzMYbroJVM+5e1k2z2tWbJBiYxiF6F3fsCRMk19bkOni+Tgv5PisS Ys3A== MIME-Version: 1.0 X-Received: by 10.180.107.71 with SMTP id ha7mr5218598wib.23.1426671729949; Wed, 18 Mar 2015 02:42:09 -0700 (PDT) Received: by 10.194.162.6 with HTTP; Wed, 18 Mar 2015 02:42:09 -0700 (PDT) In-Reply-To: <87619y1xab.fsf@vigenere.g10code.de> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> <87619y1xab.fsf@vigenere.g10code.de> Date: Wed, 18 Mar 2015 09:42:09 +0000 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Character encodings 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, 18 Mar 2015 09:42:12 -0000 On Wed, Mar 18, 2015 at 9:15 AM, Werner Koch wrote: > On Wed, 18 Mar 2015 04:48, pgut001@cs.auckland.ac.nz said: > >>>> Just get rid of the notion of text. Make it be all binary. Push the >>>> problem up a layer in the software stack -- they have to deal with it >>>> anyway, and all OpenPGP can do is make it worse. >>> >>>+1 >> >> +2. The rest of the world has made do with the existing infrastructure for > > +3. The text mode and the different interpretation on how to handle > line endings has likely been the most troublesome experience for any > implementation. And it still does not work universally (the last LF > problem). > > The drawback will be the loss of the easy to c+p clearsign method. It > might be replaced by something MIMEish to still allow for c+p. > >> (If all else fails, make the contents of the PGP message a MIME body like >> S/MIME does, so the processing-flow is "MIME message" (S/MIME data) -> filter >> implementing the crypto (in decoded, binary form) -> "MIME message" > > i.e. PGP/MIME without the requirement of using an armored message. > Should be easy to implement in any MUA. Wouldn't anything that can be cut and pasted essentially run in to this problem? I do think there is still utility in having something that is a "clearsign" (that is, human-readable even without OpenPGP software) that can be easily cut and pasted. From nobody Wed Mar 18 02:46:50 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 D4A8B1A87EF for ; Wed, 18 Mar 2015 02:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIX0BmJ-C200 for ; Wed, 18 Mar 2015 02:46:47 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 08F641A8827 for ; Wed, 18 Mar 2015 02:46:46 -0700 (PDT) Received: by wifj2 with SMTP id j2so34368041wif.1 for ; Wed, 18 Mar 2015 02:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=l9rH7DCTZZvri4TdGbxQ0XjP/ObiPAA8T9eRzYthXYM=; b=HPt2xW+gts3T23BGj2k4j9Q0nG7AYkeqHL5dAaW5kdYJd4h+yI176loDnTmKtbg4PU Y2NrfUF3SZK24sbYhleBYWQLDoMMXzUJofobjJ1EQoMJFt0brdq+yuBl3Kcb1aIyZUI2 hsIW9JiLnMkeTzdanqKdJBrHfOf/Y9ClpM9J/XNPago2pUDrpkiCIo4g6gyGa4I2lIYO JfMoX0SnPMGt6htgyqAEo4WL/lfE37xOLprOJjk3/YLWMdI4XM2UW3vCpzLypYxzmqbT VP5QHiqBije4qDeNKH9b4j6c/V8CVhxQ6Jnz7XQlaB9x+OQIwvOwPF026skE7HaIIQBY Nxmw== MIME-Version: 1.0 X-Received: by 10.180.107.71 with SMTP id ha7mr5249345wib.23.1426672005707; Wed, 18 Mar 2015 02:46:45 -0700 (PDT) Received: by 10.194.162.6 with HTTP; Wed, 18 Mar 2015 02:46:45 -0700 (PDT) Date: Wed, 18 Mar 2015 09:46:45 +0000 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] Signing Email Headers 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, 18 Mar 2015 09:46:49 -0000 One issue that comes up again and again is the question of signed email headers. Isn't there an obvious solution -- nest an email message within a PGP/MIME message -- complete with the headers that you want to protect? Message gateways could still add headers as usual as the message went across the net, and of course the To: and From: lines etc. would need to be on the outer message as well, but client software could warn users if (for example) the subject line had been changed or the To and >From lines were different. N. From nobody Wed Mar 18 03:41:27 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 7B2CC1A0016 for ; Wed, 18 Mar 2015 03:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 T8PNbNXkCU2R for ; Wed, 18 Mar 2015 03:41:24 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396DE1A000D for ; Wed, 18 Mar 2015 03:41:23 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YYBPd-0007eR-JO for ; Wed, 18 Mar 2015 11:41:21 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YYBLw-0005Wf-VC; Wed, 18 Mar 2015 11:37:33 +0100 From: Werner Koch To: Nicholas Cole References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> <87619y1xab.fsf@vigenere.g10code.de> 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 Date: Wed, 18 Mar 2015 11:37:32 +0100 In-Reply-To: (Nicholas Cole's message of "Wed, 18 Mar 2015 09:42:09 +0000") Message-ID: <87k2yezj4j.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] Character encodings 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, 18 Mar 2015 10:41:25 -0000 On Wed, 18 Mar 2015 10:42, nicholas.cole@gmail.com said: > Wouldn't anything that can be cut and pasted essentially run in to > this problem? I do think there is still utility in having something Yeah, but we would delegate that to the MIME department and thus simplify OpenPGP itself. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Mar 18 04:49: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 CD3B71A007B for ; Wed, 18 Mar 2015 04:49:15 -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 Fp79QqQhif11 for ; Wed, 18 Mar 2015 04:49:14 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4521A007C for ; Wed, 18 Mar 2015 04:49:14 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 3956CF984; Wed, 18 Mar 2015 07:49:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A684620239; Wed, 18 Mar 2015 04:49:07 -0700 (PDT) From: Daniel Kahn Gillmor To: Nicholas Cole , "openpgp\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 18 Mar 2015 07:49:07 -0400 Message-ID: <87vbhyjzkc.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Signing Email Headers 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, 18 Mar 2015 11:49:16 -0000 On Wed 2015-03-18 05:46:45 -0400, Nicholas Cole wrote: > One issue that comes up again and again is the question of signed > email headers. Isn't there an obvious solution -- nest an email > message within a PGP/MIME message -- complete with the headers that > you want to protect? Please see the thread in this working group titled "Encrypting / Signing the mail subject?" from the last several days for this very topic, including a proposal that should be simpler for non-compliant MUAs to handle than a full embedded e-mail message, while still providing the features you're looking to add. --dkg From nobody Wed Mar 18 04:58:36 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 4D1A81A0060 for ; Wed, 18 Mar 2015 04:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yQ2-x1OJvQF for ; Wed, 18 Mar 2015 04:58:33 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 5E9161A004C for ; Wed, 18 Mar 2015 04:58:33 -0700 (PDT) Received: by wibg7 with SMTP id g7so88135865wib.1 for ; Wed, 18 Mar 2015 04:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BocjDuSDnH1PGOyApfagWNz3PXMBnbTZGW4fPnesQLQ=; b=Ovy0F0Kokoot7mw0UJ96XbGWfbdcvAGYmCrajwHa6hfn1Z9NfglTTSGDtlqgHrS8RV QW5Lm+k3xiZJcncfhfRQ1XQ/KP1esEBb24ps4eEYyq/GTTEKgZ0myz3zXfgCLMDIWo9S BgxfNW/6FaYFoI2AU6IQ6HB8D1SSjX8OhDJTXLABZ+MY2RBusSVNGNzIwmaltOyi0Izx BmOHSTuZ08tTKf0AbTzbCQI7E699x1uNmD394WP/Vj6R1nzMz6qCVnAWWtEdJLx4C40a 5PeI+T0dn6PwOqQInbmnB3bItEYA4cLLTSZfgPegMpHKtVG5+FfFN7NlhOt9BPf9TwEr +n5A== MIME-Version: 1.0 X-Received: by 10.194.48.74 with SMTP id j10mr144122505wjn.38.1426679912086; Wed, 18 Mar 2015 04:58:32 -0700 (PDT) Received: by 10.194.162.6 with HTTP; Wed, 18 Mar 2015 04:58:31 -0700 (PDT) In-Reply-To: <87vbhyjzkc.fsf@alice.fifthhorseman.net> References: <87vbhyjzkc.fsf@alice.fifthhorseman.net> Date: Wed, 18 Mar 2015 11:58:31 +0000 Message-ID: From: Nicholas Cole To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Signing Email Headers 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, 18 Mar 2015 11:58:35 -0000 On Wed, Mar 18, 2015 at 11:49 AM, Daniel Kahn Gillmor wrote: > On Wed 2015-03-18 05:46:45 -0400, Nicholas Cole wrote: >> One issue that comes up again and again is the question of signed >> email headers. Isn't there an obvious solution -- nest an email >> message within a PGP/MIME message -- complete with the headers that >> you want to protect? > > Please see the thread in this working group titled "Encrypting / Signing > the mail subject?" from the last several days for this very topic, > including a proposal that should be simpler for non-compliant MUAs to > handle than a full embedded e-mail message, while still providing the > features you're looking to add. > Thanks. Sorry. I missed that thread. From nobody Wed Mar 18 06:08:31 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 2DD3A1A00E9 for ; Wed, 18 Mar 2015 06:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 5NlZS625_rJ4 for ; Wed, 18 Mar 2015 06:08:28 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (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 773601A0077 for ; Wed, 18 Mar 2015 06:08:28 -0700 (PDT) Received: by ladw1 with SMTP id w1so35458845lad.0 for ; Wed, 18 Mar 2015 06:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ubEw7vwgZQeQz8iNoVSjcBv/iDXP2uTzxQODlpy34iY=; b=kJllZC6wmsxsG7z6L3mmdm0a71gQAywYo86KhKNXNTxvGkE8TwRvFavr/2l+jUXT+C 1HB/gKh2xoakyQ7q0jeIgfaJ9OIm1Rd1eZrsgyBPbeDS5QVbXqupPnbgBSYg6jIKQJ3U RNIH5ZHCTfXLNGQv3PxoW3fbZrVMpXTz3wsY4zZvPIQy+DNSd8gPW7qqAyK/iFJ3Bb5J Yqe85PPmJcP+uqepu1LlZ+RNwMQgRWm6F4aqC0cHuboQ9o9I0dZZqdMKdn5NCE4EpUsc fkg4bou4h2V4Q51IfwbfGvRPMnsskxoCcas/8nyiybwJsv3Zhn/DGYMz6D2dSQA1Hihk /M4w== MIME-Version: 1.0 X-Received: by 10.112.13.7 with SMTP id d7mr1178082lbc.79.1426684106949; Wed, 18 Mar 2015 06:08:26 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Wed, 18 Mar 2015 06:08:26 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 18 Mar 2015 09:08:26 -0400 X-Google-Sender-Auth: jUGAHMmXRBcSM5WW765b7LuR4yI Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a1133d16266c97705118fc777 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Character encodings 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, 18 Mar 2015 13:08:30 -0000 --001a1133d16266c97705118fc777 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 11:48 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > >On Tue, Mar 17, 2015 at 3:44 PM, Jon Callas wrote: > >> One of the things that OpenPGP doesn't do very well that needs to be > fixed > >> is layering. > >>[...] > >> Just get rid of the notion of text. Make it be all binary. Push the > >> problem up a layer in the software stack -- they have to deal with it > >> anyway, and all OpenPGP can do is make it worse. > > > >+1 > > +2. The rest of the world has made do with the existing infrastructure for > getting data from A to B, one way or another, without civilisation > collapsing. > PGP isn't a universal character-format translator, it's an encryption app, > and > should restrict itself to that. Leave the character-set issues to other > layers where they belong. > > (If all else fails, make the contents of the PGP message a MIME body like > S/MIME does, so the processing-flow is "MIME message" (S/MIME data) -> > filter > implementing the crypto (in decoded, binary form) -> "MIME message" > (plaintext) back out to the mail app). > This makes it a lot easier for folk who have an S/MIME implementation to add OpenPGP support. It is also the approach that has been debugged and is known to work with legacy mail infrastructure. One of the main challenges with end-to-end mail is Webmail which is now used by most mail users. It is possible to get end-to-end to work with webmail on the receiver side but it requires a mechanism that allows the server to say 'here is an encrypted blob in format X, decrypt it with the key you hold locally and present it to the user'. On the sender side you need an editing widget that can be called out that will deliver the content to be encrypted. That is going to be easiest to get from the browser community if there is least variation between the E2E email formats. --001a1133d16266c97705118fc777 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 11:48 PM, Peter Gutmann <<= a href=3D"mailto:pgut001@cs.auckland.ac.nz" target=3D"_blank">pgut001@cs.au= ckland.ac.nz> wrote:
Phillip Hallam-Baker <phill@hallambaker.com> writes:
>On Tue, Mar 17, 2015 at 3:44 PM, Jon Callas <jon@callas.org> wrote:
>> One of the things that OpenPGP doesn't do very well that needs= to be fixed
>> is layering.
>>[...]
>> Just get rid of the notion of text. Make it be al= l binary. Push the
>> problem up a layer in the software stack -- they have to deal with= it
>> anyway, and all OpenPGP can do is make it worse.
>
>+1

+2.=C2=A0 The rest of the world has made do with the existing infras= tructure for
getting data from A to B, one way or another, without civilisation collapsi= ng.
PGP isn't a universal character-format translator, it's an encrypti= on app, and
should restrict itself to that.=C2=A0 Leave the character-set issues to oth= er
layers where they belong.

(If all else fails, make the contents of the PGP message a MIME body like S/MIME does, so the processing-flow is "MIME message" (S/MIME dat= a) -> filter
implementing the crypto (in decoded, binary form) -> "MIME message&= quot;
(plaintext) back out to the mail app).

= This makes it a lot easier for folk who have an S/MIME implementation to ad= d OpenPGP support. It is also the approach that has been debugged and is kn= own to work with legacy mail infrastructure.

One o= f the main challenges with end-to-end mail is Webmail which is now used by = most mail users. It is possible to get end-to-end to work with webmail on t= he receiver side but it requires a mechanism that allows the server to say = 'here is an encrypted blob in format X, decrypt it with the key you hol= d locally and present it to the user'. On the sender side you need an e= diting widget that can be called out that will deliver the content to be en= crypted.

That is going to be easiest to get from t= he browser community if there is least variation between the E2E email form= ats.
--001a1133d16266c97705118fc777-- From nobody Wed Mar 18 06:36:55 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 856C11A0120 for ; Wed, 18 Mar 2015 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 W90a1R217axf for ; Wed, 18 Mar 2015 06:36:51 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (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 6F9D81A00E0 for ; Wed, 18 Mar 2015 06:36:51 -0700 (PDT) Received: by lamx15 with SMTP id x15so36206206lam.3 for ; Wed, 18 Mar 2015 06:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0HJzUXe2avLN8TmiAU+B07MwfoT9T4nxN0RJq65Gmtk=; b=vx7t0fuj7ifXiw8aOp3mhMpcyCxOHawkGnz+cC8HWu8I+do9WsktauAfnn0bbj8Usz XQtTec7DHkg1DNvtK0EADdUa6BCBRPmakt7RRq1XwHHcnk/aSOi1y82n1hB6uS8QfZ8I ugzLn8p2pb5WJVEZOiPd+DUfnE2IX6kbVQZWmSJSeBS3ir+F5AyB9XPyXUHq72kCtdUg 6sJdW6ID/iRVEUSgi9ProYk+7FBjlmaFPnMu20pWhXPNM0UtsN+QsVt87vGREeIQM33g 8YH6hTJ2oE1oP0WZTDrbP1XmOQUztSJ0xIEvS9vjMXNf+L4QR+nQZefW5M5x/TMX8MVm lGQw== MIME-Version: 1.0 X-Received: by 10.153.6.35 with SMTP id cr3mr37358768lad.79.1426685809583; Wed, 18 Mar 2015 06:36:49 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Wed, 18 Mar 2015 06:36:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 09:36:49 -0400 X-Google-Sender-Auth: 14i6nRjLLjzejf5U2yMmU-iZQzQ Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11349e2ce2eb570511902c59 Archived-At: Cc: dgil@yahoo-inc.com, Werner Koch , IETF OpenPGP , David Leon Gil , Bill Frantz Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 18 Mar 2015 13:36:53 -0000 --001a11349e2ce2eb570511902c59 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 11:04 AM, Derek Atkins wrote: > Bill Frantz writes: > > > On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote: > > > >>Oh, you expected me to decrypt/re-encrypt my encrypted email as I got > it??? > > > > For many uses, decrypting from the wire format and re-encrypting in > > the "data at rest" security format makes excellent sense. Having only > > one encryption scheme for long-term storage allows easy (relatively) > > upgrade and helps to ensure that the data is still accessible, > > i.e. the decryption still works. I probably have a bunch of old PGP > > encrypted email I can't read anymore because I don't have the secret > > key, or its passphrase. If that mail had been re-encrypted in a format > > that I decrypt every day, I would still be able to read the > > mail. Encryption that isn't regularly exercised gets rusty. > > Show me an MUA that does this, please? None of the OpenPGP-aware MUAs > I've ever used have this feature, as far as I know. I suppose I could > go out of my way to replace the encrypted email with a > re-encrypted/plaintext email. > > But frankly I'd like my encryption software to just maintain the ability > to decrypt it later. > > > Cheers - Bill > > -derek > The only thing I have seen done that is similar is re-signing documents under a stronger signature key. But that is now obsolete since the Harber-Stornetta patents expired and hash chain type schemes are possible. We have considered the underlying problem quite a bit on the cryptography list. There are many problems of key management. For example, do I want people to be able to read some of my emails on death? In an enterprise scenario, I don't want the bank to lose all the emails I sent to my broker because she fell under a bus. There are also many complicating factors. Phones get stolen or lost, etc. etc. This led me to an approach in which each user has a personal PKI hierarchy. This is probably going to look excessive. But solving the use cases requires every bit. If you want to be able to have some part of your communications be proof against court warrants, you need more. 1) A personal offline key signing key. [R] 2) A personal offline recovery encryption key. [R] 3) A personal online key signing key with expiry ~ 10 years 4) A personal mail encryption key [R] that is rotated monthly and escrowed under the personal offline recovery encryption key. In addition each device has a personal message signing key and a key distribution key that are unique to that device and never leave it. So in PRISM-PROOF, the standard configuration begins with six keygens(!) The keys marked [R] may have recovery support. To do this we encrypt the message and store the bits in the cloud. This means we only need to escrow the decryption key somehow. In the case of (1) and (2) this is done with key shares printed out onto paper (and as QR codes). In the case of (4) the key is escrowed under key (2). Each key is wrapped in X.509. Yes, I hate it as much as anyone else. But doing that allows me to use the keys in S/MIME and enroll them in TRANS logs. Yes, there is a lot of complexity. But the user does not see any of it. I would rather have more code complexity than user experience complexity. The user's fingerprint is the hash of (1) which is intended to be potentially a life long master key. By which I mean that it should work for a person's whole life though it is possible it might be superseded in certain circumstances. Now this is probably not something people want to be thinking about in OpenPGP vNext. But it is something you might want to consider as a future convergence possibility. --001a11349e2ce2eb570511902c59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 11:04 AM, Derek Atkins <warlord@mit.edu><= /span> wrote:
Bill Frant= z <frantz@pwpconsult.com>= ; writes:

> On 3/16/15 at 6:51 AM, warlord@MIT.= EDU (Derek Atkins) wrote:
>
>>Oh, you expected me to decrypt/re-encrypt my encrypted email as I g= ot it???
>
> For many uses, decrypting from the wire format and re-encrypting in > the "data at rest" security format makes excellent sense. Ha= ving only
> one encryption scheme for long-term storage allows easy (relatively) > upgrade and helps to ensure that the data is still accessible,
> i.e. the decryption still works. I probably have a bunch of old PGP > encrypted email I can't read anymore because I don't have the = secret
> key, or its passphrase. If that mail had been re-encrypted in a format=
> that I decrypt every day, I would still be able to read the
> mail. Encryption that isn't regularly exercised gets rusty.

Show me an MUA that does this, please?=C2=A0 None of the OpenPGP-awa= re MUAs
I've ever used have this feature, as far as I know.=C2=A0 I suppose I c= ould
go out of my way to replace the encrypted email with a
re-encrypted/plaintext email.

But frankly I'd like my encryption software to just maintain the abilit= y
to decrypt it later.

> Cheers - Bill

-derek

The only thing I have see= n done that is similar is re-signing documents under a stronger signature k= ey. But that is now obsolete since the Harber-Stornetta patents expired and= hash chain type schemes are possible.

We have con= sidered the underlying problem quite a bit on the cryptography list. There = are many problems of key management. For example, do I want people to be ab= le to read some of my emails on death? In an enterprise scenario, I don'= ;t want the bank to lose all the emails I sent to my broker because she fel= l under a bus.

There are also many complicating fa= ctors. Phones get stolen or lost, etc. etc.


This led me to an approach in which each user has a personal PKI h= ierarchy. This is probably going to look excessive. But solving the use cas= es requires every bit. If you want to be able to have some part of your com= munications be proof against court warrants, you need more.

<= /div>
1) A personal offline key signing key. [R]
2) A persona= l offline recovery encryption key. [R]

3) A person= al online key signing key with expiry ~ 10 years
4) A personal ma= il encryption key [R] that is rotated monthly and escrowed under the person= al offline recovery encryption key.

In addition ea= ch device has a personal message signing key and a key distribution key tha= t are unique to that device and never leave it.

So= in PRISM-PROOF, the standard configuration begins with six keygens(!)

The keys marked [R] may have recovery support. To do t= his we encrypt the message and store the bits in the cloud. This means we o= nly need to escrow the decryption key somehow. In the case of (1) and (2) t= his is done with key shares printed out onto paper (and as QR codes). In th= e case of (4) the key is escrowed under key (2).

E= ach key is wrapped in X.509. Yes, I hate it as much as anyone else. But doi= ng that allows me to use the keys in S/MIME and enroll them in TRANS logs.<= /div>


Yes, there is a lot of complexity. = But the user does not see any of it. I would rather have more code complexi= ty than user experience complexity.

The user's= fingerprint is the hash of (1) which is intended to be potentially a life = long master key. By which I mean that it should work for a person's who= le life though it is possible it might be superseded in certain circumstanc= es.


Now this is probably not someth= ing people want to be thinking about in OpenPGP vNext. But it is something = you might want to consider as a future convergence possibility.=C2=A0
=
--001a11349e2ce2eb570511902c59-- From nobody Wed Mar 18 15:13:33 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 4D7BF1A88FD for ; Wed, 18 Mar 2015 15:13:31 -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 GgicZWiF3BKs for ; Wed, 18 Mar 2015 15:13:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 914831A88F0 for ; Wed, 18 Mar 2015 15:13:29 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 603FCF984; Wed, 18 Mar 2015 18:13:25 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 67246201BE; Wed, 18 Mar 2015 15:13:20 -0700 (PDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , Peter Gutmann In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4B37@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 18 Mar 2015 18:13:20 -0400 Message-ID: <87y4mugdj3.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Character encodings 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, 18 Mar 2015 22:13:31 -0000 On Wed 2015-03-18 09:08:26 -0400, Phillip Hallam-Baker wrote: > This makes it a lot easier for folk who have an S/MIME implementation to > add OpenPGP support. It is also the approach that has been debugged and is > known to work with legacy mail infrastructure. > > One of the main challenges with end-to-end mail is Webmail which is now > used by most mail users. It is possible to get end-to-end to work with > webmail on the receiver side but it requires a mechanism that allows the > server to say 'here is an encrypted blob in format X, decrypt it with the > key you hold locally and present it to the user'. On the sender side you > need an editing widget that can be called out that will deliver the content > to be encrypted. > > That is going to be easiest to get from the browser community if there is > least variation between the E2E email formats. Please take a look at the "end-to-end" website API: https://github.com/google/end-to-end/wiki/Website-API I don't think it covers all the cases you describe, but it's nicely concise at the moment, and maybe just needs a few tweaks to be able to reach some of the mechanisms you're looking for. --dkg From nobody Wed Mar 18 15:32:59 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 11AE71A8900 for ; Wed, 18 Mar 2015 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O0USWtoqX66t for ; Wed, 18 Mar 2015 15:32:56 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F4B1A88FD for ; Wed, 18 Mar 2015 15:32:55 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 8A9115FC12 for ; Wed, 18 Mar 2015 22:32:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id 9iVibjnJ8P5u for ; Wed, 18 Mar 2015 22:32:51 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Wed, 18 Mar 2015 22:32:51 +0000 (UTC) Message-ID: <1426717970.4249.16.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 18 Mar 2015 23:32:50 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-2aXy0nDd4iMzUhdU26LH" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Character encodings 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, 18 Mar 2015 22:32:58 -0000 --=-2aXy0nDd4iMzUhdU26LH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-17 at 12:44 -0700, Jon Callas wrote:=20 > Just get rid of the notion of text. Make it be all binary. Agreed 100%,.. OpenPGP should never to any conversions (e.g. for signature verifications), hinting or anything else with respect to "text encoding". The best thing that can happen is that nothing gets worse (cause even if the OpenPGP implementation would do everything right, the MUA or any other application on top/below may still mangle up data). The worst thing that can happen, is that one could trick users/implementations into taking things as signed in a form which they were not intended to be signed, e.g. I deliberately only wanted to have the file with \n EOLs to be signed, but not any \n\r. In such case however, if a "text mode" is identified, the peer's application would also trust that. With character encodings things are probably even worse. All should be binary. Cheers, Chris. --=-2aXy0nDd4iMzUhdU26LH Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxODIyMzI1 MFowTwYJKoZIhvcNAQkEMUIEQJPnoFahTlxS5PZ9vv15UGkAAR6LU8o2myQH57YgxNmrpzpTP19A BCzLeZnxuCWY1eR1e+OBIsR21tuHnWA+tbEwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB8Iy9voDufB2AvGQUiH1oJtlH1fN99 p2pdXhG2ENX5D1H6HJpv5s+sxLtCnqQwrdLKB+/iKtuSGxPPmg6vi/MjaqGgPbVb4FuUVIpa4dGG g4vgm1mfgK8ZsMS4HavvCbiCQBmOvxMUOjmGNnSIsqj7EDIF5/qPpdkmyq3Eryx2465Me8Zt90tB /aUIWX7OjQmWR+Tp9XoAEyVBT+dWms+j4JKeNQbWKVxOBeeIcS0gf3AK5KSCz8lkMgWt4OTsVB2O qOuy3Dk69GzgNty6r0Uj1LGFiKrRBNT8QBcudS5VE0TEcLNipKbT6g4YRN3vvLAdrYC9ji1s7eac KjNXZr4tAAAAAAAA --=-2aXy0nDd4iMzUhdU26LH-- From nobody Wed Mar 18 15:39:05 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 DFD751A8906 for ; Wed, 18 Mar 2015 15:39:04 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 rUmbP37KGyhR for ; Wed, 18 Mar 2015 15:39:03 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 479D81A8905 for ; Wed, 18 Mar 2015 15:39:03 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YYMc7-0006iH-8e; Wed, 18 Mar 2015 18:38:59 -0400 Date: Wed, 18 Mar 2015 15:38:59 -0700 From: Bill Frantz To: Falcon Darkstar Momot X-Priority: 3 In-Reply-To: <550927F8.7080504@iridiumlinux.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec794e84a18e20d5e2ffc352dd3827deca47350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 18 Mar 2015 22:39:05 -0000 The software works fine. The user has either lost the secret key=20 file or has forgotten the passphrase. I don't know a technical=20 solution, particularly to the 2nd problem. Any suggestions? Cheers - Bill On 3/18/15 at 12:23 AM, falcon@iridiumlinux.org (Falcon Darkstar=20 Momot) wrote: >No! This is the kind of attitude that got OpenPGP into its current >usability mess! > >On 17/03/2015 16:11, Bill Frantz wrote: >>> But frankly I'd like my encryption software to just maintain the abilit= y >>> to decrypt it later. >> >>Well, the problem isn't the software. It is the user. >> >>Cheers - Bill >> >>----------------------------------------------------------------------- >>Bill Frantz | I don't have high-speed | Periwinkle >>(408)356-8506 | internet. I have DSL. | 16345 Englewood Ave >>www.pwpconsult.com | | Los Gatos, CA 95032 >> >>_______________________________________________ >>openpgp mailing list >>openpgp@ietf.org >>https://www.ietf.org/mailman/listinfo/openpgp > > > > >----- >_______________________________________________ >openpgp mailing list >openpgp@ietf.org >https://www.ietf.org/mailman/listinfo/openpgp > ----------------------------------------------------------------------- Bill Frantz | Security is like Government | Periwinkle (408)356-8506 | services. The market doesn't | 16345=20 Englewood Ave www.pwpconsult.com | want to pay for them. | Los Gatos,=20 CA 95032 From nobody Wed Mar 18 15:43:23 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 280731A90F2 for ; Wed, 18 Mar 2015 15:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BU00tXJYJptQ for ; Wed, 18 Mar 2015 15:43:19 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523841A90E6 for ; Wed, 18 Mar 2015 15:43:19 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 0BAC85FC59 for ; Wed, 18 Mar 2015 22:43:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id k7ecGkCaVZQs for ; Wed, 18 Mar 2015 22:43:16 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Wed, 18 Mar 2015 22:43:16 +0000 (UTC) Message-ID: <1426718594.4249.23.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 18 Mar 2015 23:43:14 +0100 In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-WcRxf6H71AMhJ5pIxudd" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 18 Mar 2015 22:43:21 -0000 --=-WcRxf6H71AMhJ5pIxudd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-03-16 at 23:48 -0700, Jon Callas wrote: > ASCII armor ends up being a nice way to encode something so you don=E2=80= =99t > have to play "guess the binary format." But isn't that basically the same case as with the character encoding thread?! In the sense of: It's not OpenPGPs task to fix other applications/protocols! If these need to use OpenPGP messages and they don't support binary formats (which by itself is fine), then their own native means for converting blobs into a suitable form should be used (e.g. XML's or whichever) and if no such form exist, we should at best give a recommendation about what to use (in the sense of referring to something else). Especially I don't like the idea that applications out there may use the ascii armor's enclosing (i.e. the ---- PGP ... ----) to detect "this is a PGP message". There should be other things around in the protocol that uses OpenPGP which specifies that (e.g. Content-Type: headers). I think it would be theoretically[0] fine if a future OpenPGP standard specifies multiple native formats, e.g. a binary one as we have right now, a XML representation and whatever other ugly things (JSON?! ;-) ) people might want... but the ASCII armor isn't a real native format but just an encoding, and that shouldn't be OpenPGPs duty. Cheers, Chris. [0] In practise, though, there should be really strong reasons if more than one such native format would be defined. --=-WcRxf6H71AMhJ5pIxudd Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxODIyNDMx NFowTwYJKoZIhvcNAQkEMUIEQLvIxghCMwGt8ptd7HPWG7oi86e84/nXstqDUEZ2ECUwTjK5R2ZG HEYbf4sqdXShTn+k3aqPtgqvvD1odxXyspUwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAJqu/yYAXa0/xT3mGw0zje+dYEOzI2 IBNnQZAakkrj5MJ/t9A1cMYyrvG3mhbCIKyBl1VSABWNwY1hzjx1IjTrMn2DbYklU3qkobcjH5GE eDvfK7i81kP7egh4XnVZS21ArFn5Lo2ybk8DN/phqeRTStSSsCS87WhYYsW6C9PBcZ3Qt6N1C8PS 1tl/A2z6YnHxj6K60qzbcqgjcgt64Lm8tDNWKn5tOSmfr7FFeYdSvMHYd1+eLl11Cf8IahEFUSok 5ctcW5OXiTWMi6VS3HS6N4i4z/ex/okxcnrrG83ItdBDtQ1VE/1urW3l4t9HZI1otXSCIrsF4ZK1 fXbAYYlRAAAAAAAA --=-WcRxf6H71AMhJ5pIxudd-- From nobody Wed Mar 18 15:51: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 43C751A891A for ; Wed, 18 Mar 2015 15:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1aW900oHC9w8 for ; Wed, 18 Mar 2015 15:51:54 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB391A8908 for ; Wed, 18 Mar 2015 15:51:53 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw02.dd24.net (Postfix) with ESMTP id 8B4C95FBA4 for ; Wed, 18 Mar 2015 22:51:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id LlRAA9dHwT8s for ; Wed, 18 Mar 2015 22:51:50 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Wed, 18 Mar 2015 22:51:50 +0000 (UTC) Message-ID: <1426719109.4249.28.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 18 Mar 2015 23:51:49 +0100 In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-0bG05k6XWYKeE1j9F1kN" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 18 Mar 2015 22:51:55 -0000 --=-0bG05k6XWYKeE1j9F1kN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-17 at 10:30 -0400, Phill wrote: > Do not build OpenPGP around assumptions based on SMTP continuing > forever. +1, especially since I there are still many people here mentioning mail/SMTP and their restrictions/issues/problems quite often. A future OpenPGP (core) standard should try to avoid solving the issues/limitations of any other standard/protocols. That being said, I also don't like the idea of mail header signing/encryption. It's simply not OpenPGP's task and one should rather create an amendment for the mail standards or MIME which describes how an OpenPGP signed/encrypted headers would be embedded in an mail. Cheers, Chris. --=-0bG05k6XWYKeE1j9F1kN Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxODIyNTE0 OVowTwYJKoZIhvcNAQkEMUIEQEY5/hcqhBp6dN/VLEWlNgNf86fpHxbE97CsCCrvpvIobTsEFy3F dAFbDBjZKb5jv3ELkRV3h6itlFhfHdKLFoowagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCHIr/YPwvfLPyh4645/9XAJjWG7Cmx az+EnrhabMPI4G6jKkauyIhtcnj7qxIEaW8jDrqUwOzkU1VnA7ssAk/SqoXZ5aKNYko8XumUwU0F 0QbTjlr1FqMBAhvt+XmD0/EQQUl8iJGQoqGHd7P7W7SkU4T/1oYZbSZ3r7KDXpUZTm5pjS+6rfsn r+9jOmWYkMpZO9t0/2D6oPxUhQS1PX+BYFgFVr/cP1ulXKP6he12x4rSCoAZPR4WE6tiK4yQfOef M3vCaK09LUCCcXPXlzEzPV2Z2ED1HkMxWnCCQEOn+uXMChVQdfvm+9TggPoPIDrxEDRtymPoXGpw PhAMc789AAAAAAAA --=-0bG05k6XWYKeE1j9F1kN-- From nobody Wed Mar 18 16:05:09 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 4BFD31A8931 for ; Wed, 18 Mar 2015 16:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EhNP5mz5aIUL for ; Wed, 18 Mar 2015 16:05:05 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845661A892A for ; Wed, 18 Mar 2015 16:05:05 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 648505FC33 for ; Wed, 18 Mar 2015 23:05:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id 3__dj_W1Dwot for ; Wed, 18 Mar 2015 23:05:02 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Wed, 18 Mar 2015 23:05:02 +0000 (UTC) Message-ID: <1426719900.4249.40.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 19 Mar 2015 00:05:00 +0100 In-Reply-To: <5507E916.4040307@sumptuouscapital.com> References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-QL3GyvDkKB/jyPvXqi1I" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 18 Mar 2015 23:05:07 -0000 --=-QL3GyvDkKB/jyPvXqi1I Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-17 at 09:43 +0100, Kristian Fiskerstrand wrote:=20 > I fail to see how this behaviour is either dangerous, Take 0x10 as example: > The issuer of this certification does not make any particular=20 > assertion as to how well the certifier has checked that the owner > of the key is in fact the person described by the User ID. Implementation A: may interpret this as "can also include signatures, where NO check has been made at all" and thus it might use it to sign other keys (for whatever reason, e.g. a key-pinning-like method), since it expects that no other implementation would use such sigs anyway Implementation B: may interpret this as "the certifier has checked the identity, but simply doesn't want to tell, how well he has done so" Such implementation might then use the untrustworthy sigs from A. Well a bit made up,... but I guess you can see what I mean. > The > signatures (except for 0x11) are treated the same by the > implementations, which is fine. Which also shows that they're basically useless. > The information is still useful as > metadata when performing manual analysis of a certification network > and depends on a published certification policy by the issuer. I disagree, if a user wants to tell under which circumstances he certified another user/key, hey can do so via the policy URL and in fact this is the only way for analysis to find out what the certification means to the certifier. Using the different signature levels as metadata for certification network analysis would only produce meaningful results, if all would have agreed upon the same meaning for these different levels - which is not the case. > The > uses not being explicit in the RFC does not mean they are vague and > ambiguous, just that they are defined on a per-context / per-CA basis Which again is the Policy URL, but then you don't need different levels of user sigs (at least not all of them), just do something like: http://me.com/pgp-policy?keyfp=3D and you can give back per signature policy information. Cheers, Chris. --=-QL3GyvDkKB/jyPvXqi1I Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxODIzMDUw MFowTwYJKoZIhvcNAQkEMUIEQIwxoOnZV2oiH5YG/R9r5+1Q5IFBwLN0etmotXGVXU//9a/A5kjX UOpd9MtfjZaOZBjzvyh+YMOhSK3CfDwaLIQwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCWBHewzqzwHGAj9MPRK3Y1fM0MsLi3 kQr1+hs00pLoxbGxMIf06CPFp4HSXnAhtki6QWlXDyoEd17L7uF1/Z1F6J4jEgcCBO2EVIPPHjNm rYaqLIVOopWO1Ylx/Qv0+MAP7x8LLEydAiZTO/kIWWpK9IkpPB9qldCWVbCOfTc+q9R3DiIb1aIq UzU7TgvaNpFX0LdL2B1s2nzN90TD4Dnj+iFh9k+3EuKmpiwLV8qEn/QC5yuu0vco773oLwYLkBNw A0P8S8fJEbK9d8haNUOCTIvoxnLHRR1gIIVcKuPInfxzmlPn2tQ5N8OMG6wAhM8P8RsJr9eFNQy7 pQdpxCqZAAAAAAAA --=-QL3GyvDkKB/jyPvXqi1I-- From nobody Wed Mar 18 16:33: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 A2FEF1A913E for ; Wed, 18 Mar 2015 16:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Nv64hTnsnoJm for ; Wed, 18 Mar 2015 16:33:00 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 E30811A913F for ; Wed, 18 Mar 2015 16:32:59 -0700 (PDT) Received: by lbnq5 with SMTP id q5so13015820lbn.0 for ; Wed, 18 Mar 2015 16:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=i0MsLZnykaj9u95ZbYKoRwcBI3MUEPH8bvTLtBdQAHg=; b=BNyLkfBLIpsuyaRCy4hv9ffRPgVXFayhzrv20INEqPi/Go0R158QtgttK+1u6Jo2dF bc6mdN1qe4Z4j5uc+IK23PtcNsWKyi3i8km8An3te4pPuDHr9lVYAjEENoZIPOSixod4 Q4DJ24GIh7RChCTrsrAxYATc9URN8OsZUcl/vQqFVDeXvJ82IwTIOmm0WI5po2yUl/At Wl5wnU7Kh4sA4cR4+VfKnT6xSO7GuQuxXbdZrYh73YjysgsN3SFl2y3tjAVYzF0UwhiM RVAUgwhDAH/3/Cu7PRYxAdabhAKO4evyaf2DcTkqepZ61kS6tqzSJ6x5AnXpSl2i3AtB Fz7Q== MIME-Version: 1.0 X-Received: by 10.152.120.8 with SMTP id ky8mr64017590lab.118.1426721578429; Wed, 18 Mar 2015 16:32:58 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Wed, 18 Mar 2015 16:32:58 -0700 (PDT) In-Reply-To: <1426719109.4249.28.camel@scientia.net> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> <1426719109.4249.28.camel@scientia.net> Date: Wed, 18 Mar 2015 19:32:58 -0400 X-Google-Sender-Auth: emQTTB3WUmMC5OWC1_H8FMrOZTw Message-ID: From: Phillip Hallam-Baker To: Christoph Anton Mitterer Content-Type: multipart/alternative; boundary=089e0122aef8e035520511988006 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] "OpenPGP Simple" 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, 18 Mar 2015 23:33:01 -0000 --089e0122aef8e035520511988006 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 18, 2015 at 6:51 PM, Christoph Anton Mitterer < calestyo@scientia.net> wrote: > On Tue, 2015-03-17 at 10:30 -0400, Phill wrote: > > Do not build OpenPGP around assumptions based on SMTP continuing > > forever. > +1, especially since I there are still many people here mentioning > mail/SMTP and their restrictions/issues/problems quite often. > > A future OpenPGP (core) standard should try to avoid solving the > issues/limitations of any other standard/protocols. > > > That being said, I also don't like the idea of mail header > signing/encryption. > It's simply not OpenPGP's task and one should rather create an amendment > for the mail standards or MIME which describes how an OpenPGP > signed/encrypted headers would be embedded in an mail. > I think that it is now widely agreed that if SMTP was to be revised, it would be separated into two layers with the message routing headers in one section and the content meta-data in another. Subject, To, From, Content-Type, etc. are all content headers. They have nothing to do with SMTP. They are only used by the MUA. As a general rule, if a fix works for S/MIME and OpenPGP, then we can probably be fairly confident it will work for SMTPvNext as well. --089e0122aef8e035520511988006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 18, 2015 at 6:51 PM, Christoph Anton Mitterer <calesty= o@scientia.net> wrote:
On Tue, 2015-03-17 at 10:30 -0400, Phill wrote:
> Do not build OpenPGP around assumptions based on SMTP continuing
> forever.
+1, especially since I there are still many people here mentioning mail/SMTP and their restrictions/issues/problems quite often.

A future OpenPGP (core) standard should try to avoid solving the
issues/limitations of any other standard/protocols.


That being said, I also don't like the idea of mail header
signing/encryption.
It's simply not OpenPGP's task and one should rather create an amen= dment
for the mail standards or MIME which describes how an OpenPGP
signed/encrypted headers would be embedded in an mail.

I think that it is now widely agreed that if SMTP was to be= revised, it would be separated into two layers with the message routing he= aders in one section and the content meta-data in another.

Subject, To, From, Content-Type, etc. are all content headers. The= y have nothing to do with SMTP. They are only used by the MUA.=C2=A0
<= div>
As a general rule, if a fix works for S/MIME and OpenPGP= , then we can probably be fairly confident it will work for SMTPvNext as we= ll.



=C2=A0
--089e0122aef8e035520511988006-- From nobody Wed Mar 18 16:33: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 B5C031A914B for ; Wed, 18 Mar 2015 16:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 cMfOdz5itEeG for ; Wed, 18 Mar 2015 16:33:41 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 64A191A9163 for ; Wed, 18 Mar 2015 16:33:33 -0700 (PDT) Received: by lbnq5 with SMTP id q5so13021910lbn.0 for ; Wed, 18 Mar 2015 16:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/nh7NK4rHdwXfYBWhKYHShKzddri/+Gn4mF9WqpWy6Q=; b=lMLX8LJvXkRxO9WPbdKxyRZm6xdERg43Qs8qeKI1AocPFupOi06Z0ePlste29hDUFC QYrBuBWRtLqZItHZsiPdpc+PUFhOazk3vMGzYknELpw52i1/8gR8xztx4cB57aJLrUtj uSOIs67CovUPYMjY7oBcAhvITzBn7N4QK3cVktc1ENd/w7HNVK/tdQ6BHdezO4KTQtGa XEDJjwezJ3CTP6iWdmRENYDDoihfQnKePXToVvKz2MSSxzqli1mOyBEnJA5lmCkWeITG PansOsZnfO4CQvnda+kgDaFV0RTTB3cAGKQW0zifVEVuWsD28lStfra70mvkz/wkztAh 4lmQ== MIME-Version: 1.0 X-Received: by 10.152.191.135 with SMTP id gy7mr65004087lac.91.1426721611885; Wed, 18 Mar 2015 16:33:31 -0700 (PDT) Received: by 10.112.45.203 with HTTP; Wed, 18 Mar 2015 16:33:31 -0700 (PDT) In-Reply-To: <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> Date: Wed, 18 Mar 2015 19:33:31 -0400 Message-ID: From: Phillip Hallam-Baker To: David Shaw Content-Type: multipart/alternative; boundary=001a1134303adeb57b051198821a Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 18 Mar 2015 23:33:42 -0000 --001a1134303adeb57b051198821a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 16, 2015, at 11:05 PM, David Shaw wrote: On Mar 16, 2015, at 10:10 PM, Peter Gutmann wrote: David Shaw writes: On Mar 16, 2015, at 5:15 PM, David Leon Gil wrote: Partial lengths are really a nuisance to parse. No argument there... The whole bizarro sort-of-fixed-point encoding of lengths is a pain (this is a cue for Jon to do his "every bit is sacred" dance). If the format is revised, there should be only two lengths, a 16-bit one for almost everything (keyring data, signatures, etc), and a 32-bit one for payloads and partial lengths that are going to exceed 16-bit lengths. Length-decoding shouldn't be any more complicated than: read tag; if( tag & length_32_flag ) length =3D read32(); else length =3D read16(); I'm fine with that, but I do want to keep the concept of partial lengths, as you did above. People do encrypt things without knowing how large they are ahead of time. I'm fine with a restriction (which already exists today) that only payloads can use partial lengths. +1 But that 32 bit length really worries me. Just because people can=E2=80=99t= send 4GB messages today does not mean that they can=E2=80=99t or won=E2=80=99t i= n the future. Do not build OpenPGP around assumptions based on SMTP continuing forever. Use today is not limited to mail in any case. If I have a 1TB archive file I am not going to want to break it into chunks just to encrypt it. I am not convinced a complete overhaul of the messaging format is desirable. But if people were going to completely revise the message format, the field is moving towards JSON for almost everything. The only thing JSON does not do that is essential for crypto is length prefixed binary encoding of binary blobs. Base64 encoding is not so bad if you do it only once. But a 33% penalty for each time a file is wrapped starts to add up. When folk were suggesting yet another data encoding, several of us who only want one data model suggested just adding code points for binary blobs to JSON. It does get the job done. Again, I am not sure that a complete overhaul is desirable. Just pruning back the unnecessary features is probably sufficient. But if a change is made, best to pick something that looks as much like the standard the rest of the protocol stack above layer 5 is converging on as possible. --001a1134303adeb57b051198821a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mar 16, 2015, at = 11:05 PM, David Shaw <dshaw@jabberwocky.com> wrote:

On Mar 16, 2015= , at 10:10 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:

David Shaw <dshaw@jabberwocky.com> writes:
On Mar 16, 2015, at 5:15 PM, David Leon Gil <coruus@gmail.com> wrote:
Partial lengths are really a nuisance to parse.
=

No argument there...

The whole bizarro= sort-of-fixed-point encoding of lengths is a pain (this is a
cue for Jo= n to do his "every bit is sacred" dance).=C2=A0 If the format is = revised,
there should be only two lengths, a 16-bit one for almost every= thing (keyring
data, signatures, etc), and a 32-bit one for payloads and= partial lengths that
are going to exceed 16-bit lengths.=C2=A0 Length-d= ecoding shouldn't be any more
complicated than:

read tag;
= if( tag & length_32_flag )
length =3D read32();
else
length = =3D read16();

I'm fine with that, but I do want to = keep the concept of partial lengths, as you did above.=C2=A0 People do encr= ypt things without knowing how large they are ahead of time.=C2=A0 I'm = fine with a restriction (which already exists today) that only payloads can= use partial lengths.


+1=C2=A0

But that 32 bit length really worries me. Just because p= eople can=E2=80=99t send 4GB messages today does not mean that they can=E2= =80=99t or won=E2=80=99t in the future. Do not build OpenPGP around assumpt= ions based on SMTP continuing forever. Use today is not limited to mail in = any case.

If I have a 1TB archive file I am not going to want to break it int= o chunks just to encrypt it.


I am not = convinced a complete overhaul of the messaging format is desirable. But if = people were going to completely revise the message format, the field is mov= ing towards JSON for almost everything.
<= br>
The only thing JSON does not do that = is essential for crypto is length prefixed binary encoding of binary blobs.= Base64 encoding is not so bad if you do it only once. But a 33% penalty fo= r each time a file is wrapped starts to add up. When folk were suggesting y= et another data encoding, several of us who only want one data model sugges= ted just adding code points for binary blobs to JSON. It does get the job d= one.


Again, I am not sure that a compl= ete overhaul is desirable. Just pruning back the unnecessary features is pr= obably sufficient. But if a change is made, best to pick something that loo= ks as much like the standard the rest of the protocol stack above layer 5 i= s converging on as possible.

--001a1134303adeb57b051198821a-- From nobody Wed Mar 18 16:38:11 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 0786C1A0194 for ; Wed, 18 Mar 2015 16:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7k9kkzB2Z2mt for ; Wed, 18 Mar 2015 16:38:07 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778281A9170 for ; Wed, 18 Mar 2015 16:38:07 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw02.dd24.net (Postfix) with ESMTP id 576275FC49 for ; Wed, 18 Mar 2015 23:38:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id LLoXu38EHp4n for ; Wed, 18 Mar 2015 23:38:04 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Wed, 18 Mar 2015 23:38:03 +0000 (UTC) Message-ID: <1426721882.4249.72.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 19 Mar 2015 00:38:02 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-ySQJaBO+BHHGUQTr7uLY" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] New encryption formats for messaging 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, 18 Mar 2015 23:38:10 -0000 --=-ySQJaBO+BHHGUQTr7uLY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-03-13 at 17:41 -0700, David Leon Gil wrote:=20 > A0. Be as secure as possible by default. Do not offer options to > fallback to doing unsafe things. "Experienced" users often think they > want them; there are usually better solutions for their use-cases. Yes and no. Looking at the context you come from (Yahoo) I must note, that the big players seem to have discovered security recently ... o.O And part of their marketing strategy seems to be "security must be easy" (i.e. a totally unaware person should be able to be "secure"). This is basically the same what some people around the heise Verlag seem to campaign for recently. While this sounds like a great goal it's completely unrealistic. Someone who doesn't at least know some basic concepts will never be secure, because he'll believe any social engineering and the first mail telling him to just fetch the "unknown key from website X or keyserver Y" will be followed. Many of my less crypto-aware friends use nowadays things like TextSecure/etc. on their mobiles, believing they're secure. Well first it's Android (so failed) and second, none of them knows about the basic principle that one *is not* secure if not some form of mutual authentication hasn't taken place via some secure path (i.e. not first-come-is-trusted like key pinning). To be honest, Yahoo, doesn't have the best security record, and in general I wouldn't trust any web-based crypto app regardless of who it wrote. That being said, I agree that it shouldn't be easy to make a well designed crypto system insecure by settings - but not if this means that one takes away valid functionality from the more experienced users. And definitely not for marketing reasons. > A1. Only specify a single asymmetric encryption scheme and a single > asymmetric signature scheme. This is critical: This is the second most > dangerous and buggy code in any crypto scheme. Why? a) What's the problem a with symmetric scheme as we have it now? b) Why should there be only one? I think its a wrong assumption that code will become more secure by supporting less algos/systems. If a project cannot develop/maintain more of them securely it's rather a sign for lack of funding/manpower. The past has shown that sooner or later every algorithm (except for OTP of course ;) ) has its flaws and is needed to be replaced. Quite often recently, people waited far too long till that replacement started (just look at the issues in SSL/TLS). Since the experience has shown that standardisation of something new takes quite a while (see the discussions about Curve25519 at the CFRG) I would feel much better if a cryptosystem has several algorithms (ciphers, signature schemes, hash algos, etc.) ready in place. Implementations can still strongly suggest only a small subset to be actually used - but *if* some problem is found in these, it wouldn't take ages to get rid of them (like RC4, basically all the old CBC and non-EtM algos in SSH, TLS,... hell we still have systems in the wild which use MD5 for security purposes) > A2. Clearly separate handling of various message and key metadata from > the underlying encryption scheme. This is critical: Parsing code is > the most dangerous and buggy code in any crypto scheme. It's a bit unclear to me, what exactly you mean here. > A3. Do not specify things which are infeasible to thoroughly test. > This implies avoiding combinatorial complexity, which the OpenPGPv4 > spec doesn't. As above, I doubt you can really check every combination, and I wouldn't want to sacrifice too much, just for being able to do so - especially not diversity of algorithms. > A4. All messages, including signed but unencrypted messages, should be > indistinguishable from random to an adversary who does not know the > public key of the signer. (This is, essentially, a Tor-style security > requirement.) By "messages" you mean "OpenPGP Messages" i.e. also they keys? > B1. Only modern hash functions that provide a significant security > margin against cryptanalysis. Let's not repeat the MD-5/SHA-1 > disaster. (We only need two hash functions at most.) Disagreeing with the "We only need two hash functions at most.". Diversity is good (of course we should only include secure algos), especially when one expects that each algo sooner or later sees weaknesses. > B2. Only block and stream ciphers that offer a significant margin of > safety against cryptanalysis. (Or that, when composed, offer a > significant margin of safety against cryptanalysis.) >=20 > B3.. A single AEAD mode that is maximally misuse-resistant, in the > sense of https://eprint.iacr.org/2014/793. (But probably not AEZ, or > any other CAESAR competitor for that matter. I would prefer a scheme > that uses generic composition of well-studied primitives.) >=20 > Thus, what any proposal should specify, at the crypto level: >=20 > C1. A single curve providing security above the 192-bit-equivalent > level. (This is because the *tightest* security reductions for any > concrete instantiation of EC primitives result in a security level of > ~ 120-bits for a 384-bit curve.) Same as above for all the "single foo" demands.=20 > C2. A single message format intended for use with signed and encrypted > messages of length >> 128 bytes and << 2^24 bytes. (That is, something > appropriate for email. I would consider encryption of large files and > very short messages out of scope at this time.) I am agnostic as to > whether encrypted-then-signed or signed-then-encrypted is preferable. > I am curious if anyone else has strong views on this? You're aware that OpenPGP isn't just for mail respectively what Yahoo want's to do with it? > C3. A single message format intended for detached signatures. This > should target, specifically, the common use-case of OpenPGP signatures > for code-signing. No strong opinions here. The only thing important is that we warn implementors about the typical issues (see the InRelease hacks within Debian, or the problems with the --verify option in GnuPG with detached sigs but only one argument) > C4. Specify a mechanism for encapsulating a signature over the body of > an HTML email in a way that is compatible with HTML email as commonly > used. This signature should be indifferentiable from random for anyone > who does not know the public key of the sender. Not the task of OpenPGP - we're not a mail standard only. > (This last should be easy. A concrete proposal: If a > "data-openpgp-sig" attribute is present on a tag, it contains a > base64urlsafe-encoded signature over the contents of that tag, with no > special normalization rules applied. This can be made more precise by > reference to the HTML5 spec.) Isn't that also out of the scope of an OpenPGP standard? > The IETF lately has not seemed to be so much about canonizing "de > facto" standards (which it was good at) as design-by-committee (which > it isn't). And recent revelations have shown that design-by-committee > is -- besides being irritating for implementors -- a boon to > intelligence agencies. Well it doesn't seem to me as if IETF would make bad work here and I'd see no reason to pull the standardisation to some other body. And "not helping the NSA comments" from a US company?! ;-) > So: I would encourage anyone interested in seeing something > standardized to make a complete proposal a la Hugo Krawycz's OP-TLS > proposal for TLS1.3. But implement the proposal first. Working code > &c. off topic: That approach is IMHO much more problematic with respect to potentially evil orgsanisations/people, since those who do the code, spread it in the wild before it was discussed by experts make quite some pressure to have their ideas being used (see e.g. SPDY). > Yahoo will not support a specification that, by sloppiness or > untestability, makes our users unsafe. Apart from the fact that this sentence makes me smile (just searching through the heise archive for security issues at Yahoo ^^): I guess someone else has already mentioned that it's really not appropriate that someone of the "big players" (even though I wouldn't call any of Google/Yahoo/MS big players for people who want *real* security ;) ) try to make any kinds of pressure here. Cheers, Chris. --=-ySQJaBO+BHHGUQTr7uLY Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxODIzMzgw MlowTwYJKoZIhvcNAQkEMUIEQPfhyDoUZ/Dcz7vm8rU0sWmSWK65sDpxuzsB8sJWxRS1jC8US3x8 x75RlA4QJsmNpFq+RSQBBwMzuIKGyVtnMoEwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBeNOZo+NjkZdvK6lfGNkglefxZyFcE NmusZj1edFMDpSIeQt74vLV8f+hnnUc2f259/5TaLvb9svkyz9ST08mmh+qcwN4Azbk/z69LQw00 xcjodaoNUWDO1J6eQMEsrG2VTDByTVIHPfoCf+Euel5goA3wFwzBOkmxUVoKgPmE91ulmZcvZRA5 TbHL6vPQXQmT0K6bF8fpW0+pk3RzidcS5L11+e/w8ngTn0HRlwKl/7pQLdsgCDeWXYSyrhKCqq2A stprQriTRnMKFfyZA6JWlrZmhWXta37SvItFMXzsvl+S752EUE8sfJ4S6CYKL0cAbpdii2mzDFjH JpY+O8vVAAAAAAAA --=-ySQJaBO+BHHGUQTr7uLY-- From nobody Thu Mar 19 11:00:47 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 7234D1A8771 for ; Thu, 19 Mar 2015 11:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 aN34vL_amDzU for ; Thu, 19 Mar 2015 11:00:43 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F8C1A88F6 for ; Thu, 19 Mar 2015 11:00:29 -0700 (PDT) X-AuditID: 12074425-f79846d0000054e1-b2-550b0ebbd531 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.C3.21729.BBE0B055; Thu, 19 Mar 2015 14:00:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2JI0RRA009017; Thu, 19 Mar 2015 14:00:27 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2JI0OHu026733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Mar 2015 14:00:26 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2JI0Oq6007128; Thu, 19 Mar 2015 14:00:24 -0400 (EDT) Date: Thu, 19 Mar 2015 14:00:24 -0400 (EDT) From: Benjamin Kaduk To: Christoph Anton Mitterer In-Reply-To: <1426719900.4249.40.camel@scientia.net> Message-ID: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com> <1426719900.4249.40.camel@scientia.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrLubjzvUYMkVc4uPt6+wWDT8e8ju wOSxZMlPJo+ONyuZA5iiuGxSUnMyy1KL9O0SuDLe3z7HXPCUpeLZtK9MDYxPmLsYOTkkBEwk Lp+dygRhi0lcuLeerYuRi0NIYDGTxMtdDcwQzkZGidev7kFlDjFJzPhwHirTwCixf/ItRpB+ FgFtiXtrH4LNZRNQkZj5ZiNQBweHCNCOjx9SQUxmARGJO4ctQUxhATOJ2VddQYo5gQoW9T0G a+QVcJBYfryBEWL6PCaJqVe2gSVEBXQkVu+fwgJRJChxcuYTMJtZQEti+fRtLBMYBWchSc1C klrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMjKFDZXVR3ME44pHSIUYCD UYmHN8OdK1SINbGsuDL3EKMkB5OSKK8sD3eoEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeeYxA Od6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd5qXqBGwaLU9NSKtMyc EoQ0EwcnyHAeoOEZIDW8xQWJucWZ6RD5U4y6HHem/F/EJMSSl5+XKiXO2wpSJABSlFGaBzcH lmBeMYoDvSXMuxykigeYnOAmvQJawgS05F8tF8iSkkSElFQDo3Gd4akO12daGjUil+U+WLvc l8g6ea7nzalfW+effPVGpOL0nnPXGVRsJ09Zvmbyih7HudMit7cpTIkyPi1yyWi9bP0t+cW3 7Nbz//B4L1CTnOHGmNPy5+1Z7XhH6Tk7LRfu0Fgzw4XX469AieH0db3s99ojK7OfMj7fvfMS T9M+jU3Z8qeKVZRYijMSDbWYi4oTAc0+2dQLAwAA Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 19 Mar 2015 18:00:45 -0000 On Wed, 18 Mar 2015, Christoph Anton Mitterer wrote: > > > The information is still useful as > > metadata when performing manual analysis of a certification network > > and depends on a published certification policy by the issuer. > I disagree, if a user wants to tell under which circumstances he > certified another user/key, hey can do so via the policy URL and in fact > this is the only way for analysis to find out what the certification > means to the certifier. What happens when the policy listed at the policy URL changes? It seems that a local resource would be needed. -Ben Kaduk From nobody Thu Mar 19 11:11:09 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 7F2931A8AAF for ; Thu, 19 Mar 2015 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jrDKWy-QgdhR for ; Thu, 19 Mar 2015 11:11:05 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957D81A8AAC for ; Thu, 19 Mar 2015 11:10:54 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw01.dd24.net (Postfix) with ESMTP id 189745FBE6 for ; Thu, 19 Mar 2015 18:10:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id AsTVzr9NX9T0 for ; Thu, 19 Mar 2015 18:10:51 +0000 (UTC) Received: from gar-nb-etp06.garching.physik.uni-muenchen.de (unknown [141.84.43.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Thu, 19 Mar 2015 18:10:51 +0000 (UTC) Message-ID: <1426788650.13059.16.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 19 Mar 2015 19:10:50 +0100 In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com> <1426719900.4249.40.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-BFrv9zRWdWywjIbKom8Z" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 19 Mar 2015 18:11:07 -0000 --=-BFrv9zRWdWywjIbKom8Z Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-03-19 at 14:00 -0400, Benjamin Kaduk wrote:=20 > What happens when the policy listed at the policy URL changes? It seems > that a local resource would be needed. Well first, the different signature levels (if they rely on a policy document, which they effectively do due to their vague definition) wouldn't help you in such case either. Second, it's IMHO in the responsibility of the signer to keep the old policies available, of course it wouldn't be enough for the URL to just contain the key ID... (it would need at least the valid from / through dates and probably more values like signing key finger print and more... or even better a hash on the signature packet). Cheers, Chris=20 --=-BFrv9zRWdWywjIbKom8Z Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMxOTE4MTA1 MFowTwYJKoZIhvcNAQkEMUIEQKRO9yyp4Xa2wwhszTQV+sc7iOGT2w0SnyRsjmj9yZiOm5N6AfWS SAchRXp1AO9qAu7XmcqzSdFAJ4jg4wabtygwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAta3KyNxJ+Hdgj1FV6VMVJhJQ9Bnd5 FH1+5jN5sKPb0FaahLnqSzGbQoeg7hT4cWrhF0ZlbWY0GhV2Zfo1iVY1DIY+Ksy2tyFFyvy8T/1v DIXEG5A7z/ZjOxBFctZYe5gKKcReY+/nWXgOuxL03fwUli34TEIW92AniAffxPrNvI7AJriuO3PW 5bbQR1AazxO5jK1dTRoRHsCQqNrdNdqhrN7cTLsjJAk7cI0OS+4C+tdsuZyG41AVC6a9NUj6zFvY 9BHpPJlSXsV5DS/6DBTLv7f6WSuct7u60KmM+Ig23qqRg1+M523UloisFcXRTUvdd2bxYiipzfq6 d7sd5naYAAAAAAAA --=-BFrv9zRWdWywjIbKom8Z-- From nobody Thu Mar 19 15:44:09 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 844191A90F0 for ; Thu, 19 Mar 2015 15:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 BdUu5elHEMGW for ; Thu, 19 Mar 2015 15:44:06 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0F81A90EB for ; Thu, 19 Mar 2015 15:44:03 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-34-550b5132aa54 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2B.56.03359.2315B055; Thu, 19 Mar 2015 18:44:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2JMi2ft018769; Thu, 19 Mar 2015 18:44:02 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2JMi0kQ030620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Mar 2015 18:44:01 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2JMhxY7013014; Thu, 19 Mar 2015 18:43:59 -0400 (EDT) Date: Thu, 19 Mar 2015 18:43:59 -0400 (EDT) From: Benjamin Kaduk To: Christoph Anton Mitterer In-Reply-To: <1426788650.13059.16.camel@scientia.net> Message-ID: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com> <1426719900.4249.40.camel@scientia.net> <1426788650.13059.16.camel@scientia.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrGsUyB1qcP+sgcXH21dYLBr+PWR3 YPJYsuQnk0fHm5XMAUxRXDYpqTmZZalF+nYJXBk/9mUUXOeo2DHlH1sD40e2LkZODgkBE4mt yzYwQ9hiEhfurQeKc3EICSxmkljZOB+sSEhgI6PEueu6EIlDTBJz725mhHAaGCVW3d3BCFLF IqAtse7eTLBRbAIqEjPfbATq5uAQAVrx8UMqiMksICJx57AliCksYCYx+6orSDGngKnE7Yv3 GUHCvAIOEseO10IM/8MkMWXOB7CBogI6Eqv3T2EBsXkFBCVOznwCZjMLaEksn76NZQKj4Cwk qVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaUbmIEh6gkzw7GNweVDjEK cDAq8fAu4OMOFWJNLCuuzD3EKMnBpCTKyx0AFOJLyk+pzEgszogvKs1JLT7EKMHBrCTCm+AJ lONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuB97Q/UKFiUmp5akZaZ U4KQZuLgBBnOAzT8KEgNb3FBYm5xZjpE/hSjopQ4712QhABIIqM0D64XlkJeMYoDvSLM6wFy Nw8w/cB1vwIazAQ0+F8tF8jgkkSElFQDo0ViTVXxrOXi82v2nZ0ss31Z9Csb/5qLv46dsD/B JdHs0z8jnGvlzDlr06+V2+96yuW06ZlyzOJXk1S2iMQ/+bbxsnfqof+8T5//8Fv7JjngVur9 xDrHI3MqfttoSE7dfWpyl/GLW6u1k3+FfexQPnZ8icJEbeu+DfmbT55oYrjOVCqt8Fx7a5YS S3FGoqEWc1FxIgBeLyAM/AIAAA== Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 19 Mar 2015 22:44:07 -0000 On Thu, 19 Mar 2015, Christoph Anton Mitterer wrote: > On Thu, 2015-03-19 at 14:00 -0400, Benjamin Kaduk wrote: > > What happens when the policy listed at the policy URL changes? It seems > > that a local resource would be needed. > Well first, the different signature levels (if they rely on a policy > document, which they effectively do due to their vague definition) > wouldn't help you in such case either. I wasn't trying to say that the existing technology is better than your proposal, just that your proposal needs to take this concern into account. > Second, it's IMHO in the responsibility of the signer to keep the old > policies available, of course it wouldn't be enough for the URL to just > contain the key ID... (it would need at least the valid from / through > dates and probably more values like signing key finger print and more... > or even better a hash on the signature packet). Sure, it's their responsibility. But some signers are going to fail to adhere to it, and the client trying to use such a signature needs to know how to behave in that case. -Ben From nobody Thu Mar 19 16:14:06 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 85CB01A0013 for ; Thu, 19 Mar 2015 16:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UwyQcq1r1y0M for ; Thu, 19 Mar 2015 16:14:03 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 589571A000A for ; Thu, 19 Mar 2015 16:14:03 -0700 (PDT) Received: by ladw1 with SMTP id w1so74523310lad.0 for ; Thu, 19 Mar 2015 16:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5+vD93b14XGmiQ7vZA1bMBPCUDxe1sPXo4bXEHOB+kY=; b=nk3XBttfA9dEuGE8XT+phqifTt+QuLKV8tK13KzyDV8MdAZ1hiGees8/0GXzEaH7fh 7jqJhImBncXTRvk/jOB4pETH770weEP7mgymRnCKM8uQsDlkjVL/MDYh1irAEi8BwHsd SB7KAVFROrC/5WG2zlJA6kPOMRu66Utds/km3xe/UmY/f59lxW+SF+lhJFWKmyFGtC+a C/rdXDJiiBzOiAePebt134KxYx9fOf5CJrOK/UTS3PwnbfxtOVu3FAZA38PG681DwoUZ jxCEAGs3tu8faNJVKR/IhwrgNjXzcdAW/mxrDHqMw0jVONTPyODaOXS4grzk0aa0Z9Dw sQNw== MIME-Version: 1.0 X-Received: by 10.112.133.2 with SMTP id oy2mr18919707lbb.124.1426806841801; Thu, 19 Mar 2015 16:14:01 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Thu, 19 Mar 2015 16:14:01 -0700 (PDT) In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com> <1426719900.4249.40.camel@scientia.net> <1426788650.13059.16.camel@scientia.net> Date: Thu, 19 Mar 2015 19:14:01 -0400 X-Google-Sender-Auth: NAK_mV3j-zW45GNOg05MEvrqm_Q Message-ID: From: Phillip Hallam-Baker To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=047d7b3a8c9cf7ff900511ac5a9c Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 19 Mar 2015 23:14:04 -0000 --047d7b3a8c9cf7ff900511ac5a9c Content-Type: text/plain; charset=UTF-8 As a branding issue, I would pick the name PGP/MIME for the working group and make the focus decrufting legacy bits of PGP and making a MIME based scheme the new common denominator for framing. If there was also a clearly defined strategy for interop with S/MIME credentials then such a specification could be positioned as the future upgrade path for OpenPGP and S/MIME. Since an S/MIME credential can be turned into a fingerprint pretty easily and the fingerprints are what people actually use in practice to exchange OpenPGP mail. This is not exactly a major problem. (Yes I know that there is a PGP/MIME mode at the moment. but that isn't the point). Think of it as embrace and extend... --047d7b3a8c9cf7ff900511ac5a9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a branding issue, I would pick the name PGP/MIME for th= e working group and make the focus decrufting legacy bits of PGP and making= a MIME based scheme the new common denominator for framing.

=
If there was also a clearly defined strategy for interop with S/MIME c= redentials then such a specification could be positioned as the future upgr= ade path for OpenPGP and S/MIME.

Since an S/MIME c= redential can be turned into a fingerprint pretty easily and the fingerprin= ts are what people actually use in practice to exchange OpenPGP mail. This = is not exactly a major problem.

(Yes I know that t= here is a PGP/MIME mode at the moment. but that isn't the point).
=

Think of it as embrace and extend...
--047d7b3a8c9cf7ff900511ac5a9c-- From nobody Fri Mar 20 06:46:52 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 77D571B2D6A for ; Fri, 20 Mar 2015 06:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 8OwqHXKZQBXX for ; Fri, 20 Mar 2015 06:46:49 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 AD4751B2D63 for ; Fri, 20 Mar 2015 06:46:49 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so78247228obd.3 for ; Fri, 20 Mar 2015 06:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=4HtWhPjl/4EfZD1pe43E8Zsmh8DK5SID6IqiJR4GaAA=; b=JKPxGJs4ESqJBk7TtLqkuFtOh4+M14qPzDEUGC5kp9ZBK5DU+/aLW7t8XaonvuzGUV 3yvOanLVzfMhKVJPypECTyi2xQlYWlPC6Ejy+rgNMgh7XOLWkmaDzbzpi3/Y+UM/5gyT B+tremaXvkjsfNg2x4m2k1N5x9JV+2yadKj3b1/xvVkAvIQKpFasm1YMYbXFq7l8t9Pr uA4vpCTs+Yyg48qQzoZirwYMvu0KQOfmA4r6yadPDv0K8GOqJomX5fFMMm2g3dLqWNZ1 tt7iLzZ5DDODJvuX6iZvrnZdjhjhEXSwsAGIJ0qa58ilu4RBAUkuGUJRxgRD2xp/GYQF ZmOA== X-Received: by 10.202.77.198 with SMTP id a189mr24017037oib.49.1426859209156; Fri, 20 Mar 2015 06:46:49 -0700 (PDT) MIME-Version: 1.0 References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com> <1426719900.4249.40.camel@scientia.net> <1426788650.13059.16.camel@scientia.net> In-Reply-To: From: Wyllys Ingersoll Date: Fri, 20 Mar 2015 13:46:47 +0000 Message-ID: To: Phillip Hallam-Baker , Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a1134fdc84e70230511b88ce7 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 20 Mar 2015 13:46:51 -0000 --001a1134fdc84e70230511b88ce7 Content-Type: text/plain; charset=UTF-8 MIME is fine for PGP over email, but do keep in mind that PGP is not strictly used in email and using MIME is not necessarily helpful and is possibly needlessly complicated in some of the other use cases (just encrypting personal files and data at rest, for example). And if we are going to start talking about "PGP/MIME", then I think revising RFC-3156 should be part of the discussion at some point. As it is stands today, it is impossible to craft a proper "PGP/MIME" message unless your mail client directly supports 3156. It requires special SMTP headers that are usually set by the mail client and over which the user has no control (and don't get me started on that extra "version 1" MIME section...). -Wyllys On Thu, Mar 19, 2015 at 7:14 PM Phillip Hallam-Baker wrote: > As a branding issue, I would pick the name PGP/MIME for the working group > and make the focus decrufting legacy bits of PGP and making a MIME based > scheme the new common denominator for framing. > > If there was also a clearly defined strategy for interop with S/MIME > credentials then such a specification could be positioned as the future > upgrade path for OpenPGP and S/MIME. > > Since an S/MIME credential can be turned into a fingerprint pretty easily > and the fingerprints are what people actually use in practice to exchange > OpenPGP mail. This is not exactly a major problem. > > (Yes I know that there is a PGP/MIME mode at the moment. but that isn't > the point). > > Think of it as embrace and extend... > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1134fdc84e70230511b88ce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
MIME is fine for PGP over email, but do keep in mind that = PGP is not strictly used in email and using MIME is not necessarily helpful= and is possibly needlessly complicated in some of the other use cases (jus= t encrypting personal files and data at rest, for example).

<= div>And if we are going to start talking about "PGP/MIME", then I= think revising RFC-3156 should be part of the discussion at some point. As= it is stands today, it is impossible to craft a proper "PGP/MIME"= ; message unless your mail client directly supports 3156.=C2=A0 It requires= special SMTP headers that are usually set by the mail client and over whic= h the user has no control (and don't get me started on that extra "= ;version 1" MIME section...).

-Wyllys



On Thu, Ma= r 19, 2015 at 7:14 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
As a branding issue, I would pick the name PGP/MI= ME for the working group and make the focus decrufting legacy bits of PGP a= nd making a MIME based scheme the new common denominator for framing.
<= br>
If there was also a clearly defined strategy for interop with= S/MIME credentials then such a specification could be positioned as the fu= ture upgrade path for OpenPGP and S/MIME.

Since an= S/MIME credential can be turned into a fingerprint pretty easily and the f= ingerprints are what people actually use in practice to exchange OpenPGP ma= il. This is not exactly a major problem.

(Yes I kn= ow that there is a PGP/MIME mode at the moment. but that isn't the poin= t).

Think of it as embrace and extend...
_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a1134fdc84e70230511b88ce7-- From nobody Fri Mar 20 07:24:15 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 97F081B2E0F for ; Fri, 20 Mar 2015 07:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 AK6QFmiEpVge for ; Fri, 20 Mar 2015 07:24:13 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 5F83D1B2DEC for ; Fri, 20 Mar 2015 07:24:13 -0700 (PDT) Received: by lagg8 with SMTP id g8so88320884lag.1 for ; Fri, 20 Mar 2015 07:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eifWdlV+wvJkqFwN4xWs1jzF8DYLqgEsMQa0jH0Nus8=; b=wrqwijiLjfBDwpPAvxWeuG7IkR13GrFG7RdNkt1IF4qBxXdfQLcFjkRNNA0vKTI3Q1 tidshXxU5pxC9hEVR26coBX3riMlHIoRmbKEELKIosto8H35NknqeC8Os/zNrHUV7vXa 8fKTx6CMnr7xg6t36W1oe/Tm4tZ6wkLmp9YBvv6fWlnHij/bem/WjbAKwTe7hcN+AV+X 5ENUcBO5hVdyrSl74XvDsXC0PWjJ0NSoNGfN16tI/WTgC2Qn3FWIsqkv4Hvfe+QbDXQu 5CDD/alh7PENIC8a9fm/vbAmws/zFXpuGMJqKHYuu8lnqRgK/v78JDz6PRk+TRJQIowS x8vQ== MIME-Version: 1.0 X-Received: by 10.112.236.68 with SMTP id us4mr1180513lbc.91.1426861451888; Fri, 20 Mar 2015 07:24:11 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Fri, 20 Mar 2015 07:24:11 -0700 (PDT) In-Reply-To: References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> <874mppgyez.fsf@vigenere.g10code.de> <1426564752.18487.35.camel@scientia.net> <5507E916.4040307@sumptuouscapital.com> <1426719900.4249.40.camel@scientia.net> <1426788650.13059.16.camel@scientia.net> Date: Fri, 20 Mar 2015 10:24:11 -0400 X-Google-Sender-Auth: A8k2CyqyHlTg5LIvu18FjSsNIWA Message-ID: From: Phillip Hallam-Baker To: Wyllys Ingersoll Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP , Benjamin Kaduk Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 20 Mar 2015 14:24:14 -0000 On Fri, Mar 20, 2015 at 9:46 AM, Wyllys Ingersoll wrote: > MIME is fine for PGP over email, but do keep in mind that PGP is not > strictly used in email and using MIME is not necessarily helpful and is > possibly needlessly complicated in some of the other use cases (just > encrypting personal files and data at rest, for example). Absolutely. Which is why PGP should be properly layered and abstracted so that all the mail specific parts are in 'MIME' and all the encryption parts are in the 'PGP' bit. > And if we are going to start talking about "PGP/MIME", then I think revising > RFC-3156 should be part of the discussion at some point. As it is stands > today, it is impossible to craft a proper "PGP/MIME" message unless your > mail client directly supports 3156. It requires special SMTP headers that > are usually set by the mail client and over which the user has no control > (and don't get me started on that extra "version 1" MIME section...). Absolutely. The stalemate has to end at some point. PGP does its own thing in too many places. What we have is a description of a product rather than a multi-vendor standard. Winning means that everyone gets access to email encryption with full control of their trust environment. Tonight there are two crypto parties in my neighborhood where people will be taught how to use PGP. This is really good and really sad. The good part is that it shows that people are really interested in getting crypto. The sad part is that the tools we have today require user education. Teaching people how to use vim/PGP to send and receive secure mail is actually a sign that we are doing something wrong. Every browser comes with TLS built in and everyone uses it at least some of the time. Every email client comes with an email encryption solution but almost nobody uses it. From nobody Fri Mar 20 09:13:29 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 BB5C61A19F8 for ; Fri, 20 Mar 2015 09:13:28 -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 jxmy0mdmVdMu for ; Fri, 20 Mar 2015 09:13:27 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CF91ACC83 for ; Fri, 20 Mar 2015 09:13:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C2EE6E2038; Fri, 20 Mar 2015 12:13:22 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26759-08; Fri, 20 Mar 2015 12:13:21 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 3FD61E2036; Fri, 20 Mar 2015 12:13:21 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2KGDKx6029669; Fri, 20 Mar 2015 12:13:20 -0400 From: Derek Atkins To: Bill Frantz References: Date: Fri, 20 Mar 2015 12:13:20 -0400 In-Reply-To: (Bill Frantz's message of "Tue, 17 Mar 2015 15:11:57 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 20 Mar 2015 16:13:28 -0000 Bill Frantz writes: >>But frankly I'd like my encryption software to just maintain the ability >>to decrypt it later. > > Well, the problem isn't the software. It is the user. Bzzt. I'm sorry, but when my software removes decryption algorithm support it is most definitely NOT a user problem. Requiring support for multiple versions in parallel is also not a user problem. But this has moved way far off-topic for this list. > Cheers - Bill -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 20 09:15: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 4AEA31A19E3 for ; Fri, 20 Mar 2015 09:15:21 -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 MnG6lux6RumL for ; Fri, 20 Mar 2015 09:15:20 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB761ACD74 for ; Fri, 20 Mar 2015 09:15:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 12531E2038; Fri, 20 Mar 2015 12:15:09 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26820-08; Fri, 20 Mar 2015 12:15:07 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 7A2D7E2036; Fri, 20 Mar 2015 12:15:07 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2KGF6vJ029798; Fri, 20 Mar 2015 12:15:06 -0400 From: Derek Atkins To: Bill Frantz References: Date: Fri, 20 Mar 2015 12:15:06 -0400 In-Reply-To: (Bill Frantz's message of "Wed, 18 Mar 2015 15:38:59 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org, Falcon Darkstar Momot Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 20 Mar 2015 16:15:21 -0000 Bill Frantz writes: > The software works fine. The user has either lost the secret key file > or has forgotten the passphrase. I don't know a technical solution, > particularly to the 2nd problem. Any suggestions? Nope, that's NOT the problem. They keys all exist. The passphrase is known. The problem is that software removed support for the keys/algorithms in which the data is encrypted. This is absolutely a technical problem with the software and is completely solvable. > Cheers - Bill -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 20 09:23:30 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 A65101A1A04 for ; Fri, 20 Mar 2015 09:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 w7rJ1w-vByy4 for ; Fri, 20 Mar 2015 09:23:29 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7AE21A0B00 for ; Fri, 20 Mar 2015 09:23:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B0A37E2039; Fri, 20 Mar 2015 12:23:27 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 26820-10; Fri, 20 Mar 2015 12:23:25 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5A120E2036; Fri, 20 Mar 2015 12:23:25 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2KGNOiw030358; Fri, 20 Mar 2015 12:23:24 -0400 From: Derek Atkins To: Stephen Paul Weber References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> <20150317151510.GD2983@singpolyma-liberty> <20150317154832.GF2983@singpolyma-liberty> Date: Fri, 20 Mar 2015 12:23:24 -0400 In-Reply-To: <20150317154832.GF2983@singpolyma-liberty> (Stephen Paul Weber's message of "Tue, 17 Mar 2015 10:48:32 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: openpgp@ietf.org, Wyllys Ingersoll , Tim Bray , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 20 Mar 2015 16:23:29 -0000 Stephen Paul Weber writes: >>IMHO it's much nicer, from an implementation point of view, to have >>everything in one document instead of having to go off and reference a >>dozen or more documents. > > This is true if you're building a complete implentation like GnuPG, > but less true if you just want a way to verify signatures sent to you. > > I mean, not that I find the spec that complex, but the webby people I > deal with seem to. Have you tried to have them read the CMS/PKIX set of specs?? And they still think that 4880 is too complex?? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 20 09:26:32 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 107361A1A3E for ; Fri, 20 Mar 2015 09:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 tWWOchT_h4D1 for ; Fri, 20 Mar 2015 09:26:24 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9B71A1A04 for ; Fri, 20 Mar 2015 09:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id AE08CE2038; Fri, 20 Mar 2015 12:26:22 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27083-01; Fri, 20 Mar 2015 12:26:20 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 8E993E2036; Fri, 20 Mar 2015 12:26:20 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2KGQK9N030568; Fri, 20 Mar 2015 12:26:20 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Date: Fri, 20 Mar 2015 12:26:20 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 17 Mar 2015 12:30:03 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 20 Mar 2015 16:26:31 -0000 Phillip Hallam-Baker writes: > We have been having a similar discussion in ACME which is for issue of > certificates for use in TLS, email, etc. > > The body of the message is going to be JSON. But the message needs to be > signed. After a number of proposals we seem to have settled on a scheme in > which the start of the message is a JSON header carrying the signature which is > followed by a JSON message carrying the transaction request or response. Okay, I'll bite.. Why don't you use JWS? That would seem to be the appropriate way to sign JSON, no? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 20 09:57: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 6CAA81A1A33 for ; Fri, 20 Mar 2015 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 CPJvFbm1phKa for ; Fri, 20 Mar 2015 09:56:59 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (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 A338B1A005D for ; Fri, 20 Mar 2015 09:56:58 -0700 (PDT) Received: by lagg8 with SMTP id g8so91785820lag.1 for ; Fri, 20 Mar 2015 09:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2EkkecTfaQSKlyrrRsa5Akyf1ZO5Hwpj+AabZj6LZ+g=; b=NO8uYU3b+LOI/fc596lB/NxzkcJwi+HOaGXAPIOu5q01HoqPBTkjQe5weL0B8k+SCR o8Ul6CQBgEPDIYwb+thlMHZBQoDCDKihd9Wbtu5PlvHH0CJ5+ksyis7Y5t0Enmqj1yQf 2v8pWf7kS2F6yThZ1ggNDIz+E4yJdFaQuiOD2v5/1AH67qGSXdaKx1SmLdtcMSVc3603 IKY4zv5HAJOBog5P0KX2x/NTPaVntgJYn0K+Tuqo2LA8cgiV+OoDxAkEgpeEuF5UoR97 51K1esPTqxFI3CUJZoJdhowJ8FUos1f97x4U5lf9hjYbnO7h05kenjOtbcUlfhhpo/L3 dJnA== MIME-Version: 1.0 X-Received: by 10.152.18.225 with SMTP id z1mr74915026lad.124.1426870617226; Fri, 20 Mar 2015 09:56:57 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Fri, 20 Mar 2015 09:56:57 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> Date: Fri, 20 Mar 2015 12:56:57 -0400 X-Google-Sender-Auth: bGRjak5JXn-oSoGjUgr3Ssqt6oY Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 20 Mar 2015 16:57:00 -0000 On Fri, Mar 20, 2015 at 12:26 PM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > >> We have been having a similar discussion in ACME which is for issue of >> certificates for use in TLS, email, etc. >> >> The body of the message is going to be JSON. But the message needs to be >> signed. After a number of proposals we seem to have settled on a scheme in >> which the start of the message is a JSON header carrying the signature which is >> followed by a JSON message carrying the transaction request or response. > > Okay, I'll bite.. Why don't you use JWS? That would seem to be the > appropriate way to sign JSON, no? The idea is to use JWS for the signature. The only part that is not in the JWS spec would be the 'JWS Serialization' signature packaging. There are two versions of this in the current spec. All we are proposing is to add a third. JWS Compact Serialization is essentially BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature) This is designed for use in OpenID. For our purposes, it is much easier to use: JWS Signature . JWS Payload The advantages of this change are: 1) It is more efficient in space (no need to base 64 encode) 2) It is easy to interpret examples and debug implementations if you can see the plaintext without a tool 3) In our application, there isn't actually a need for the protected header. But we could add that in as well just to keep things straight. I can't see much point in going to JSON so that we have the benefits of plaintext and then base64 encoding everything just to be compliant with a spec written for a different purpose. If adopted, I am sure that the JWS group will pick the scheme up and add it to their spec at their next iteration. They have two serialization formats today, adding a third is hardly an imposition. From nobody Sat Mar 21 18:34:35 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 EE0501A005A for ; Sat, 21 Mar 2015 18:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888] 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 WXL-YmsQbOnF for ; Sat, 21 Mar 2015 18:34:30 -0700 (PDT) Received: from klein.gross.net (50-78-110-165-static.hfc.comcastbusiness.net [50.78.110.165]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1F1A003A for ; Sat, 21 Mar 2015 18:34:29 -0700 (PDT) Received: from [IPv6:::1] (127.0.0.1) by klein.gross.net with ESMTP (EIMS X 3.3.9) for ; Sat, 21 Mar 2015 18:34:29 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Stephan Somogyi In-Reply-To: Date: Sat, 21 Mar 2015 18:34:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BD72344-7839-4F5F-9C4B-2E44FC5B7E29@lt.gross.net> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> To: "openpgp@ietf.org" X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 01:34:33 -0000 I=E2=80=99m enjoying this exchange tremendously, but Phill just said = something that overcame my reticence to pipe up. On Mar 17, 2015, at 09:44, Phillip Hallam-Baker = wrote: > The body of any modern email is going to be UTF8 after all. There=E2=80=99s a fair bit of email still being exchanged that isn't = UTF8, and I expect this=E2=80=99ll continue for as long as we=E2=80=99re = still using SMTP. Everyone really should read = in the context of making these = types of assumptions. I still wish the charset header had been added to = OpenPGP sooner, and made to have teeth. When we started work on End-To-End, it=E2=80=99d=E2=80=99ve been easier = in many ways to start from scratch, invent our own spiffy new protocol, = and evade the tyranny of the installed base entirely. But interop = matters. As do maturity and understood-ness of protocols. We made some = implementation-specific choices (eg only ever generating ECC keys), but = we very concertedly set out not to break anything. David=E2=80=99s = declaration of intent to deprecate is worded a bit more strongly than I = would=E2=80=99ve done, but I certainly don't disagree with the idea of = considered algorithmic tidying in order to encourage modern OpenPGP = implementations to generate contemporarily appropriate keys and = messages. When it comes to decryption, I=E2=80=99m (unsurprisingly) in vigorous = agreement with Derek that this is a software problem, not a human = problem. The question is whether we need a more usable universally = backward compatible OpenPGP decryptor for our older data. s. From nobody Sun Mar 22 02:18:27 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 241811A8793 for ; Sun, 22 Mar 2015 02:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA3mcJtS5FpG for ; Sun, 22 Mar 2015 02:18:24 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (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 7EDF81A876E for ; Sun, 22 Mar 2015 02:18:24 -0700 (PDT) Received: by iedm5 with SMTP id m5so17216436ied.3 for ; Sun, 22 Mar 2015 02:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:openpgp:content-type:content-transfer-encoding; bh=40Z09NvvJAw37jeh1MyTMx/FxKkVNCRQz/O4LqOGHHw=; b=x/R+zaphPuC5bVxEn1R+w6p9F+zqUCN8M69nZPWxprATnELn/Sb5Io4ztyRO8g44RO vaGEuVJlyswgaQCPfERARvfDqj7P5oFkkcPfSazzr8EHQWjK/Xl8s60fBZUAFzrHoP3I 5wtyafR2TEJilpisPOhwh6lIcTcarTddpHKIpstvN9KkXjd6pGB/XDlHk42PW3/vm8vj UM5MQNO/oqjvo0vJmVPiGjBhgv0VPEg1xpEzDAh0dQkGi5j38pXT8jT3wsIelCEpKS80 5k/GeMqa/2CGsyD97XxcJlv04H2GQWRykH6uMbdMeL8G61s+KSWTvwi+06d6DgKHPTWb NYpg== X-Received: by 10.50.9.97 with SMTP id y1mr7456210iga.34.1427015903924; Sun, 22 Mar 2015 02:18:23 -0700 (PDT) Received: from [192.168.37.5] (72-24-92-16.cpe.cableone.net. [72.24.92.16]) by mx.google.com with ESMTPSA id g76sm7359431iod.8.2015.03.22.02.18.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2015 02:18:23 -0700 (PDT) Message-ID: <550E88DD.3050908@gmail.com> Date: Sun, 22 Mar 2015 09:18:21 +0000 From: Andrew Skretvedt User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: OpenPGP: id=6C976BB3; url=http://andrewskretvedt.blogspot.com/p/my-pgp-public-key.html Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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: Sun, 22 Mar 2015 09:18:26 -0000 I am a curious onlooker with no operational affiliation to the business of this list (and normally silent), with an observation/question at this point in this thread: Is it considered best practice now to encrypt, then sign? I think I heard somewhere that SSL/TLS does it the other-way-round and has thereby innocently created certain problems. GnuPG allows these operations to be combined on the command line, and then I don't know in what order they actually occur. If you receive an encrypted and signed message, and best practice would be to, in reasonable time, decrypt from wire-format and re-encrypt to local format for PFS (which seems to me a really sound policy, given modern experiences, and might be just as easy as leaving it to your full-disk-encryption system where you store your mail), might you lose the ability to provably authenticate the messages in your archive? I can think of situations where one would not want to lose this ability (e.g. some sort of dispute or legal proceeding). Perhaps if they get signed, then encrypted, this problem goes away. But then why /should/ one do these two operations in one order in the e-mail context, but perhaps the opposite order in others? (Perhaps I betray my ignorance at this point.) From nobody Sun Mar 22 06:54:41 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 2D76E1A90E0 for ; Sun, 22 Mar 2015 06:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 nL9Ed51I2d82 for ; Sun, 22 Mar 2015 06:54:37 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CA31A90DD for ; Sun, 22 Mar 2015 06:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1427032477; x=1458568477; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qAOhvg1QRGWsf0S1WDVr8bfagAlhEFY09kM435ARE9c=; b=hWV0W61wLhoMXBghcaPloMUzGxKzWMI3/rdxUp7hkvhEFIoOBPdP1+Gt CJL3QO9eAKO9fVlivZlAOA5SJXroxZvOIdd/CJttM8xskl8Xf1UPgV/k7 5XC8m2K9M+Q2B1GUx6KlEqkwpa6CVpIiSt5ILYtI4wNiOyS2xeHIkepLa A=; X-IronPort-AV: E=Sophos;i="5.11,446,1422874800"; d="scan'208";a="315625949" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Mar 2015 02:54:33 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 23 Mar 2015 02:54:33 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] "OpenPGP Simple" Thread-Index: AdBkp7mFNH9yEikdSKynhhjcBjnEoQ== Date: Sun, 22 Mar 2015 13:54:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 13:54:39 -0000 Derek Atkins writes:=0A= =0A= >Have you tried to have them read the CMS/PKIX set of specs?? And they sti= ll=0A= >think that 4880 is too complex??=0A= =0A= Having implemented both 3369 and 4880 (I'm not going to touch 5280 et al, n= o-=0A= one has that much asbestos), 3369 is much easier to work with. The reason = for=0A= this is that there's a single overall type (ContentInfo) for everything and= =0A= then consistent subtypes (SignedData, EnvelopedData) within that, all=0A= collected together inside type-specific containers. PGP OTOH is a series o= f=0A= packets with somewhat arbitrary fields (look at the literal-data packet for= =0A= example), all concatenated together in a rather ad hoc order, which means y= ou=0A= have to hand-craft parsing code for almost everything. When a new type=0A= (AuthEnvelopedData) was added to CMS I just added an OID and a function=0A= pointer to the decoding table and a bit of glue code and I was done. The P= GP=0A= equivalent OTOH, MDC'd data... ugh.=0A= =0A= Peter.= From nobody Sun Mar 22 07:05: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 22C021A90E1 for ; Sun, 22 Mar 2015 07:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 bxLl90Rfpq7W for ; Sun, 22 Mar 2015 07:05:06 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 C6F171A90DB for ; Sun, 22 Mar 2015 07:05:05 -0700 (PDT) Received: by labto5 with SMTP id to5so9020300lab.0 for ; Sun, 22 Mar 2015 07:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WANqzPuYHgal41gF2mS1z2FBtNx0VoRtfbPI2vPjRD4=; b=MuJm0R6PSMKETdFtxPlZ8IYUdURLgDRGNO5I4AKGhdiSZBvpHN0gdHXqlAKBaHz3Rr zvm1xKm6NoIeT4CDkiv+4T+ulRWrQ/ETZmnGwy+Z/YGdH7SEEpC/74Sy/G2BmdlTbV+W OCIXdkdc2cfxvY7YDg58ZhdKf+0xZF8whw1QZZg/VW1NMDuLEKrgmjZSRmBjDwDv26bf M3IGwZvE637Ywuc0ZQc10GII9z+3kwTrMaJEwD+bzK0ef4Cm5bX7+jMWpXdY5Gz+vJBF T6O9pdEfBzf9iNlJl2tk1A8ArSghgT69c52/2GrLLkhLc7Ae8KJrafzHVAhG9j0wrSQe 1pYQ== MIME-Version: 1.0 X-Received: by 10.152.120.8 with SMTP id ky8mr77054717lab.118.1427033104310; Sun, 22 Mar 2015 07:05:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Sun, 22 Mar 2015 07:05:04 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 22 Mar 2015 10:05:04 -0400 X-Google-Sender-Auth: llaXZF2ECJjczNDh-v8egkJeA1Q Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 14:05:07 -0000 On Sun, Mar 22, 2015 at 9:54 AM, Peter Gutmann wrote: > Derek Atkins writes: > >>Have you tried to have them read the CMS/PKIX set of specs?? And they still >>think that 4880 is too complex?? > > Having implemented both 3369 and 4880 (I'm not going to touch 5280 et al, no- > one has that much asbestos), 3369 is much easier to work with. The reason for > this is that there's a single overall type (ContentInfo) for everything and > then consistent subtypes (SignedData, EnvelopedData) within that, all > collected together inside type-specific containers. PGP OTOH is a series of > packets with somewhat arbitrary fields (look at the literal-data packet for > example), all concatenated together in a rather ad hoc order, which means you > have to hand-craft parsing code for almost everything. When a new type > (AuthEnvelopedData) was added to CMS I just added an OID and a function > pointer to the decoding table and a bit of glue code and I was done. The PGP > equivalent OTOH, MDC'd data... ugh. I have also done a CMS a few times, it isn't a biggie. PKIX path math certainly is, particularly if the insanity of policy constraints is attempted. But CMS isn't that hard. Even ASN.1 BER encoding isn't that difficult. The really horrible part is having to do DER. From nobody Sun Mar 22 07:20: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 5919E1A913F for ; Sun, 22 Mar 2015 07:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mn9x4PLBtTVa for ; Sun, 22 Mar 2015 07:19:59 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 0A5931A9128 for ; Sun, 22 Mar 2015 07:19:59 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so19637995iec.0 for ; Sun, 22 Mar 2015 07:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N2TfI8JnN85/dG+yRdsGhKgS+ZfuiYmUZp2RCKaX714=; b=Df5AQemZvsxMB1BQHk0rWjkX/fMlGCut1Gf/U2s3KwlPaPXHA1w/EPGeuXIRTdRBa0 vLsUyvRznCv2dQLIz3jtHfW1PozdaH4EYuaga9g3gNCPdqxWNDHHkDVsbjLncF4Kov5q JxxyhO4K2BTz1y2sOEffMtgSYPd2bHd25OKg2FnU/GN0C2fu9kmABqTq/SYiVnQYj/CC PVLS1Wt6eOQNwMlGZAJj5f3++6MHt7lX3W8JPvksVYWvSJD/ddjXb9eTpw9VDUzTSpar 0K5VJmB/d1c1zqymMvR6GoGwY/47RxBapFrfFYs/jKKeY/O+sFQHRLLbtoqXn/EPsCwa dthA== MIME-Version: 1.0 X-Received: by 10.107.31.14 with SMTP id f14mr120301115iof.28.1427033998423; Sun, 22 Mar 2015 07:19:58 -0700 (PDT) Received: by 10.107.6.133 with HTTP; Sun, 22 Mar 2015 07:19:58 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 22 Mar 2015 14:19:58 +0000 Message-ID: From: Gregory Maxwell To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 14:20:00 -0000 On Sun, Mar 22, 2015 at 2:05 PM, Phillip Hallam-Baker wrote: > Even ASN.1 BER encoding isn't that difficult. The really horrible part > is having to do DER. BER has many strange encoding corner cases that no one actually gets right. I went through a while ago checking BER implementations and I was not able to find a _single_ correct open source implementation of it. The code in OpenSSL, bouncy castle, etc. are all incorrect. DER is fairly straight forward itself, but what people do is implement DER with their (incomplete) BER parser and fail to narrow the behavior sufficiently and end up with something that is a weird superset of DER but still a subset of BER. Most applications are not harmed by these problems is deseralization but from time to time they result in actual meaningful vulnerabilities. From nobody Sun Mar 22 07:56:59 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 2B6B21A8A50 for ; Sun, 22 Mar 2015 07:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 WGib3el7AmMQ for ; Sun, 22 Mar 2015 07:56:57 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 A12D01ABD3B for ; Sun, 22 Mar 2015 07:56:51 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so103167889lbc.2 for ; Sun, 22 Mar 2015 07:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KKkfDZJQIyuppheYsU8089GbDeJfJJLhNm4zHXiWFWk=; b=VobwkIRDniHoYbJQzbkE2ZWI5WC6zTYHItNOH5jY1xpY63PJF+bT58d/tjMFFbWEYT NAh1lxJrS+PKptU7DiOh291+AMgj1AkWI37U6zLp7gKATPNld4wLpSBEfrAoW8zPgYvN LWcuWQTQJOUmAU1ENK5M3LZZKpCW+X9ie3FBcnNft5BRH/KhEnun/VA59pixAhSEOSZJ fpTypHjmKIcgIQmUS1+rVqPu4ohgwP58RbAfHcopVh3AIxSkzZ6WAgJeFZHe6RP/FbJO zwa8IuNAX3aQLeIIpFpniXOBNjLfEVMpdjPCNt94iWHgf8QsWA3EsnTOyEYMmhCHklbj gDmA== MIME-Version: 1.0 X-Received: by 10.112.236.68 with SMTP id us4mr7898791lbc.91.1427036210104; Sun, 22 Mar 2015 07:56:50 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Sun, 22 Mar 2015 07:56:49 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 22 Mar 2015 10:56:49 -0400 X-Google-Sender-Auth: __sDatII00zgq3VM0TJgiIkChtE Message-ID: From: Phillip Hallam-Baker To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 14:56:58 -0000 On Sun, Mar 22, 2015 at 10:19 AM, Gregory Maxwell wrote: > On Sun, Mar 22, 2015 at 2:05 PM, Phillip Hallam-Baker > wrote: >> Even ASN.1 BER encoding isn't that difficult. The really horrible part >> is having to do DER. > > BER has many strange encoding corner cases that no one actually gets > right. I went through a while ago checking BER implementations and I > was not able to find a _single_ correct open source implementation of > it. > The code in OpenSSL, bouncy castle, etc. are all incorrect. > > DER is fairly straight forward itself, but what people do is implement > DER with their (incomplete) BER parser and fail to narrow the behavior > sufficiently and end up with something that is a weird superset of DER > but still a subset of BER. > > Most applications are not harmed by these problems is deseralization > but from time to time they result in actual meaningful > vulnerabilities. People keep telling me that canonicalization is necessary for security. In 25 years I have never once heard someone give a use case where it did. Of course, the real author of ASN.1 becomes clear when you know it is his name backwards. From nobody Sun Mar 22 08:06:42 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 540771AC39F for ; Sun, 22 Mar 2015 08:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKrFPmUPUBk1 for ; Sun, 22 Mar 2015 08:06:36 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 B864D1AC39C for ; Sun, 22 Mar 2015 08:06:36 -0700 (PDT) Received: by ignm3 with SMTP id m3so18866718ign.0 for ; Sun, 22 Mar 2015 08:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wvhcfIx3rDF7Evqx3cfeAqmmTUpQwSEGTrX85iGbS4A=; b=W+076uTdtXlsuGx1lIwHAWn2T4c2JyvdZVHy8nOFmXBhLScu4qGZ2PoCMoIFWWfFeb Eqc3Mtozm5+dIY/OkQxEWRixmfGGl1XGw/j+f3BkrMk1y5G9zWb0nF4A4qNlIZIqWYJb DMmFOADRoGwr0yavXhH2kiMhPFVWLLklZRdzdZiJm+hqnZPLZgn2Ucec7dGjFq9bgaM6 xfef+jgvtHxgR12I5D30R/nnubUkT5H1o7dUkR8FzDY98DcLmDo+M3i3Okq0u3M3F9OW 37nRg/ZaOm9M1FIfpHDKvsAXYzTxUlC/qU+SFuQZrk2kO9FRfQci/gZAnumurxhZmqY0 AzBA== MIME-Version: 1.0 X-Received: by 10.43.70.10 with SMTP id ye10mr15251116icb.66.1427036796126; Sun, 22 Mar 2015 08:06:36 -0700 (PDT) Received: by 10.107.6.133 with HTTP; Sun, 22 Mar 2015 08:06:35 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 22 Mar 2015 15:06:35 +0000 Message-ID: From: Gregory Maxwell To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 15:06:38 -0000 On Sun, Mar 22, 2015 at 2:56 PM, Phillip Hallam-Baker wrote: > People keep telling me that canonicalization is necessary for > security. In 25 years I have never once heard someone give a use case > where it did. Okay, sure I can fix that problem for you, here is a recent example; look at OpenSSL CVE CVE-2014-8275 (https://www.openssl.org/news/secadv_20150108.txt). A CA has signed an intermediate CA cert which is loaded in an interception appliance. You blacklist this certificate by ID. Your blacklisting is bypassed by simply changing the encoding of the when sending the cert chain and now your traffic can be intercepted again. (This isn't unique, but a recent example; if you're still thinking that you've still not had once usecase where it did I'd be glad to spend more time convincing you off-list) From nobody Sun Mar 22 08:28:23 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 2A2D11A89E0 for ; Sun, 22 Mar 2015 08:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 7bZ-IsKLQsOk for ; Sun, 22 Mar 2015 08:28:19 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (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 728171A8A07 for ; Sun, 22 Mar 2015 08:28:14 -0700 (PDT) Received: by lbbrr9 with SMTP id rr9so39114613lbb.0 for ; Sun, 22 Mar 2015 08:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jhPWUU3xezQX5EsAnKMQPtAbDEoRYjUK8Htd/c9gBIs=; b=Gw9hHRVrWo2EwZ5tp/1EfWZFDFlnrNGBahLrb5aMr9xG92X87NzFarltf09qvpC69i BcGHgqZRh1209tTdlWAkN2QICLBOwnn04B0gOc1DUvRG2aH28lUO43SiOmPQe6QDqjEj UyvkdRteJ6hAV+BwkaFFFx6KBxoLIL3DVe1oOkoGlMSjvPq3qyAukPqCVFhzOmH4aWH0 PF7HiQZisOm7kvJFo8vrqglssPaElV49gRklPicAKGuyNucxc4eyE6mAovj54JGi7ksb GjXcUJn57aAaTaNmWGokx9lOwXmGS6NWcrvGeRhcTRlZ5NwWP9e4SXPBP4imeBMP21Vh 036g== MIME-Version: 1.0 X-Received: by 10.112.151.226 with SMTP id ut2mr61995134lbb.55.1427038092982; Sun, 22 Mar 2015 08:28:12 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Sun, 22 Mar 2015 08:28:12 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 22 Mar 2015 11:28:12 -0400 X-Google-Sender-Auth: ydzu5WyTGQAvgMnwf0DkUyEGeOc Message-ID: From: Phillip Hallam-Baker To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 15:28:20 -0000 On Sun, Mar 22, 2015 at 11:06 AM, Gregory Maxwell wrote: > On Sun, Mar 22, 2015 at 2:56 PM, Phillip Hallam-Baker > wrote: >> People keep telling me that canonicalization is necessary for >> security. In 25 years I have never once heard someone give a use case >> where it did. > > Okay, sure I can fix that problem for you, here is a recent example; > look at OpenSSL CVE CVE-2014-8275 > (https://www.openssl.org/news/secadv_20150108.txt). > > A CA has signed an intermediate CA cert which is loaded in an > interception appliance. You blacklist this certificate by ID. Your > blacklisting is bypassed by simply changing the encoding of the when > sending the cert chain and now your traffic can be intercepted again. > > (This isn't unique, but a recent example; if you're still thinking > that you've still not had once usecase where it did I'd be glad to > spend more time convincing you off-list) Umm, I remain unconvinced. Basically this comes down to a defective signature validation routine. For revocation purposes the fingerprint should be taken over the signedData blob or a subset thereof (e.g. keyinfo). PKIX does not use the fingerprint for revocation, it uses the issuer name and serial number. From nobody Sun Mar 22 08:48:27 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 1AB371A8A7C for ; Sun, 22 Mar 2015 08:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 zeH95qUwrjaf for ; Sun, 22 Mar 2015 08:48:22 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67551A8A1B for ; Sun, 22 Mar 2015 08:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1427039302; x=1458575302; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=xwl/9FXT7VbgRA3DjeoxB1TBlkeANe+0ebNNuuJpvig=; b=QYaiacVmZjx8PvE2guN3eSFOGwGpsgQjxJzYZKKljMH0XrzmjOyo4jAn T8AweiBLtMC58Y8cn3EmeX5fEN7xk3Lk+t7V/zhpNryGmv45icbApujrK LKJOBd5eOKobQJKaZ1IWGwnn3PFdsQxSrgx/U7wh2HPvWNBG3j/5gpMcx A=; X-IronPort-AV: E=Sophos;i="5.11,446,1422874800"; d="scan'208";a="315631989" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Mar 2015 04:48:19 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 23 Mar 2015 04:48:18 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] "OpenPGP Simple" Thread-Index: AdBkt52PnuT6ijpBTwa2qKg8mG4pgg== Date: Sun, 22 Mar 2015 15:48:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB9A25@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 15:48:24 -0000 Gregory Maxwell writes:=0A= =0A= >A CA has signed an intermediate CA cert which is loaded in an interception= =0A= >appliance. You blacklist this certificate by ID. Your blacklisting is=0A= >bypassed by simply changing the encoding of the when sending the cert cha= in=0A= >and now your traffic can be intercepted again.=0A= =0A= This issue has been known for a long, long time (well, I guess not by the= =0A= OpenSSL authors :-). The problem is its being tied to a blacklist-based=0A= security mechanism, you can always evade the blacklist through trivial=0A= encoding changes that produce a valid but not bit-for-bit identical encodin= g.=0A= =0A= Since all of PKI is built around blacklists (the second dumbest idea in=0A= computer security, and arguably a special case of the dumbest idea in compu= ter=0A= security, default-allow), the PKIX folks argued that using certificate=0A= fingerprints to uniquely identify a cert wasn't allowed because it broke th= eir=0A= blacklist/default-allow based approach to things.=0A= =0A= As a result, they identify certs via their serial numbers (so a CRL isn't= =0A= really a CRL but a SNRL, a serial-number revocation list). So now, instead= of=0A= a single easily-identified problem (trivially fixed by not relying on=0A= blacklists for security), you have a whole raft of problems, many of them= =0A= still waiting to be discovered.=0A= =0A= In other words the PKIX approach is to decide on a wrong solution=0A= (blacklists), and then to break other things (certificate IDs) in order to= =0A= perpetuate the wrong solution.=0A= =0A= Peter.= From nobody Sun Mar 22 09:01: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 AA5CA1A8A7C for ; Sun, 22 Mar 2015 09:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 599eTdH9Nosz for ; Sun, 22 Mar 2015 09:01:55 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (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 47A141A8A58 for ; Sun, 22 Mar 2015 09:01:55 -0700 (PDT) Received: by labon10 with SMTP id on10so17273013lab.2 for ; Sun, 22 Mar 2015 09:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G147aKVaw8+LCvshdHSuCunTjjX4meWhg8qdM4wsdsQ=; b=VDRs2uaqdFRuXZSQvfH7Mv8zbVT1B+dX6c8R5onBPHn5GtTcu70RUMMmL0pFOPDSha UFrTzlpOUBleepggq1qkasq7N41u2QVRfo1W/wd4WwnC1ufvcyxYKC5NhyzP3vHcwV75 Z9ec5p2oB82AyDC2i3w6Yd7Xbk9MrCg+EVhEEgjaJAeYkU30PGmoVjS4Gv5/hi3n3GMj 309ZYIc0JiSI2B9Xan6kdoOm49DJ93vuVGEASEdTMA2Pr2VkhEEBfRvIiBMD0rpoA35f nbyff+z3/XUXT/EBkvUxbrCNP96OkiFLOw8uBePoRhHm+6Yrv2e8V0Wb75jKjKi7m+lY Sl0A== MIME-Version: 1.0 X-Received: by 10.112.151.226 with SMTP id ut2mr62093317lbb.55.1427040113727; Sun, 22 Mar 2015 09:01:53 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Sun, 22 Mar 2015 09:01:53 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB9A25@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB9A25@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 22 Mar 2015 12:01:53 -0400 X-Google-Sender-Auth: KR7ce0w_CjkhBExEJwpoj7jBTIA Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 16:01:56 -0000 On Sun, Mar 22, 2015 at 11:48 AM, Peter Gutmann wrote: > Gregory Maxwell writes: > >>A CA has signed an intermediate CA cert which is loaded in an interception >>appliance. You blacklist this certificate by ID. Your blacklisting is >>bypassed by simply changing the encoding of the when sending the cert chain >>and now your traffic can be intercepted again. > > This issue has been known for a long, long time (well, I guess not by the > OpenSSL authors :-). The problem is its being tied to a blacklist-based > security mechanism, you can always evade the blacklist through trivial > encoding changes that produce a valid but not bit-for-bit identical encoding. > > Since all of PKI is built around blacklists (the second dumbest idea in > computer security, and arguably a special case of the dumbest idea in computer > security, default-allow), the PKIX folks argued that using certificate > fingerprints to uniquely identify a cert wasn't allowed because it broke their > blacklist/default-allow based approach to things. > > As a result, they identify certs via their serial numbers (so a CRL isn't > really a CRL but a SNRL, a serial-number revocation list). So now, instead of > a single easily-identified problem (trivially fixed by not relying on > blacklists for security), you have a whole raft of problems, many of them > still waiting to be discovered. > > In other words the PKIX approach is to decide on a wrong solution > (blacklists), and then to break other things (certificate IDs) in order to > perpetuate the wrong solution. No, the idea in PKI is that certificate issue is a whitelisting. So CRLs are then a blacklisting of previous whitelist entries. I don't think it really matters though as short lived certs are going to be the basis for the emerging PKI/2. The need for certificate revocation lists goes away just when I work out how to compress them. If we could agree on one way to calculate a fingerprint of a key that can be used for both OpenPGP purposes and PKI/2 then we can get the systems to interop very nicely. From nobody Sun Mar 22 09:17:23 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 A6B471AC3D7 for ; Sun, 22 Mar 2015 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5VGwUxoJono for ; Sun, 22 Mar 2015 09:17:21 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 240B91AC3B7 for ; Sun, 22 Mar 2015 09:17:21 -0700 (PDT) Received: by igcau2 with SMTP id au2so24118598igc.0 for ; Sun, 22 Mar 2015 09:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3dE5gQbSr2s02nLBAnw7WGwWjyGnmstxAnr28T9jh/g=; b=uPN6230YLhgWFvig5cx1uyte8JfM1RKil85504yGikqf3J7tK7UP7gugpDai3tTAQu dtnztnRaPHkGXNxQ7DiOVdJ0qgDBhG8xLc8L22GuW/enXzOwcpK8mBCR0CNqvuKnrRiq LMSJ8oM9kPfToEjWyk5Uf6Jtp6c33sEtV17f5YXKeqI17gksjePl2XlGYGAIDr0nd6UC //PccOJsH6uTN5ahfilYDdBBelGNk/Pn4G+hlVUQXAx2WA8uJZ33vHlO5WvV3FopqSmJ Lg5XIN8d0kjlGWmv6SfldHC4CdKog8LmOrDY2m4tuMJFYeOwIKAcQZRxkxS5jT8q6K9a QRDg== MIME-Version: 1.0 X-Received: by 10.50.176.196 with SMTP id ck4mr9391581igc.40.1427041040628; Sun, 22 Mar 2015 09:17:20 -0700 (PDT) Received: by 10.107.6.133 with HTTP; Sun, 22 Mar 2015 09:17:20 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB9A25@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB9A25@uxcn10-5.UoA.auckland.ac.nz> Date: Sun, 22 Mar 2015 16:17:20 +0000 Message-ID: From: Gregory Maxwell To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 16:17:22 -0000 On Sun, Mar 22, 2015 at 3:48 PM, Peter Gutmann wrote: > This issue has been known for a long, long time (well, I guess not by the OpenSSL authors :-) Yes, it was known by me in advance of that CVE as well. > In other words the PKIX approach is to decide on a wrong solution > (blacklists), and then to break other things (certificate IDs) in order to > perpetuate the wrong solution. And yet, in the end of the day users who thought they were secure are left insecure. How many years of compromises must people be subjected to before we, in industry, become mature enough to develop systems which remain secure _in practice_ in the face of design and implementation errors by avoiding designs which have repeatedly resulted in breaks and defending in depth? We cannot know in advance what procedures and protocols people will build in the future. If our abstractions are less safe-- if they have a large amount of surprising hidden behavior such as non-canonical encodings-- then the review requirements for anyone attempting to build on them becomes unreasonably large and the amount of failure will increase. The true complexity of a modern application is beyond what any one mind can fully grasp at one time, we all must manage complexity by abstraction, and some designs lead to safer abstraction than others. That an approach that was taken, like blacklisting, by a downstream user of a cryptosystem design which stupid and wrong may also be true and it's fine to also say that when it is so... But that fact does not excuse specifying a protocol which is a footgun when it could have been avoided with little cost (or, in the case of BER.. lower cost, since a complete BER implementation is very complex). People will do stupid things, from time to time, if our cryptosystems can only be secure with completely perfect use then we might as well give up and go home because perfect use will not happen and demanding it at all times is an unreasonable cost which can easily outweighs the benefits of the tools. Sometimes there is a trade-off where there is a exclusive choice between a valuable feature and a footgun. In those cases, it often is reasonable to accept the footgun. I have _never_ seen such an argument for overcomplete encodings; other than for the sake of compatibility with legacy systems (for cryptographic tools this compatibility is inevitably lost due to other reasons, like the legacy systems being insecure). The overcomplete encodings massively increase the review and testing burden (the usual response is to just fail to test sufficiently) and as a result hide bugs. They inherently increase the communication overhead (not that it matters, the context where they come up are are usually very inefficient to begin with) when they are possible, but subsetting them out (like DER does to BER) hardly increases the overhead compared to 'optimal' use. Sadly, it is infeasible to uncover in advance all the corner cases in a spec that will surprise people and contribute to vulnerability; but in cases where we've /seen/ problems in the wild we should not respond by blaming the victims that misused the use fragile constructions, once we know they're fragile we should avoid them where possible. From nobody Sun Mar 22 11:04: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 48D851A0022 for ; Sun, 22 Mar 2015 11:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aiu6uUoKCll for ; Sun, 22 Mar 2015 11:04:35 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (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 63D311A0004 for ; Sun, 22 Mar 2015 11:04:35 -0700 (PDT) Received: by qcbjx9 with SMTP id jx9so90995507qcb.0 for ; Sun, 22 Mar 2015 11:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QeH7sz2+7ie0hrY8RqTLUxJnPEId35yhu0rC9jYwajY=; b=aotDHtABvSRhQRtyAYunvFu/c/Tb5sdPz/1IdiYBzq6TJ24ZiUpjvt5agaVebwHFA9 ZW6xnzYYcjH7VMlzEkjmNAzNEo3E+dv1twG69ZbxfqaKVS9RpkCM61WvCK9PRqkTEkve +h6e/vsvm+Ox8/DJUDnMH7Zu1IAvVNJ+b/bGzTLowUV4qMQLhI80pEgSnXAr9w+2TX8x eaKCLIcTFiT28sITf+sUmHem8fLWtMjOCis5ceQ8U/f2S6fjDA457veMNF8MovhWo0R1 5Hgzo8Z5dyxjD9RHZugTrO2gLbMiheb0K7kFAeklcL4i24wHxiYZuxcwWNtXEQcjT7xO rJZg== X-Received: by 10.140.152.10 with SMTP id 10mr85945966qhy.40.1427047474712; Sun, 22 Mar 2015 11:04:34 -0700 (PDT) Received: from [10.56.108.80] (mobile-107-107-61-60.mycingular.net. [107.107.61.60]) by mx.google.com with ESMTPSA id 10sm7488934qha.38.2015.03.22.11.04.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 11:04:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPhone Mail (12B436) In-Reply-To: Date: Sun, 22 Mar 2015 14:04:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB9A25@uxcn10-5.UoA.auckland.ac.nz> To: Gregory Maxwell Archived-At: Cc: "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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: Sun, 22 Mar 2015 18:04:37 -0000 In this case the security problem was created by an unjustified assumption t= hat the relying party would verify the canonical encoding=20 So no, this is a problem the canonicalists caused.=20 Sent from my difference engine > On Mar 22, 2015, at 12:17, Gregory Maxwell wrote: >=20 > On Sun, Mar 22, 2015 at 3:48 PM, Peter Gutmann > wrote: >> This issue has been known for a long, long time (well, I guess not by the= > OpenSSL authors :-) >=20 > Yes, it was known by me in advance of that CVE as well. >=20 >> In other words the PKIX approach is to decide on a wrong solution >> (blacklists), and then to break other things (certificate IDs) in order t= o >> perpetuate the wrong solution. >=20 > And yet, in the end of the day users who thought they were secure are > left insecure. >=20 > How many years of compromises must people be subjected to before we, > in industry, become mature enough to develop systems which remain > secure _in practice_ in the face of design and implementation errors > by avoiding designs which have repeatedly resulted in breaks and > defending in depth? >=20 > We cannot know in advance what procedures and protocols people will > build in the future. If our abstractions are less safe-- if they have > a large amount of surprising hidden behavior such as non-canonical > encodings-- then the review requirements for anyone attempting to > build on them becomes unreasonably large and the amount of failure > will increase. The true complexity of a modern application is beyond > what any one mind can fully grasp at one time, we all must manage > complexity by abstraction, and some designs lead to safer abstraction > than others. >=20 > That an approach that was taken, like blacklisting, by a downstream > user of a cryptosystem design which stupid and wrong may also be true > and it's fine to also say that when it is so... But that fact does not > excuse specifying a protocol which is a footgun when it could have > been avoided with little cost (or, in the case of BER.. lower cost, > since a complete BER implementation is very complex). People will do > stupid things, from time to time, if our cryptosystems can only be > secure with completely perfect use then we might as well give up and > go home because perfect use will not happen and demanding it at all > times is an unreasonable cost which can easily outweighs the benefits > of the tools. >=20 > Sometimes there is a trade-off where there is a exclusive choice > between a valuable feature and a footgun. In those cases, it often is > reasonable to accept the footgun. >=20 > I have _never_ seen such an argument for overcomplete encodings; other > than for the sake of compatibility with legacy systems (for > cryptographic tools this compatibility is inevitably lost due to other > reasons, like the legacy systems being insecure). The overcomplete > encodings massively increase the review and testing burden (the usual > response is to just fail to test sufficiently) and as a result hide > bugs. They inherently increase the communication overhead (not that it > matters, the context where they come up are are usually very > inefficient to begin with) when they are possible, but subsetting them > out (like DER does to BER) hardly increases the overhead compared to > 'optimal' use. >=20 > Sadly, it is infeasible to uncover in advance all the corner cases in > a spec that will surprise people and contribute to vulnerability; but > in cases where we've /seen/ problems in the wild we should not respond > by blaming the victims that misused the use fragile constructions, > once we know they're fragile we should avoid them where possible. >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Sun Mar 22 14:47:54 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 B7E321A1C06 for ; Sun, 22 Mar 2015 14:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 H8Ffahmyf9IH for ; Sun, 22 Mar 2015 14:47:51 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id F35091A1C05 for ; Sun, 22 Mar 2015 14:47:50 -0700 (PDT) Received: from fifthhorseman.net (unknown [199.227.110.154]) by che.mayfirst.org (Postfix) with ESMTPSA id C57B4F984; Sun, 22 Mar 2015 17:47:47 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2B8E6207C0; Sun, 22 Mar 2015 16:47:46 -0500 (CDT) From: Daniel Kahn Gillmor To: Albrecht =?utf-8?Q?Dre=C3=9F?= In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 22 Mar 2015 16:47:45 -0500 Message-ID: <87h9tcd7r2.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: gnupg-devel@gnupg.org, IETF OpenPGP , Hanno =?utf-8?Q?B=C3=B6ck?= Subject: Re: [openpgp] Encrypting / Signing the mail subject? 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: Sun, 22 Mar 2015 21:47:52 -0000 Hi Albrecht-- On Sun 2015-03-22 11:56:42 -0500, Albrecht Dreß wrote: > Am 17.03.15 00:28 schrieb(en) Daniel Kahn Gillmor: >> Are you thinking of having this line in the embedded header or in the >> external header? > > Only in the embedded, signed headers block. [...] >> As for the embedded header, i'm not sure it's useful there either. >> it seems like a bit of a chicken-and-egg problem. > > Hmmm, yes, thinking again about it, you're right. The only use of > that header would be informing the recipient of a message about the > purpose of this part if the MUA does not perform any further action > with it (see the attached screen shot as example). Hm, if the goal is human-friendliness, then we probably want to think about how to be even friendlier -- english text plus a URL to an en_US-only webpage isn't very nice to the majority of the world either :P >> i think the list of encrypted headers might arguably be *all* of the >> headers except for some dummy block that is generated per-message. > > What do you mean with "some dummy block"? the "dummy block" is the headers that get wrapped around the outside of the message. Alexey Melnikov just pointed me to this draft: https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00 which has a similar mechanism (and is designed for S/MIME), and it refers to the same idea as a "stub value" https://tools.ietf.org/html/draft-melnikov-smime-header-signing-00#section-3 > BTW, the Message-Id header may also leak information if uses the > recommended form of RFC 5322, sect 3.6.4 (domain or FQDN as right-hand > side). The 'dot-atom-text - "@" - dot-atom-text' format with random > data on both sides (which is also explicitly allowed) should be > preferred IMHO, as long as it is guaranteed to be unique. good point! >>> I think this should read: "if the text/rfc822-headers part is >>> * the first part of a multipart/mixed, which in turn is the first part of the top-level multipart/signed or application/pkcs7-mime, or >>> * the first part of the top-level decrypted multipart/mixed for unsigned, but encrypted messages." >> >> That seems more narrowly scoped, which is probably a good thing, but >> it might be more brittle too; are there specific cases that you're >> trying to carve out from my broader suggestion? > > I think your definition would try to match the text/rfc822-headers > part to the message headers in the following weird case: > > multipart/signed > +- multipart/mixed <-- message #1 does *not* contain protected headers > | +- text/pain > | +- message/rfc822 <-- forwarded message #2 *with* protected headers > | +- multipart/signed > | +- multipart/mixed > | | +- text/rfc822-headers <-- protected headers of forwarded message #2 > | | +- text/plain > | +- application/pgp-signature > +- application/pgp-signature > > Here, text/rfc822-headers *is* the first non-multipart part within a > multipart/signed, but it doesn't belong to the (top-level) message #1, > so it's wrong to compare them. I think, my definition would catch > this case. You're right. I think this distinction is useful. PS i love the content type "text/pain" -- can we register that one officially, please? ;) Melnikov's draft proposes a content-type parameter "forwarded" to be used on the message/rfc822 element, to distinguish these cases. I haven't thought through the consequences of the way this his draft sets it up, though -- it seems possible to misinterpret the lack of a header from a non-compatible sender forwarding a message. --dkg From nobody Mon Mar 23 07:10:46 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 031111A8ACB for ; Mon, 23 Mar 2015 07:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] 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 FJzoPGgzpu0R for ; Mon, 23 Mar 2015 07:10:43 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622531A8AC1 for ; Mon, 23 Mar 2015 07:10:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0B402E2038 for ; Mon, 23 Mar 2015 10:10:42 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15496-03 for ; Mon, 23 Mar 2015 10:10:39 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:2001:67c:370:176:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 419F3E2036 for ; Mon, 23 Mar 2015 10:10:39 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2NEAbC4028502; Mon, 23 Mar 2015 10:10:37 -0400 From: Derek Atkins To: openpgp@ietf.org Date: Mon, 23 Mar 2015 10:10:37 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [openpgp] Bar BOF tonight: French Room, 1930 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, 23 Mar 2015 14:10:45 -0000 Hi, We have a location for the Bar BOF tonight. We've acquired access to the French Room on the banquet level. Let's meet there at 1930 after the plenary. Then we could migrate to a place with more liquid refreshments. See you there, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Mar 23 11:12:36 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 6B94F1AD0BE for ; Mon, 23 Mar 2015 11:12:34 -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 czOaKtpVLjCC for ; Mon, 23 Mar 2015 11:12:31 -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 AA0661AD0BD for ; Mon, 23 Mar 2015 11:12:29 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id EF01E6D7FA; Mon, 23 Mar 2015 14:12:27 -0400 (EDT) Message-ID: <5510578A.80304@iang.org> Date: Mon, 23 Mar 2015 18:12:26 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1426721882.4249.72.camel@scientia.net> In-Reply-To: <1426721882.4249.72.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New encryption formats for messaging 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, 23 Mar 2015 18:12:34 -0000 On 18/03/2015 23:38 pm, Christoph Anton Mitterer wrote: > On Fri, 2015-03-13 at 17:41 -0700, David Leon Gil wrote: >> A0. Be as secure as possible by default. Do not offer options to >> fallback to doing unsafe things. "Experienced" users often think they >> want them; there are usually better solutions for their use-cases. > Yes and no. > > Looking at the context you come from (Yahoo) I must note, that the big > players seem to have discovered security recently ... o.O Hmmm... so our technique is to punish people for wanting to improve. Grand... > And part of their marketing strategy seems to be "security must be > easy" (i.e. a totally unaware person should be able to be "secure"). > This is basically the same what some people around the heise Verlag seem > to campaign for recently. New to some, but it has a long history: Kerckhoffs' 6th principle: "6. Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe." Writing about cryptography communications systems in 1883. http://www.financialcryptography.com/mt/archives/000195.html > While this sounds like a great goal it's completely unrealistic. > Someone who doesn't at least know some basic concepts will never be > secure, because he'll believe any social engineering and the first mail > telling him to just fetch the "unknown key from website X or keyserver > Y" will be followed. > Many of my less crypto-aware friends use nowadays things like > TextSecure/etc. on their mobiles, believing they're secure. > Well first it's Android (so failed) and second, none of them knows about > the basic principle that one *is not* secure if not some form of mutual > authentication hasn't taken place via some secure path (i.e. not > first-come-is-trusted like key pinning). I think this is simply wrong. This is no principle. TOFU has proved itself. If you don't want to use it, that's fine, but the notion that it's "not secure" is simply rubbish because security is a relative risks thing, not an absolute thing, and it is extremely unlikely in almost all cases that anyone's going to watch and dive like that. Security is statistical, it is risk. Empirically, I just today got my first 419 hit on Skype, which was set up to let others see my name - their mistake on default install. After about a decade of usage? Even including the notion that Microsoft now copies it all to the NSA, that's still only 4 parties with capability to connect to me: Me, my friends, Microsoft and NSA. > To be honest, Yahoo, doesn't have the best security record, and in > general I wouldn't trust any web-based crypto app regardless of who it > wrote. > > That being said, I agree that it shouldn't be easy to make a well > designed crypto system insecure by settings - but not if this means that > one takes away valid functionality from the more experienced users. Why do you prioritise "experienced users" above the lesser experienced? Do they pay more money? Is this the Church Of BOFHs? Do they pay their dues by helping others? From your writings it seems unlikely... > And definitely not for marketing reasons. No such group exists in most places. In SSL there is a myth that sysadms can understand how to configure the apache config files, so consequently choice is good. None do, to a very high statistical confidence - most copy files back and forth, and a few read guides like bettercrypto.org. And I can tell you that the BetterCrypto guys are always having arguments about what is right, best, etc. If the <1% can't agree the 99% is screwed. >> A1. Only specify a single asymmetric encryption scheme and a single >> asymmetric signature scheme. This is critical: This is the second most >> dangerous and buggy code in any crypto scheme. > Why? > > a) What's the problem a with symmetric scheme as we have it now? It's all old stuff. We've moved on. > b) Why should there be only one? > I think its a wrong assumption that code will become more secure by > supporting less algos/systems. > If a project cannot develop/maintain more of them securely it's rather a > sign for lack of funding/manpower. Ah. So you see that handling more algorithms is a cost for big companies to meet and therefore a barrier to entry which makes for less choice and eventual balkanisation. What about opportunity cost - time spent managing and debugging algorithms that are rarely if ever used - could be better spent on getting more usability? > The past has shown that sooner or later every algorithm (except for OTP > of course ;) ) has its flaws and is needed to be replaced. > Quite often recently, people waited far too long till that replacement > started (just look at the issues in SSL/TLS). Fully agreed. Now, here? > Since the experience has shown that standardisation of something new > takes quite a while (see the discussions about Curve25519 at the CFRG) I > would feel much better if a cryptosystem has several algorithms > (ciphers, signature schemes, hash algos, etc.) ready in place. > Implementations can still strongly suggest only a small subset to be > actually used - but *if* some problem is found in these, it wouldn't > take ages to get rid of them (like RC4, basically all the old CBC and > non-EtM algos in SSH, TLS,... hell we still have systems in the wild > which use MD5 for security purposes) That argument didn't work. Basically when ever a problem was found, it couldn't be solved by an algorithm switch, 9 times out of 10. The one time that a problem was found, it was solved by ... a switch *backwards* to RC4. Not exactly a happy result. Secondly, *there is no plan to switch*. There is a switch, but no plan, no methodology nor siren nor alert. Algorithm agility is all standards body sophistry, not real life. It's another paper invention thrown over the wall, and when it's actually needed, it doesn't deliver. >> A2. Clearly separate handling of various message and key metadata from >> the underlying encryption scheme. This is critical: Parsing code is >> the most dangerous and buggy code in any crypto scheme. > It's a bit unclear to me, what exactly you mean here. layering. >> A3. Do not specify things which are infeasible to thoroughly test. >> This implies avoiding combinatorial complexity, which the OpenPGPv4 >> spec doesn't. > As above, I doubt you can really check every combination, and I wouldn't > want to sacrifice too much, just for being able to do so - especially > not diversity of algorithms. When has diversity of algorithms ever bought user advantage? I can think of (been told) one case: the "Russians GOST" requirements. Frankly, I'm not that keen to let them do that. If *every* government did it, then we'd be in a pickle, and we'd not be talking to any of them at all. So why do we care about the Russians? Why are we actually preparing a perfect argument for USA Congress to turn around and mandate a USA weak key suite? >> A4. All messages, including signed but unencrypted messages, should be >> indistinguishable from random to an adversary who does not know the >> public key of the signer. (This is, essentially, a Tor-style security >> requirement.) > By "messages" you mean "OpenPGP Messages" i.e. also they keys? > > > >> B1. Only modern hash functions that provide a significant security >> margin against cryptanalysis. Let's not repeat the MD-5/SHA-1 >> disaster. (We only need two hash functions at most.) > Disagreeing with the "We only need two hash functions at most.". > > Diversity is good (of course we should only include secure algos), > especially when one expects that each algo sooner or later sees > weaknesses. Well, sure, on paper. But if you had a process to switch then you could also ... use that process to switch! Why not just roll out v+1 ? >> B2. Only block and stream ciphers that offer a significant margin of >> safety against cryptanalysis. (Or that, when composed, offer a >> significant margin of safety against cryptanalysis.) >> >> B3.. A single AEAD mode that is maximally misuse-resistant, in the >> sense of https://eprint.iacr.org/2014/793. (But probably not AEZ, or >> any other CAESAR competitor for that matter. I would prefer a scheme >> that uses generic composition of well-studied primitives.) Here's my take on this. Pick the most experienced guy in the room, tell him to come back next month with a recommendation. Done. iang From nobody Mon Mar 23 11:29:50 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 819301AD213 for ; Mon, 23 Mar 2015 11:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OPPNzv344LnW for ; Mon, 23 Mar 2015 11:29:47 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A641AD0B2 for ; Mon, 23 Mar 2015 11:29:46 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id D3FA85FB89 for ; Mon, 23 Mar 2015 18:29:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id kywIGLLWNkp3 for ; Mon, 23 Mar 2015 18:29:43 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Mon, 23 Mar 2015 18:29:43 +0000 (UTC) Message-ID: <1427135380.10191.27.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Mon, 23 Mar 2015 19:29:40 +0100 In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> <1426719109.4249.28.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-keK9SoYFlTeZLkmoibri" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 23 Mar 2015 18:29:49 -0000 --=-keK9SoYFlTeZLkmoibri Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-03-18 at 19:32 -0400, Phillip Hallam-Baker wrote:=20 > I think that it is now widely agreed that if SMTP was to be revised, > it would be separated into two layers with the message routing headers > in one section and the content meta-data in another. And you really think this is every going to happen in our life time? ;-) (And standardising something is one thing, but having it effectively used on millions of mail systems/software/etc. - a completely different topic). Cheers, Chris.=20 --=-keK9SoYFlTeZLkmoibri Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyMzE4Mjk0 MFowTwYJKoZIhvcNAQkEMUIEQIglkU1ZTkcEEALgVfW5g2Vr2+c7XBrQO0aQ1NEDrQl2TKfY01gb 4syT60WFrglwN6V9Br6Ay/sYqmTCrFS/+YAwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQC47QN4P1bFFoz9tsUVsSSvlfBr5Re9 uHik1WkJBqjauiNNxutnHiUNFVxRLC/c0kpL6z5RMLvg/tDPT82hLsAEEJYbRE8QE/TEtgrZlg+M njsSUC9TOWhqWHZAAw8JwF4g99wEs7tvdyDXTBmxRTrLzGCtzJNgfpEtbJLd0gtSj71P05X0aaEL VavS0egw2QimGGVF6IeHnFuksQMxdCeLD+9auXE2zyDImJQ2asCNGsRtxxVmr248Cuo38Kc+en5G JiCAieiOAbZzGu4TwTJDoQcKVDg/EDzac3Yyt2HV+CntwT4K4zOGwIxhhsoDhlTMnILy2BghZNUJ FBDBAxPtAAAAAAAA --=-keK9SoYFlTeZLkmoibri-- From nobody Mon Mar 23 11:33:51 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 49FA31AD1BF for ; Mon, 23 Mar 2015 11:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B7kv9PKHsobi for ; Mon, 23 Mar 2015 11:33:47 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883051AD0CB for ; Mon, 23 Mar 2015 11:33:47 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id C5D3A5FBA7 for ; Mon, 23 Mar 2015 18:33:45 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id mUokEmX4l-uL for ; Mon, 23 Mar 2015 18:33:44 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Mon, 23 Mar 2015 18:33:43 +0000 (UTC) Message-ID: <1427135621.10191.30.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Mon, 23 Mar 2015 19:33:41 +0100 In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <088CD5E6-CDB9-44E3-8762-DA51E3D7A294@jabberwocky.com> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-yQLZoy85FaKcglJjd5x/" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 23 Mar 2015 18:33:50 -0000 --=-yQLZoy85FaKcglJjd5x/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-03-18 at 19:33 -0400, Phillip Hallam-Baker wrote:=20 > But that 32 bit length really worries me. Just because people can=E2=80= =99t > send 4GB messages today does not mean that they can=E2=80=99t or won=E2= =80=99t in the > future. Do not build OpenPGP around assumptions based on SMTP > continuing forever. Use today is not limited to mail in any case. +1 > If I have a 1TB archive file I am not going to want to break it into > chunks just to encrypt it. +1 > the field is moving towards JSON for almost everything. I'm not so convinced about that... there are still many areas where completely other things (e.g. XML) are used. > Again, I am not sure that a complete overhaul is desirable. When I originally wrote about "complete overhaul" in my wishlist, I didn't meant to say whether it's necessary or not. But it would at least be a nice way to get rid of all legacy cruft that may have came together over the years. A fresh start often allows one to employ much cleaner designs :) Cheers=20 --=-yQLZoy85FaKcglJjd5x/ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyMzE4MzM0 MVowTwYJKoZIhvcNAQkEMUIEQJM7PWjtLREWOs1cXrXD1zY2XArUUO7n6iPhWoERXfWQq3eyvhlr /+n8L478lKhoqoBFmkRn4LAiZXWSF/gsmwMwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBGNZ8DHmwIQHEFQvDNbXBTCzpffr2c 0Pv9D7cfX2BcQQGAG6fGnTEWFEE1m/IW2d1EdfWW1nhlyfOOuMnOfCDWPzW7jyFLjuNIUmwtmfXS WJKiZJo9Al8xQCwoA8FywE+QI93UPPLNVFV2Dtc220u5BTnwqPb4Z+J7RVm0yjePIqTTa4M/ya7O 4bhjyC35Mitq3EFikBM6RIbpWcrXmYlJZMLyfBb3OK2rb78G5R3jx3GZ+k91JjcbXsyAnhwC56qA gAX+s03qGqHkyqZhgyHGXXEP09EbLmUTqxT2pwMJZKwmnPZI05RNvR6cluPi4Vq1Ro45xz8L91+M 50BBdUFCAAAAAAAA --=-yQLZoy85FaKcglJjd5x/-- From nobody Mon Mar 23 11:37: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 69B6B1AD1EC for ; Mon, 23 Mar 2015 11:37: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 CNYm8maObUaF for ; Mon, 23 Mar 2015 11:37:00 -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 925211AD0F0 for ; Mon, 23 Mar 2015 11:37:00 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 716CA6D7A7; Mon, 23 Mar 2015 14:36:59 -0400 (EDT) Message-ID: <55105D4A.3030307@iang.org> Date: Mon, 23 Mar 2015 18:36:58 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 23 Mar 2015 18:37:01 -0000 On 18/03/2015 22:38 pm, Bill Frantz wrote: > The software works fine. The user has either lost the secret key file or > has forgotten the passphrase. I don't know a technical solution, > particularly to the 2nd problem. Any suggestions? Keystores like Apple's do fine here. Basically, if we see the pgo key password as just one password in 100 then it becomes clearer. Just another thing that made sense in 1992, but things have moved on ;) iang From nobody Mon Mar 23 11:48:35 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 F25A31AD2EE for ; Mon, 23 Mar 2015 11:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, 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 sZhSmq3Q-hBU for ; Mon, 23 Mar 2015 11:48:33 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAB51AD2C0 for ; Mon, 23 Mar 2015 11:48:33 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 39AC55FBA8 for ; Mon, 23 Mar 2015 18:48:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id j1jcfZu-z7-j for ; Mon, 23 Mar 2015 18:48:30 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Mon, 23 Mar 2015 18:48:30 +0000 (UTC) Message-ID: <1427136508.10191.33.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 23 Mar 2015 19:48:28 +0100 In-Reply-To: References: <55038CBE.7070608@iridiumlinux.org> <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-EnM19BfePEtTggtsmKZ9" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 23 Mar 2015 18:48:35 -0000 --=-EnM19BfePEtTggtsmKZ9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-17 at 11:27 -0400, Derek Atkins wrote:=20 > I don't agree with this statement. It wasn't flexibility that stopped > changing CFB, it was that CTR mode was relatively new when the group was > working on 4880 (I'm not sure it even existed when we did 2440). And > compatibility was always (generally) paramount. I.e., if it ain't > completely broke let's not fix it.. and where it is broke, let's fix it > in the most compatible way. >=20 > Were I do start from scratch today then yes, I'd just use GCM. We could > certainly add a GCM mode and a preference to specify support for it. > But for interop I don't think we could drop CFB support completely from > implementations. Could you elaborate on that? I probably lack some decent+recent cryptanalysis of CFB as used with OpenPGP, but at least we had quite a number of crypto systems where it caused all kinds of issues recently. So *if* there's a new OpenPGP v.X (and not just "amendments" as with Ed25519), shouldn't it be actually a goal to get current state of the art things? Cheers, Chris. --=-EnM19BfePEtTggtsmKZ9 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyMzE4NDgy OFowTwYJKoZIhvcNAQkEMUIEQOhNm5ns/dCIwi3FPZUIKAJNFdxqrrKMogDnTNJZalB1LakRJBVz D4fPDC/ExFM+W18SO9cKmov7CQidfwYLw/EwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB+WNiwPXh7ZaPXcc9Hsc5G1Frog3sl mrK75TDaKPs0ND3rutjvMUF+jazGsKFTKkWTdKu5PkAAzfMuXCu3yeYFfVZEiG0EwVDT324yqQ/U CNCwdccwjfVeuGZPDwdVBZcTlhQWZUyhraZd1Q2RfE6sOU/fn02Nuo1KeJyGqEn4o8xn2ahgXXGr 5HXNZ4U88qh/hKt1+Vf+AIKU0iBIjtm/lTq0x0Chfk6d0N38nOQsiGPoiHFgGixvQS2oz7D3FYgT U3ZmcM013b+vzqOGTuwLL99hY83BtQf/0hOPMRHfORfnSxeIc0YRO2G5ei3E04rBqtrq8cG4XPGJ lIQRmc3xAAAAAAAA --=-EnM19BfePEtTggtsmKZ9-- From nobody Mon Mar 23 12:04:05 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 236631AD0C2 for ; Mon, 23 Mar 2015 12:04:04 -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 QJus-LS1s8FW for ; Mon, 23 Mar 2015 12:04:02 -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 AC7BE1AD333 for ; Mon, 23 Mar 2015 12:04:02 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 81EE66D7A3; Mon, 23 Mar 2015 15:04:01 -0400 (EDT) Message-ID: <5510639F.3030004@iang.org> Date: Mon, 23 Mar 2015 19:03:59 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <550E88DD.3050908@gmail.com> In-Reply-To: <550E88DD.3050908@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 23 Mar 2015 19:04:04 -0000 On 22/03/2015 09:18 am, Andrew Skretvedt wrote: > I am a curious onlooker with no operational affiliation to the business > of this list (and normally silent), with an observation/question at this > point in this thread: > > Is it considered best practice now to encrypt, then sign? What is the meaning of 'sign'? Do you mean here to sign as if you are affirming that it is you sending the message and you might consider this a digitial signature over your words? If so, then you should sign before encryption, and it's a good idea to do that in cleartext/inline format. Alternatively, are you signing to put a message authentication code over it so that it is securely delivered? In which case, it is better practice to encrypt then sign. While this is not a totally solid rule (it depends on the protocol details) I think this is safe in OpenPGP. > I think I > heard somewhere that SSL/TLS does it the other-way-round and has thereby > innocently created certain problems. GnuPG allows these operations to be > combined on the command line, and then I don't know in what order they > actually occur. Yeah, the research on attacking the order came after these things were thought about in groups. But bear in mind there is a bit of a difference between SHA-style HMACs and RSA-style digsigs. > If you receive an encrypted and signed message, and best practice would > be to, in reasonable time, decrypt from wire-format and re-encrypt to > local format for PFS (which seems to me a really sound policy, given > modern experiences, and might be just as easy as leaving it to your > full-disk-encryption system where you store your mail), might you lose > the ability to provably authenticate the messages in your archive? I can > think of situations where one would not want to lose this ability (e.g. > some sort of dispute or legal proceeding). Yes, that's complicated. Suffice to say that the need to prove that you received a message and didn't change it is way-over-thought in the tech world. 99.999% of it is about having the message [1]. So let's solve the real problems before we make up problems... > Perhaps if they get signed, then encrypted, this problem goes away. But > then why /should/ one do these two operations in one order in the e-mail > context, but perhaps the opposite order in others? (Perhaps I betray my > ignorance at this point.) The reasons are historical. Back then, nobody much knew the difference between authentication and signing. Later on, HMACs were developed for the message integrity. And signing-as-intent fell out of favour because nobody wanted it. So likely a new message suite will include an AE or Authenticated Encryption suite, which will handle all the message integrity. That'll be stripped off, and the message will be delivered plain. Then the software will say who it comes from. If there is a need to keep that proof then we'll likely need another tag to attach to the plaintext message. iang [1] as long as we're talking words. If we're talking transactions then a common dispute is having different 'recollections' of the transaction, and having good MAC'd copies is what we want to achieve. From nobody Mon Mar 23 12:25:49 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 EA2131B29AE for ; Mon, 23 Mar 2015 12:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KqtDgxP8BivE for ; Mon, 23 Mar 2015 12:25:47 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252811AD34D for ; Mon, 23 Mar 2015 12:25:47 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 020F05FBA8 for ; Mon, 23 Mar 2015 19:25:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id Bz24KCg5S4Iu for ; Mon, 23 Mar 2015 19:25:43 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Mon, 23 Mar 2015 19:25:43 +0000 (UTC) Message-ID: <1427138741.10191.48.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 23 Mar 2015 20:25:41 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-3FWUw8vwBNNkfQE7vRQl" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Intent to deprecate: Insecure primitives 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, 23 Mar 2015 19:25:49 -0000 --=-3FWUw8vwBNNkfQE7vRQl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-17 at 11:04 -0400, Derek Atkins wrote:=20 > Show me an MUA that does this, please? None of the OpenPGP-aware MUAs > I've ever used have this feature, as far as I know. I suppose I could > go out of my way to replace the encrypted email with a > re-encrypted/plaintext email. >=20 > But frankly I'd like my encryption software to just maintain the ability > to decrypt it later. While I don't think that implementations should throw away old algos (even if insecure) - the should just no longer use it for creating new content, and should only decrypt/verify signatures with appropriate warnings, I'd say that the question of long term storage of encrypted/signed content (e.g. mails) is (and should be) beyond the scope of OpenPGP. That being said, the WG shouldn't alter the decisions it makes based on that question, but rather only on security considerations. As for e.g. long term email storage: - if you just store them as received over the wire (i.e. encrypted/signed) they may very well become insecure over time, so the original purpose of confidentiality and authenticity is no longer guaranteed (by leaving them with the old encryption/signature). - constantly re-encrypting them seems to be not feasible, and you cannot re-sign mails from someone else. - IMHO the appropriate way would be for a MUA to record that the mail was sent encrypted to you and by whom of your contacts it was signed (if any of that was the case) - for later reference. And any further protection of the content should be handled by disk encryption. Cheers, Chris. --=-3FWUw8vwBNNkfQE7vRQl Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyMzE5MjU0 MVowTwYJKoZIhvcNAQkEMUIEQIDX21xyy3/c7ze8704mxwUFU5n1/07PLV1XZ4Mi84bGOpwObQbz /2xlSeNke8dsz8JVnSOA2hmLx+N4roUbHCcwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDOqT6Cdi6n9rd6lP8hz5JYCifxstxY AdmXs60t6uROEKQYbelkTbR7y1tKL1SwY2sdULLsk/hl3e4XAxDgU/bowMgMmu4JTojVJQv6gln7 PGP0jVzYFuZiBmC9nrOXXl3Nirt+ZVu9veVJstMvWcvkKBAixFC2vWZIMnNpoxYj5f7YvQZJ8piu Bbh4eSljjJEGND92u65cjokDDNm7W47v/Yk4m2Sr6AKaV76DBPHgVeOPJA3nBV6R2+ZpR5W6+MVL bWfVb2Q0p2wZ581bc2BSADN5flX7Jff2HS9pMZ1mo9VIVUczIelisNvze0Ory8eL2dromswVu0pI DnYZig3iAAAAAAAA --=-3FWUw8vwBNNkfQE7vRQl-- From nobody Mon Mar 23 12:52:07 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 EB07C1A034F for ; Mon, 23 Mar 2015 12:52:05 -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 atptSOq2khHd for ; Mon, 23 Mar 2015 12:52:04 -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 959551A037A for ; Mon, 23 Mar 2015 12:52:04 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 08CA06D717; Mon, 23 Mar 2015 15:52:02 -0400 (EDT) Message-ID: <55106EE1.5060404@iang.org> Date: Mon, 23 Mar 2015 19:52:01 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 23 Mar 2015 19:52:06 -0000 On 17/03/2015 02:10 am, Peter Gutmann wrote: > David Shaw writes: >> On Mar 16, 2015, at 5:15 PM, David Leon Gil wrote: >>> Partial lengths are really a nuisance to parse. >> >> No argument there... > > The whole bizarro sort-of-fixed-point encoding of lengths is a pain (this is a > cue for Jon to do his "every bit is sacred" dance). If the format is revised, > there should be only two lengths, a 16-bit one for almost everything (keyring > data, signatures, etc), and a 32-bit one for payloads and partial lengths that > are going to exceed 16-bit lengths. Crazy * 2 :) One int is good enough for anyone. Just use an expanding 7 bit form, where the hi bit says, grab the following byte. > Length-decoding shouldn't be any more > complicated than: > > read tag; > if( tag & length_32_flag ) > length = read32(); > else > length = read16(); > > While I'm venting, shall I get started on the MDC kludge? Simplify! Simplify! iang From nobody Mon Mar 23 12:57:21 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 C83091A065C for ; Mon, 23 Mar 2015 12:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVX3KHIJWQBa for ; Mon, 23 Mar 2015 12:57:18 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::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 650711A1A28 for ; Mon, 23 Mar 2015 12:57:14 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so73703636wib.1 for ; Mon, 23 Mar 2015 12:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yVurbbxvLfAzPznHsen0UunX/aI7MIpSYenbaR2UxyU=; b=nDvEVMHuG9ogyce66Yfl5IPiv7oaDZucMjV06lIsVgx9wxhSifhl2EsmBNrg7Q/c0E 78Q4GQYUakNPf+nXBJL2CT7Y6ionlwzQ+K4P5oBIO6n4hVzF52rDfPLUpGY6QsKC8JIb 2gTc1qVy+JEr+0p+AWGwlgUdg/zZSKpEnMidhMtb3DHIVHAOwg0erMtkjUYjk8WWmSk4 +tUYhycBEeQVEdLN2OvJclCWOSmiuyWqcOzVoiqtYO6XxqMUz/epXVFxWjqt5u3ynf4n kKjNsGWqp9Y9vFh2DbDwI0JEcPUgMQlbhY+ijv3yoaEXNYSOFj2mBxCUd9S/ibX+reu8 j4Zg== X-Received: by 10.194.133.101 with SMTP id pb5mr1638828wjb.40.1427140633198; Mon, 23 Mar 2015 12:57:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:3c9d:f65a:5519:d0c7? ([2001:67c:370:136:3c9d:f65a:5519:d0c7]) by mx.google.com with ESMTPSA id ew13sm12623100wid.1.2015.03.23.12.57.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 12:57:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPhone Mail (12B436) In-Reply-To: <55106EE1.5060404@iang.org> Date: Mon, 23 Mar 2015 14:57:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3823@uxcn10-5.UoA.auckland.ac.nz> <55106EE1.5060404@iang.org> To: ianG Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] "OpenPGP Simple" 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, 23 Mar 2015 19:57:20 -0000 One of the thing I really hate in asinine one is the way they managed to tak= e a bunch of good ideas and trash them....=20 Yes one integer format that expands as needed would be the way to go IFF thi= s is reopened. Sent from my difference engine > On Mar 23, 2015, at 14:52, ianG wrote: >=20 >> On 17/03/2015 02:10 am, Peter Gutmann wrote: >> David Shaw writes: >>>> On Mar 16, 2015, at 5:15 PM, David Leon Gil wrote: >>>> Partial lengths are really a nuisance to parse. >>>=20 >>> No argument there... >>=20 >> The whole bizarro sort-of-fixed-point encoding of lengths is a pain (this= is a >> cue for Jon to do his "every bit is sacred" dance). If the format is rev= ised, >> there should be only two lengths, a 16-bit one for almost everything (key= ring >> data, signatures, etc), and a 32-bit one for payloads and partial lengths= that >> are going to exceed 16-bit lengths. >=20 >=20 > Crazy * 2 :) >=20 > One int is good enough for anyone. Just use an expanding 7 bit form, wher= e the hi bit says, grab the following byte. >=20 >=20 >> Length-decoding shouldn't be any more >> complicated than: >>=20 >> read tag; >> if( tag & length_32_flag ) >> length =3D read32(); >> else >> length =3D read16(); >>=20 >> While I'm venting, shall I get started on the MDC kludge? >=20 >=20 > Simplify! Simplify! >=20 >=20 > iang >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Mon Mar 23 12:59:59 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 4F96D1A0439 for ; Mon, 23 Mar 2015 12:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zjLF3_DS5h47 for ; Mon, 23 Mar 2015 12:59:54 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36B11A03E3 for ; Mon, 23 Mar 2015 12:59:53 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 9CD495FBB3 for ; Mon, 23 Mar 2015 19:59:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id l1i2Q30M9suA for ; Mon, 23 Mar 2015 19:59:50 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Mon, 23 Mar 2015 19:59:50 +0000 (UTC) Message-ID: <1427140788.10191.75.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 23 Mar 2015 20:59:48 +0100 In-Reply-To: <5510578A.80304@iang.org> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-sx0+1bna6HYIpDP0bExI" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] New encryption formats for messaging 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, 23 Mar 2015 19:59:56 -0000 --=-sx0+1bna6HYIpDP0bExI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-03-23 at 18:12 +0000, ianG wrote:=20 > On 18/03/2015 23:38 pm, Christoph Anton Mitterer wrote: > > Looking at the context you come from (Yahoo) I must note, that the big > > players seem to have discovered security recently ... o.O > Hmmm... so our technique is to punish people for wanting to improve.=20 > Grand... Where did I "punish" someone and/or where is my observation wrong? > New to some, but it has a long history: Kerckhoffs' 6th principle: >=20 > "6. Finally, it is necessary, given the circumstances that command its= =20 > application, that the system be easy to use, requiring neither mental=20 > strain nor the knowledge of a long series of rules to observe." >=20 > Writing about cryptography communications systems in 1883. >=20 > http://www.financialcryptography.com/mt/archives/000195.html > I think this is simply wrong. This is no principle. TOFU has proved=20 > itself. Then we can probably abolish fingerprints verification in the next versions of OpenPGP implementations altogether,... if TOFU works, why should anyone bother to check their keys o.O > If you don't want to use it, that's fine, but the notion that=20 > it's "not secure" is simply rubbish because security is a relative risks= =20 > thing, not an absolute thing, and it is extremely unlikely I kinda amused every time security based on such assumptions. Some 5 years ago, the masses still thought that they're not victims of mass surveillance and that their emails and data would be safe. Nowadays people think that TOFU would provide high security and that NSA and friends would never dare to abuse that... > Empirically, I just today got my first 419 hit on Skype, which was set= =20 > up to let others see my name - their mistake on default install. After= =20 > about a decade of usage? Well, NSA and friends probably don't bother to attack systems like Skype on the crypto level, one can be quite sure that they have other means for these =3D) > Even including the notion that Microsoft now copies it all to the NSA,= =20 > that's still only 4 parties with capability to connect to me: Me, my=20 > friends, Microsoft and NSA. uhm... great? o.O > > To be honest, Yahoo, doesn't have the best security record, and in > > general I wouldn't trust any web-based crypto app regardless of who it > > wrote. > > > > That being said, I agree that it shouldn't be easy to make a well > > designed crypto system insecure by settings - but not if this means tha= t > > one takes away valid functionality from the more experienced users. >=20 > Why do you prioritise "experienced users" above the lesser experienced?= =20 > Do they pay more money? Is this the Church Of BOFHs? Do they pay=20 > their dues by helping others? From your writings it seems unlikely... Actually I don't. I just don't prioritise lesser experienced users over experienced ones. What I prioritise is the intention of crypto, which is security. > > b) Why should there be only one? > > I think its a wrong assumption that code will become more secure by > > supporting less algos/systems. > > If a project cannot develop/maintain more of them securely it's rather = a > > sign for lack of funding/manpower. > Ah. So you see that handling more algorithms is a cost for big=20 > companies to meet and therefore a barrier to entry which makes for less= =20 > choice and eventual balkanisation. What about opportunity cost - time= =20 > spent managing and debugging algorithms that are rarely if ever used -= =20 > could be better spent on getting more usability? The biggest "usability" problem we likely have nowadays in crypto is that people would need to understand what they do and mutually authenticate each other. Apart from that we have quite nice UIs at all levels, don't we? gnupg is actually quite nice for people who want to use command line, we have fine tools like enigmail. I somehow have the feeling, that for many people "usability" means not noticing crypto at all, but I guess that just won't work. > That argument didn't work. Basically when ever a problem was found, it= =20 > couldn't be solved by an algorithm switch, 9 times out of 10. The one= =20 > time that a problem was found, it was solved by ... a switch *backwards*= =20 > to RC4. Not exactly a happy result. So problems in the alogs themselves don't count for you? I.e. we could still use MD5 since problems in it aren't solved by e.g. SHA2? Or we should still use DES, since an algorithm switch couldn't solve it's problems? > >> A3. Do not specify things which are infeasible to thoroughly test. > >> This implies avoiding combinatorial complexity, which the OpenPGPv4 > >> spec doesn't. > > As above, I doubt you can really check every combination, and I wouldn'= t > > want to sacrifice too much, just for being able to do so - especially > > not diversity of algorithms. > When has diversity of algorithms ever bought user advantage? Nothing in that his screen becomes more colourful or that his "experience" would be more like 4K than just HD. *If* someone does crypto, than probably because he wants to be secure. So if diversity enhances security or at least allows one to switch more easily in case it gets necessary (which of course you disputed above), then it benefits the user by helping with his original goal (being secure). > I can think of (been told) one case: the "Russians GOST" requirements.= =20 > Frankly, I'm not that keen to let them do that. If *every* government= =20 > did it, then we'd be in a pickle, and we'd not be talking to any of them= =20 > at all. So why do we care about the Russians? Agreed. But hopefully the whole crypto standardisation would go anyway rather into community hands now. > > Disagreeing with the "We only need two hash functions at most.". > > > > Diversity is good (of course we should only include secure algos), > > especially when one expects that each algo sooner or later sees > > weaknesses. > Well, sure, on paper. But if you had a process to switch then you could= =20 > also ... use that process to switch! Why not just roll out v+1 ? How long does it usually take us to roll out v+1? Take SSL/TLS, how many years have SSL still been used while it should have not? The same for MD5, the same for RC4, and so on. Cheers, Chris. --=-sx0+1bna6HYIpDP0bExI Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyMzE5NTk0 OFowTwYJKoZIhvcNAQkEMUIEQNqpGbKmWTnx7iCMf9aURQD3Rmrc5ppTeMGBA/ZHhmWdX5sFrbUR XJEe6tz2obde/84bKJ0RyA5NVrwI/LR8k6IwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDCZftsh38p9Rh/pze3d7u1Ae0mhtk/ 6c1lK5wVsWcClrzQ0FQFBhON/RBI18uqeTq3UYrcfU4TqS3hBRb7Biui8/rf9I17uVNGHEJz4br8 oRkvMqVFrzJ8PCzIi/5e1ywwsgtZOK10163+WimWultwwgxfUvHe0vW7rE2f8jm+klUJgqdROFnJ WUK8Z2scRN3uLO2tZ+rkj9+gU7tMAdL2T0rhckQTA4SKqIEB3qtQcYbqPpsdjeX2MGYzPm27cMCE CqUUgYqxFBOXiNH3WqTKu6rgS5HBKC9n3x+LwjftyJ23tqsElbbj7eQZ95R7RkKDcS3o37lzaFf6 mwA25GmzAAAAAAAA --=-sx0+1bna6HYIpDP0bExI-- From nobody Mon Mar 23 13:03:29 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 7A5901A049A for ; Mon, 23 Mar 2015 13:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6] 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 ga-eWfdRYC3U for ; Mon, 23 Mar 2015 13:03:27 -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 EF46A1A036F for ; Mon, 23 Mar 2015 13:03:26 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id DBBE96D734; Mon, 23 Mar 2015 16:03:25 -0400 (EDT) Message-ID: <5510718C.50704@iang.org> Date: Mon, 23 Mar 2015 20:03:24 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 23 Mar 2015 20:03:28 -0000 On 17/03/2015 12:53 pm, Wyllys Ingersoll wrote: > > > On Tue, Mar 17, 2015 at 3:03 AM Tim Bray > wrote: > > I have repeatedly found it useful, even in recent times, to > cut/paste ASCII-armored messages on my mobile. Am I a Neanderthal? > > > No! This was exactly my first thought also. ASCII Armor format is > extremely useful for passing the messages from app-to-app via the system > clipboard using copy-and-paste. As a mobile PGP developer, there are > situations where this is the most convenient way to move the PGP > message/key from a non-PGP enabled app (like most standard mobile mail > clients) and into an app that can decode/decrypt it correctly. > > If ASCII Armor is to be deprecated, I would hope that we at least > replace it with something else that can be easily copied-and-pasted. Ascii armour is also very useful for plaintext keys, which make an appearance in contracts that distribute their own PKI. Which also get signed inline with an ascii-armoured signature. Also very useful. Now, these things don't get cut&pasted much, if at all, although to be fair that was an expectation when I designed them. But they do get printed out; the contracts have been in court (twice to my knowledge) and their ability to be printed out and looked at by judges has been critical to their acceptance as contracts. In short my 'requirement' would be printable keys and sigs. I don't so much care if it is 'ascii-armoured' in the current form or not, but ... something would be nice. iang (For those unsure what I'm talking about, there is a form of legal contract called the Ricardian Contract which I wrote about here a long long time ago: http://iang.org/papers/ricardian_contract.html This is now having a bit of a renaissance in Bitcoin / crypto-currency scenes as various businesses are discovering they want to couple legal prose into transactions and blockchains and whathaveyou. End of obligatory plug.) From nobody Mon Mar 23 13:14:48 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 116921B29BC for ; Mon, 23 Mar 2015 13:14:46 -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 AyxjOqsQ2oqe for ; Mon, 23 Mar 2015 13:14:45 -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 AE8931ACEF6 for ; Mon, 23 Mar 2015 13:14:44 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 68A506D770; Mon, 23 Mar 2015 16:14:43 -0400 (EDT) Message-ID: <55107432.10007@iang.org> Date: Mon, 23 Mar 2015 20:14:42 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFB984B@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] "OpenPGP Simple" 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, 23 Mar 2015 20:14:46 -0000 On 22/03/2015 14:56 pm, Phillip Hallam-Baker wrote: > People keep telling me that canonicalization is necessary for > security. In 25 years I have never once heard someone give a use case > where it did. It was *very* important when people were cut& pasting pgp-signed emails around (and the contracts I eluded to earlier) but this all disappeared when more sophisticated techniques turned up which included MIME and also PGP encryption itself. The last time I had a canonicalisation nightmare was in about 1997, sitting in a tent hand-crufting bits of a PGP book back together. With a bunch of Americans giggling in the background to accentuate our pain. That amusing memory aside, I think yes, canonicalisation has kind of shifted down in priorities and would be a contender for occam's razor. > Of course, the real author of ASN.1 becomes clear when you know it is > his name backwards. lol... "the one" iang From nobody Mon Mar 23 13:23:32 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 F41D21A03D5 for ; Mon, 23 Mar 2015 13:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9XwqxmxKz2a for ; Mon, 23 Mar 2015 13:23:29 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 38AA91A0404 for ; Mon, 23 Mar 2015 13:23:28 -0700 (PDT) Received: by wibg7 with SMTP id g7so57478962wib.1 for ; Mon, 23 Mar 2015 13:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iJCg5FK/vB1zKGRcqibkDGrvDAkDY3BOUhrvzO7x2b4=; b=Ko3uEhnS7kZ9HFX19+I5AmI8JRYDYpfCUOTzNVdCr7E6AcnZgUat/nZFfu1jD6fYh/ 6CPB0nO9DQgYQikniVT7Qsp0xeNXQw5otqxL8aF3XfZXbvBnvjLdoj4UBQMYGlx3e+6k 4sl8kcG3k6lxm/Vsm1PpZKNrRqJwD5EpIWTUeIBHxv7N81g8jEQi7XYYlJqsE6z3DNZG IQzDqOT8KR9a0ns70QtH+fZoz3xYDELrCAShGJ3HMxSYHif3FpsN6GC7tEIRH6tIty7t Q2DGo6rHavFPwZlNLVzSe4mDIhfcCuQROvy8y/Zd0z2qcDCxoBwVOKaFY5Io39luCmJm rCiA== X-Received: by 10.180.97.106 with SMTP id dz10mr22124185wib.33.1427142206948; Mon, 23 Mar 2015 13:23:26 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:d5f1:a1be:7417:dccd? ([2001:67c:370:176:d5f1:a1be:7417:dccd]) by mx.google.com with ESMTPSA id ge8sm2929736wjc.32.2015.03.23.13.23.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 13:23:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPad Mail (12B440) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB37EF@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 23 Mar 2015 15:23:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <986B81E6-73A0-4DDA-9AB2-EF6DC3D96FC4@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB37EF@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4 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, 23 Mar 2015 20:23:31 -0000 So as with Smime, the message packaging bit is easy to implement, it is the k= ey management bit that is hard. Sent from my iPad > On Mar 16, 2015, at 8:50 PM, Peter Gutmann wro= te: >=20 > Derek Atkins writes: >=20 >> Having implemented it myself, I disagree completely. It is absolutely >> possible to create a modular implementation. See my Usenix Security Talk= on >> the PGP Message Processing Pipeline from.... 1996?? >=20 > PGP message processing isn't hard (apart from the *&*^#&*# partial-lengths= > kludge), I've done the same, I have retargetable code that does either S/M= IME > or PGP depending on which encoding/decoding functions you point to. >=20 > The killer with PGP is keyrings, which are impossible to process in any ki= nd > of nontrivial API (in other words a library) because there's no concept of= > "single blob containing a key + name" as there is for X.509 certs. Instea= d, > you have a mass of packets concatenated together, deeply bound in a spaghe= tti > of implicit cross-references (some of the following packets apply to a > previous packet, and some are signatures that tie other bits together, and= > then there's trust packets that change the semantics or earlier packets, a= nd > so on). >=20 > It's pretty much impossible to create any clean API to handle this, you ne= ed > an interactive app that keeps going back to the user and asking "I've just= > found some X here, what shall I do now?". Similarly, storing these things= in > something like a key/value store for fast lookup is nearly impossible beca= use > you end up having a more or less open-ended number of index fields and cro= ss- > references that need to be maintained. >=20 > If anyone wants to challenge that, please provide in your reply an outline= of: >=20 > - An "add a key API" that takes a newly-received PGP key and adds it to a > keyring, along with a clear description of its semantics. >=20 > - A schema for storing PGP keys in a key/value store. >=20 > (This is to pre-empt a flamefest. If you think it's possible, prove it :-= ). >=20 > Peter. > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Mon Mar 23 18:03:21 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 A895E1B2ADE for ; Mon, 23 Mar 2015 18:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, LOTS_OF_MONEY=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 1wgviksBnHvw for ; Mon, 23 Mar 2015 18:03:17 -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 699511B2AE4 for ; Mon, 23 Mar 2015 18:03:14 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id C265A6D765; Mon, 23 Mar 2015 21:03:12 -0400 (EDT) Message-ID: <5510B7CF.8060308@iang.org> Date: Tue, 24 Mar 2015 01:03:11 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> In-Reply-To: <1427140788.10191.75.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] New encryption formats for messaging 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, 24 Mar 2015 01:03:20 -0000 On 23/03/2015 19:59 pm, Christoph Anton Mitterer wrote: > On Mon, 2015-03-23 at 18:12 +0000, ianG wrote: >> On 18/03/2015 23:38 pm, Christoph Anton Mitterer wrote: >>> Looking at the context you come from (Yahoo) I must note, that the big >>> players seem to have discovered security recently ... o.O >> Hmmm... so our technique is to punish people for wanting to improve. >> Grand... > Where did I "punish" someone and/or where is my observation wrong? Yahoo and google are at the forefront of secure email delivery. They are trying something nobody else has got anywhere near - so I don't see how they can be called laggards. (Assuming that is we debunk the joke of security known as S/MIME... which was deployed but was crippled by committee-design.) >> New to some, but it has a long history: Kerckhoffs' 6th principle: >> >> "6. Finally, it is necessary, given the circumstances that command its >> application, that the system be easy to use, requiring neither mental >> strain nor the knowledge of a long series of rules to observe." >> >> Writing about cryptography communications systems in 1883. >> >> http://www.financialcryptography.com/mt/archives/000195.html > > >> I think this is simply wrong. This is no principle. TOFU has proved >> itself. > Then we can probably abolish fingerprints verification in the next > versions of OpenPGP implementations altogether,... if TOFU works, why > should anyone bother to check their keys o.O The essence of TOFU is that it works in default mode, and gives you tools to do better if you so desire. Now, of course, the concept works so well that one never bothers to check for the most part, so fingerprint verification could be dropped and would still provide more security than not using it. Which is the goal. So what you suggest is not incompatible with the goal. But the PGP community came from a different age, so they do often check. Add, they have turned it into a ceremony, one that binds the community at least for the time of the 'party'. So I doubt we'll get rid of it just because it's only adding one more 9 to the 99.909% good enough. >> If you don't want to use it, that's fine, but the notion that >> it's "not secure" is simply rubbish because security is a relative risks >> thing, not an absolute thing, and it is extremely unlikely > I kinda amused every time security based on such assumptions. What other basis is there for security other than risk? > Some 5 years ago, the masses still thought that they're not victims of > mass surveillance and that their emails and data would be safe. Yup, and the vendors figured that the masses aren't important enough to provide security. Go figure. As you point out, Yahoo is late to the game. But Mozilla and Microsoft have always been emotionally contorted over it, and google has only recently started being serious, before there mantra was "all your data base belong to us'. The only player that was ever serious about *the user* was Apple. And they *all* promote the security-barrier called PKI/x.509, which delivers to compliance customers, and distracts from overall security by selling a tired old cold war military model as something to protect banks from phishing. Go figure. > Nowadays people think that TOFU would provide high security and that NSA > and friends would never dare to abuse that... Bring it on. The point of improving security is to get from here to there, and actually improve the result. Those who push the old 'perfect security models' mantra typically end up with an extremely narrow set of compliance customers, or nothing. E.g., SSL. Here in the PGP community we are *not interested in compliance* so much as actual ordinary users. (Which isn't to say we don't come into connection with the compliance world; we do because business models force us there from time to time. But hearts and minds here are about real security delivered, not paper calculations.) >> Empirically, I just today got my first 419 hit on Skype, which was set >> up to let others see my name - their mistake on default install. After >> about a decade of usage? > Well, NSA and friends probably don't bother to attack systems like Skype > on the crypto level, one can be quite sure that they have other means > for these =) Well, we know they now have direct access. No need to speculate. But the fact remains: Skype has other than yesterday never directly harmed me. Can't say the same for email, browsing, ... >> Even including the notion that Microsoft now copies it all to the NSA, >> that's still only 4 parties with capability to connect to me: Me, my >> friends, Microsoft and NSA. > uhm... great? o.O So, what's my risk? Microsoft (yawn). NSA could get narked at my repeated jabs at their Stasi behaviour, and stop me at the border. Grab my skype records and accuse me of naughty behaviour. OK, I'll take that risk. Meanwhile: I've actually lost non-trivial fortunes because my counterparties turned around and attacked me. I'm bombarded every day with spam. I have to train my family in phishing because the browser vendors don't react or when they react, they PKI-me-harder rather than looking at the information being rendered to my mother. Granted, if I worked at a Belgian ISP or SWIFT or my payments biz took off in a bad-ass way, I'd be terrified of NSA. >>> To be honest, Yahoo, doesn't have the best security record, and in >>> general I wouldn't trust any web-based crypto app regardless of who it >>> wrote. >>> >>> That being said, I agree that it shouldn't be easy to make a well >>> designed crypto system insecure by settings - but not if this means that >>> one takes away valid functionality from the more experienced users. >> >> Why do you prioritise "experienced users" above the lesser experienced? >> Do they pay more money? Is this the Church Of BOFHs? Do they pay >> their dues by helping others? From your writings it seems unlikely... > Actually I don't. I just don't prioritise lesser experienced users over > experienced ones. > What I prioritise is the intention of crypto, which is security. Security is only measured by delivered results. Let's say you improve the lot of the experts by offering them cipher suites to choose from. Hypothetically that improves the 0.1%, those that actually know what those words mean. OK, 1 billion browser users, that would say about 1 million know what a cipher suite is. Exaggerated, but let's see where this goes. Let's say we double their utility. But, putting in vanity ciphers as we used to call them causes complexity. A lot of problems in SSL would sweep away if we cut that crap out. E.g., Heartbleed and somewhere it was claimed $500m costs... So, let's say this all costs 1% for the masses. Result: Security = 1,000,000 * 2 + 1,000,000,000 * 0.99 Guess what? Only the security delivered to the masses matters. Which is why Skype worked and everything else fell in a hole. Simple maths. >>> b) Why should there be only one? >>> I think its a wrong assumption that code will become more secure by >>> supporting less algos/systems. >>> If a project cannot develop/maintain more of them securely it's rather a >>> sign for lack of funding/manpower. >> Ah. So you see that handling more algorithms is a cost for big >> companies to meet and therefore a barrier to entry which makes for less >> choice and eventual balkanisation. What about opportunity cost - time >> spent managing and debugging algorithms that are rarely if ever used - >> could be better spent on getting more usability? > The biggest "usability" problem we likely have nowadays in crypto is > that people would need to understand what they do and mutually > authenticate each other. Well, right. Systems that try and "authenticate" each other are typically usability nightmares. Change the paradigm. > Apart from that we have quite nice UIs at all levels, don't we? > gnupg is actually quite nice for people who want to use command line, we > have fine tools like enigmail. Not for the masses, sorry, not of any interest. > I somehow have the feeling, that for many people "usability" means not > noticing crypto at all, but I guess that just won't work. Skype. (Sad to say, it got rolled before it was sold to Microsoft, and the NSA got their dream entre. Oh well -- like we say, there's no such thing as a complete security model ... there's always a way around.) But in an elegant way, that provded the K6 hypothesis. Skype was so darn successful that the NSA had to 'buy' its way in, breach the company. GSM - killed the serious risk dead, which was the paparazzi listening in to the famous doing sex talk. And nobody noticed! >> That argument didn't work. Basically when ever a problem was found, it >> couldn't be solved by an algorithm switch, 9 times out of 10. The one >> time that a problem was found, it was solved by ... a switch *backwards* >> to RC4. Not exactly a happy result. > So problems in the alogs themselves don't count for you? Of course they count. But, they are pretty much down the bottom of the list. Check it out, do some historical research. If you're worried about a crypt algo breaking, you ain't in the security game, you're in the cryptography game. > I.e. we could > still use MD5 since problems in it aren't solved by e.g. SHA2? MD5 was deprecated in 1995 by SHA0. Then 3 months later SHA0 was deprecated by SHA1. I know, coz we cursed and changed. SHA1 was deprecated in favour of SHA2 sometime early 2000s. If anyone is using MD5 they're negligent. If they're using SHA1, then they'd better be sure it ain't a collision risk (I do and it isn't) and if goes full belly up they still won't be in trouble. > Or we should still use DES, since an algorithm switch couldn't solve > it's problems? to channel Santayana, those who don't study their deprecation history are doomed to have their systems deprecated? >>>> A3. Do not specify things which are infeasible to thoroughly test. >>>> This implies avoiding combinatorial complexity, which the OpenPGPv4 >>>> spec doesn't. >>> As above, I doubt you can really check every combination, and I wouldn't >>> want to sacrifice too much, just for being able to do so - especially >>> not diversity of algorithms. >> When has diversity of algorithms ever bought user advantage? > Nothing in that his screen becomes more colourful or that his > "experience" would be more like 4K than just HD. So, marketing. Getting an upgrade to earn the fee. OK. > *If* someone does crypto, than probably because he wants to be secure. Not really. Vendors choose crypto because of their mastery of the security model (I'm being sarcastic here, anyone who uses SSL has no clue as to the security model) and that fits into the holistic business approach. Very few users - the masses - rush out and say "I wanna six-pack o' crypto and 3 jars of authentication with some random side orders..." It is *myth* perpetuated by the x.509/PKI tribe that "choosing crypto" means "wanting security". This is part of the careful marketing edifice that was used to sell certs to an blase public. Because they didn't want it, some elements were forced into being embarrassed to use it, and the rest is compliance history. Also, it's part of the marketing against self-signed certificates; if users "choose" certificates it is because they "want" security which is not allowed to include MITM possibilities so we have to deny self-signed certs. Or some such sophistry. Sorry 'bout dat! > So if diversity enhances security or at least allows one to switch more > easily in case it gets necessary (which of course you disputed above), > then it benefits the user by helping with his original goal (being > secure). Yeah, sure. Just doesn't work in practice, and doesn't work in theory, if we actually think about how it is supposed to work. >> I can think of (been told) one case: the "Russians GOST" requirements. >> Frankly, I'm not that keen to let them do that. If *every* government >> did it, then we'd be in a pickle, and we'd not be talking to any of them >> at all. So why do we care about the Russians? > Agreed. But hopefully the whole crypto standardisation would go anyway > rather into community hands now. > > >>> Disagreeing with the "We only need two hash functions at most.". >>> >>> Diversity is good (of course we should only include secure algos), >>> especially when one expects that each algo sooner or later sees >>> weaknesses. >> Well, sure, on paper. But if you had a process to switch then you could >> also ... use that process to switch! Why not just roll out v+1 ? > How long does it usually take us to roll out v+1? Take SSL/TLS, how many > years have SSL still been used while it should have not? The same for > MD5, the same for RC4, and so on. I measured a 3.5 years OODA cycle for the first big SSL oops. I haven't been following the others but I have a feeling they've got a lot faster. Point is however, it's still all ad hoc. We don't actually know what we're going to be switching, and pretty much each time it is a download / reinstall. So why not have a v+1 waiting in the wings? Each new generation is substantially better and is far more likely to cover anything uncovered. My point isn't that is what should be done. But that right now we've go no plan. So *anything* would do better than what we had right now. iang From nobody Mon Mar 23 18:31:34 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 8FC051B2B30 for ; Mon, 23 Mar 2015 18:31:33 -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 grdgfD8mCU8x for ; Mon, 23 Mar 2015 18:31:32 -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 D5C801B2B2E for ; Mon, 23 Mar 2015 18:31:31 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 87B006D781; Mon, 23 Mar 2015 21:31:30 -0400 (EDT) Message-ID: <5510BE71.1040000@iang.org> Date: Tue, 24 Mar 2015 01:31:29 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <878uf2iehi.fsf@vigenere.g10code.de> <1426218768.22326.80.camel@scientia.net> In-Reply-To: <1426218768.22326.80.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 24 Mar 2015 01:31:33 -0000 On 13/03/2015 03:52 am, Christoph Anton Mitterer wrote: > Since people start to come up with their wishlists... here'd be mine: > > > 1) More general things > - The WG should consider whether to just bring OpenPGP up to date... or > whether to completely overhaul or even re-design it. Re-design. It's still the late 1980s model, it's way behind current knowledge. No point in overhaul. > In the later case: > - The basic meshed web of trust must obviously be retained, :) I would agree that it should remain firmly oriented towards the p2p channel. > but apart > from that there should IMHO be no taboos, like dropping the old > formats or perhaps even completely changing the format (if some people > would think an XML representation would be better, discussions should > be open for that - not that I'd be an advocate of this). > > - OpenPGP should be made fit or at least extensible enough for any mid- > or long-term developments in engineering and crypto, this might > include things like: > - Since the X.509 PKI infrastructure in the internet is inherently > broken and since DANE would only partially improve things (one still > has several CA's above which could be evil), the time may come in > which at least some security conscious people would want to use TLS > or similar with a fully meshable PKI as OpenPGP. > For that we might need similar things as X.509 got eventually,... > things like SubjectAlternativeNames for IP, DNS, email, etc. > - Any preparations for PQ Crypto? Or for hybrids of PQ and "normal" > crypto? > - For the ultra-paranoid: Semantics that allow usage of multiple > ciphers and hash algos (i.e. encrypt a message with AES first, then > Serpent, then Cesar chiffre ;) ... or make signatures with SHA2 and > SHA3 and require all to be valid. The ultra paranoid can go off and do their own thing anyway. Let them compose their fantasies in their own code, no need to clutter up our own code with "made up algorithms". > 2) More specific things: > - get rid of any SHA1 > - fingerprints should allow to use different hash algos, in order to > keep it easily up to crypto developments Nah - just use Keccak and tie it to the current new version 5. Frankly we've had 2 decades of peace with the SHA 1 -> 2 -> 3 family. Worring about the hashes failing is sooooo overdone. ... > 3) UIDs respectively the data that others actually verify/sign should be > completely overhauled. > Right now we have User ID Packet (13) and User Attribute Packet (17), > with the later having only one actual attribute (the image) defined. > > The UID is by convention a mail address, but even the standard already > says that this is just "by convention", it doesn't even use SHOULD or > RECOMMEND. That's how I like it. And in CAcert we came to the same conclusion - the NAME that is authenticated by the user is a single string, it is up to the humans to add any semantics on what that name is / means. ... > - Everything that really identifies the person behind the key (i.e. puts > trust into the key) should be go into something like the attribute > packet... In CAcert we concluded that there should just be multiple UIDs. No particular semantics like Attribute implied. > - It should be possible to connect these fields with a "valid from" date > and it should be possible to revoke them later in a way that just > means like "data superseded". > E.g. people might merry and their family name changes, they may > divorce and it changes again. Or one grows older and the image > changes. Hmmm... this might be overthinking things. > 4) one of the IMHO most important things: > It should be possible to connect a UID or something similar with > specific subkeys. > > Right now, we have a key with multiple UIDs bound to the key via > selfsigs. If I sign someone else's key or sign some text, regardless of > which subkey I use,... I do this with all my identities, right? > That's quite limiting. Now you're talking about a heirarchy. Typically what people do is create a key "Iang Signing Key" and another "Iang Contract key" signed by the first, and then use the latter only for contract signing. What's useful is to deliver tools that can be composed by the user, less so to get all the composition possibilities into one single structure. just some comments! iang From nobody Mon Mar 23 18:48:35 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 D27781B2B3C for ; Mon, 23 Mar 2015 18:48:33 -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 aJhjrU6u8U67 for ; Mon, 23 Mar 2015 18:48:32 -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 837A91B2B35 for ; Mon, 23 Mar 2015 18:48:32 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 2745D6D744; Mon, 23 Mar 2015 21:48:31 -0400 (EDT) Message-ID: <5510C26E.7070409@iang.org> Date: Tue, 24 Mar 2015 01:48:30 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <878uf2iehi.fsf@vigenere.g10code.de> In-Reply-To: <878uf2iehi.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 24 Mar 2015 01:48:34 -0000 Late comments! On 12/03/2015 12:31 pm, Werner Koch wrote: > Hi, > > Since some time the OpenPGP protocol is again en vogue and the tendency > to prefer S/MIME over OpenPGP is not as strong as it seems to have been > once. Case in point, the DANE WG has a last call for an OpenPGP DNS > record type. This is obviously related to OpenPGP and should have been > discussed here as well (actually we did briefly in Summer 2013). > > There are several tasks the WG should do: > > - New signature subpackets. For example one to specify a fingerprint > and not just the keyid. > > - Take care of individual I-Ds. > > - The use of SHA-1 needs to be replaced. SHA3. > - A v5 key format. Prepare for forthcoming public key algorithms. Completely. > - A new encryption mode to replace our aging CFB+SHA1 method with a > fast and standard mode. Wait for CAESAR, 2017. It'll take that long anyway. > - Maybe extend it to key distribution. > > Is there any interest in this? I'm theoretically interested. But I think it is time to try another paradigm. 4880 took a decade. Too long, the OODA loop was bigger than the evolving knowledge, the work-by-committee approach was broken. Many of us died, emotionally. I'd say: * designate key persons to design the elements. Stick with what they choose. Argue it a bit, but if we can't shift them, then go with it. * Less. Algs, hashes, formats, protocols, bit saving, etc. * More. We need to look up into the stack of apps and see what is needed. Those apps didn't exist when PGP was designed. We are in a new world now. No point in designing for command line. * Trust model. It's got to be completely overhauled. Not so much as to change the internals, but to make sure that future uses can be composed with the new design. * Vendors. Ain't nothing gonna happen unless you get them on side. By them, I mean the big ones. * project planning. Let's not treat this as a committee, let's set up some coding projects to actually move the game forward. Like, a C team, a Java team, PHP, what else? Mandate: to track the draft, compat, and push for more speed from the designers. > How can we get the WG out of the concluded state? As long as they don't turn off the list, do we care? ;-) > Would the Dallas meeting be a starting point for this? > Who would volunteer as Chair? Hell's bells, no, can't afford it. iang From nobody Mon Mar 23 20:36: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 DAF1A1B2C3A for ; Mon, 23 Mar 2015 20:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_32=0.6, LOTS_OF_MONEY=0.001, 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 PNsgFa6AGVVG for ; Mon, 23 Mar 2015 20:36:35 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2B91B2C3B for ; Mon, 23 Mar 2015 20:36:35 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 503275FAD5 for ; Tue, 24 Mar 2015 03:36:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id L6UQfoPbuopi for ; Tue, 24 Mar 2015 03:36:32 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Tue, 24 Mar 2015 03:36:31 +0000 (UTC) Message-ID: <1427168189.10191.241.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 24 Mar 2015 04:36:29 +0100 In-Reply-To: <5510B7CF.8060308@iang.org> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-ouwzDEFTB8bHUZ12xhSN" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] New encryption formats for messaging 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, 24 Mar 2015 03:36:43 -0000 --=-ouwzDEFTB8bHUZ12xhSN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-24 at 01:03 +0000, ianG wrote:=20 > Yahoo and google are at the forefront of secure email delivery. They=20 > are trying something nobody else has got anywhere near - so I don't see= =20 > how they can be called laggards. Uhm? Forefront? All these technologies were implemented long before by others... I remember that not so long ago Yahoo was even criticised every now and then since they didn't even offer https to their webmail. And what can they do better/more than what we already do? If they implement e2e crypto within their webinterfaces, one cannot really trust it - not because they're evil per se, but because *if* some bored NSA agent sends them a national security letter they'll have to comply, and when there's a gag order they couldn't even tell. If they "secure" the TOFU step it's the same,... > the joke of security known as S/MIME...=20 I can't say anything against that :D > > Then we can probably abolish fingerprints verification in the next > > versions of OpenPGP implementations altogether,... if TOFU works, why > > should anyone bother to check their keys o.O > The essence of TOFU is that it works in default mode, and gives you=20 > tools to do better if you so desire. And exactly this is also the point where it fails in practise: None of the masses typically do so ever. Worse, since the products/programs are now marketed as being secure, everyone is even convinced that he'd be secure so doing more work (i.e. real mutual authentication), which people were already reluctant to do before, is now totally out of motivation. And even worse, many applications/program actually stop giving you the tools to do better - since nowadays it's enough to say "we do e2e crypto with super-duper-algo XZY". Take the current hype apps like TextSecure, which some campaigners (heise and friends) advertise as the "good" tools (and as "usable" instead of gnupg/PGP): The mutual authentication step is basically completely hidden from the user, much more than it used to be with most OTR implementations where you got at least some dialogue that told you to do something. But even if you know about that, you cannot do proper mutual authentication - well it shows you the keys, but you cannot mark your peers as trusted or not, which makes it useless when you have more than a hand full of them. > Now, of course, the concept works=20 > so well that one never bothers to check for the most part, so=20 > fingerprint verification could be dropped and would still provide more= =20 > security than not using it. Which is the goal. So what you suggest is= =20 > not incompatible with the goal. If at a certain point, everyone would believe in TOFU, what would prevent NSA&Co. from simply MitM every single communication? There'd be not mutual authentication, so they could be Mallory. And technically they're definitely capable, even today. We know they sit at all big internet exchanges, undersea cables, satellites and probably even at the big players (Google, Cogent, and so on) whether they know and are part of this or not. Even if you assume, that *something* would happen, if they're caught by MitM attacking connections, when someone finally actually does the mutual authentication. What do you think would happen? We found already out that they do mass surveillance, hack devices, routers and break into our computers... and did anything happen? > But Mozilla Which distributes clearly untrustworthy CAs (and this is not the only outrageous security issue, when you look at many issues in their BTS). > and Microsoft have always been emotionally contorted=20 > over it, and google has only recently started being serious, before=20 > there mantra was "all your data base belong to us'. The only player=20 > that was ever serious about *the user* was Apple. In the end, all of these would need to comply with their intelligence agencies, and it's no so unlikely that they actually do. Even security companies like RSA were caught. > Those who push the old 'perfect=20 > security models' mantra typically end up with an extremely narrow set of= =20 > compliance customers, or nothing. I wouldn't say "nothing" ... it's simply the set of users who *seriously* care about their security. And yes, the set of e.g. OpenPGP users is probably small,... so what? > But the fact remains: Skype has other than yesterday never directly=20 > harmed me. Neither has me the NSA or the GHCQ, nevertheless I wouldn't want to share my secret world domination plans with them ;) > Can't say the same for email, browsing, ... Well I guess you can't really compare these. Skype is a singly system completely in the hand of one company with only little numbers of users compare to mail or web. Of course it's much easier to "secure" that. > So, what's my risk? Microsoft (yawn). NSA could get narked at my=20 > repeated jabs at their Stasi behaviour, and stop me at the border. Grab= =20 > my skype records and accuse me of naughty behaviour. OK, I'll take that= =20 > risk. If you feel like you want to share your stuff with them it's of course okay,... but others might not want to. > > Actually I don't. I just don't prioritise lesser experienced users over > > experienced ones. > > What I prioritise is the intention of crypto, which is security. > Security is only measured by delivered results. Let's say you improve= =20 > the lot of the experts by offering them cipher suites to choose from.=20 > Hypothetically that improves the 0.1%, those that actually know what=20 > those words mean. OK, 1 billion browser users, that would say about 1= =20 > million know what a cipher suite is. Exaggerated, but let's see where= =20 > this goes. >=20 > Let's say we double their utility. >=20 > But, putting in vanity ciphers as we used to call them causes=20 > complexity. A lot of problems in SSL would sweep away if we cut that=20 > crap out. E.g., Heartbleed and somewhere it was claimed $500m costs...= =20 > So, let's say this all costs 1% for the masses. >=20 > Result: >=20 > Security =3D 1,000,000 * 2 + 1,000,000,000 * 0.99 >=20 > Guess what? Only the security delivered to the masses matters. That's IMHO quite some weird argumentation... - First it again prioritises one group over other, i.e. the minority of people who could be really secure don't count - just the masses who anyway reach just a certain security level. - With the same argumentation you could also drop OpenPGP,... in practise X.509 is enough for the masses. Yes I know it's broken, and yes fraud happens, but not to an extent that it would really bother anyone (neither from the point of loosing confidentiality or authenticity, nor from financial reasons). Or do you see the masses demonstrating against X.509? Do you see many people from big banks sitting around in our IETF WGs demanding for security systems for their online banking? No. - Actually even more, you could completely drop ALL encryption (not to confuse with authenticity/integrity protection). As you said yourself, the NSA probably never did anything very evil to the masses that they really effectively noticed (i.e. they didn't rob our bank accounts, or stole our private pictures). The same for online criminals,... integrity protection/authenticity would be largely enough do to secure shopping and online banking. What else could they do the masses? Okay stealing all private kinds of data, nude pictures transferred to the cloud or the secret diary. But if one sends such stuff to the iCloud,... well *owned*. - Or you could project this to other areas,... take Linux/Unix/OpenSource. The masses were just happy with there Windoze boxes. Thus, by your argumentation, experts/others don't count, thus they have to use proprietary cr** as well. This analogously works for the typical argumentation of opposing people which typically say "it's useless to secure XZY, because there's still the weaker element ABC of the chain". Well there always is a weaker element in the chain, if you focus on that you could never secure anything else. Long story short: I don't think that OpenPGP was ever the system of the masses, and perhaps it even shouldn't be. It's mostly used in areas and by people where TOFU isn't enough, or at least I wouldn't want to get my signed Debian packages just by good luck authentic. All this doesn't mean that one should intentionally try to lock out the masses by making things overly complex. It just means - we shouldn't weaken the security/functionality of those who can actually use it, just for another group of people wo even doesn't care so much - we shouldn't give people the wrong impression that security is for free, just by activating the "i-want-to-be-secure" switch. > Which is why Skype worked and everything else fell in a hole. Simple mat= hs. I don't think this WG's or standard's intent should be to strive for the highest popularity, market share or for making big money. This is the path e.g. Mozilla chose at a certain point and that's why the nowadays sell the interests/security/freedom of their users by making all kinds of questionable choices. OpenPGP already has a user base who likes its current philosophy. If we can improve things so that we get more users, great, but not at the expense of the current user base. > > The biggest "usability" problem we likely have nowadays in crypto is > > that people would need to understand what they do and mutually > > authenticate each other. > Well, right. Systems that try and "authenticate" each other are=20 > typically usability nightmares. I don't even think there's a usability problem from the software side. The point is simply: people don't want to do the verification step, regardless of how nicely the software assists that process. > Change the paradigm. Well, if you have a crypto system which is secure and doesn't need mutual authentication or some exchange of data on a secure path... just tell us. Apart from that, if you change the paradigm you rather end up at something like X.509 where the responsibility for the trust is delegated to some other party (which usually gives a sh** about that). > > Apart from that we have quite nice UIs at all levels, don't we? > > gnupg is actually quite nice for people who want to use command line, w= e > > have fine tools like enigmail. > Not for the masses, sorry, not of any interest. Just speak for yourself... =3D) > MD5 was deprecated in 1995 and is still used even in security critical fields... > If they're using SHA1, then=20 > they'd better be sure it ain't a collision risk (I do and it isn't) and= =20 > if goes full belly up they still won't be in trouble. git > Very few users - the masses - rush out and say "I wanna six-pack o'=20 > crypto and 3 jars of authentication with some random side orders..." But why then prioritising those who don't even care?=20 > > So if diversity enhances security or at least allows one to switch more > > easily in case it gets necessary (which of course you disputed above), > > then it benefits the user by helping with his original goal (being > > secure). > Yeah, sure. Just doesn't work in practice, and doesn't work in theory,= =20 > if we actually think about how it is supposed to work. Any proofs for this claims? We have e.g. OpenPGP which uses multiple algos and that works quite well. > >> Well, sure, on paper. But if you had a process to switch then you cou= ld > >> also ... use that process to switch! Why not just roll out v+1 ? > > How long does it usually take us to roll out v+1? Take SSL/TLS, how man= y > > years have SSL still been used while it should have not? The same for > > MD5, the same for RC4, and so on. > I measured a 3.5 years OODA cycle for the first big SSL oops. I haven't= =20 > been following the others but I have a feeling they've got a lot faster. You think? I kinda remember that when the first papers came out about the CBC issues or the compression oracles, the responsible engineers said this was just theoretical. Then we saw BEAST. Or we had CRIME, and after it was fixed for SPDY, not really much happened immediately (even though the authors already warned that this would also work in general)... and... surprise... BREACH. > Point is however, it's still all ad hoc. We don't actually know what=20 > we're going to be switching, and pretty much each time it is a download= =20 > / reinstall. Well the download/reinstall is the least of the problems. It's rather the standardisation/development. And if we follow the original paradigm that was claimed here, and around which all our discussion is motivated, and implement just single security paradigms/alogs, it won't for sure get easier to exchange something once necessary. Cheers, Chris. --=-ouwzDEFTB8bHUZ12xhSN Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNDAzMzYy OVowTwYJKoZIhvcNAQkEMUIEQIXLyO4t7+moyV3n4FxdUHxM3iRhvT/h/eQn6SfOK5eoq8O21MtC Tmdf2NBxVgK9i4TKOqeJIXD1BwHvKyIid6AwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAQjQrQPRDgC/1nWrE4LHCUynykNl1u gyOkLRchfqX5z1wcHQsLBhQCdld7PxVjxtxjCOIalOnN+W1enGMjx/6GR0/JMNWzxnKztQtOyxIB 3O1eZBD9q8cFwAi967JdCjvlh8tIcRblwkRWQLAQ1/+GeTZzc6JNT13nnTBmv4Txy+qcEGXZm/bv 7JXvh7omHgkJz9ILPIRk+BC1HRuSmAbLamC3vSQ5RhkW7+i0IT4MAjzzz6bm6AN6fjchqtauZ/54 rz8gZt+rzU5HlxyZXW0ugW/tTTaP/Qn4kCRK570AzkhbFRqLOlxBv0BjjsQrwDJzR1DSkWqGOJkF psnLgYnRAAAAAAAA --=-ouwzDEFTB8bHUZ12xhSN-- From nobody Mon Mar 23 20:46:27 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 E46F11B2C49 for ; Mon, 23 Mar 2015 20:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uFYj_28dR9lx for ; Mon, 23 Mar 2015 20:46:25 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A5E1B2C42 for ; Mon, 23 Mar 2015 20:46:25 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id EABA45FBB3 for ; Tue, 24 Mar 2015 03:46:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id 85Sk0zeN1gz4 for ; Tue, 24 Mar 2015 03:46:22 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Tue, 24 Mar 2015 03:46:21 +0000 (UTC) Message-ID: <1427168779.10191.249.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 24 Mar 2015 04:46:19 +0100 In-Reply-To: <5510C26E.7070409@iang.org> References: <878uf2iehi.fsf@vigenere.g10code.de> <5510C26E.7070409@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-fxWPUGASUI+p6VIwuiNN" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 24 Mar 2015 03:46:27 -0000 --=-fxWPUGASUI+p6VIwuiNN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-24 at 01:48 +0000, ianG wrote:=20 > > - The use of SHA-1 needs to be replaced. > SHA3. +1 > * designate key persons to design the elements. Stick with what they= =20 > choose. Argue it a bit, but if we can't shift them, then go with it. Isn't that the NIST model which kinda blew up? Any process should be open, fully transparent and even though it's likely that there will be a number of key people doing a big deal of work, those shouldn't be designated and any others be more or less locked out. > * Less. Algs, hashes, formats, protocols, bit saving, etc. Well I guess my opinion on that is clear :) > * More. We need to look up into the stack of apps and see what is=20 > needed. Those apps didn't exist when PGP was designed. We are in a new= =20 > world now. No point in designing for command line. +1, at least as long as we don't prioritise one use case over the other and we still have many people/fields where the perfectly mutually authenticated integrity/encryption is desired. > * Vendors. Ain't nothing gonna happen unless you get them on side.= =20 > By them, I mean the big ones. I'd rather consider that problematic. Typically the main interest of any company is not necessarily the general good but rather making money. And we know of far to many cases in the past were companies or other big players (e.g. standardisation bodies) intentionally weakened crypto systems. Just take the whole GSM development and weak keys... even though this was motivated by the government agencies, the vendors all knew what they were agreeing to. > * project planning. Let's not treat this as a committee, let's set= =20 > up some coding projects to actually move the game forward. Like, a C=20 > team, a Java team, PHP, what else? Mandate: to track the draft,=20 > compat, and push for more speed from the designers. Sounds compelling, especially when looking at the back and forth that the CFRG saw recently ;) But not at the expense of flexibility, and the things should be finished when it's finished - not when the date is due.=20 Cheers, Chris. --=-fxWPUGASUI+p6VIwuiNN Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNDAzNDYx OVowTwYJKoZIhvcNAQkEMUIEQJ1fLtGPaAcaVqD7RuWci9hshYJLgcu7T86hc9r4a6pD7CcP9hqg OvIEhQZ8Mo7E5UZvZU9EgKf8c9MVujbgPmYwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDG1k5Ejeyrc6WdD2R0CWZnKSXN+yU9 AW03AmtReTv/DWpeqfpjU5oFBcRig/GIzOR123XnZ0fQ9u96AfntOQ3wxfzxteO+Qa3QllYhWXkG kRg2tf1X01DDb381DxvliQ5rrjnixa+i7wpF/02tUAse+a5FYvDu/WoUEUqnn88N4MXn2wlLQWEw K7TIBO+E6uNU/TdPRCQpXYT/xWydA6ZPO9NIekz4NgHb3uzIFQFFRWnIsOmDOePqmm8w7hluQrNs j9/bEHIXHjBtRceOzCtTxrB5KK2BWpFRdUiIsVLeaeb/E4eIm2KFV3QRasWvDLo7Ch5vLaYwhds+ F3psE5UAAAAAAAAA --=-fxWPUGASUI+p6VIwuiNN-- From nobody Tue Mar 24 00:51:29 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 309A71B2CCB for ; Tue, 24 Mar 2015 00:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 RDQKoMJb3sXM for ; Tue, 24 Mar 2015 00:51:26 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C4D1B2CC8 for ; Tue, 24 Mar 2015 00:51:26 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YaJcS-0007mJ-EJ for ; Tue, 24 Mar 2015 08:51:24 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YaJYl-0004Z7-Ld; Tue, 24 Mar 2015 08:47:35 +0100 From: Werner Koch To: ianG References: <878uf2iehi.fsf@vigenere.g10code.de> <5510C26E.7070409@iang.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 Date: Tue, 24 Mar 2015 08:47:35 +0100 In-Reply-To: <5510C26E.7070409@iang.org> (iang@iang.org's message of "Tue, 24 Mar 2015 01:48:30 +0000") Message-ID: <87mw32omzs.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] How to re-launch the OpenPGP WG 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, 24 Mar 2015 07:51:28 -0000 On Tue, 24 Mar 2015 02:48, iang@iang.org said: >> - The use of SHA-1 needs to be replaced. > > SHA3. That was the original plan. However it turned out that the still not finalized SHA-3 is meanwhile considered a fallback option in case of new developments. SHA-2 has wide support and is already in wide use. We only need a new fingerprint style and use that for some designated revokers etc. >> - A new encryption mode to replace our aging CFB+SHA1 method with a >> fast and standard mode. > > > Wait for CAESAR, 2017. It'll take that long anyway. I am more thinking of OCB; there is a free patent grant for all relevant parties and the patent will anyway expire by the time a new encryption format will get in widespread use. > 4880 took a decade. Too long, the OODA loop was bigger than the Nope. 4880 is a minor update of 2440 which barely took a year to be released with code ready 6 months earlier. The major new features in 4880 have been enabled since fall 2000 (MDC packets) >> How can we get the WG out of the concluded state? > > As long as they don't turn off the list, do we care? ;-) May I read this and your other remarks that you see no more value in the IETF process? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Mar 24 01:36:30 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 B5B5C1B2D3C for ; Tue, 24 Mar 2015 01:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-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 O0xQS3rGlzr5 for ; Tue, 24 Mar 2015 01:36:27 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3251B2D54 for ; Tue, 24 Mar 2015 01:36:26 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YaKK0-000851-IW for ; Tue, 24 Mar 2015 09:36:24 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YaKGv-0004h4-5a; Tue, 24 Mar 2015 09:33:13 +0100 From: Werner Koch To: Albrecht =?utf-8?Q?Dre=C3=9F?= References: 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: Albrecht =?utf-8?Q?Dre=C3=9F?= , Daniel Kahn Gillmor , gnupg-devel@gnupg.org, IETF OpenPGP Date: Tue, 24 Mar 2015 09:33:12 +0100 In-Reply-To: ("Albrecht =?utf-8?Q?Dre=C3=9F=22's?= message of "Sun, 22 Mar 2015 17:56:42 +0100") Message-ID: <87384uokvr.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: gnupg-devel@gnupg.org, IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Encrypting / Signing the mail subject? 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, 24 Mar 2015 08:36:28 -0000 On Sun, 22 Mar 2015 17:56, albrecht.dress@arcor.de said: > X-Protected-Headers: protected message headers, see > Do you want to write a short text explaining this so we can setup a page https://gnupg.org/faq/protected-headers.html ? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Mar 24 05:25:54 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 BF90F1A88C4 for ; Tue, 24 Mar 2015 05:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 VvYErFCFybKV for ; Tue, 24 Mar 2015 05:25:52 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::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 AAE9A1A8834 for ; Tue, 24 Mar 2015 05:25:52 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so64733770igb.1 for ; Tue, 24 Mar 2015 05:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=HaAtxHLKEwQ69Wz57hMWvDJHVLB8dnNQsRVfrSK8M4M=; b=Q3oGJGvPDaMFLJ2lm2sMo1oKu+j6+XfB8OJ2HYaurAcUEKD1CZPRHoe9hP2KMbnSUj MxdhXlf4qfF5n4A4cQzzAEikFFpBPFwfLJo+m7efZl2FuuDB3MCxgYoZLen5rriJlexh qXcEXbIxTwc0GSKERe28yVKt3QNYlK1zDsH0w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=HaAtxHLKEwQ69Wz57hMWvDJHVLB8dnNQsRVfrSK8M4M=; b=dJyD/Bo8osrYIsK9DF+cIlkTxVLenoPvOWyK6CmgFdNevd1xTlsLjSMxAmSMBnfbn6 UBIjCBREEqIe03PoX23qzt1KkIg0VEPiZZpR/SJ2gkRw1biAHkjEkP96N/QgNpArmWB7 +IxPKk88x81kjjN2/udihd87XQoiiMkdICPIgM3T0dGBL1aGZPdPRTWUMPomIwvFyoSQ OFmjkQUy2aIlRrE/Zk4kgAL33VkjLJ1XbgHTIgtWV4W2c990R9I90E7w72HSPxOaz61x EkXvQxjnf3HBeDgnLAz87PVl3ZV++6N5i32iyIgtxf4C1V2HC2rPchX4DtjUuLG9bMd0 7RfA== X-Gm-Message-State: ALoCoQlaLP5Pa8TwWxFwhrA6oxbxdkM4XcDl4ekJZdj09nmP+aVd83O/sNU1TBRZwRaha0sO5yns X-Received: by 10.42.94.65 with SMTP id a1mr24763012icn.1.1427199952134; Tue, 24 Mar 2015 05:25:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.166.84 with HTTP; Tue, 24 Mar 2015 05:25:31 -0700 (PDT) From: Tom Ritter Date: Tue, 24 Mar 2015 07:25:31 -0500 Message-ID: To: openpgp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [openpgp] On Streaming and Chunking 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, 24 Mar 2015 12:25:53 -0000 Adam's post on streaming API's has been posted before: https://www.imperialviolet.org/2014/06/27/streamingencryption.html The same problem is the root cause of the Java GCM CipherInputStream issue: http://blog.philippheckel.com/2014/03/01/cipherinputstream-for-aead-modes-is-broken-in-jdk7-gcm/ But I haven't seen any discussion of Adam's point that one _can_ construct a format for chunking and authenticating the chunks (and ordering thereof) to provide authenticated streaming. And that someone has already done so: https://github.com/kaepora/miniLock#4-file-encryption I think support for a mode like this would be good to consider, and I think if IPR allows it, a fully-specified design for it is a good place to start. -tom From nobody Tue Mar 24 09:47:11 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 E3A421A6F3F for ; Tue, 24 Mar 2015 09:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaAykTcE7KV6 for ; Tue, 24 Mar 2015 09:46:59 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (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 C3B561A8AF7 for ; Tue, 24 Mar 2015 09:46:58 -0700 (PDT) Received: by wetk59 with SMTP id k59so168226528wet.3 for ; Tue, 24 Mar 2015 09:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=9mc87HgTWMyCTEayQhgTUcNplWuQmu/iDukxwKBJNBo=; b=y28RiyTvqEoxDf3FkafA+7J38PTod/Xlu0gA1frymtaajA8IWzGV3y7KQj1pEw7W13 Vfw3cBFl9+t+ZXYDTQoEII+9Q4932zvY0mhjDSFtjJuINeQiMW/yiwAuwoTW4jDYUCwx AKs1o1IvQr6CllwycqhssFSh/V9dERer9QKkO6IFMMazPMzef8a4tDsAzVrWyfve1onD s9/nN795oPa/NlSF8aYvZDcg2o23s2CpL4TcnIfKyaENd3trD/vIlJmF1+xYiwdvrxnm RpeNR6Zs70upLTsXBP6HVXyR1Ixs+KSdjwb3JDD9CBotdeDodj9rk0r+XyIHYrQJWZrU 5hSg== X-Received: by 10.194.9.98 with SMTP id y2mr9714102wja.85.1427215617609; Tue, 24 Mar 2015 09:46:57 -0700 (PDT) Received: from [31.133.138.236] ([31.133.138.236]) by mx.google.com with ESMTPSA id hi6sm6826147wjc.34.2015.03.24.09.46.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 09:46:56 -0700 (PDT) From: Phillip Hallam-Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <644FDE72-CB1A-4EBE-9309-B429860A360D@gmail.com> Date: Tue, 24 Mar 2015 11:46:55 -0500 To: openpgp@ietf.org X-Mailer: iPad Mail (12B440) Archived-At: Subject: [openpgp] Hybrid proposal for algorithm identifiers 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, 24 Mar 2015 16:47:05 -0000 * Maintaining algorithm registries takes time and effort * Modern best practice for algorithms rejects the idea that more algorithms i= s 'better'.=20 * The security of the system is determined by the weakest algorithm an att= acker can persuade you to use, * One Mandatory to implement plus a reserve is generally emerging as best * Support for vanity crypto is an unfortunate necessity. * ASN.1 OIDs are kind of obnoxious * Suites don't work * Most OpenPGP folk would like to use short identifiers For many years I have wanted a way to move discussion of vanity crypto out o= f the IETF, etc. If we touch a spec, the vendor can pretend that we endorse i= t. So what I propose is a two level scheme: Mandatory and Recommended algorithms are registered in a short identifier re= gistry.=20 For everything else there is a reserved 'escape code' that states the algori= thm is specified by OID.=20 OIDs do get a little large sometimes. But they do have the advantage that no= body can claim that they have IETF endorsement. That is not true of any sche= me we could devise ourselves.=20 This approach means that there is a real difference between being one of the= supported algorithms and the recommended algorithm.= From nobody Tue Mar 24 12:15: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 1DC2B1A8AB7 for ; Tue, 24 Mar 2015 12:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 yAeOv3JrFsi5 for ; Tue, 24 Mar 2015 12:15:34 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 4830C1A8A72 for ; Tue, 24 Mar 2015 12:15:34 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 6758C26C0001; Tue, 24 Mar 2015 19:15:33 +0000 (UTC) Date: Tue, 24 Mar 2015 14:15:33 -0500 From: Stephen Paul Weber To: Derek Atkins Message-ID: <20150324191533.GI20518@singpolyma-liberty> References: <9A043F3CF02CD34C8E74AC1594475C73AAFB3811@uxcn10-5.UoA.auckland.ac.nz> <20150317151510.GD2983@singpolyma-liberty> <20150317154832.GF2983@singpolyma-liberty> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Wyllys Ingersoll , openpgp@ietf.org, Tim Bray , Peter Gutmann Subject: Re: [openpgp] "OpenPGP Simple" 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, 24 Mar 2015 19:15:36 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >> I mean, not that I find the spec that complex, but the webby people I >> deal with seem to. > >Have you tried to have them read the CMS/PKIX set of specs?? And they >still think that 4880 is too complex?? They wouldn't even touch those. They just invent their own crypto system= =20 and go "poof, see, easier!" I'm not supporting their decisions at all, just relaying them. Again, see= =20 Salmon/MagicSig for one such example. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVEbfUAAoJENEcKRHOUZzeVrcP/0MiI38LC0zDlSQCbXCre4f1 o+jXBJevGVQCUsS9bpJKUb+txbIlstwF4SF1bNAjYDpP+CxKEsa8E0ayHsevze0i /rhR0j1UWBz6Ld0RKHgyvPN1GVubB2MM1XBGMHI9I0sOpG8TZrEZ+pq4lsxrXKWI VUoIYFc+/8tDw91L8pJwuclVtT3jlWYtMw6CvLbVE80899ToU0zMtcBwr2ZJHHyY gGqG1yiJLpYqcDaYFSZApuknXwMo4WzP5UYYLs7a3EDdTfde/iOdH9Vfo/VcKTCa CmcmcP3gOVN7h/G1Gp2zHqNKF7WzHlvQycVu9mYKRbyevWOnFgDvFFBOvGz3AvLK gxmuoxe3VVH7STnF8lh9qARAx9AfrIDgquedif4G7J38bHchu6v+diGprHcWOgFH 3t5wAEDU2T182Y+dXBTBm9GutI4exF4TLkFQMO+eEAgktiKpCMRqgB7SjAVUNV2S BGPQhPtJafcsiTWZvzo2TOtq5ay8WcCh6/ElOH0f+R5Uads4rmUIFohfxVzNlBkj Dis5Jqk/Om6pycRdOh7qmqezg0aSg6jetZpGYE3JAVrA2CFXUb1cr8j+mHzhfDL4 6wicDqsO303/TPu+FzQKYbBT3NYd3k+TdmjX8Tx1hwItjh6EAi984zArnK7JN+6B N709iR+jld3jQ+Jui2OY =LvXi -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From nobody Tue Mar 24 16:17:48 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 B24B91A1A52 for ; Tue, 24 Mar 2015 16:17:46 -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 ZS2O7FwE-Iic for ; Tue, 24 Mar 2015 16:17:45 -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 409531A000B for ; Tue, 24 Mar 2015 16:17:45 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 975FD6D85A; Tue, 24 Mar 2015 19:17:43 -0400 (EDT) Message-ID: <5511F096.7000404@iang.org> Date: Tue, 24 Mar 2015 23:17:42 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <644FDE72-CB1A-4EBE-9309-B429860A360D@gmail.com> In-Reply-To: <644FDE72-CB1A-4EBE-9309-B429860A360D@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Hybrid proposal for algorithm identifiers 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, 24 Mar 2015 23:17:46 -0000 On 24/03/2015 16:46 pm, Phillip Hallam-Baker wrote: > > * Maintaining algorithm registries takes time and effort > * Modern best practice for algorithms rejects the idea that more algorithms is 'better'. > * The security of the system is determined by the weakest algorithm an attacker can persuade you to use, > * One Mandatory to implement plus a reserve is generally emerging as best I would say One+One is emerging as a centrist compromise. On the left, there are the pluralists, and on the right, there are OneTrueBelievers. Personally, I think the numbers are balanced between the right and the center, with the left (many) now a clear minority party. Or at least, that's what a straw poll showed about 6 months back. > * Support for vanity crypto is an unfortunate necessity. That ... is an argument I'd love to see fleshed out. > * ASN.1 OIDs are kind of obnoxious > * Suites don't work > * Most OpenPGP folk would like to use short identifiers > > For many years I have wanted a way to move discussion of vanity crypto out of the IETF, etc. If we touch a spec, the vendor can pretend that we endorse it. > > So what I propose is a two level scheme: > > Mandatory and Recommended algorithms are registered in a short identifier registry. > > For everything else there is a reserved 'escape code' that states the algorithm is specified by OID. > > > OIDs do get a little large sometimes. But they do have the advantage that nobody can claim that they have IETF endorsement. That is not true of any scheme we could devise ourselves. > > This approach means that there is a real difference between being one of the supported algorithms and the recommended algorithm. Assuming your premises, this is a good proposal. iang From nobody Tue Mar 24 16:51:29 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 9AF7B1A1A65 for ; Tue, 24 Mar 2015 16:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5LZHtittzMoF for ; Tue, 24 Mar 2015 16:51:26 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0CF1A1A55 for ; Tue, 24 Mar 2015 16:51:26 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 591425FC3B for ; Tue, 24 Mar 2015 23:51:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id DNqqOcUeLOWZ for ; Tue, 24 Mar 2015 23:51:22 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Tue, 24 Mar 2015 23:51:22 +0000 (UTC) Message-ID: <1427241081.10191.348.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 25 Mar 2015 00:51:21 +0100 In-Reply-To: <5511F096.7000404@iang.org> References: <644FDE72-CB1A-4EBE-9309-B429860A360D@gmail.com> <5511F096.7000404@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-hk2h2aCv8tWFHYoQSSWO" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Hybrid proposal for algorithm identifiers 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, 24 Mar 2015 23:51:28 -0000 --=-hk2h2aCv8tWFHYoQSSWO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-24 at 23:17 +0000, ianG wrote:=20 > On the left,=20 > there are the pluralists So pluralists are left-wing?! ;-P Seriously, being one of the "pluralists", let me perhaps clarify this a bit: I don't think that the standard should necessarily standardise 20 alogs for each type and make 10 of them mandatory. - It should rather come with a few defined, perhaps at most 3 (per type) mandatory. - It should be easy to extend it and the community should be open enough to at least not put unnecessary obstacles in the way of such extensions. (E.g. I remember that quite often some people would have liked to see Serpent supported - the first thing was always like "do we really want that and would we even support that"). In the end, the implementations should decide which further algos are actually implemented, but even here, being a "pluralist" :D (I kinda like that ^^) I'd rather wish for a culture of accepting things, if a proper implementation is provided and there are not security concerns. E.g. if the Japanese really want their CAMELLIA or the Russians their GOST and if the provide a clean implementation and the algorithms aren't known to be severely flawed, I'd hope that Werner accept these in gnupg. However, whether he enables them per default for outgoing stuff, respectively whether he adds a warning about their use or perhaps requires a special parameter to enable/trust them... that would IMHO be totally up to him. - It should be rather simple to change the mandatory algos in the standard. I mean we still list 3DES, while in reality it's probably AES. Cheers, Chris. --=-hk2h2aCv8tWFHYoQSSWO Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNDIzNTEy MVowTwYJKoZIhvcNAQkEMUIEQDfkf3Gd+X9tbqtjqdQfpJJzZIHQsUxfZy6JSoz1bSXTTmKcxirc vzjuL5DNcht4NUeV2LlkQx7K9x0RSIWsn0MwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAlSNtbAn4Pew2wtmL0nj29eiy18hDZ m1muoXhl93rzpVgkWbRsFjM9aYbMatmNSVehDpWoUpFUOA+rhq5km/qLGPMlwIP5vmM0mPCsjqel RBFwDHzWns88ImQ3YMahnhzqA9QgdsrVFR3ZT4i5L9udIbIRNIRFsGIkaNlK14znnLZDJaU3/nca g3zZGnTqn5FsyR5/WUhXBIGp2yJ5B4rBKFGYdByWZPTUf54qHm/lzSbD0pjlPoWagx0pstW1O603 Je7jtEpG6PdFAR/SagEX/w9X4SWnLoiN4puzkklS8CJhQt8Cj8O5q+0ARI1l2YZI7/Z+eoJFOb1L 2Uv8JmW0AAAAAAAA --=-hk2h2aCv8tWFHYoQSSWO-- From nobody Tue Mar 24 17:17:12 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 8E1411A1BCA for ; Tue, 24 Mar 2015 17:17:11 -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 in93_-2MdRQY for ; Tue, 24 Mar 2015 17:17:09 -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 55A4D1A1B3D for ; Tue, 24 Mar 2015 17:17:09 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id CE5796D814; Tue, 24 Mar 2015 20:17:07 -0400 (EDT) Message-ID: <5511FE82.6010807@iang.org> Date: Wed, 25 Mar 2015 00:17:06 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> In-Reply-To: <1427168189.10191.241.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 00:17:11 -0000 On 24/03/2015 03:36 am, Christoph Anton Mitterer wrote: > Long story short: > I don't think that OpenPGP was ever the system of the masses, and > perhaps it even shouldn't be. OK! Now that's the beginnings of a manifesto. It's a position, plain and simple. I think differently - I think a system that doesn't target the masses is doomed. What do others think? This is no light question, it could decide who participates, what the security model is, how 'hard' it is, where the compromises are found ... and decide its ultimate success. iang ps; this was taken from the other thread, plenty of actual argumentation in that too, but I know most will not read for length. From nobody Tue Mar 24 17:31: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 4E4071A1B85 for ; Tue, 24 Mar 2015 17:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lG759AI9YKtg for ; Tue, 24 Mar 2015 17:30:58 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886901A1B20 for ; Tue, 24 Mar 2015 17:30:55 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 13DBD5FC62 for ; Wed, 25 Mar 2015 00:30:54 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id 4GqwdEHs5HkR for ; Wed, 25 Mar 2015 00:30:52 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Wed, 25 Mar 2015 00:30:51 +0000 (UTC) Message-ID: <1427243451.10191.375.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 25 Mar 2015 01:30:51 +0100 In-Reply-To: <5511FE82.6010807@iang.org> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-cREBTD1KEhMB3/i+ReY8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 00:31:00 -0000 --=-cREBTD1KEhMB3/i+ReY8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-03-25 at 00:17 +0000, ianG wrote:=20 > I think differently - I think a system that doesn't target the masses is= =20 > doomed. Any proofs for this? OpenPGP (probably not targeted for the masses) =3D> still okay and secure X.509 (absolutely targeted for the masses) =3D> inherently broken (unless of course one trusts the Mozilla CAs, e.g. turktrust and CNNIC O:-) ) XMPP (*intended* for the masses, but basically failed (actually, mostly thanks to the big players and greedy companies like wotzapp) =3D> well, at least people have their freedom Skype,Hangouts,Wotzapp (targeted for the masses, backed as such by the big players) =3D> people completely surrender to the vendors and their conditions (and don't these typically even include that the vendor may do basically anything he likes with the data, including selling it?) Cheers, Chris. --=-cREBTD1KEhMB3/i+ReY8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNTAwMzA1 MVowTwYJKoZIhvcNAQkEMUIEQH7DsxesUJWk/bgXRLE4u4xQ7tiih9/safLIe28qVuUGGbfQNLaX PLoVcKxGmRkDokysQtV98SRZaFbqoLsxJfEwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCqn1YQ0LQ2jcKH+Uh7CDFFpDpOcDM+ A981jxa0hXQknL3w87xjzifVVf6CVvzKkT6r7TgqkZVu0XciBSkMOb+j5tNASfzGoSgW7CXUT00D 7iCGTzkLDjie2z8J4MsLJsoqEUtjoaU4AoBj4xgt5mQIXl6HF7QgPQNedAHEEh1BtmdTtZpeV1wZ Tyf9ox9Jd5j6lJlQ4zMUzDsmtrMlSFrHG6K8evyT13eZYP5kuUEAeF+eQcwNAzZTJi3syicThf5g n9/16i/EW31NZvpAGvuLSoM/8nN+yQmcxiW/H+9Kw3FAZSNats8/l2BeDs3z1rlMtK9iCIWTJMwb 4O6p4pKiAAAAAAAA --=-cREBTD1KEhMB3/i+ReY8-- From nobody Tue Mar 24 21:06:42 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 081001ACD84 for ; Tue, 24 Mar 2015 21:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 Xl70vu_FG_nV for ; Tue, 24 Mar 2015 21:06:40 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 769DC1ACD93 for ; Tue, 24 Mar 2015 21:06:40 -0700 (PDT) Received: by laae1 with SMTP id e1so10084159laa.2 for ; Tue, 24 Mar 2015 21:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=crcpEG7BDuBYol2gPaCeOstyKylttSggR+7NxEgQqXY=; b=A4q5TxoVTEuicYuuYii4YBJFZc9F/B3AiE8uIRtXGNAkupDl6gtXmJKi+pmuP1V5gP 0lpAHZZosvDsKJ/cltanG7Eu590eDpnMhs3pg0M1IShQHmgLDePOTHqRU/DOI1wytXeM JGgiTPobauZ6hkGVx9B+48wugL88x4qZoOek10hM/x5H3FgYeoSaNJ1Ueu+rkROXaMrz bFWs9GCoYmEGN9zOy+5yk4zsXuVuCH+lxDemQUBGxnfpPlnMarLDhzx7yGDA6aan155q eX9zVzpZN5JnmNoNaEcaYaeRl5pptjaH6OwQ56XeEFLpGFLvNm2cu5wtUla6YEGcpQUm d0Ow== MIME-Version: 1.0 X-Received: by 10.152.206.7 with SMTP id lk7mr6626537lac.55.1427256398984; Tue, 24 Mar 2015 21:06:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Tue, 24 Mar 2015 21:06:38 -0700 (PDT) In-Reply-To: <5511FE82.6010807@iang.org> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> Date: Tue, 24 Mar 2015 23:06:38 -0500 X-Google-Sender-Auth: 3_JvJM8ubuzd4LQoYqqLyeHOpG0 Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 04:06:42 -0000 The Internet is for Everyone. 7.125 billion or go home. On Tue, Mar 24, 2015 at 7:17 PM, ianG wrote: > On 24/03/2015 03:36 am, Christoph Anton Mitterer wrote: > >> Long story short: >> I don't think that OpenPGP was ever the system of the masses, and >> perhaps it even shouldn't be. > > > > OK! Now that's the beginnings of a manifesto. It's a position, plain and > simple. > > I think differently - I think a system that doesn't target the masses is > doomed. > > What do others think? > > This is no light question, it could decide who participates, what the > security model is, how 'hard' it is, where the compromises are found ... and > decide its ultimate success. > > > > iang > > > > ps; this was taken from the other thread, plenty of actual argumentation in > that too, but I know most will not read for length. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Wed Mar 25 01:05:06 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 0C21B1ACE09 for ; Wed, 25 Mar 2015 01:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 5cWc6q-5Z1NC for ; Wed, 25 Mar 2015 01:05:04 -0700 (PDT) Received: from smtp.iridiumlinux.org (akira.iridiumlinux.org [184.70.203.174]) by ietfa.amsl.com (Postfix) with ESMTP id 081221ACE02 for ; Wed, 25 Mar 2015 01:05:04 -0700 (PDT) Received: by smtp.iridiumlinux.org (Postfix, from userid 65534) id 6A1FF13F40BD; Wed, 25 Mar 2015 02:04:33 -0600 (MDT) X-Spam-ASN: Received: from [192.168.0.5] (c-24-143-80-128.customer.broadstripe.net [24.143.80.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.iridiumlinux.org (Postfix) with ESMTPSA id 3121214FA0B5 for ; Wed, 25 Mar 2015 02:04:32 -0600 (MDT) Message-ID: <55126C0D.30807@iridiumlinux.org> Date: Wed, 25 Mar 2015 01:04:29 -0700 From: Falcon Darkstar Momot User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070505060600060803040304" Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 08:05:06 -0000 This is a cryptographically signed message in MIME format. --------------ms070505060600060803040304 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In all seriousness, attempts to create useability for any target audience by committee are probably doomed (even though what we have now is balked at even by a lot of security professionals). PoC something fir= st. --Falcon Darkstar Momot --Shadytel On 24/03/2015 21:06, Phillip Hallam-Baker wrote: > The Internet is for Everyone. > > 7.125 billion or go home. > > On Tue, Mar 24, 2015 at 7:17 PM, ianG wrote: >> On 24/03/2015 03:36 am, Christoph Anton Mitterer wrote: >> >>> Long story short: >>> I don't think that OpenPGP was ever the system of the masses, and >>> perhaps it even shouldn't be. >> >> >> OK! Now that's the beginnings of a manifesto. It's a position, plain= and >> simple. >> >> I think differently - I think a system that doesn't target the masses = is >> doomed. >> >> What do others think? >> >> This is no light question, it could decide who participates, what the >> security model is, how 'hard' it is, where the compromises are found .= =2E. and >> decide its ultimate success. >> >> >> >> iang >> >> >> >> ps; this was taken from the other thread, plenty of actual argumentati= on in >> that too, but I know most will not read for length. >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp --------------ms070505060600060803040304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKUjCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFMDCCBBigAwIBAgIRAN3sgt3ll/yQeOZPRId2L3IwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw NjEwMDAwMDAwWhcNMTUwNjEwMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhdmYWxjb25AaXJp ZGl1bWxpbnV4Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANFEuUdfP+wv X950Km0FMhQMuSGDWruO3Wy6Vxf4kgEcGqDl73zZzQ7vohYUEtUc3kyluw9qwk42FGqHSs5Y pW5CDWr85Ov167Z3DwjCHJ2cA9qtTCD0GwjW9MkYRDQpWs87pq9Ur51G0/mkiG4y4Xkif4Dl 28R2YM3QIvs1XL6bobjmcyt30eZrArkgNuBBmcAybuo0pqFlBaKud8HcgrOR91keU7mAqJIz MVnV+jBeFbX5Rs7RXAtJBM1n3u48w8v3V/2E034DBa0vjhyafpPDKv9LQ4LyJysBZ9uIArCk 7HJqzGO2kT/6cXFbwCphHY5C3IMPx0FdMboi2isoDsUCAwEAAaOCAecwggHjMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTmkI6vq81eszHm8NLf/xOfFPDl ozAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1Ud HwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEF BQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2Rv Y2EuY29tMCIGA1UdEQQbMBmBF2ZhbGNvbkBpcmlkaXVtbGludXgub3JnMA0GCSqGSIb3DQEB BQUAA4IBAQABMQFyXEQDcedRrbgAbhuMFztPeTMz+XuM/tybABL8aCzxyB3b7tiJ1kY5jMA1 2O7bydcen9XGfXI2RZM2btU2zoOSYqdh9SoLX1pSIL2P48b7PV7SYK/iruplh8S/s9+/ziav 2f1q2LT3aN4brT+QBDHLz0+/g6sYNg6nnNbHBGT3uTX4mSS9iP5IohKmKmHGCKFXXiWmcRCU 1CynAd9fmQroFXRpJYtbRbR1nEpUfJ2NGffKO7qLkA+X2H9ORvBQvuBa20P5Q4sjehTX87d+ zdbtA4lxOsA5/MSoeZ+LKlx1hXmY+i/qmjlZO42FpMBKGQYW9ioJ8vSiiSHjarAuMYIEHDCC BBgCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDd 7ILd5Zf8kHjmT0SHdi9yMAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNTA4MDQyOVowIwYJKoZIhvcNAQkEMRYEFDKJ8VJ3 XM+3MP/Qbvd1om5cphH0MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAN3sgt3ll/yQeOZPRId2L3IwgbwGCyqGSIb3 DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcG A1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEA3eyC3eWX/JB45k9Eh3YvcjANBgkqhkiG9w0BAQEFAASCAQC3b1h8lyscEE5LMscLGWCO WashDtbBDmG7OzNcLzRjyO4vHPPrDXkqQ04vc+CEGZjGxQr0d/KhxfvO9URyw2go0AAS1o34 JhEZDNJpyJLU6itML2FXgefi7TIDACk/N+DiQQNtvzni2hbv0kTF5tPNXMUf6mS8FJCX9NDn UrJ00Posq3St22pogLUOWiVuxSXyRgdv1fYeX+a33bWAv/LI+6xg+sVI5XLgfbewGZ93lmqC 5a3QFl6nQstxM6a4ock1XStAU8FSrkU1oCfLubebjuTiBU/jSYUaRnKzbxw7ERwUQfKIViGF 8AE1FC5LHumGUc7ToJKA+7t2PvSDKU+UAAAAAAAA --------------ms070505060600060803040304-- From nobody Wed Mar 25 01:31:28 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 7EEA71A90BC for ; Wed, 25 Mar 2015 01:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 iNNe4LuLpGzH for ; Wed, 25 Mar 2015 01:31:26 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E81A1A00DD for ; Wed, 25 Mar 2015 01:31:26 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yagii-0003ya-Vp for ; Wed, 25 Mar 2015 09:31:25 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yagd1-0000Vb-Sf; Wed, 25 Mar 2015 09:25:31 +0100 From: Werner Koch To: ianG References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.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 Date: Wed, 25 Mar 2015 09:25:31 +0100 In-Reply-To: <5511FE82.6010807@iang.org> (iang@iang.org's message of "Wed, 25 Mar 2015 00:17:06 +0000") Message-ID: <87wq25iiv8.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] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 08:31:28 -0000 Hi! FWIW: When I kicked of this thread I was not thinking of a "new OpenPGP" but of long planned extensions and updates to an existing protocol. Throwing everything over board and start from scratch should not be done under the label of OpenPGP; there are already a couple of other projects working on re-doing everything from scratch. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Mar 25 04:38:01 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 34CC11A6EDC for ; Wed, 25 Mar 2015 04:38: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 l1ECBVXQHy0u for ; Wed, 25 Mar 2015 04:38:00 -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 074721A1F1D for ; Wed, 25 Mar 2015 04:37:59 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 9693E6D857; Wed, 25 Mar 2015 07:37:57 -0400 (EDT) Message-ID: <55129E14.9010000@iang.org> Date: Wed, 25 Mar 2015 11:37:56 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <644FDE72-CB1A-4EBE-9309-B429860A360D@gmail.com> <5511F096.7000404@iang.org> <1427241081.10191.348.camel@scientia.net> In-Reply-To: <1427241081.10191.348.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Hybrid proposal for algorithm identifiers 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, 25 Mar 2015 11:38:01 -0000 On 24/03/2015 23:51 pm, Christoph Anton Mitterer wrote: > On Tue, 2015-03-24 at 23:17 +0000, ianG wrote: >> On the left, >> there are the pluralists > So pluralists are left-wing?! ;-P Actually that's a point - you should be right wing. That's the confused state of politics these days, or maybe it was the beer talking :) iang From nobody Wed Mar 25 06:00:45 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 50B7E1ACEAE for ; Wed, 25 Mar 2015 06:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 mtlqdZCnhr3u for ; Wed, 25 Mar 2015 06:00:42 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7D41ACEAD for ; Wed, 25 Mar 2015 06:00:42 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id EEE53F2138; Wed, 25 Mar 2015 13:00:40 +0000 (UTC) Date: Wed, 25 Mar 2015 08:00:39 -0500 From: Stephen Paul Weber To: ianG Message-ID: <20150325130039.GB3160@singpolyma-liberty> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <5511FE82.6010807@iang.org> Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 13:00:44 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >>Long story short: >>I don't think that OpenPGP was ever the system of the masses, and >>perhaps it even shouldn't be. > >I think differently - I think a system that doesn't target the masses is= =20 >doomed. OpenPGP does not specify a UI. "Target the masses" implies some kind of UI= =20 or use case or *something*. OpenPGP is a format for packing bits together= =20 and specifying how some of them were encrypted/signed. You can build any= =20 kind of PKI I've ever seen on top of OpenPGP, because it's just a format an= d=20 doesn't specify such details. This is as it should be. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVErF3AAoJENEcKRHOUZze6pwP/iU023WeUr5kJSWlZck2gDu1 U2aGins2SwRqJ+5T05wmvFv8FYTfEdCEtA2lxdVCADnxbjafUxl1iitfqHlYtAiF ECz9gEFvUEeEqRIoZ7Nqzgd/aKQaYU/3cQnDeO/0+VRC3QqfwtCmAcy27DjAyegb xuu9nEW031rISAGeHQnB1e4GpPOOl+llsp2DzaRqOfq+evNbVrrgjmti6uA2LFSk T464Z1eKbt5uGkcwbIkNQ0vC9H0HpiGEaUYcWtkaINpBUCsPbjK+mmPYgJncQWEN SqaLCaoD2ZNS/05EGJa75q76NjP0zQtzCqOTdM8mPlzZUc6c3uG7Fqh3Yxx8UEMi krcLzxYAMlyLIdM4BFEMW79SCJ+0FUYIujU9OLOrge81EJTceludqChbqB75IoOH 3R4CvoiSvo9b/yZb1tr2p9vGDikZZxOilCAEpZEOgCFfvX2bTPp1dy8/55xCnx65 /Nq6IPZa/3ENfiCxzIxJVQO6T/nq+F/Rhp3EwDW8P7DEzgatDondTQMyJskR6YB5 2qlfFNoLp7DusagQyPo2bKgxHfZXpbadX+Lc7yekayCOU0qvpm5ahQ1EeLcmmjVN a7/G2M4e36HDc9s+uHmCETRBKYBu0GyvHowH/MWPCxGDyXRWp/mlzfE87Lp7TQ1Y soJJ+R36nQCifB0f4Fak =HxE8 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From nobody Wed Mar 25 06:03:00 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 77FFF1ACECD for ; Wed, 25 Mar 2015 06:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 6eCBdcThl9Vz for ; Wed, 25 Mar 2015 06:02:56 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4E61ACECC for ; Wed, 25 Mar 2015 06:02:55 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id D78F1F2140; Wed, 25 Mar 2015 13:02:54 +0000 (UTC) Date: Wed, 25 Mar 2015 08:02:53 -0500 From: Stephen Paul Weber To: Werner Koch Message-ID: <20150325130253.GC3160@singpolyma-liberty> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <87wq25iiv8.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: <87wq25iiv8.fsf@vigenere.g10code.de> Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: openpgp@ietf.org, ianG Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 13:03:00 -0000 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >FWIW: When I kicked of this thread I was not thinking of a "new OpenPGP" >but of long planned extensions and updates to an existing protocol. >Throwing everything over board and start from scratch should not be done >under the label of OpenPGP; I very much agree. To be "OpenPGP" is to be at least *able* to be backward= s=20 compatible with the current OpenPGP. Otherwise you are something new and= =20 other. --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --9zSXsLTf0vkW971A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVErH9AAoJENEcKRHOUZzelRkP/iU6xwBuHN/j0pmVPuBb9Smx ZfltLwjtZHQ/u/lOroLmUwZqWux9Jr/1rMHf4q65BSrXoRrK2kqOMR+abuGo5j1V pQ5hhqJ8ocnF8k7SWU+cNMxSFZqGDEB5Qa4I1YFdxXjwC/ajAd7YT7O+oQnKfnVb xLxu0H3Exf879ejiOtWZyuTPyKG4NuP3WJtnsktuCUO8iKg4WxS3WIKnbZAupWtI Tq9tdqoefeWZrSUwkUKWBDLFcfGz65V15VtgVnRrubEOXW3bZk61WdjA5fcIMA/s srYmZEohYrNcPHGMeQpDQ8wBS6gCJbt7Tp+KJ4QKIQ7GKBBn6patt8q1kEymL9ro u7sRfH72XdOrsNzCp+rrP/xranzYGN9QWBZXrBAiFEmSOa+kSLna4HVFvJIINB76 IQWuH9L9uLxajoRGSeqjXPpf7C3gCDWA97YXhUCprIhG5c/p5qHndiSmWsjIXeRx XW6gsMlifpE0vS/sRJ8j8ZEDJ8M2L1W6XbnvDZBuKnmlOl+TSBuVvB6w5WYcz5ec Y0pEBKBkefXoXIigDcv0f2k3xbe7ffWEZjvMlv0eie9AjAoFzrq4iTGxGVPi1xCd QwkWS8sgFoI95/ZmAibaz7RIql+Zcdjll+679H9pdPMb+Ownl0QPOg7AYyxYusSj 2hLolyjaL4oPNcDqKMuW =BQN6 -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From nobody Wed Mar 25 06:41:36 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 D25761AD065 for ; Wed, 25 Mar 2015 06:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 PMcFFIPEqy4H for ; Wed, 25 Mar 2015 06:41:32 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 93DF21AD05B for ; Wed, 25 Mar 2015 06:41:32 -0700 (PDT) Received: by oiag65 with SMTP id g65so21372312oia.2 for ; Wed, 25 Mar 2015 06:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=BE4gcEkc9JdvN9BeurIoi1mjeSNfumjbTvdubI3YBrg=; b=lItytVJWRgNNzkw8Xx1Eg85J6Y2yXzPi6VOQorKgjXhdMXrgx0U1o8XRK+EFheAbzB 6tTR3NJAJv71ZZLy3G4DL4tYvnlIrbYqLnBwCJOS29E0R1Efra3673p9aLKySOTglUL7 ZX8TzDyuNUmQ8rMFgxUMYfFsWmfYLztQw6llCTQc35izWtlSFYo+K5Hh1W78Sz6SrLOg UZXyDHny/hZDZ79g72foMFDliZ6IEdywbPCegl7jLrQdyaShBnJoOBG7lAkiwwCONdZu F1UCXYPNhj3D+p02Qf4vOBNR8Z4FOuj2RDjGPPzV7lIifN3mwOBFFKJ2Uvemwk2HGiRg SUFQ== X-Received: by 10.202.202.82 with SMTP id a79mr7099874oig.5.1427290892141; Wed, 25 Mar 2015 06:41:32 -0700 (PDT) MIME-Version: 1.0 References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <87wq25iiv8.fsf@vigenere.g10code.de> <20150325130253.GC3160@singpolyma-liberty> In-Reply-To: <20150325130253.GC3160@singpolyma-liberty> From: Wyllys Ingersoll Date: Wed, 25 Mar 2015 13:41:30 +0000 Message-ID: To: Stephen Paul Weber , Werner Koch Content-Type: multipart/alternative; boundary=001a1135293c9e0ba805121d0e3a Archived-At: Cc: openpgp@ietf.org, ianG Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 13:41:35 -0000 --001a1135293c9e0ba805121d0e3a Content-Type: text/plain; charset=UTF-8 Compatibility with existing implementations should be a consideration when making any updates to the spec. Creating a "V5" key format is certainly within scope. Radically changing the packet structure or data encoding scheme in a way that breaks all existing implementations or forces the implementors to have 2 very different code bases to support old vs "new" formats should be strongly discouraged. One of the (many) problems with todays OpenPGP is that it is impossible to update older keys to a newer format, which leads to many users continuing to rely on old keys and implementors end up having to support the older formats. We could encourage users to "modernize" their keys if new formats were designed with some thought to having an upgrade path from V4. Revoking old keys and re-issuing your public key to your "circle of trust" is tedious and semi complicated and most people just give up and create new keys or stop using PGP altogether. Certainly, weak keys should be revoked and replaced, but "reasonable" keys that are just in an older format should be easily updated to newer formats if possible. IMO, the goals of an OpenPGP update should be: 1. Remove any outdated and/or insecure ciphers and hashes 2. Specify profiles for new ciphers, modes, and hashes with an eye towards simplification. Keep the "MUST" list short and the optional list brief but extensible. 3. Upgrade path from V4 keys to V5 and beyond. 4. Don't fix what ain't broke. ASCII Armor, for example. If whatever results from this effort requires a complete rewrite of existing OpenPGP parsing engines and reengineering existing apps from the ground up, then it will be a complete failure and should be renamed something else and taken to a new WG. -Wyllys @ipgmail On Wed, Mar 25, 2015 at 9:03 AM Stephen Paul Weber < singpolyma@singpolyma.net> wrote: > >FWIW: When I kicked of this thread I was not thinking of a "new OpenPGP" > >but of long planned extensions and updates to an existing protocol. > >Throwing everything over board and start from scratch should not be done > >under the label of OpenPGP; > > I very much agree. To be "OpenPGP" is to be at least *able* to be > backwards > compatible with the current OpenPGP. Otherwise you are something new and > other. > > -- > Stephen Paul Weber, @singpolyma > See for how I prefer to be contacted > edition right joseph > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1135293c9e0ba805121d0e3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Compatibility with existing implementations should be = a consideration when making any updates to the spec.=C2=A0 Creating a "= ;V5" key format is certainly within scope.=C2=A0 Radically changing th= e packet structure or data encoding scheme in a way that breaks all existin= g implementations or forces the implementors to have 2 very different code = bases to support old vs "new" formats should be strongly discoura= ged. =C2=A0

One of the (many) problems with todays OpenP= GP is that it is impossible to update older keys to a newer format, which l= eads to many users continuing to rely on old keys and implementors end up h= aving to support the older formats.=C2=A0 We could encourage users to "= ;modernize" their keys if new formats were designed with some thought = to having an upgrade path from V4.=C2=A0 Revoking old keys and re-issuing y= our public key to your "circle of trust" is tedious and semi comp= licated and most people just give up and create new keys or stop using PGP = altogether.=C2=A0 Certainly, weak keys should be revoked and replaced, but = "reasonable" keys that are just in an older format should be easi= ly updated to newer formats if possible.

IMO, the g= oals of an OpenPGP update should be:
1. Remove any outdated and/o= r insecure ciphers and hashes
2. Specify profiles for new ciphers= , modes, and hashes with an eye towards simplification.=C2=A0 Keep the &quo= t;MUST" list short and the optional list brief but extensible.
3. Upgrade = path from V4 keys to V5 and beyond.
4. Don't fix w= hat ain't broke.=C2=A0 ASCII Armor, for example.=C2=A0


If whatever results from this effort requires a com= plete rewrite of existing OpenPGP parsing engines and reengineering existin= g apps from the ground up, then it will be a complete failure and should be= renamed something else and taken to a new WG.

-Wy= llys
@ipgmail



On Wed, Mar 25, 2015 at 9:03 AM Stephen Pa= ul Weber <singpolyma@singpo= lyma.net> wrote:
>FWIW: When I = kicked of this thread I was not thinking of a "new OpenPGP"
>but of long planned extensions and updates to an existing protocol.
>Throwing everything over board and start from scratch should not be don= e
>under the label of OpenPGP;

I very much agree.=C2=A0 To be "OpenPGP" is to be at least *able*= to be backwards
compatible with the current OpenPGP.=C2=A0 Otherwise you are something new = and
other.

--
Stephen Paul Weber, @singpolyma
See <http://singpoly= ma.net> for how I prefer to be contacted
edition right joseph
_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a1135293c9e0ba805121d0e3a-- From nobody Wed Mar 25 07:54:32 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 D40A81A873B for ; Wed, 25 Mar 2015 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_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 KdC7bCU2Z80k for ; Wed, 25 Mar 2015 07:54:28 -0700 (PDT) Received: from thumb.scru.org (thumb.scru.org [67.18.186.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7022E1A1B2A for ; Wed, 25 Mar 2015 07:54:28 -0700 (PDT) Received: by thumb.scru.org (Postfix, from userid 1000) id 9CB3110D4EB; Wed, 25 Mar 2015 14:54:27 +0000 (UTC) Date: Wed, 25 Mar 2015 14:54:27 +0000 From: Clint Adams To: Werner Koch Message-ID: <20150325145427.GA22635@scru.org> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <87wq25iiv8.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wq25iiv8.fsf@vigenere.g10code.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 14:54:31 -0000 On Wed, Mar 25, 2015 at 09:25:31AM +0100, Werner Koch wrote: > FWIW: When I kicked of this thread I was not thinking of a "new OpenPGP" > but of long planned extensions and updates to an existing protocol. > Throwing everything over board and start from scratch should not be done > under the label of OpenPGP; there are already a couple of other projects > working on re-doing everything from scratch. Could you list them? From nobody Wed Mar 25 08:16:34 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 1FD1E1B2A2B for ; Wed, 25 Mar 2015 08:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 0mmULj4W6QBt for ; Wed, 25 Mar 2015 08:16:30 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 403C61B2A2C for ; Wed, 25 Mar 2015 08:16:16 -0700 (PDT) Received: by labe2 with SMTP id e2so22468288lab.3 for ; Wed, 25 Mar 2015 08:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eP7D7AwDwCMpGfogJ4bipEROK4dC5+/UuMXxozWOVXM=; b=SKB6zxXbryxC6HfqRx12zzMWDW9Il07Sk3NSJMZxE8XAy7FioIUB+HeUp6KdKMsayS PqW5J61Z602sBrVhV5gTwLlUXtdF6rtmP0+n1IBBI9bXvaoD7VUHer3BaISZOs8vfmCh 0r8xiyEIc83cVFZQwZt8iqy2nzBBKG1Zk9wqIPNPjLZejeDb8HhAOt0A9HrWhpFDTP+w GHudPrtUuDqHILTb/UwsfdPg3eJTIUkpPxIYbmk0Ib2ojMMmUekJ6AZn8YPjjzSw82wK dBKqNSlg5DMqOYfj3bRqJNVWyzGCBxky+myPrVO1zilx2fCFwP5TjQy6QzEuJUQpIeSf EYuA== MIME-Version: 1.0 X-Received: by 10.112.147.163 with SMTP id tl3mr3677521lbb.118.1427296574686; Wed, 25 Mar 2015 08:16:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Wed, 25 Mar 2015 08:16:14 -0700 (PDT) In-Reply-To: <55126C0D.30807@iridiumlinux.org> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <55126C0D.30807@iridiumlinux.org> Date: Wed, 25 Mar 2015 05:16:14 -1000 X-Google-Sender-Auth: pBFMvjmeBPY688kDIzF3XhHWpnY Message-ID: From: Phillip Hallam-Baker To: Falcon Darkstar Momot Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 15:16:32 -0000 On Tue, Mar 24, 2015 at 10:04 PM, Falcon Darkstar Momot wrote: > In all seriousness, attempts to create useability for any target > audience by committee are probably doomed (even though what we have now > is balked at even by a lot of security professionals). PoC something first. Take a look at the work on http://prismproof.org/ I have done security usability in the past and the bit with the testing lab and one way mirrors. After a while I realized that I didn't need any of it. All that we need to do to achieve usable email security is to make using the secure mail exactly as easy as using insecure. Think that is impossible? I have running code on SourceForge that works with existing mail clients with no plug ins. It is based on S/MIME of course because that is the message format that the clients support. The trust model I am using is actually PGP fingerprints. The configuration tool essentially has only one option, whether to select a CA or not and if so the DNS name of the CA. (Right now the CA registration code is incomplete due to the ACME situation). Regardless of what the user chooses, the tool creates a personal PKI for the user, complete with a self signed root, intermediate, split encryption/decryption keys and a device key for use in key rollovers. This is the CostCo strategy, instead of selling 20 different models with different features, CostCo tells the vendor to provide all the features of the top of the line model at the base model price. Giving every user a 'standard' trust environment allows us to get to a pretty good compromise between security and convenience from the start. Expert users can always enroll supplemental keys which make different security tradeoffs, not escrowing the key provides some protection against a subpoena but introduces a real risk of data loss. To send mail, users just send and receive as normal. The only time a user has to be aware of the encryption is if they want to require the message to be encrypted. As I said, right now the code only supports S/MIME. But I have always planned to add OpenPGP support so I can make use of the PGP keys as well. The key bit of technology is basically taking a bit of design for the web "Take all the information you need to establish a connection and pack it into one identifier that can be cut and pasted". aed9ef23-12393764-64931237?alice@example.com From nobody Wed Mar 25 16:27:21 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 AD9991AC3B0 for ; Wed, 25 Mar 2015 16:27:20 -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 a1aLuDy9bohb for ; Wed, 25 Mar 2015 16:27:19 -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 EE45F1ACC87 for ; Wed, 25 Mar 2015 16:27:18 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 88FA26D737; Wed, 25 Mar 2015 19:27:17 -0400 (EDT) Message-ID: <55134455.2070606@iang.org> Date: Wed, 25 Mar 2015 23:27:17 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <878uf2iehi.fsf@vigenere.g10code.de> <5510C26E.7070409@iang.org> <87mw32omzs.fsf@vigenere.g10code.de> In-Reply-To: <87mw32omzs.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 25 Mar 2015 23:27:20 -0000 On 24/03/2015 07:47 am, Werner Koch wrote: > On Tue, 24 Mar 2015 02:48, iang@iang.org said: > >>> - The use of SHA-1 needs to be replaced. >> >> SHA3. > > That was the original plan. However it turned out that the still not > finalized SHA-3 is meanwhile considered a fallback option in case of new > developments. SHA-2 has wide support and is already in wide use. We > only need a new fingerprint style and use that for some designated > revokers etc. SHA3 because it has sponge, it can do MACs, it can do stream ciphers, it can do authenticated stream ciphers, it can brew the morning tea if you plug it in the right way. (Yeah, I know NIST said it's in fallback mode, but when the thing actually comes out, I think it will be a game changer. Sponge changes everything.) >>> - A new encryption mode to replace our aging CFB+SHA1 method with a >>> fast and standard mode. >> >> >> Wait for CAESAR, 2017. It'll take that long anyway. > > I am more thinking of OCB; there is a free patent grant for all relevant > parties and the patent will anyway expire by the time a new encryption > format will get in widespread use. See, this is where the cryptographers and the cryptoplumbers have sort of moved on. Instead of us arguing about what mode to use, we've thrown it back over the wall, and shouted out to them lot on the other side (cryptographers) stop with the silly modes! Give us one stream cipher that does *the lot* and let us get back to real coding... That's CAESAR. It will replace all the modes, all the algs, all the everything in the entire symmetric space. And make your tea ;) Hence I think waiting until it comes out and picking up its good work is worthwhile. (and, ps; Keccak has been submitted, it'll make your tea and your coffee too!) >> 4880 took a decade. Too long, the OODA loop was bigger than the > > Nope. 4880 is a minor update of 2440 which barely took a year to be > released with code ready 6 months earlier. The major new features in > 4880 have been enabled since fall 2000 (MDC packets) > >>> How can we get the WG out of the concluded state? >> >> As long as they don't turn off the list, do we care? ;-) > > May I read this and your other remarks that you see no more value in the > IETF process? I'm an acknowledged skeptic of the IETF process... maybe need to send that memo out again? Here's my big criticism of the IETF process: like all processes it eventually ends up becoming a place for people to create silos of knowledge and careers, and eventually divorces itself from what's happening out there in the real world. But it holds the keys to some powerful Internet protocol components, and while it's not bringing in the new, outside knowledge, the IETF WG becomes the blockage, the inner sanctum, the guilds that the IETF swore to bring down. So what do we do? Leave? Stay? Fight? iang From nobody Wed Mar 25 16:34:00 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 9B0F41A8898 for ; Wed, 25 Mar 2015 16:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543] 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 s0wVwXWkHrwq for ; Wed, 25 Mar 2015 16:33:57 -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 892F11A1B51 for ; Wed, 25 Mar 2015 16:33:57 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 0DA5C6D748; Wed, 25 Mar 2015 19:33:55 -0400 (EDT) Message-ID: <5512F137.80702@iang.org> Date: Wed, 25 Mar 2015 17:32:39 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> In-Reply-To: <1427243451.10191.375.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 23:33:58 -0000 On 25/03/2015 00:30 am, Christoph Anton Mitterer wrote: > On Wed, 2015-03-25 at 00:17 +0000, ianG wrote: >> I think differently - I think a system that doesn't target the masses is >> doomed. > Any proofs for this? Yup. > OpenPGP (probably not targeted for the masses) > => still okay and secure PGP - pretty good privacy - was targetted at the command line masses of the pre-web Internet of 1992. Still ok, still secure, but ... The definition of the masses has moved on. OpenPGP no longer targets the masses. And, in my view, unless something good comes out of the current Yahoo-google-friends partnership, will slowly fade. > X.509 (absolutely targeted for the masses) > => inherently broken (unless of course one trusts the Mozilla > CAs, e.g. turktrust and CNNIC O:-) ) No. It never targetted the masses. They only tell you in their marketing that it's "for the masses" so as to appease the browsers which have users as clients. You bought that because they kept saying it so many times they believe it themselves. But no. x.509/PKI/CAs are for the corporates. x.509 is irrelevant for privacy, expecially of the PGP variety. And in the pre-web telco 1980s days the fixed-line masses, it was never intended to be a privacy system, but an anti-privacy system. It was intended to map the world's population for the exploitation and control by the world's telcos, being national champions and in bed with governments and intel. > XMPP (*intended* for the masses, but basically failed (actually, mostly > thanks to the big players and greedy companies like wotzapp) > => well, at least people have their freedom Hmmm, I don't know why it failed. It didn't fail because of the *zapp companies, they simply did a better job. Yes, I agree that the players wrote things like OTR as privacy, but I would agree that essentially they failed, it's another lesson. Let's learn from it. > Skype,Hangouts,Wotzapp (targeted for the masses, backed as such by the > big players) Yup. > => people completely surrender to the vendors and > their conditions (and don't these typically > even include that the vendor may do basically > anything he likes with the data, including > selling it?) Right. So let's take google mail. google's meta is data data data. All your data are belong us. Which meant that google had conflicted inventives, which got sliced open by NSA. Hence today's story. Hence, I have difficulty in saying that google are PGP people in the sense of pretty good privacy - who we are on this list are about. Skype I would say were much more our sort of people, until they sold to ebay. Then their new masters had ... different ideas, but that story has never been told in public, so let's not get distracted. But back to your question: do we need to target the masses to survive? Yes. Skype, google, Whatsapp, snapchat, Facebook, Apple iMessage, etc are still all in business and are providing revenues, and they provided what privacy they did as a secondary to delivering a revenue-generating service to the masses. Absolutely. Whereas the PGP community took the old 1992 model of privacy absolutism, and found that their brief spurt of success in building a community around key signing parties and so forth ... was steamrollered by the wider onslaught of the open web. iang From nobody Wed Mar 25 16:34: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 D33751A899C for ; Wed, 25 Mar 2015 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592] 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 i7rOnsJO-mNq for ; Wed, 25 Mar 2015 16:33:59 -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 1FA6B1A1B51 for ; Wed, 25 Mar 2015 16:33:59 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1FAB86D748; Wed, 25 Mar 2015 19:33:58 -0400 (EDT) Message-ID: <5512F1FA.3010207@iang.org> Date: Wed, 25 Mar 2015 17:35:54 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Werner Koch References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <87wq25iiv8.fsf@vigenere.g10code.de> In-Reply-To: <87wq25iiv8.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 25 Mar 2015 23:34:00 -0000 On 25/03/2015 08:25 am, Werner Koch wrote: > Hi! > > FWIW: When I kicked of this thread I was not thinking of a "new OpenPGP" > but of long planned extensions and updates to an existing protocol. Good point. > Throwing everything over board and start from scratch should not be done > under the label of OpenPGP; there are already a couple of other projects > working on re-doing everything from scratch. What do people think? I certainly wouldn't stand in the way of a group that wanted to do that. But OpenPGP is more than an RFC - it's a shared vision, community, and a history. We've learnt a lot since 1992. If, in the act of tapping that learning, we tell the experience to go away and think up another name, I fear that's not productive, not efficient. iang From nobody Wed Mar 25 17:44:40 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 9BE051A0100 for ; Wed, 25 Mar 2015 17:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 mQQe__n_wk56 for ; Wed, 25 Mar 2015 17:44:36 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 C13E71A00FE for ; Wed, 25 Mar 2015 17:44:35 -0700 (PDT) Received: by lagg8 with SMTP id g8so33495497lag.1 for ; Wed, 25 Mar 2015 17:44:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J54v06ST0RUuYAqdeMoQ7e1M+EjX++3Fmn9w+Fb5I9g=; b=MraIu4MySFgunkdNStdK968/ktcO028i1M4EBuPY9V/RxbQnanaoUQyOxvSgqqg8Yp 1CS/zFWnxytRReuKfA6tNDsgrR+JyTk77pWEAfaVQrh2Hhrqv3JlvXmUepkoHAYG8Ubu 5pAM4GCZkHXxx03Ojy1ORoUEOE2usmMchTJnV4pv9kz/JZW/soPArt4F9e34u11hO0Hy qjviXhpVNRIehC9SiJxfI58oysEij5eMoGim2Q6m/afl0adUL+U5BLlhmEB1P4MtZKoE jLEJUc9WIaZQtWdqbQ+rjBrkddi7SRcSUeccDJk0DPjt47sIL6rrSukjoYhPGX7zjWxT Tb2g== X-Gm-Message-State: ALoCoQkY2Ysy4+i4vyt5R4UbqqPQj6HWGSI2LtMjcM1mTx9dHZDDH//jsRg3EKxqbAgDiBdf1PtI MIME-Version: 1.0 X-Received: by 10.152.28.233 with SMTP id e9mr10917232lah.3.1427330674210; Wed, 25 Mar 2015 17:44:34 -0700 (PDT) Received: by 10.114.3.242 with HTTP; Wed, 25 Mar 2015 17:44:34 -0700 (PDT) X-Originating-IP: [122.56.202.31] Received: by 10.114.3.242 with HTTP; Wed, 25 Mar 2015 17:44:34 -0700 (PDT) In-Reply-To: <5512F137.80702@iang.org> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> Date: Thu, 26 Mar 2015 13:44:34 +1300 Message-ID: From: Tim Bray To: ianG Content-Type: multipart/alternative; boundary=089e0158c7ccd054ee0512265112 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 00:44:38 -0000 --089e0158c7ccd054ee0512265112 Content-Type: text/plain; charset=UTF-8 You guys are taking it as axiomatic that a high-quality UX can't be provided for users of OpenPGP. Used OpenKeychain recently? Not quite there yet, but I think your axiom is looking a little shaky. On Mar 26, 2015 12:34 PM, "ianG" wrote: > On 25/03/2015 00:30 am, Christoph Anton Mitterer wrote: > >> On Wed, 2015-03-25 at 00:17 +0000, ianG wrote: >> >>> I think differently - I think a system that doesn't target the masses is >>> doomed. >>> >> Any proofs for this? >> > > Yup. > > OpenPGP (probably not targeted for the masses) >> => still okay and secure >> > > PGP - pretty good privacy - was targetted at the command line masses of > the pre-web Internet of 1992. Still ok, still secure, but ... > > The definition of the masses has moved on. OpenPGP no longer targets the > masses. And, in my view, unless something good comes out of the current > Yahoo-google-friends partnership, will slowly fade. > > > X.509 (absolutely targeted for the masses) >> => inherently broken (unless of course one trusts the Mozilla >> CAs, e.g. turktrust and CNNIC O:-) ) >> > > No. It never targetted the masses. They only tell you in their marketing > that it's "for the masses" so as to appease the browsers which have users > as clients. You bought that because they kept saying it so many times they > believe it themselves. But no. x.509/PKI/CAs are for the corporates. > > x.509 is irrelevant for privacy, expecially of the PGP variety. And in > the pre-web telco 1980s days the fixed-line masses, it was never intended > to be a privacy system, but an anti-privacy system. It was intended to map > the world's population for the exploitation and control by the world's > telcos, being national champions and in bed with governments and intel. > > > XMPP (*intended* for the masses, but basically failed (actually, mostly >> thanks to the big players and greedy companies like wotzapp) >> => well, at least people have their freedom >> > > Hmmm, I don't know why it failed. It didn't fail because of the *zapp > companies, they simply did a better job. Yes, I agree that the players > wrote things like OTR as privacy, but I would agree that essentially they > failed, it's another lesson. Let's learn from it. > > > > Skype,Hangouts,Wotzapp (targeted for the masses, backed as such by the >> big players) >> > > Yup. > > > => people completely surrender to the vendors and >> their conditions (and don't these typically >> even include that the vendor may do basically >> anything he likes with the data, including >> selling it?) >> > > Right. So let's take google mail. google's meta is data data data. All > your data are belong us. Which meant that google had conflicted > inventives, which got sliced open by NSA. Hence today's story. Hence, I > have difficulty in saying that google are PGP people in the sense of pretty > good privacy - who we are on this list are about. > > Skype I would say were much more our sort of people, until they sold to > ebay. Then their new masters had ... different ideas, but that story has > never been told in public, so let's not get distracted. > > > > But back to your question: do we need to target the masses to survive? > Yes. Skype, google, Whatsapp, snapchat, Facebook, Apple iMessage, etc are > still all in business and are providing revenues, and they provided what > privacy they did as a secondary to delivering a revenue-generating service > to the masses. Absolutely. > > Whereas the PGP community took the old 1992 model of privacy absolutism, > and found that their brief spurt of success in building a community around > key signing parties and so forth ... was steamrollered by the wider > onslaught of the open web. > > > > iang > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --089e0158c7ccd054ee0512265112 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You guys are taking it as axiomatic that a high-quality UX c= an't be provided for users of OpenPGP.=C2=A0 Used OpenKeychain recently= ? Not quite there yet, but I think your axiom is looking a little shaky.

On Mar 26, 2015 12:34 PM, "ianG" <<= a href=3D"mailto:iang@iang.org">iang@iang.org> wrote:
On 25/03/2015 00:30 am, Christoph = Anton Mitterer wrote:
On Wed, 2015-03-25 at 00:17 +0000, ianG wrote:
I think differently - I think a system that doesn't target the masses i= s
doomed.
Any proofs for this?

Yup.

OpenPGP (probably not targeted for the masses)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> still okay and secure

PGP - pretty good privacy - was targetted at the command line masses of the= pre-web Internet of 1992.=C2=A0 Still ok, still secure, but ...

The definition of the masses has moved on.=C2=A0 OpenPGP no longer targets = the masses.=C2=A0 And, in my view, unless something good comes out of the c= urrent Yahoo-google-friends partnership, will slowly fade.


X.509 (absolutely targeted for the masses)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> inherently broken (unless of cour= se one trusts the Mozilla
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAs, e.g. turktrust and CNNIC O:-= ) )

No.=C2=A0 It never targetted the masses.=C2=A0 They only tell you in their = marketing that it's "for the masses" so as to appease the bro= wsers which have users as clients.=C2=A0 You bought that because they kept = saying it so many times they believe it themselves.=C2=A0 But no.=C2=A0 x.5= 09/PKI/CAs are for the corporates.

x.509 is irrelevant for privacy, expecially of the PGP variety.=C2=A0 And i= n the pre-web telco 1980s days the fixed-line masses, it was never intended= to be a privacy system, but an anti-privacy system.=C2=A0 It was intended = to map the world's population for the exploitation and control by the w= orld's telcos, being national champions and in bed with governments and= intel.


XMPP (*intended* for the masses, but basically failed (actually, mostly
=C2=A0 =C2=A0 =C2=A0 thanks to the big players and greedy companies like wo= tzapp)
=C2=A0 =C2=A0 =C2=A0 =3D> well, at least people have their freedom

Hmmm, I don't know why it failed.=C2=A0 It didn't fail because of t= he *zapp companies, they simply did a better job.=C2=A0 Yes, I agree that t= he players wrote things like OTR as privacy, but I would agree that essenti= ally they failed, it's another lesson.=C2=A0 Let's learn from it.


Skype,Hangouts,Wotzapp (targeted for the masses, backed as such by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0big players)

Yup.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =3D> people completely surrender to the vendors and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0their conditions (and don't these typically
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0even include that the vendor may do basically
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0anything he likes with the data, including
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0selling it?)

Right.=C2=A0 So let's take google mail.=C2=A0 google's meta is data= data data. All your data are belong us.=C2=A0 Which meant that google had = conflicted inventives, which got sliced open by NSA.=C2=A0 Hence today'= s story.=C2=A0 Hence, I have difficulty in saying that google are PGP peopl= e in the sense of pretty good privacy - who we are on this list are about.<= br>
Skype I would say were much more our sort of people, until they sold to eba= y.=C2=A0 Then their new masters had ... different ideas, but that story has= never been told in public, so let's not get distracted.



But back to your question:=C2=A0 do we need to target the masses to survive= ?=C2=A0 Yes.=C2=A0 Skype, google, Whatsapp, snapchat, Facebook, Apple iMess= age, etc are still all in business and are providing revenues, and they pro= vided what privacy they did as a secondary to delivering a revenue-generati= ng service to the masses.=C2=A0 Absolutely.

Whereas the PGP community took the old 1992 model of privacy absolutism, an= d found that their brief spurt of success in building a community around ke= y signing parties and so forth ... was steamrollered by the wider onslaught= of the open web.



iang

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--089e0158c7ccd054ee0512265112-- From nobody Wed Mar 25 18:23:36 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 0199A1A1BB8 for ; Wed, 25 Mar 2015 18:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 oPkOyAwX2XiD for ; Wed, 25 Mar 2015 18:23:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E5C1ACDD5 for ; Wed, 25 Mar 2015 18:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1427333010; x=1458869010; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=CzZx9gRI2C3vGYveuzOs3s4AFiAAJiN/3LfQgzuTbu8=; b=DatMz82bTT6eXu0KIYMAo4lMWTTXqHYT4Cv6mlJ0Wv1Q/1AGSILH96Yk PNNqfl+8ay59PsfYO7OnQyllJh13d/hFKGXGfORJ5esuqsBMhCRfuG+GP usXvnFzCCOjoKD4oLOqtF1L/wyoAFkROqG619+UUVzDdsHPNNhdcefaRv Y=; X-IronPort-AV: E=Sophos;i="5.11,468,1422874800"; d="scan'208";a="316935303" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Mar 2015 14:23:28 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 26 Mar 2015 14:23:27 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] Manifesto - who is the new OpenPGP for? Thread-Index: AdBnY3ZBwtFJNVXAQ2u9BRvRU6Ta1g== Date: Thu, 26 Mar 2015 01:23:27 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFBEC7E@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 01:23:35 -0000 Christoph Anton Mitterer writes:=0A= =0A= > inherently broken (unless of course one trusts the Mozilla CAs, e.g.=0A= > turktrust and CNNIC O:-) )=0A= =0A= I've always wondered, what do people have against these two certificate=0A= vending machines in particular? Given that other vending machines trusted = by=0A= Mozilla have done all manner of bad things (selling certs to phishers and= =0A= other criminals, selling certs for things like apple.com to multiple people= =0A= who asked for them, selling thousands upon thousands of certs for internal,= =0A= unqualified, and RFC 1918 domains/addresses, etc), why the hostility direct= ed=0A= at these two? They're vending machines like any others, and what they did= =0A= seems to be genuine slip-ups rather than, for example, supplying certs to= =0A= Russian organised crime as other vendors have done.=0A= =0A= It seems like a second informal requirement for being in a browser, alongsi= de=0A= "Don't sell only a small number of certs" (to meet the TB2F criteria requir= ed=0A= by browsers if something goes wrong) is "Don't be Chinese or Arab/Persian/= =0A= Turkic". I don't know if any Russian/Byelorussian/Ukrainian/*stani vending= =0A= machines are present in browsers, but I'm guessing being one of those won't= be=0A= easy either.=0A= =0A= Peter.= From nobody Wed Mar 25 20:56:23 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 43FDA1A7004 for ; Wed, 25 Mar 2015 20:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 cn0O7cChkKsw for ; Wed, 25 Mar 2015 20:56:21 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 9CB1F1A6F5D for ; Wed, 25 Mar 2015 20:56:20 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so32094311lbc.2 for ; Wed, 25 Mar 2015 20:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7s4JJ8UpirznzOq/gQi4qc5B5+E4yb/LbC9XSwaDlZU=; b=rzV82OkzBPg4PY37sdbD9wLDNEkqg2sRWjOG5hjZYifdAoaG9QZnst2VbZKWWp7+Sw eg8Tv8EHVeYOPcZ73D74JdHxZ5ZPTFKcbyxs/kPyZdnoJHZjsiKJFZIwoRSURNeAGR0Q CSm7XasW5pgyuNu9QLFsC0gL2AT6gpt3BUL0jH3ivnTGQgtzkSRpES1HZ7eFpAIbG4c5 LdtfrM2p+NQxpkvUGQD+gAAF8mxUr7W9JsBO7e9Ba2gdhfbz9AU2YPyGxRuygWXSkle3 k0AHx83HGikIRgeF6wxwGG3z9Q+yx4wbwPc08EfsgRzIfqGEzQYF8qh6z9LADQWMT9RA Zbfw== MIME-Version: 1.0 X-Received: by 10.152.206.7 with SMTP id lk7mr11579710lac.55.1427342178999; Wed, 25 Mar 2015 20:56:18 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Wed, 25 Mar 2015 20:56:18 -0700 (PDT) In-Reply-To: References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> Date: Wed, 25 Mar 2015 22:56:18 -0500 X-Google-Sender-Auth: -Dciq_ILcHFfmBU3raDcD_UPsy4 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 03:56:22 -0000 On Wed, Mar 25, 2015 at 7:44 PM, Tim Bray wrote: > You guys are taking it as axiomatic that a high-quality UX can't be provided > for users of OpenPGP. Used OpenKeychain recently? Not quite there yet, but > I think your axiom is looking a little shaky. Certainly not me. PrismProof email makes S/MIME completely frictionless in use by essentially grafting the PGP fingerprint trust model onto S/MIME. I think the idea that we are going to get anywhere by pointing to the faults in opposing systems is also flawed. S/MIME and PGP have both suffered from lousy usability because the original trust models simply don't work. X.509 is fine as a certificate format, but there is no key discovery infrastructure until deployment of X.500 is complete. Web of Trust is a fine academic theory but it is not how OpenPGP is really used in the real world. The lesson here that I draw is to look at how people are actually using OpenPGP in practice and work out ways to apply the same approach to other similar problems. I do use one trick I borrowed from TimBL, take all the information you need to establish a connection and smoosh it together in one identifier: AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB?alice@example.com But more recently, I have been playing about with games similar to .onion: alice@example.com._AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB http://example.com._AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB/ OK, so what is going on here? Well we have a fingerprint as the rightmost (i.e. most important) item in the DNS identifier. Which means 'require a signed security policy describing how to interact with the identifier to the left.' So if you want to send email to alice@example.com, do so under a security policy that is signed under a key with the fingerprint AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB. That security policy could say something like 'use PGP encryption to this key'. One of the things OpenPGP proves is that we can quite easily build an infrastructure that maps from a fingerprint to a security policy. But one of the major changes since BaL and David and co put the MIT PGP server together, the Harber-Stornetta patents have expired and we now have better options like TRANS (or the BitCoin blockchain without the need to wade through treacle). From nobody Wed Mar 25 21: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 656A81A9096 for ; Wed, 25 Mar 2015 21:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w0k-C7dNtJtM for ; Wed, 25 Mar 2015 21:25:54 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4C41A9080 for ; Wed, 25 Mar 2015 21:25:54 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 8E6D85FC1B for ; Thu, 26 Mar 2015 04:25:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id lG9oPytSQIzG for ; Thu, 26 Mar 2015 04:25:50 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Thu, 26 Mar 2015 04:25:50 +0000 (UTC) Message-ID: <1427343948.23692.14.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 26 Mar 2015 05:25:48 +0100 In-Reply-To: References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-2qRIxHyoX8ud3mRnQ0oz" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 04:25:56 -0000 --=-2qRIxHyoX8ud3mRnQ0oz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-03-25 at 22:56 -0500, Phillip Hallam-Baker wrote:=20 > Web of Trust is a fine academic > theory but it is not how OpenPGP is really used in the real world. Lol? How else do you use it?=20 > The lesson here that I draw is to look at how people are actually > using OpenPGP in practice and work out ways to apply the same approach > to other similar problems. Well if your goal is to drop the WoT respectively simply let people download stuff from a (secured or not) keyserver believing whatever comes and hoping the best,... then better call it something else (InsecurePGP?) and leave OpenPGP as is. Cheers. --=-2qRIxHyoX8ud3mRnQ0oz Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjA0MjU0 OFowTwYJKoZIhvcNAQkEMUIEQMk/mPTTGJzgZs1Xz4YKthIoVrkyR0EvvVh7QeenB916ghvvpJI+ Vpp8bV/Soy7MgHU0kDcd0xRmXn2rwy2oALowagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBlc0T8seE6RRtRroHJ6tDu1M6xrwmu bTADFnfpVBCyAFbc4Uo18oso4We89FI6LI3YsnD6JERZoeVoYN3eCyOcprbqqwguyaH/g40iyETS 9jf9lK8yGIMe8ZzsQ9IKBJe1GBntdQaziauUIvj+vYksopTSrtT+9mtZJ6G3R9Jm152jgkyWKhWl 5sgZFM5+phISspS2I8yi/k1L/bItH6djb0QoWguUgK24nP9aNE5dD7hofEdyxxThY4q9IkGX3Qad W5IF2mLcSx6IurAD/gN1g94a/4MYEdpAUFsOtmvA9+Z7dC3mYWnuMLQnE4qgdyDZsSBI/PT/Zd76 PcGc9Mw3AAAAAAAA --=-2qRIxHyoX8ud3mRnQ0oz-- From jek@iflig.ininx.com Wed Mar 25 23:42:45 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 474A21B2C00 for ; Wed, 25 Mar 2015 23:42:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Date" X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, INVALID_DATE=1.096, T_RP_MATCHES_RCVD=-0.01] 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 FzknZJtZkrJx for ; Wed, 25 Mar 2015 23:42:44 -0700 (PDT) Received: from iflig.ininx.com (ininx.com [66.159.196.94]) (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 5D3A91ACDC7 for ; Wed, 25 Mar 2015 23:42:44 -0700 (PDT) Received: from jek by iflig.ininx.com with local (Exim 4.84) (envelope-from ) id 1YaQEK-0008Vx-0t; Wed, 25 Mar 2015 23:42:43 -0700 Date: Wed, 25 Mar 2015 23:42:36 -0700 From: John Kreznar To: openpgp@ietf.org References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> Date: Wed, 25 Mar 2015 23:42:36 -0700 In-Reply-To: <1427343948.23692.14.camel@scientia.net> (Christoph Anton Mitterer's message of "Thu, 26 Mar 2015 05:25:48 +0100") Message-ID: <87y4mkuun7.fsf@ivtd4.ininx.pvt> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 07:08:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Anton Mitterer writes: > On Wed, 2015-03-25 at 22:56 -0500, Phillip Hallam-Baker wrote: >> Web of Trust is a fine academic >> theory but it is not how OpenPGP is really used in the real world. > Lol? > How else do you use it? Speaking as a PGP user of over 20 years, I can say that I've NEVER used the web of trust. The way I really use it is to exchange keys with a correspondent in plain text and confirm fingerprints out of band. - -- OpenPGP key: http://ininx.com John E. Kreznar jek@ininx.com 9F1148454619A5F08550 705961A47CC541AFEF13 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.9 iEYEARECAAYFAlUTqg0ACgkQYaR8xUGv7xMMrwCfXjXwCT0Lhn18V7yfR6oHgnoT BFIAnREq3zSbIZrgrrLyh/NLFPMQOMMN =2Ech -----END PGP SIGNATURE----- From nobody Thu Mar 26 03:16:30 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 A22C71ACE30 for ; Thu, 26 Mar 2015 03:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 IoFTWxNAHmLz for ; Thu, 26 Mar 2015 03:16:26 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940401ACE2B for ; Thu, 26 Mar 2015 03:16:26 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yb4ps-00032I-TS for ; Thu, 26 Mar 2015 11:16:24 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yb4lj-0004ya-6f; Thu, 26 Mar 2015 11:12:07 +0100 From: Werner Koch To: Christoph Anton Mitterer References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.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 Date: Thu, 26 Mar 2015 11:12:06 +0100 In-Reply-To: <1427343948.23692.14.camel@scientia.net> (Christoph Anton Mitterer's message of "Thu, 26 Mar 2015 05:25:48 +0100") Message-ID: <87fv8sgj9l.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] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 10:16:28 -0000 On Thu, 26 Mar 2015 05:25, calestyo@scientia.net said: > Well if your goal is to drop the WoT respectively simply let people The OpenPGP protocol does not specify any trust model. It provides just the features to build a PKI. Some use the WoT, others build a X.509 alike system, some do not care at all, or use an ssh like non-PKI. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Mar 26 06:32:31 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 ECD631A1A0B for ; Thu, 26 Mar 2015 06:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 VZGVPSPFLnSb for ; Thu, 26 Mar 2015 06:32:28 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (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 51B031A897E for ; Thu, 26 Mar 2015 06:32:28 -0700 (PDT) Received: by lagg8 with SMTP id g8so45473771lag.1 for ; Thu, 26 Mar 2015 06:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LmXLacnd7JrW9YLbGuQ9OGCxgNTdgePdXHkiFxhPw3c=; b=XNRLj5VFM5FoBHPY+c79VbHHiTtTnBpTAXo2+edjCudPugS0BsXxNDE3ZV0H5Dsw5P z69QyG+2uSIfH74z6ble081degzl6UXHLPZmWSNBybc5lQDPfgF9Wf/jFYnQ8dSPEVX2 TNpDpNk1Hd9LId18nzmA9MhXIHKj2KaMPUFeSc/kiRgpwHJmdtJve1rcNgImFbnZrCXY pYBAsEWFVyOA3Ym3LeNDKA88AqcVsS8sSBdWKUwKzY6nPnKrBjwoS0+S29ZKO8ltfV3I W6PIYd8fZGWzPYPzW09HOmHzm23InrroqtqsyILV4s2GZ1oHlmxmlv6seXMDgX6GzIfl Zt6w== MIME-Version: 1.0 X-Received: by 10.112.151.226 with SMTP id ut2mr13492849lbb.55.1427376746694; Thu, 26 Mar 2015 06:32:26 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Thu, 26 Mar 2015 06:32:26 -0700 (PDT) In-Reply-To: <1427343948.23692.14.camel@scientia.net> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> Date: Thu, 26 Mar 2015 03:32:26 -1000 X-Google-Sender-Auth: ZncUFck9-ny1-B1jXAYZniEQaZI Message-ID: From: Phillip Hallam-Baker To: Christoph Anton Mitterer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 13:32:30 -0000 On Wed, Mar 25, 2015 at 6:25 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-03-25 at 22:56 -0500, Phillip Hallam-Baker wrote: >> Web of Trust is a fine academic >> theory but it is not how OpenPGP is really used in the real world. > Lol? > How else do you use it? I see people using fingerprints directly mostly. Some download them from key servers. By Web of Trust I mean actually following a chain to check a key. >> The lesson here that I draw is to look at how people are actually >> using OpenPGP in practice and work out ways to apply the same approach >> to other similar problems. > Well if your goal is to drop the WoT respectively simply let people > download stuff from a (secured or not) keyserver believing whatever > comes and hoping the best,... then better call it something else > (InsecurePGP?) and leave OpenPGP as is. No, I think there are quite a few things that we can do today that change the WoT game. People carry smart phones with near field communication, barcode, cameras. So signing can be made a lot simpler. Another very important and useful development is Certificate transparency which has the effect of making the work factor for spoofing a key a suddenly go to practically infinity. Another resource to bring to bear is social networking And yet another is CA issued. If you want to know that someone is sending a message from the US gvot or a company that is organized in hierarchical fashion, a hierarchical PKI makes sense. I describe a hybrid approach in some detail with a mechanism for comparing trust models in terms of a 'social work factor' here: http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-01 From nobody Thu Mar 26 07:07:25 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 574DE1A88C8 for ; Thu, 26 Mar 2015 07:07:23 -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 Y1CZ40qXrdX0 for ; Thu, 26 Mar 2015 07:07:21 -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 56BBE1A8700 for ; Thu, 26 Mar 2015 07:07:21 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id F2A736D787; Thu, 26 Mar 2015 10:07:19 -0400 (EDT) Message-ID: <55141296.5050206@iang.org> Date: Thu, 26 Mar 2015 14:07:18 +0000 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] On Streaming and Chunking 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, 26 Mar 2015 14:07:23 -0000 On 24/03/2015 12:25 pm, Tom Ritter wrote: > Adam's post on streaming API's has been posted before: > https://www.imperialviolet.org/2014/06/27/streamingencryption.html > > The same problem is the root cause of the Java GCM CipherInputStream > issue: http://blog.philippheckel.com/2014/03/01/cipherinputstream-for-aead-modes-is-broken-in-jdk7-gcm/ > > But I haven't seen any discussion of Adam's point that one _can_ > construct a format for chunking and authenticating the chunks (and > ordering thereof) to provide authenticated streaming. And that someone > has already done so: > https://github.com/kaepora/miniLock#4-file-encryption > > I think support for a mode like this would be good to consider, and I > think if IPR allows it, a fully-specified design for it is a good > place to start. Part of the problem here is that there are a few too many moving parts. One moving part in particular is the interface design. It has been an article of faith for a long time that the crypto libraries should deliver to the application a CIPHER metaphor, and that's good enough for any programmer. And a MAC metaphor. And a MODE metaphor. Which has gradually morphed into a CIPHER/MODE/MAC metaphor. Instead it would be better if the crypto library delivered a PROTOCOL metaphor. For an example of this, look to djb's cryptobox. It delivers a complete arrangement for doing authentication using private/public keypairs. I do something similar, I call them Cryptors or Bees, to indicate they do "stuff" that isn't amenable to any easy boxing. Part of the fight against this move up the stack is the 'standardisation' argument, but this is only partially correct. It is entirely possible to standardise around djb's example. Just uncomfortable for some. Now, with this in mind, why does this cause a problem? Well, as there is more and more cruft added into the Java Cipher class, it is inevitable that they are going to get it wrong at some point. Taking from the above links: Cipher c = Cipher.getInstance("AES/GCM/NoPadding", "BC"); That's just an open door for trouble, it's the cryptoplumbing equivalent of a goto. iang ps; I'm not entirely convinced I have the above argument fulsome and correct. It's a sort of evolving critique against crypto libraries, there is something there/wrong, and I'm slowly trying to tease out what it is. From nobody Thu Mar 26 12:46:30 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 E68721A8776 for ; Thu, 26 Mar 2015 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 9cgd81Ck84qY for ; Thu, 26 Mar 2015 12:46:27 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A77981B2DF7 for ; Thu, 26 Mar 2015 12:46:19 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D84A5165972; Thu, 26 Mar 2015 19:46:18 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id CD7F2165971; Thu, 26 Mar 2015 19:46:18 +0000 (GMT) Received: from Tereva.local (unknown [172.19.112.199]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 4BEEC9803E; Thu, 26 Mar 2015 19:46:18 +0000 (GMT) From: Brian Sniffen To: Phillip Hallam-Baker , Christoph Anton Mitterer In-Reply-To: References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-apple-darwin14.0.0) Date: Thu, 26 Mar 2015 14:46:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 19:46:29 -0000 Phillip Hallam-Baker writes: > On Wed, Mar 25, 2015 at 6:25 PM, Christoph Anton Mitterer > wrote: >> On Wed, 2015-03-25 at 22:56 -0500, Phillip Hallam-Baker wrote: >>> Web of Trust is a fine academic >>> theory but it is not how OpenPGP is really used in the real world. >> Lol? >> How else do you use it? > > I see people using fingerprints directly mostly. Some download them > from key servers. > > By Web of Trust I mean actually following a chain to check a key. I walked a colleague through doing that today: she needs to send me a secret, and I can't take time to call her and read a fingerprint. Fortunately, my key had been signed by many other colleagues, and she had trusted keys from a few of them. It worked exactly as designed. It's similarly helpful for new peole joining that group---new staff, in that case. This is just an anecdote, of course, but so is "I have never...". I expect there are little cells of WoT usage scattered around, and little cells of blind trust, and little cells of read-the-fingerprint---when strangers meet. > No, I think there are quite a few things that we can do today that > change the WoT game. People carry smart phones with near field > communication, barcode, cameras. So signing can be made a lot simpler. I would be interested to see a tag on keysignatures. That would let me play with automatic signatures and such without polluting the WoT. I don't directly see how to do this---is this what "Key Endorsements" are for in ? Thanks, Brian -- Brian Sniffen "I reserve the right to evolve my views, and state that views I previously expressed may have been somewhere along the spectrum from insufficiently nuanced through ill-informed to dead wrong." From nobody Thu Mar 26 13:54:59 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 D9A7B1B2F16 for ; Thu, 26 Mar 2015 13:54:57 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 6SkU8rC-xC71 for ; Thu, 26 Mar 2015 13:54:52 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 44A821B2F13 for ; Thu, 26 Mar 2015 13:54:52 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YbEni-0004R8-QC; Thu, 26 Mar 2015 16:54:51 -0400 Date: Thu, 26 Mar 2015 13:54:49 -0700 From: Bill Frantz To: John Kreznar X-Priority: 3 In-Reply-To: <87y4mkuun7.fsf@ivtd4.ininx.pvt> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec793830ceb0790a5db07044179b3cbe4640350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 20:54:58 -0000 On 3/25/15 at 11:42 PM, jek@ininx.com (John Kreznar) wrote: >Christoph Anton Mitterer writes: > >>On Wed, 2015-03-25 at 22:56 -0500, Phillip Hallam-Baker wrote: >>> Web of Trust is a fine academic >>> theory but it is not how OpenPGP is really used in the real world. >>Lol? >>How else do you use it? > >Speaking as a PGP user of over 20 years, I can say that I've NEVER used >the web of trust. The way I really use it is to exchange keys with a >correspondent in plain text and confirm fingerprints out of band. I used the WoT once to validate a key. The key I validated was=20 my own. I was at work, and my key was at home and on a key=20 server. I wanted to send some company confidential data home, so=20 I down loaded my key from the key server. My key had been signed=20 by Carl Ellison, and I had a copy of Carl's business card with=20 his key fingerprint. I check the fingerprint against Carl's=20 signature, and had enough faith in my own key to use it. Life does bring up some strange uses. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"We used to quip that "password" is the most common 408-356-8506 | password. Now it's 'password1.' Who said=20 users haven't www.pwpconsult.com | learned anything about security?" -- Bruce Schneier From nobody Thu Mar 26 13:59:07 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 B17821B2EF9 for ; Thu, 26 Mar 2015 13:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 fc-tHSdLuUDM for ; Thu, 26 Mar 2015 13:59:03 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 BFD1B1B2F1A for ; Thu, 26 Mar 2015 13:58:59 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so50111072lbc.2 for ; Thu, 26 Mar 2015 13:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8b9YlwC4dFE/DuPAlx/AZf8dbEukTd4qVtgwQRvEaoY=; b=S0zyFLxR/Dgd6Jxcr1NTthrIFpSMAZSyJ2cHkNc/Vi8cEYgi9+pn7lXpR77tzNUv5m pVSmK9mbpPzncI3KxkraQw0fpTCvR0U7qMjzH8c9WgDgB71tif7sdbCj3LkS0kmS8kbM jsvCilTzU0IySUTgqMFozDTNAQYH2sQh4sHKv2ZoyegSQxdFfWwuL9ZUGK+KHP0ZgIwc PioirNEzrCa5X/sR8IuO/80lHzlAamF1/PUvZoP4YbNfCKbxcW6M1moA4A7d4zoCCLMq FbU4bArQOuWShCXsgdSjuogrPXFukeec14Ucz1AklUXrULVzFa+Af8NVqaTKp9yFwGkR 56KA== MIME-Version: 1.0 X-Received: by 10.153.4.135 with SMTP id ce7mr14653987lad.91.1427403538260; Thu, 26 Mar 2015 13:58:58 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.45.203 with HTTP; Thu, 26 Mar 2015 13:58:57 -0700 (PDT) In-Reply-To: References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> Date: Thu, 26 Mar 2015 15:58:57 -0500 X-Google-Sender-Auth: 30BMs8L4Ccg2LVb1QZ-DOA4etNg Message-ID: From: Phillip Hallam-Baker To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 20:59:04 -0000 On Thu, Mar 26, 2015 at 2:46 PM, Brian Sniffen wrote: > Phillip Hallam-Baker writes: > >> On Wed, Mar 25, 2015 at 6:25 PM, Christoph Anton Mitterer >> wrote: >>> On Wed, 2015-03-25 at 22:56 -0500, Phillip Hallam-Baker wrote: >>>> Web of Trust is a fine academic >>>> theory but it is not how OpenPGP is really used in the real world. >>> Lol? >>> How else do you use it? >> >> I see people using fingerprints directly mostly. Some download them >> from key servers. >> >> By Web of Trust I mean actually following a chain to check a key. > > I walked a colleague through doing that today: she needs to send me a > secret, and I can't take time to call her and read a fingerprint. > Fortunately, my key had been signed by many other colleagues, and she > had trusted keys from a few of them. It worked exactly as designed. Hey, S/MIME works fine with the 'call a friend' option as well :-) If we could get PGP up to critical mass then the web of trust is potentially a 'viral marketing' feature. Until we reach critical mass, viral marketing means 'chicken and egg'. As far as OpenPGPvnext goes, I would focus first on getting the message and fingerprint formats revised and seeing what we can do to eliminate 'needless' variation between S/MIME and OpenPGP. Back when I was working on the Web at CERN I told Tim Berners-Lee that we should kill the SGML bit and write our own document format language. At that point we had about a million users. Tim replied that the reason he adopted SGML was because he wanted to get buy in from the publishing industry and they were committed to SGML. So I should implement X.509(!) At this point we can tolerate two message formats. But remember that any mail encryption scheme that can emit CMS can send an encrypted message to 1 billion email users using their existing clients. So even though I despise ASN.1, I will write code that will do just that. And come to that it seems most OpenPGP implementations have as well. > It's similarly helpful for new peole joining that group---new staff, in > that case. This is just an anecdote, of course, but so is "I have > never...". I expect there are little cells of WoT usage scattered > around, and little cells of blind trust, and little cells of > read-the-fingerprint---when strangers meet. The draft I mentioned earlier describes an approach to joining those cells up together. >> No, I think there are quite a few things that we can do today that >> change the WoT game. People carry smart phones with near field >> communication, barcode, cameras. So signing can be made a lot simpler. > > I would be interested to see a tag on keysignatures. That would let me > play with automatic signatures and such without polluting the WoT. I > don't directly see how to do this---is this what "Key Endorsements" are > for in > ? Yep, I don't actually rate a keysignature as being worth anything until it is enrolled in a TRANS like log. There are some really fun things we could do in future on the trust model side. But I think we need to decruft the base OpenPGP first. From nobody Thu Mar 26 16:58:31 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 B7D1A1A86FA for ; Thu, 26 Mar 2015 16:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RUscztjmRpcR for ; Thu, 26 Mar 2015 16:58:27 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDD11A700F for ; Thu, 26 Mar 2015 16:58:27 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id DC67E5FC38 for ; Thu, 26 Mar 2015 23:58:25 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id MjNySRLVsg8y for ; Thu, 26 Mar 2015 23:58:24 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Thu, 26 Mar 2015 23:58:24 +0000 (UTC) Message-ID: <1427414303.24976.2.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Fri, 27 Mar 2015 00:58:23 +0100 In-Reply-To: <87fv8sgj9l.fsf@vigenere.g10code.de> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> <87fv8sgj9l.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-G3vmWw20B3fLfuwWx0xZ" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 26 Mar 2015 23:58:29 -0000 --=-G3vmWw20B3fLfuwWx0xZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-03-26 at 11:12 +0100, Werner Koch wrote:=20 > The OpenPGP protocol does not specify any trust model. It provides just > the features to build a PKI. Some use the WoT, others build a X.509 > alike system, some do not care at all, or use an ssh like non-PKI. Sure, I primarily meant, "if the goal is to modify OpenPGP such way, that what we can do now is no longer possible" :) Cheers, Chris. --=-G3vmWw20B3fLfuwWx0xZ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjIzNTgy M1owTwYJKoZIhvcNAQkEMUIEQA2jWyWSi9vSeAIc0xxtO4mochqKXqof1yFkpvvTE+TdzDJxojg4 E3w4pdzrb2Kd2CrRdqkRGbtFYy/sDyT5fQUwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAEspRAo8KJYKM68Jp+9QLxgRNmfj+z Xlua7b0to6u+usQLm9LvB/OhmxgTPCmNGmpX92Z/bbGLXF2qkMsp0JocYPtn04577xN+5lgUlCVx WVtjHD7fZLEDDZZ1WIwyeIdqiQF5LxfK2e6YDt5+B3gewl+m+JwAjv7s9MK8ubVW1Fy34ytupXK/ GjK17gN7ajdHhOAsx4SKAEuIviwEUlYqfwcAXgsFYqKHzFvXDuGSQ3cEV9rpXn1MOcgYgeo+OFV2 Jgj2FrMsN2C+49828PT4VVxKBXmRo7Ap9jL8V0CTxV0/S9591p32cUN9PkqLGyYTh1ut0BEgUmwt jWYkpeyCAAAAAAAA --=-G3vmWw20B3fLfuwWx0xZ-- From nobody Thu Mar 26 17:04:49 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 CD7501A8725 for ; Thu, 26 Mar 2015 17:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0h0FBJumZqDP for ; Thu, 26 Mar 2015 17:04:46 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75BB1A1A5F for ; Thu, 26 Mar 2015 17:04:45 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id C6AAB5FBC5 for ; Fri, 27 Mar 2015 00:04:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id xWY2ANpkvhHP for ; Fri, 27 Mar 2015 00:04:42 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Fri, 27 Mar 2015 00:04:42 +0000 (UTC) Message-ID: <1427414682.24976.8.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Fri, 27 Mar 2015 01:04:42 +0100 In-Reply-To: References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-uOURkRcfYL2BCkL8rz42" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Manifesto - who is the new OpenPGP for? 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, 27 Mar 2015 00:04:48 -0000 --=-uOURkRcfYL2BCkL8rz42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-03-26 at 03:32 -1000, Phillip Hallam-Baker wrote:=20 > By Web of Trust I mean actually following a chain to check a key. Okay, probably we were using different understandings of "Web of Trust". Admittedly I used it a bit wrong either, typically I mean a fully meshable relation system, which allows basically anything what the user want's to do: - from the classic WoT, where trust is achieved indirectly (which I still think is important, e.g. in communities like Open Source projects, or for people who'd have gazillions of contact partners (Linus)) - the direct mutual signing, for best security/trust - something more similar to X.509, e.g. via trust sigs. > No, I think there are quite a few things that we can do today that > change the WoT game. People carry smart phones with near field > communication, barcode, cameras. So signing can be made a lot simpler. Well I guess that should be free to the user what he actually wants to do. I personally wouldn't really trust anything a smartphone did. ;) But this seems to be anyway pretty much out of the scope of the standard?! Cheers, Chris. --=-uOURkRcfYL2BCkL8rz42 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNzAwMDQ0 MlowTwYJKoZIhvcNAQkEMUIEQGE9KC1Rbv0WnC37JNJ0pG9UzyFgSIoK7Wksnly6dl2Ivp/eTfN2 3ifHpCeS0ehRQABpnB/Ma3IiszcsheoM5cswagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQALWStGdG0F5EIuzmhkowASrXQXx3Zm 16Gh13xPpnFQuYK69cyo4WbIpdeUG1GjR1k/RIQcmVcJdYERQZ+FDKEGdSavM50Jnq1NX9fZng6k 3TVfZGR3ATjsq2jeWnKkW4ZKroG5NEn4QydLSDOJGvxLIgtfHyihZfGmq+bzy/oZLTI5I9oLLVoX cJkpk8srbKF8IKbu+O7XqGEzFD+4EXJKAsNtHTkowf347hnHdjUOQbXX8CB+kE1a4x2Z6Ga1IopU xrZQSCWi919QvtWXa1LDWnqtIh+Z5vFi1h9CdRUds+f2Rz7Fj1dAgPLKJGSfW1OlkyjhMiAR7Pkn i+jmtCEFAAAAAAAA --=-uOURkRcfYL2BCkL8rz42-- From nobody Thu Mar 26 17:14:05 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 17DC41A879A for ; Thu, 26 Mar 2015 17:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lMONJqXDEZUX for ; Thu, 26 Mar 2015 17:14:02 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9ABF1A878B for ; Thu, 26 Mar 2015 17:14:00 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw02.dd24.net (Postfix) with ESMTP id 75EF95FB52 for ; Fri, 27 Mar 2015 00:13:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id ZxajBTeOub4U for ; Fri, 27 Mar 2015 00:13:57 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Fri, 27 Mar 2015 00:13:57 +0000 (UTC) Message-ID: <1427415236.24976.13.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Fri, 27 Mar 2015 01:13:56 +0100 In-Reply-To: <55134455.2070606@iang.org> References: <878uf2iehi.fsf@vigenere.g10code.de> <5510C26E.7070409@iang.org> <87mw32omzs.fsf@vigenere.g10code.de> <55134455.2070606@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-YjNaaPRKV2chOT2kjEfn" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] How to re-launch the OpenPGP WG 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, 27 Mar 2015 00:14:04 -0000 --=-YjNaaPRKV2chOT2kjEfn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-03-25 at 23:27 +0000, ianG wrote:=20 > SHA3 because it has sponge, it can do MACs, it can do stream ciphers, it= =20 > can do authenticated stream ciphers, it can brew the morning tea if you= =20 > plug it in the right way. +1 > Here's my big criticism of the IETF process: like all processes it=20 > eventually ends up becoming a place for people to create silos of=20 > knowledge and careers, and eventually divorces itself from what's=20 > happening out there in the real world. But it holds the keys to some=20 > powerful Internet protocol components, and while it's not bringing in=20 > the new, outside knowledge, the IETF WG becomes the blockage, the inner= =20 > sanctum, the guilds that the IETF swore to bring down. >=20 > So what do we do? Leave? Stay? Fight? So do you have any better proposal idea? Anything more governmental (ISO, national standardisation bodies) or more commercial (ECMA) would IMHO be quite bad (since they're all known to be rather on the dark side of the force, and while they may have cookies, it's probably not what we should want). Not much is left the in the free/community world.... W3? Far too much in committee mode either, far to easily influenced by big players (see the whole HTML5 DRM stuff). Doing it independently... doesn't seem appealing either. I'd say IETF is quite the right place. Cheers, Chris. --=-YjNaaPRKV2chOT2kjEfn Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNzAwMTM1 NlowTwYJKoZIhvcNAQkEMUIEQCn9nf6rTqsa81dAaobC5hOi5EtwPl21E3Qa2GIHkzX2wUUPb8CT JNi/ZM6hjmEM7U9aeftkKd6T21vZJ+kI6OAwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAscUXf55W48RZ6os6CyQsWH4x0yE7m U00DvQSEf6jQKszK94li+f8kd+A1w0ATB9eJDy1gV/pPP8FpqA7pCaaTth/hVIr1SQUuAK3g5pl3 lsCnjLzXOT/xAVSYQgvMNfDzptyUpVt3+TnYeD1BeSoCgo7F/2H5GI1acuvOCeHXTWMoFOlR0VYa 22g30t2EvrEeeKJLG71LFyM0tSky74BzJwfKiCcfDZBXsZi9cgRaUAlbROrSFtj9eHBdq2U1wvpg AVqjQPrD5fgQUag+uj+LgnT64HarXwsg/YCqY9CLAEIxHlNvt4j8YibvNvRwUQP3FODgZzBDp/5J RkeAzTNfAAAAAAAA --=-YjNaaPRKV2chOT2kjEfn-- From nobody Thu Mar 26 17:15:55 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 B25461A8794 for ; Thu, 26 Mar 2015 17:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 l0K7KNAVTE0q for ; Thu, 26 Mar 2015 17:15:52 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631331A8782 for ; Thu, 26 Mar 2015 17:15:52 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 429135FC21 for ; Fri, 27 Mar 2015 00:15:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id j31lpRyQ8Y7Y for ; Fri, 27 Mar 2015 00:15:49 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for ; Fri, 27 Mar 2015 00:15:49 +0000 (UTC) Message-ID: <1427415349.24976.16.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Fri, 27 Mar 2015 01:15:49 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-DiaWK023mP2wRC8GBgSA" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Encrypting / Signing the mail subject? 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, 27 Mar 2015 00:15:53 -0000 --=-DiaWK023mP2wRC8GBgSA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A late comment on that:=20 > "X-Protected-Headers" Didn't IETF somewhere deprecate the usage of "X-"? Cheers, Chris --=-DiaWK023mP2wRC8GBgSA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNzAwMTU0 OVowTwYJKoZIhvcNAQkEMUIEQKJlh7JfZW+co0HRgjJXjEXpG63+fnexP1Gbnh6L5juQ6ZjWCBkB zzpFjorIX/BsEzns4Tc2GUw6koBph+UXFlwwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAhFcwp+sFNVwmLrScN0VizCgHMR8c5 YsUXq6icWm133BEsVS6DuEMB1ptAjokrQTz9yhbh59EJTR0TZXHHi0eHUTOMTYSooshr4u9dT6XV yOwv7qU0PJOvy1T1AY+7uLj8urLC3DjnM27VzoneWvugpKOA5CXyIOrG7nc3tMwvrbcNYFF38KuO BuYks2q/YvjTvdaKfUPSxdPCg9NEcKOaI9zHvcoF2Fhfq8oUwxgJi+N9uF9peDVmo3vU/8XBvk7b 4/8SBeSmvGmo3io+Kp3WegX3Earp6RQrNVDEn965hwe1ABvx/WaEXuWMYZnul1z7LFoylHejfnrL NzMZUwK0AAAAAAAA --=-DiaWK023mP2wRC8GBgSA-- From nobody Thu Mar 26 18:04: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 9D2ED1A0163 for ; Thu, 26 Mar 2015 18:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 vkTBGTOj4ni6 for ; Thu, 26 Mar 2015 18:04:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB6B1A00CD for ; Thu, 26 Mar 2015 18:04:18 -0700 (PDT) Received: from dhcp-b355.meeting.ietf.org (dhcp-b355.meeting.ietf.org [31.133.179.85]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2R14H6E024298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Mar 2015 18:04:18 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <1427415349.24976.16.camel@scientia.net> References: <1427415349.24976.16.camel@scientia.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----SIHPLW4KX32UNOPYQO7Z42R5WZ7P70" Content-Transfer-Encoding: 8bit From: Dave Crocker Date: Thu, 26 Mar 2015 20:04:15 -0500 To: Christoph Anton Mitterer , openpgp@ietf.org Message-ID: <3F19BC1C-DA2F-4946-B8A2-9BE539704F24@dcrocker.net> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 26 Mar 2015 18:04:18 -0700 (PDT) Archived-At: Subject: Re: [openpgp] Encrypting / Signing the mail subject? 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, 27 Mar 2015 01:04:20 -0000 ------SIHPLW4KX32UNOPYQO7Z42R5WZ7P70 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 On March 26, 2015 7:15:49 PM CDT, Christoph Anton Mitterer wrote: >A late comment on that: >> "X-Protected-Headers" >Didn't IETF somewhere deprecate the usage of "X-"? > >Cheers, >Chris > > >------------------------------------------------------------------------ > >_______________________________________________ >openpgp mailing list >openpgp@ietf.org >https://www.ietf.org/mailman/listinfo/openpgp Yes. d/ -- D. Crocker bbiw.net via mobile ------SIHPLW4KX32UNOPYQO7Z42R5WZ7P70 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On March 26, 2015 7:15:49 PM CDT, Christoph Anton Mitterer <calestyo@scientia.net> wrote:
A late comment on that: 
 "X-Protected-Headers"
Didn't IETF somewhere deprecate the usage of "X-"?

Cheers,
Chris


openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

Yes.

d/

--
D. Crocker
bbiw.net

via mobile ------SIHPLW4KX32UNOPYQO7Z42R5WZ7P70-- From nobody Fri Mar 27 03:38:04 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 D4C351ACD4A for ; Fri, 27 Mar 2015 03:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 fJPFUo_c90n1 for ; Fri, 27 Mar 2015 03:37:57 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F681ACD4B for ; Fri, 27 Mar 2015 03:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1427452678; x=1458988678; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=aSl/sZRfmZYaj9vdM9KJZ0PTdWYKXpE1DEtiueSLabM=; b=OZt8P7dHmZJLZn3VGQPFJ+Ciwo38h94ui9AWBD7OgKWfChH+SuuvY5a/ YCPGnXyeY0gOkn8JA+um2A9uDWG2U3sHEjI6UA+TjMjjEh4ZI7E2c9zEL Jxho/pvA4hJCazeTJPtIT1hTKscCwDdSECbsWrC+xA7kYOR7oXLzLpL5b M=; X-IronPort-AV: E=Sophos;i="5.11,478,1422874800"; d="scan'208";a="317281846" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Mar 2015 23:37:55 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Fri, 27 Mar 2015 23:37:53 +1300 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] On Streaming and Chunking Thread-Index: AdBoehQ4V4p8aftNSiG0CJGZhsjXXg== Date: Fri, 27 Mar 2015 10:37:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFC29AC@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] On Streaming and Chunking 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, 27 Mar 2015 10:38:02 -0000 ianG writes:=0A= =0A= >One moving part in particular is the interface design. It has been an=0A= >article of faith for a long time that the crypto libraries should deliver = to=0A= >the application a CIPHER metaphor, and that's good enough for any programm= er.=0A= >And a MAC metaphor. And a MODE metaphor. Which has gradually morphed int= o a=0A= >CIPHER/MODE/MAC metaphor.=0A= =0A= And one with the defaults set wrong. In Java, do a Cipher.getInstance("AES= ")=0A= and you get AES in ECB mode. To paraphrase a quote about C, "it gives you = a=0A= loaded gun and points it at your foot by default".=0A= =0A= Peter.= From nobody Sat Mar 28 10:41:46 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 E55601A899A for ; Sat, 28 Mar 2015 10:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 d5spcco_isDh for ; Sat, 28 Mar 2015 10:41:43 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD9C1A8997 for ; Sat, 28 Mar 2015 10:41:42 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id 0DD615FB49 for ; Sat, 28 Mar 2015 17:41:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id 4--budNPax9s for ; Sat, 28 Mar 2015 17:41:39 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-180-118.dynamic.mnet-online.de [188.174.180.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for ; Sat, 28 Mar 2015 17:41:39 +0000 (UTC) Message-ID: <1427564498.4912.1.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Sat, 28 Mar 2015 18:41:38 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-WyA269DWqjOBcjjz+zOa" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Encrypting / Signing the mail subject? 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, 28 Mar 2015 17:41:45 -0000 --=-WyA269DWqjOBcjjz+zOa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2015-03-28 at 15:19 +0100, Albrecht Dre=C3=9F wrote: > And, yes, I missed RFC 6648 which deprecates X-something headers - > maybe a "Comments:" header might be used instead of it? Just don't use a generic term like comments for anything which would be really machine-readed. That always causes troubles sooner or later. Cheers, Chris. --=-WyA269DWqjOBcjjz+zOa Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCEZIw ggW/MIIDp6ADAgECAgMCOakwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4x HjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMg Um9vdDAeFw0xNDA2MTIxNjM2MThaFw0xNjA2MTExNjM2MThaMHwxITAfBgNVBAMTGENocmlzdG9w aCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEw LwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4phP/j9vT9dZT+k3ffHxvRWMOuzBnu5O3Fl4y2+WL7pL rfLiEhWzGXhHvjSqpt4vCNSdqy43453nnu8+hMb+uEtqSIL1AHU5eLhuDNVN9S4bt9E7nA2WKYBU LCUi/xCD/GL7ToyJNwhrhzcCZ7pXSc3xVqFoC4f6weU9ExhoEZQNRpTM0BFCOi4fRxvKFNnUYgjK hqy0Ta5H0Xx86mAp0Q4dxoD7mhI5iTF6TRkUheELxF24JCuAf04M89Cwft6DRH1FpJ3yvgW2B5U5 aFSL4ZnF4N/wyCB7Dkm1rQ7RCAvw5btkf0VdPnU7ccDCx8HEc2nxK/lbCjrznvh3sa1CCwIDAQAB o4IBcDCCAWwwDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNl cnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYD VR0PAQH/BAQDAgOoMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYK KwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLmNhY2VydC5vcmcv Y2xhc3MzLXJldm9rZS5jcmwwRAYDVR0RBD0wO4EVY2FsZXN0eW9Ac2NpZW50aWEubmV0gSJtYWls QGNocmlzdG9waC5hbnRvbi5taXR0ZXJlci5uYW1lMA0GCSqGSIb3DQEBDQUAA4ICAQBefctiLgGl e5baspuozyA4k7Up7SVhGHbif6pQfoFc/9Thx9GXnYpX+U64PMyWBfWwHZIy52Vg0RVkvPi1t6mi GyBfoSpC6ooR0bKWtUIogw/ymqKWlTLVR8kbLqRmRk4juMtCXG2K3yMygX/rjkuUSuFj2Bjpkmzg CtMojbUMYbszePmhQ7DJ62YEdtKpcjN94QAsI5GWlIAbs3KJazAcaNCRJeXCLcUMchyKHJA+NXH5 az/ekBxBMBzJP2An20PP88UI4JW18z31KiG9UVGa2uO4l4aWgVe2GnhNEdCD/o48msJEWKAt5vl2 yMqr7ihmNPocU2+/FW0xPe/vftdOTD9pgXdSGf4prdD+23q2YvpalOCzr2p8yCJZNVBPMxAP4mL0 3OEktXza4wohqAmceXKfGUNwRGBaPvtIGnPrpLhCQ+2YJDg8g1UEsk23bKyZlJWeKJyVqOBsDJmj aBsN/qKhQFnav+zQdqGhMeaSisF/53mD3gyVYg2JRl18apgGbg32kyLmomqa0JbhnY3Dc3FVtZfe +P+s2Cyep3pVKvFer2llRoGm8TwraG5Yhyx8Oq/1qETpstjbURJOVBLDCV4AjOEUj0ZnE/tEo/DK yexgGaViNvjp+IZdFdJhYmsVjw4Q3vG7O0pfsLiYEyQjeDgjNEWDfa5/MufPywIfxzCCBb8wggOn oAMCAQICAwI5qTANBgkqhkiG9w0BAQ0FADBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UE CxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290MB4X DTE0MDYxMjE2MzYxOFoXDTE2MDYxMTE2MzYxOFowfDEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9u IE1pdHRlcmVyMSQwIgYJKoZIhvcNAQkBFhVjYWxlc3R5b0BzY2llbnRpYS5uZXQxMTAvBgkqhkiG 9w0BCQEWIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDimE/+P29P11lP6Td98fG9FYw67MGe7k7cWXjLb5Yvukut8uISFbMZ eEe+NKqm3i8I1J2rLjfjneee7z6Exv64S2pIgvUAdTl4uG4M1U31Lhu30TucDZYpgFQsJSL/EIP8 YvtOjIk3CGuHNwJnuldJzfFWoWgLh/rB5T0TGGgRlA1GlMzQEUI6Lh9HG8oU2dRiCMqGrLRNrkfR fHzqYCnRDh3GgPuaEjmJMXpNGRSF4QvEXbgkK4B/Tgzz0LB+3oNEfUWknfK+BbYHlTloVIvhmcXg 3/DIIHsOSbWtDtEIC/Dlu2R/RV0+dTtxwMLHwcRzafEr+VsKOvOe+HexrUILAgMBAAGjggFwMIIB bDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNh dGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8E BAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5j YWNlcnQub3JnMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9jbGFzczMt cmV2b2tlLmNybDBEBgNVHREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0 b3BoLmFudG9uLm1pdHRlcmVyLm5hbWUwDQYJKoZIhvcNAQENBQADggIBAF59y2IuAaV7ltqym6jP IDiTtSntJWEYduJ/qlB+gVz/1OHH0Zedilf5Trg8zJYF9bAdkjLnZWDRFWS8+LW3qaIbIF+hKkLq ihHRspa1QiiDD/KaopaVMtVHyRsupGZGTiO4y0JcbYrfIzKBf+uOS5RK4WPYGOmSbOAK0yiNtQxh uzN4+aFDsMnrZgR20qlyM33hACwjkZaUgBuzcolrMBxo0JEl5cItxQxyHIockD41cflrP96QHEEw HMk/YCfbQ8/zxQjglbXzPfUqIb1RUZra47iXhpaBV7YaeE0R0IP+jjyawkRYoC3m+XbIyqvuKGY0 +hxTb78VbTE97+9+105MP2mBd1IZ/imt0P7berZi+lqU4LOvanzIIlk1UE8zEA/iYvTc4SS1fNrj CiGoCZx5cp8ZQ3BEYFo++0gac+ukuEJD7ZgkODyDVQSyTbdsrJmUlZ4onJWo4GwMmaNoGw3+oqFA Wdq/7NB2oaEx5pKKwX/neYPeDJViDYlGXXxqmAZuDfaTIuaiaprQluGdjcNzcVW1l974/6zYLJ6n elUq8V6vaWVGgabxPCtobliHLHw6r/WoROmy2NtREk5UEsMJXgCM4RSPRmcT+0Sj8MrJ7GAZpWI2 +On4hl0V0mFiaxWPDhDe8bs7Sl+wuJgTJCN4OCM0RYN9rn8y58/LAh/HMIIGCDCCA/CgAwIBAgIB ATANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3 LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMTQwNzM2NTVaFw0zMzAzMjgwNzM2NTVa MFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcx HDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQCrSTURSHzSJn5TlM9Dqd0o10Iqi/OHeBlYfA+e2ol94fvrcpANdKGWZKufoCSZc9riVXbH F3v1BKxGuMO+f2SNEGwk82GcwPKQ+lHm9WkBY8MPVuJKQs/iRIwlKKjFeQl9RrmK8+nzNCkIReQc n8uUBByBqBSzmGXEQ+xOgo0J0b2qW42S0OzekMV/CsLj6+YxWl50PpczWejDAz1gM7/30W9HxM3u YoNSbi4ImqTZFRiRpoWSR7CuSOtttyHshRpocjWr//AQXcD0lKdq1TuSfkyQBX6TwSyLpI5idBVx bgtxA+qvFTia1NIFcm+M+SvrWnIl+TlG43IbPgTDZCciECqKT1inA62+tC4T7V2qSNfVfdQqe1z6 RgRQ5MwOQluM7dvyz/yWk+DbETZUYjQ4jwxgmzuXVjit89Jbi6Bb6k6WuHzX1aCGcEDTkSm3ojyt 9Yy7zxqSiuQ0e8DYbF/pCsLDpyCaWt8sXVJcukfVm+8kKHA4IC/VfynAskEDaJLM4JzMl0tF7zoQ CqtwOpiVcK01seqFK6QcgCExqa5geoAmSAC4AcCTY1UikTxW56/bOiXzjzFU6iaLgVn5odFTEcV7 nQP2dBHgbbEsPyyGkZlxmqZ3izRg0RS0LKydr4wQ05/EavhvE/xzWfdmQnQeiuP43NJvmJzLR5iV QAX76QIDAQABo4G/MIG8MA8GA1UdEwEB/wQFMAMBAf8wXQYIKwYBBQUHAQEEUTBPMCMGCCsGAQUF BzABhhdodHRwOi8vb2NzcC5DQWNlcnQub3JnLzAoBggrBgEFBQcwAoYcaHR0cDovL3d3dy5DQWNl cnQub3JnL2NhLmNydDBKBgNVHSAEQzBBMD8GCCsGAQQBgZBKMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZy9pbmRleC5waHA/aWQ9MTAwDQYJKoZIhvcNAQEEBQADggIBAH8IiKHa GlBJ2on7oQhy84r3HsQ6tHlbIDCxRd7CXdNlafHCXVRUPIVfuXtCkcKZ/RtRm6tGpaEQU55tiKxz biwzpvD0nuB1wT6IRanhZkP+VlrRekF490DaSjrxC1uluxYG5sLnk7mFTZdPsR44Q4Dvmw2M77in YACHV30eRBzLI++bPJmdr7UpHEV5FpZNJ23xHGzDwlVks7wU4vOkHx4y/CcVBc/dLq4+gmF78CEQ GPZE6lM5+dzQmiDgxrvgu1pPxJnIB721vaLbLmINQjRBvP+LivVRIqqIMADisNS8vmW61QNXeZvo 3MhN+FDtkaVSKKKs+zZYPumUK5FQhxvWXtaMzPcPEAxSTtAWYeXlCmy/F8dyRlecmPVsYGN6b165 Ti/Iubm7aoW8mA3t+T6XhDSUrgCvoeXnkm5OvfPi2RSLXNLrAWygF6UtEOucekq9ve7O/e0iQKtw OIj1CodqwqsFYMlIBdpTwd5Ed2qz8zw87YC8pjhKKSRf/lk7myV6VmMAZLldpGJ9VzZPrYPvH5JT oI53V93lYRE9IwCQTDz6o2CTBKOvNfYOao9PSmCnhQVsRqGP9Md246FZV/dxssRuFFxtbUFm3xuT sdQAw+7Lzzw9IYCpX2Nl/N3gX6T0K/CFcUHUZyX7GrGXrtaZghNB0m6lG5kngOcLqagAMYIC7TCC AukCAQEwWzBUMRQwEgYDVQQKEwtDQWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNl cnQub3JnMRwwGgYDVQQDExNDQWNlcnQgQ2xhc3MgMyBSb290AgMCOakwDQYJYIZIAWUDBAIDBQCg ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyODE3NDEz OFowTwYJKoZIhvcNAQkEMUIEQBuGwml9TdowFrflLh/WfJ4Gx2pZT3xluTpmZpP7CHLdllpJbCJb 2LMppzVfX5f+fyWvKMYwoMdYM0S6AoFAeZcwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQC3G2yelbJx0OfFJM/WvUWp90yR8p5Y q0iNyqzTdvvzkY8OVe6HnV9/UI2YJHg1DOajQZE9RXt808x2+nZiZ8G6pSGnozWtn/Ssc7MLUSI9 WD/X43kkuzc0il/Ye/WdIWTFhXDOQlFtSJledMzSa/jCD9YSSzz5KyB5h6m8yl57jmJdM0BS8J7v E6NamUi4CODmWFLQqDaU+HyQ8qagelYec+9zcgUedrR9zWN731A0f8GszyM/QZRfY1IQYmRcSB8m Z0o6g+QYmhusJNwieoRiIaL6cy2C3+/potMk2N3TjGFcF6EVEkUe3g1TqWM0S+VlWHApIs7USfq8 sS2YVlvfAAAAAAAA --=-WyA269DWqjOBcjjz+zOa-- From nobody Sat Mar 28 11:53:31 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 EA71B1A8F44 for ; Sat, 28 Mar 2015 11:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2] 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 n0dAL8znayOF for ; Sat, 28 Mar 2015 11:53:25 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A09DD1A8F3D for ; Sat, 28 Mar 2015 11:53:25 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 957B5F987; Sat, 28 Mar 2015 14:53:22 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1D7F021573; Sat, 28 Mar 2015 10:56:11 -0500 (CDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , Brian Sniffen In-Reply-To: References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sat, 28 Mar 2015 11:56:11 -0400 Message-ID: <87vbhlt8tg.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: [openpgp] OpenPGP private certification [was: Re: Manifesto - who is the new OpenPGP for?] 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, 28 Mar 2015 18:53:29 -0000 On Thu 2015-03-26 15:58:57 -0500, Phillip Hallam-Baker wrote: > Yep, I don't actually rate a keysignature as being worth anything > until it is enrolled in a TRANS like log. I think this perspective is dangerous to privacy, if we want to be able to support non-public certifications. I often certify people's keys publicly (or i make OpenPGP certifications and send them to the subject and let them decide whether to publish them or not). But i also think it's important to be able to make a non-logged, non-public "letter of introduction", to be handed off when needed. OpenPGPv4 already supports this in the form of non-exportable signatures. The UI/UX for this is abysmal in most clients today (anyone with UI/UX cycles to spare who wants some brainstorming ideas about how to improve this, please talk to me), but it would be a real shame to change the protocol in such a way to rule this technique out completely. Parties who are globally relied-upon (e.g. the X.509 CAs that everyone implicitly "trusts") should definitely be publicly logged. But not everyone who certifies is in (or should be in) that position; some of these relationships are private, and we should not force people to publish them. --dkg From nobody Sat Mar 28 12:24:46 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 A83AC1A8871 for ; Sat, 28 Mar 2015 12:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 3P8snb6bMb9Z for ; Sat, 28 Mar 2015 12:24:40 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 339DD1A88CF for ; Sat, 28 Mar 2015 12:24:40 -0700 (PDT) Received: by lboc7 with SMTP id c7so26883664lbo.1 for ; Sat, 28 Mar 2015 12:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+Yx0J6B63mkdzVMjPdpiwIaiPA5Q+nHjhb7sEPxi+Kc=; b=AH+eyAaod5dYvHY0IfET9aXUVr1bF9uOxsr70Wb+LS/nDeJLblCKpcfOQcqgQmfNpN bP+/4x5bQtvXpjoNcs8/8F7vsVnFuz9etKOsIvB8GcGqO7KNvY7YOZCdO2MuaZQ5pITU +URgu2y5eDr58dx8CoFKWRgKZ2DfExSpI1N+hHEiQXQ8DP8EGseQ9t5wA79ftanswwcd e7TO+NOzrhY9VPwXiABF75Wlf+mZHMePRBHJUHOwRzReQW5Bsu940JCgl8kmQokoXbTG HTlkmVRIPkIQ8Y3VGzV/yKDwzrjtAq5rwhgd0U2oVr7YQ0uncQLuQEoV9wjlg8qd4qxL Divg== MIME-Version: 1.0 X-Received: by 10.152.4.136 with SMTP id k8mr22450061lak.103.1427570678661; Sat, 28 Mar 2015 12:24:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Sat, 28 Mar 2015 12:24:38 -0700 (PDT) In-Reply-To: <87vbhlt8tg.fsf@alice.fifthhorseman.net> References: <1426721882.4249.72.camel@scientia.net> <5510578A.80304@iang.org> <1427140788.10191.75.camel@scientia.net> <5510B7CF.8060308@iang.org> <1427168189.10191.241.camel@scientia.net> <5511FE82.6010807@iang.org> <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> <87vbhlt8tg.fsf@alice.fifthhorseman.net> Date: Sat, 28 Mar 2015 15:24:38 -0400 X-Google-Sender-Auth: 8N8sdBOeR2Z73Mi4FKrib6dgYkc Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , Brian Sniffen , IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification [was: Re: Manifesto - who is the new OpenPGP for?] 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, 28 Mar 2015 19:24:44 -0000 On Sat, Mar 28, 2015 at 11:56 AM, Daniel Kahn Gillmor wrote: > On Thu 2015-03-26 15:58:57 -0500, Phillip Hallam-Baker wrote: >> Yep, I don't actually rate a keysignature as being worth anything >> until it is enrolled in a TRANS like log. > > I think this perspective is dangerous to privacy, if we want to be able > to support non-public certifications. > > I often certify people's keys publicly (or i make OpenPGP certifications > and send them to the subject and let them decide whether to publish them > or not). But i also think it's important to be able to make a > non-logged, non-public "letter of introduction", to be handed off when > needed. OpenPGPv4 already supports this in the form of non-exportable > signatures. The UI/UX for this is abysmal in most clients today (anyone > with UI/UX cycles to spare who wants some brainstorming ideas about how > to improve this, please talk to me), but it would be a real shame to > change the protocol in such a way to rule this technique out completely. > > Parties who are globally relied-upon (e.g. the X.509 CAs that everyone > implicitly "trusts") should definitely be publicly logged. > > But not everyone who certifies is in (or should be in) that position; > some of these relationships are private, and we should not force people > to publish them. By that I mean fixed in time. I agree that it does not need to be public. Only the hash needs to be enrolled. From nobody Mon Mar 30 04:09: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 2EE3C1ACDC8 for ; Mon, 30 Mar 2015 04:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVzJ5pzf7isy for ; Mon, 30 Mar 2015 04:09:00 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (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 AC56A1ACDC6 for ; Mon, 30 Mar 2015 04:09:00 -0700 (PDT) Received: by qcgx3 with SMTP id x3so9915660qcg.3 for ; Mon, 30 Mar 2015 04:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6fpOdNrdvA4EJT+6hzUDEdwmadBPT1e4aWF9NiYI8QI=; b=bl+Z/f16j3gHZ2Tm5vPf67edkouP3zA46ji8zZoFUKxFH6YBsNo3zS1SeLlAcWbdJC z5m23OXb3fNv0xlOnZfO1Lm7hi659i7KqXuZbuQAwhWeLPYfk8QEZKxXF+pnIviSrxQH uMEZkXZvB0Y+WK3VT/xdYCSh0GvXDuISa4pHaWWDKyG8+9WDHZ5jy/eWZhpd2jZVLYC9 uacNsRQNpvWRrEhlYdnlGNk1Xq9FCzYZhnt5qH3AxQ1MiRbNPdh+a48hh+Aa+iyCjhDh UgaoYjwPNKr1k/m6ssQV8gjyHPrK1SjM7xgBLdUfzcMkhiWR7HQb1lYxNPNPU6fYr0c9 mZlg== X-Received: by 10.55.52.77 with SMTP id b74mr8789162qka.78.1427713739766; Mon, 30 Mar 2015 04:08:59 -0700 (PDT) Received: from [192.168.1.29] (pool-71-174-213-210.bstnma.fios.verizon.net. [71.174.213.210]) by mx.google.com with ESMTPSA id 75sm7447199qhw.22.2015.03.30.04.08.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Mar 2015 04:08:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phill In-Reply-To: <1427241081.10191.348.camel@scientia.net> Date: Fri, 27 Mar 2015 12:03:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9C89276D-8978-43E2-AF2A-A4DA9C3D1AFF@gmail.com> References: <644FDE72-CB1A-4EBE-9309-B429860A360D@gmail.com> <5511F096.7000404@iang.org> <1427241081.10191.348.camel@scientia.net> To: Christoph Anton Mitterer X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Hybrid proposal for algorithm identifiers 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, 30 Mar 2015 11:09:02 -0000 > On Mar 24, 2015, at 6:51 PM, Christoph Anton Mitterer = wrote: >=20 > On Tue, 2015-03-24 at 23:17 +0000, ianG wrote:=20 >> On the left,=20 >> there are the pluralists > So pluralists are left-wing?! ;-P >=20 > Seriously, being one of the "pluralists", let me perhaps clarify this = a > bit: >=20 > I don't think that the standard should necessarily standardise 20 = alogs > for each type and make 10 of them mandatory. ... > - It should be rather simple to change the mandatory algos in the > standard. > I mean we still list 3DES, while in reality it's probably AES. We should separate out the question of backwards compatibility = support=E2=80=A6 * One mandatory to implement * One strongly recommended backup * Additional algorithms that have been found to be necessary in practice = for legacy interop, preferably with =E2=80=98best before=E2=80=99 dates. Decryption support is likely to be required for much longer than = encryption.