From nobody Wed Apr 1 10: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 5C1961A0127 for ; Wed, 1 Apr 2015 10:22:58 -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 ouOjrzzsep8A for ; Wed, 1 Apr 2015 10:22:56 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 743EA1A009C for ; Wed, 1 Apr 2015 10:22:56 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B3659F985; Wed, 1 Apr 2015 13:22:53 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3512A20191; Wed, 1 Apr 2015 12:22:51 -0500 (CDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 01 Apr 2015 13:22:51 -0400 Message-ID: <87ego3g3v8.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain 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: Wed, 01 Apr 2015 17:22:58 -0000 On Sat 2015-03-28 15:24:38 -0400, Phillip Hallam-Baker wrote: > By that I mean fixed in time. I agree that it does not need to be > public. Only the hash needs to be enrolled. Normal e-mail addresses are low-entropy, right? this would suggest that they're reversible in most cases without a lot of effort (e.g. consider nsec3-walker, which has similar properties [0]). how does enrolling only the hash address the privacy considerations effectively? --dkg [0] http://dnscurve.org/nsec3walker.html From nobody Wed Apr 1 10:27: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 29DA71A016C for ; Wed, 1 Apr 2015 10:27:02 -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 AlYKcXK64oMc for ; Wed, 1 Apr 2015 10:27:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 719BD1A0127 for ; Wed, 1 Apr 2015 10:27:01 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 92F65F984; Wed, 1 Apr 2015 13:26:59 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CABE520286; Wed, 1 Apr 2015 12:26:56 -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: Wed, 01 Apr 2015 13:26:56 -0400 Message-ID: <87bnj7g3of.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, Werner Koch , 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: Wed, 01 Apr 2015 17:27:02 -0000 On Sat 2015-03-28 10:19:54 -0400, Albrecht Dreß wrote: > And I think it's not necessary if RFC 5751 would simply define that > the "inner" protected message container *must* have the same > Message-ID as the "outer" one. If anyone is concerned that this > violates the requirement of uniqueness (RFC 5322, sect. 3.6.4), the > inner container could have instead of the "Message-ID" (which is *not* > required!) something like a "Protected-Message-ID" with the same > value. If someone tampered with the "outer" message-id, the receiving > MUA could still detect this case by the presence of the > "Protected-Message-ID". This approach would *not* break compatibility > with existing implementations. requiring the inner-message-id to be identical to the outer message-id would mean that you would not be able to hide the message-id in an encrypted message. hiding the message-id would be useful, for example, when sending the same message to multiple mailboxes, encrypted separately, but not wanting the server operators to be able to link those messages together as the same message. --dkg From nobody Wed Apr 1 10:38: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 930DB1A01C6 for ; Wed, 1 Apr 2015 10:38:31 -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 XCHUFEjaMUAw for ; Wed, 1 Apr 2015 10:38:29 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 A102A1A01AE for ; Wed, 1 Apr 2015 10:38:29 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so25568418lbb.0 for ; Wed, 01 Apr 2015 10:38:28 -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=WSj92eRgUF1dFn8E1fKrSa9JfHoN7XUJdYCtowd9Brk=; b=c/Yg/hSPD0n0mJ9aTau2KgKze79f45BW/gHtZumaPVe+YUGAgO73Zf69qZeX18DU0+ uOou28CHsNyvO3JwDNGYx2lV9eQh/NvaP1vBjCsuPQ01cBbkO6tt5IoRFIbCYbekiHfB SIv1rwLDofJf05KC8/4Tj1rg8WUfgLUX6kQ2hympRo72ZBZ/6x2AxVwBVYYuXCGRIMa3 Qj2aX0nQFIxvJKqSmLU8yzzGoT2hWnfUIDustV3TM4YdNgj2zEJusi6H89rNBTINlBvt KbOhT5caxQX5/Ag2Jhdq33YsFiMod3br8xcvcclAOFHZR20g07bkegwgTRL9w7sZDjIn 3i0w== MIME-Version: 1.0 X-Received: by 10.112.161.66 with SMTP id xq2mr36888011lbb.103.1427909908011; Wed, 01 Apr 2015 10:38:28 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 1 Apr 2015 10:38:27 -0700 (PDT) In-Reply-To: <87ego3g3v8.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> <87ego3g3v8.fsf@alice.fifthhorseman.net> Date: Wed, 1 Apr 2015 13:38:27 -0400 X-Google-Sender-Auth: U3FQyhJTDPq1iHNhsI9yn-uXgfk 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: Wed, 01 Apr 2015 17:38:31 -0000 On Wed, Apr 1, 2015 at 1:22 PM, Daniel Kahn Gillmor wrote: > On Sat 2015-03-28 15:24:38 -0400, Phillip Hallam-Baker wrote: >> By that I mean fixed in time. I agree that it does not need to be >> public. Only the hash needs to be enrolled. > > Normal e-mail addresses are low-entropy, right? this would suggest that > they're reversible in most cases without a lot of effort (e.g. consider > nsec3-walker, which has similar properties [0]). how does enrolling > only the hash address the privacy considerations effectively? > > --dkg > > [0] http://dnscurve.org/nsec3walker.html I was planning to enroll the hash of the keysigning which would include the signature at minimum. If we are doing DSA then it isn't really a problem as the signatures are non deterministic. You can get into issues with RSA though (but not in this case). From nobody Wed Apr 1 11:19: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 0C4541A1B22 for ; Wed, 1 Apr 2015 11:19: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 WsK0ks9cM3aH for ; Wed, 1 Apr 2015 11:19:06 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA951A1BD7 for ; Wed, 1 Apr 2015 11:19:06 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id DBF1DF984; Wed, 1 Apr 2015 14:19:04 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6B08A20286; Wed, 1 Apr 2015 13:19:02 -0500 (CDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87ego3g3v8.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 01 Apr 2015 14:19:02 -0400 Message-ID: <87wq1vemp5.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christoph Anton Mitterer , Brian Sniffen , IETF OpenPGP Subject: [openpgp] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 01 Apr 2015 18:19:11 -0000 On Wed 2015-04-01 13:38:27 -0400, Phillip Hallam-Baker wrote: > On Wed, Apr 1, 2015 at 1:22 PM, Daniel Kahn Gillmor > wrote: >> On Sat 2015-03-28 15:24:38 -0400, Phillip Hallam-Baker wrote: >>> By that I mean fixed in time. I agree that it does not need to be >>> public. Only the hash needs to be enrolled. >> >> Normal e-mail addresses are low-entropy, right? this would suggest that >> they're reversible in most cases without a lot of effort (e.g. consider >> nsec3-walker, which has similar properties [0]). how does enrolling >> only the hash address the privacy considerations effectively? >> >> --dkg >> >> [0] http://dnscurve.org/nsec3walker.html > > I was planning to enroll the hash of the keysigning which would > include the signature at minimum. If you log the hash of the keysigning, then how are the logs useful? the way that you detect misissuance in a log is that you can scan the log to see if any new certs have been issued over the identity or identities that you are interested in monitoring. If the only thing in the log is the hash of the full cert, how do you know whether that cert is one you should be concerned about or not? --dkg From nobody Wed Apr 1 11: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 346741A884C for ; Wed, 1 Apr 2015 11: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 csFw-6iZIoIt for ; Wed, 1 Apr 2015 11:56:21 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 3A09C1A88B6 for ; Wed, 1 Apr 2015 11:56:18 -0700 (PDT) Received: by lboc7 with SMTP id c7so43283581lbo.1 for ; Wed, 01 Apr 2015 11:56:16 -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=Jve7F2ji2GRE/WAvgtWxoY07+oq6URvkfLOZbx+NVJY=; b=Unm244jE/LrAvZwO2NOrSv2nXpbdiY87DRN0hnrWW+l4IaddbUbGtp+UcuhPFzdqvv m3NwEoZ8vmStZwAiGoF+LNAEC7Yxm67lzkM5gQg1STnlziZ0dC8tAeY06zmPkBMB+RiZ 0NzeiE74sP1p7mj1swEj0dq2ldFw0r3McVq75QveFMZ4vCTU6Pe/DX4PSRF3t3hUMQ8X 2khh7wtbXzgeePjWd0TDugTEWmhTTvh6HMEtY3BucVSn6CLHcbdVfYqpraJw96uw3GXf iD8nIBR4ptOsQa5lhQoNHQl4ZQOq21cqR2WICwpc/LExvmnWCA0OkV3SU/wgD+qtUKg5 wIeg== MIME-Version: 1.0 X-Received: by 10.112.236.68 with SMTP id us4mr10403996lbc.91.1427914576781; Wed, 01 Apr 2015 11:56:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 1 Apr 2015 11:56:16 -0700 (PDT) In-Reply-To: <87wq1vemp5.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> <87ego3g3v8.fsf@alice.fifthhorseman.net> <87wq1vemp5.fsf@alice.fifthhorseman.net> Date: Wed, 1 Apr 2015 14:56:16 -0400 X-Google-Sender-Auth: de2kbXpsGop69IqXiHbpz56S5RU 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] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 01 Apr 2015 18:56:22 -0000 OK, this is what I am planning to do for PrismProof email. After trying a number of approaches I have concluded that the best approach today is to insist that each keypair have exactly one purpose. So Alice will always have a personal root key and an intermediate key signing key and the fingerprint of this PKI is the hash of the keyinfo block of the personal root. to do key endorsement she will also need a key endorsement key on each device she wants to use for endorsements. Alice-Personal-Root -> Key Signing Key -> Key Endorsement Key[s] [One reason for the no sharing rule for KEKs is that it makes dealing with a stolen phone etc. much easier] Each cert in this chain would be enrolled in an append-only cryptographic log which provides proof that it existed at a particular point in time. But none of these certs requires an email address. For various reasons, we probably want these certs to be enrolled in a transparent log that publishes both the block chain and the input data. It is not necessary for a log to publish the input values to fix them in time however. When Alice endorses Bob, this is not an operation currently supported by PKIX and so the 'no new ASN.1' rule applies. The endorsement is probably some sort of JSON structure: {"name":"Bob", "email":"bob@example.com", fingerprint":"phb:qweflkqwhjdflkjhasdlkjhasdvlkjhlksajvh", "date":"2015-04-01:01:23Z", "blind":"askfasjkldhkjashdvkjhsadkjh"} <...Signature data...> This is of course simply another form of certificate but it is a very different type of cert so its best to use a different term. Alice is not going to commit to managing the endorsement lifecycle. The property we want to get from enrolling the endorsement in a log is to fix it in time. So we enroll the hash in the log rather than the endorsement itself. The value "blind" is a random value that leaks Alice's RNG to the NSA^h^h^h^h^h^h^h^h prevents dictionary attacks. From nobody Wed Apr 1 11:58: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 62CC61A1AA8 for ; Wed, 1 Apr 2015 11:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2hiuRcRKypBE for ; Wed, 1 Apr 2015 11:57: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 2BE8E1A1A65 for ; Wed, 1 Apr 2015 11:57:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EECC3BECF for ; Wed, 1 Apr 2015 19:57:55 +0100 (IST) 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 3jAiaA9Sf6GW for ; Wed, 1 Apr 2015 19:57:50 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22A63BE77 for ; Wed, 1 Apr 2015 19:57:50 +0100 (IST) Message-ID: <551C3FAD.6040107@cs.tcd.ie> Date: Wed, 01 Apr 2015 19:57:49 +0100 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" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 01 Apr 2015 18:57:59 -0000 Hi all, So I think the volume and content of discussions over the last few weeks clearly indicates a desire to do something about openpgp, but that discussion doesn't seem to be closing in on exactly what to do, in the IETF context. It'd help me to try figure that out if folks would respond to this saying which of the options below you think can make sense. Picking more than one is fine, but if so, please say which you prefer. Annotating/explaining your choice(s) is very welcome but please try resist the temptation to change this into a chat about a different set of options:-) It would also really help me (and I suspect others) evaluate messages if you could say something about how you fit into the openpgp universe (e.g. "I wrote the foo implementation" or "I run a thing with N people using pgp" or whatever). An essay on that is not useful here, but a line or two could be really good. Please try respond to this if you can before Wed April 8th and I'll try summarise whatever we get back to the list after that, and we may or may not have a plan of action at that point - we'll see I guess. And pretty please do change the message subject if you want to follow up and discuss something from someone else's response. That'll at least make my life a little easier when it comes to trying to summarise back to the list but it'll also make it easier for folks to check if I've mucked up in how I summarise (and I muck up a lot, sadly:-). Anyway here's the options: option 1: do nothing - there's nothing much to do or at least not in the IETF or not within the IETF for the next >6 months. option 2: do maintenance work on rfc4880 - produce a 4880bis with better crypto options at least, and debate any further detailed changes during chartering - the charter will contain a list of specific things to do and other things will be out of scope (for now) option 3: do a major revision to openpgp - take rfc4880 as a starting point but question all design decisions in the process of developing a successor version of openpgp and write a charter that allows for all such design decisions to be questioned option 4: move beyond openpgp (or smime) to develop a new flavour of end-to-end security for interpersonal messaging, possibly not that tightly coupled to email, but at least supporting an email flavour For options 2-4 one could include more or less work related to trust models or key hierarchies/key distribution. If you would like to include that kind of work please pick one of those below. If pursuing any of these, we'd need a separate discussion about the scope of that work and whether or not one specific approach ought be standardised, but please let's not yet have that discussion until we see that one of the "t" options below has a good bit of support. option 2t: option 2 + add some trust model/key management option 3t: option 3 + add some trust model/key management option 4t: option 4 + add some trust model/key management So that's for choices. Remember it's ok to pick more than one with which you could live, but please be clear about which you prefer. I'd also like to talk about how we might process some of the above if we establish rough consensus for one of 'em. Option 1 is easy. The list can continue to debate stuff, but there's no IETF process stuff needed and no new RFCs on the horizon. I get off the hook:-) For option 2, or 2t we could start crafting a charter on the list once we've gotten agreement that that's the goal. I don't think a face-to-face BoF would be needed before forming a working group unless the scope of the "t" part of 2t was proving hard to pin down. (We could arrange some virtual audio meetings if that'd help of course.) That could mean a working group is formed quite soon, and that working group might choose to meet face-to-face in Prague in July, or might prefer to work on the list only, or with some audio meetings. For options 3, 3t, 4 or 4t I do think we'd likely need to have a face-to-face BoF meeting as there'd be a lot to consider and pin down and higher bandwidth is much better for that. In that case, the important date is June 5th which is the next cutoff date for requesting such a meeting for the Prague IETF to be held July 19-24. [1] (June 5th might seem like a long way off, but it's not really so if we needed such a meeting then starting to work towards that soon would be much better than doing so late.) Also, some of this can be done sequentially. For example, as an area director I'm very happy re-chartering existing working groups to add more tasks where those groups have demonstrated the ability to be productive. In my experience that can work better than starting out with the hard/ambitious stuff as the very first thing to do. That might argue for starting with option 2 and then, if all goes well, discussing whether or how to tackle option 3 or 4. (We could even charter a group to do the maintenance work for option 2 and when that's done to then discuss how to re-charter for one of the more complicated choices.) I'd suggest however, we ignore such sequential processing for now, see what folks prefer as a goal, and then think about whether there's a way to get to what people want via sequencing things cleverly. So, just for now, please don't suggest "2, followed by 3" even if that's something you like the sound of - I think folks' initial responses will probably make it obvious if we need a chat about that. And lastly, please let's not have an IETF process discussion or a discussion about why the IETF is great or crap. If we see that there's IETF stuff folks want to do and if those folks are willing and able to implement/deploy the results then that's enough to be going on with. Thanks, S. [1] https://www.ietf.org/meeting/important-dates-2015.html#ietf93 From nobody Wed Apr 1 12:26: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 C80571A8876 for ; Wed, 1 Apr 2015 12:26:29 -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 wQ31ANoRmAmH for ; Wed, 1 Apr 2015 12:26:28 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::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 1BBDB1A8849 for ; Wed, 1 Apr 2015 12:26:28 -0700 (PDT) Received: by wgoe14 with SMTP id e14so63835194wgo.0 for ; Wed, 01 Apr 2015 12:26:26 -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=aGT9pPrfPN5RRfaSsy+G8v2XOYpcUtezrMj1GnULCe4=; b=BtvI0IUx17/k037kvEmRJQyEMcvCkqxVzVwiO8JDnSM6CD5XejG8Bd/en10221Ygy4 dheio4hB4HDvYYRFskDj/CPDWgERfDaclzGCmdGCg+ICm98P7/OewiFARdhodK91v6Rv KvA9Adt7EoFjvT4jjXIM9MXgvrtP1HhMmv91PKxihxF1+NSU0y8wtl9zWT5BfTTTtaIa mHgb6TOfbDSe52mijE7/4mngokQo/USqFshj+j4rYNy7GHlWmCt80eK3Sebn8G1/uajX ULGBVFH7QDFJPJU9cI3nbI4ToDXrpZTdgCkDFjzZr0RjZ3J2nWuvS3Pna4cGJBA+5Abh b84Q== MIME-Version: 1.0 X-Received: by 10.194.48.74 with SMTP id j10mr88582748wjn.38.1427916386865; Wed, 01 Apr 2015 12:26:26 -0700 (PDT) Received: by 10.194.162.6 with HTTP; Wed, 1 Apr 2015 12:26:26 -0700 (PDT) In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> Date: Wed, 1 Apr 2015 20:26:26 +0100 Message-ID: From: Nicholas Cole To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7ba975c802182e0512aeb180 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 01 Apr 2015 19:26:29 -0000 --047d7ba975c802182e0512aeb180 Content-Type: text/plain; charset=UTF-8 On Wednesday, 1 April 2015, Stephen Farrell wrote: > > Hi all, > > So I think the volume and content of discussions over the > last few weeks clearly indicates a desire to do something > about openpgp, but that discussion doesn't seem to be closing > in on exactly what to do, in the IETF context. It'd help me > to try figure that out if folks would respond to this saying > which of the options below you think can make sense. Picking > more than one is fine, but if so, please say which you prefer. > Annotating/explaining your choice(s) is very welcome but > please try resist the temptation to change this into a chat > about a different set of options:- > [snip] FWIIW I favour option 2. That is to say, making the necessary changes to the cypher list etc and the packet format that allow us to move away from obsolete and deprecated algorithms -- especially moving to something better than SHA-1 in those places where that is currently hard-coded. I do not think that we should be talking about successors to OpenPGP, nor do I think that we should use this as an opportunity to hard-code particular security policies or usages, which is where some of this discussion has sometimes veered. Werner has the best sense of what needs fixing is within the scope of option 2 or 3, but my vote is for evolutionary changes not a radical departure. > --047d7ba975c802182e0512aeb180 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, 1 April 2015, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi all,

So I think the volume and content of discussions over the
last few weeks clearly indicates a desire to do something
about openpgp, but that discussion doesn't seem to be closing
in on exactly what to do, in the IETF context. It'd help me
to try figure that out if folks would respond to this saying
which of the options below you think can make sense. Picking
more than one is fine, but if so, please say which you prefer.
Annotating/explaining your choice(s) is very welcome but
please try resist the temptation to change this into a chat
about a different set of options:-

[sni= p]

FWIIW I favour option 2.=C2=A0 That is to say, = making the necessary changes to the cypher list etc and the packet format t= hat allow us to move away from obsolete and deprecated algorithms -- especi= ally moving to something better than SHA-1 in those places where that is cu= rrently hard-coded.=C2=A0

I do not think that we s= hould be talking about successors to OpenPGP, nor do I think that we should= use this as an opportunity to hard-code particular security policies or us= ages, which is where some of this discussion has sometimes veered.=C2=A0

Werner has the best sense of what needs fixing is wi= thin the scope of option 2 or 3, but my vote is for evolutionary changes no= t a radical departure. =C2=A0=C2=A0


--047d7ba975c802182e0512aeb180-- From nobody Wed Apr 1 12: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 563A81A900B for ; Wed, 1 Apr 2015 12:51:25 -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 V6USzdEFEMqo for ; Wed, 1 Apr 2015 12:51:23 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 88DE61A8F3E for ; Wed, 1 Apr 2015 12:51:23 -0700 (PDT) Received: by lajy8 with SMTP id y8so44851603laj.0 for ; Wed, 01 Apr 2015 12:51:22 -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=JMMLAO+XuvOVksHuWnGl0DunKKtcq5UdEPMfLKsaMM0=; b=klhi0lAq6ohukDv/Kh1xSIFKbg5L9EyKjTpxI/vis4LTifRa1AbfuN2YB07qpl0Sdc sHYCeJWuDJvDAZoSP+PdQGJgKNelKH2J2nfWC3TZdnAIupFnP2YIfB4aRP17ZfonBchQ WxYzkLhSoWPP+9gjZ9o0tYJNF4W5rw46Nh12JxcEpfChmUVPaOy7PQ+TswdVSWSxjoaO DPRt5T+NHTkbfXzr5inP485JD1U95M+II6Nnb5+LNvZGP3UBM2XmutQ+l6mcKCP87b45 W36e5UBqk1PFeHewIJFjzFKmv2mWRfEsHoSWrSFZD/ALId6zLVWIv3XjSpyPU1VG1y9Q Ar0g== MIME-Version: 1.0 X-Received: by 10.152.87.162 with SMTP id az2mr21121378lab.58.1427917881802; Wed, 01 Apr 2015 12:51:21 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 1 Apr 2015 12:51:21 -0700 (PDT) In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> Date: Wed, 1 Apr 2015 15:51:21 -0400 X-Google-Sender-Auth: -31-sIQD1yBPoBQBM0fKFN12kkg Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 01 Apr 2015 19:51:25 -0000 On Wed, Apr 1, 2015 at 2:57 PM, Stephen Farrell wrote: > It would also really help me (and I suspect others) evaluate > messages if you could say something about how you fit into > the openpgp universe (e.g. "I wrote the foo implementation" > or "I run a thing with N people using pgp" or whatever). An > essay on that is not useful here, but a line or two could > be really good. I have written code that makes S/MIME easy to use by taking concepts from the PGP world. I am planing to extend the same approach to PGP. In particular, my scheme is designed to provide frictionless security so that the user does not need to do anything differently unless we are making something easier to do. I am also looking at trust models that combine ideas from S/MIME, PGP and TRANS. But that is not an immediate focus. > option 1: do nothing - there's nothing much to do or at least > not in the IETF or not within the IETF for the next >6 months. I think it is clear that there is important work to be done. > option 2: do maintenance work on rfc4880 - produce a 4880bis > with better crypto options at least, and debate any further > detailed changes during chartering - the charter will contain > a list of specific things to do and other things will be out > of scope (for now) I would support this. Cleaning up the legacy OpenPGP specs would be a help even if it didn't go further. It is not my preferred option. I think it is also important to decide in advance what our end objective is going to be. We are going to approach this very differently if we have given up hope of getting a single message format. > option 3: do a major revision to openpgp - take rfc4880 as a > starting point but question all design decisions in the process > of developing a successor version of openpgp and write a > charter that allows for all such design decisions to be > questioned I support this but the scope has to be manageable and to understand what is 'manageable' we need more information on the existing implementations. In particular, I would like to achieve a clean break between the message format layer and the trust model layer and tackle those independently. Quite possibly in separate IETF and IRTF tracks. If you give me the fingerprint of Alice's key and some way to resolve that to a public key and her email security preferences, encrypting the message is straightforward. I would like the IETF to come to a single answer to that problem, though just as we have JPG and PNG and GIF in the Web, it need not be a single format. The question of how Bob finds Alice's fingerprint and what confidence he can have in the answer is something that I think needs research. PKIX and PGP are both early essays in the craft. We have 20 years of operational experience and some important IPR is no longer encumbered. > option 4: move beyond openpgp (or smime) to develop a new > flavour of end-to-end security for interpersonal messaging, > possibly not that tightly coupled to email, but at least > supporting an email flavour I do not support this at this time. The reason I chose to start with email is that it is the hardest, most constrained problem. If we can solve that problem we can apply the same approach to everything else. The only problem that is as hard as email is code signing and that is hard for the same reason - because it is an asynchronous problem. It is an important and inevitable piece of work which is why I care about getting issues such as efficient JSON encoding right. But I don't want to open the subject up until we have SPUD, efficient JSON and the trust model sorted. And this is not a project I would want to do in the security area, it would need the WebRTC type folk and the messaging folk. The only near term consequence of the expectation that we will eventually do this work for me would be that I am much more open to re-working existing data structures in JSON than I would be otherwise. If we do eventually re-do the whole application layer then it should have a consistent encoding from top to bottom with as few exceptions as possible. > For options 2-4 one could include more or less work related > to trust models or key hierarchies/key distribution. If you > would like to include that kind of work please pick one of > those below. If pursuing any of these, we'd need a separate > discussion about the scope of that work and whether or not > one specific approach ought be standardised, but please > let's not yet have that discussion until we see that one of > the "t" options below has a good bit of support. > > option 2t: option 2 + add some trust model/key management > option 3t: option 3 + add some trust model/key management > option 4t: option 4 + add some trust model/key management My preferences are Option 3t [With the T part in IRTF] Option 3 Option 2 I do not want to do Option 2t or option 4. From nobody Wed Apr 1 13: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 B48E51A906C for ; Wed, 1 Apr 2015 13:04:47 -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 1b5eX2IEMpE1 for ; Wed, 1 Apr 2015 13:04:46 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5482E1A8AF8 for ; Wed, 1 Apr 2015 13:04:29 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 9728FF984; Wed, 1 Apr 2015 16:04:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id DEC2F2023A; Wed, 1 Apr 2015 15:04:13 -0500 (CDT) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87ego3g3v8.fsf@alice.fifthhorseman.net> <87wq1vemp5.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 01 Apr 2015 16:04:13 -0400 Message-ID: <87iodfehtu.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christoph Anton Mitterer , Brian Sniffen , IETF OpenPGP Subject: Re: [openpgp] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 01 Apr 2015 20:04:47 -0000 On Wed 2015-04-01 14:56:16 -0400, Phillip Hallam-Baker wrote: > The property we want to get from enrolling the endorsement in a log is > to fix it in time. So we enroll the hash in the log rather than the > endorsement itself. It sounds to me like what you're aiming for with the log to make a first-come, first-served arrangement, maybe as a way to distinguish the "correct" original key from some latecomer spoof that tries to usurp it. Is that correct? (this is quite different from the goals of CT, as far as i understand it) If FCFS is your goal, how does a user of this scheme considering multiple keys for e-mail address alice@example.com distinguish the inevitable legitimate transitions from the would-be usurper? Some examples of legitimate transitions: * Alice loses her personal root key due to fire/theft/flood/whatever * Example Corp. closes down, the example.com domain name goes up for sale, and the new owner is a different Alice. (this is getting pretty far afield of openpgp at this point, i think, so i'm happy to take this discusion someplace else (therightkey?) if you prefer). --dkg From nobody Wed Apr 1 13:12: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 63DF51A8F4C for ; Wed, 1 Apr 2015 13:12:19 -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 EMZdj8lXsmfl for ; Wed, 1 Apr 2015 13:12:18 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 3C8251A8825 for ; Wed, 1 Apr 2015 13:12:18 -0700 (PDT) Received: by lboc7 with SMTP id c7so44732036lbo.1 for ; Wed, 01 Apr 2015 13:12:16 -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=dNgeTbjeO7ol7Qy2ZZKoC/6n4KyVH5FTj7MGEBTj0nM=; b=RK2+6Xn10AwSy210rT+VHm8ijko7PhJgWI5PNmycVqDZW2yuoOw2xbyAXKN0XWxIco 9rFIqmMsDoO9wHxf9Brkybwr0Nm2KK+2BKZS/IHrwHrD8JrivRFB9hw1yOfuBJ5yddtK FThextV+BIQPUs6NiLcC6Zzt2ArtG0jMHYegTkInhEl166hqnN0iCtC7DeL5BmTlfJg2 y2TBWTUvzkacfUTxSLIyEAYUKD7B1yQkrihD2DIrVn3NCOXrpxiWBu0iUb5gSOZC1xgg UhFkrvbBE+zpYfsosKleGELi5SV/QA2BQ2qQHOoCAMHH7zz8AG5bVV6wcamtik2+BIbu +8ZQ== MIME-Version: 1.0 X-Received: by 10.152.234.42 with SMTP id ub10mr17126894lac.55.1427919136501; Wed, 01 Apr 2015 13:12:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 1 Apr 2015 13:12:16 -0700 (PDT) In-Reply-To: <87iodfehtu.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> <87ego3g3v8.fsf@alice.fifthhorseman.net> <87wq1vemp5.fsf@alice.fifthhorseman.net> <87iodfehtu.fsf@alice.fifthhorseman.net> Date: Wed, 1 Apr 2015 16:12:16 -0400 X-Google-Sender-Auth: Jw7pXfDikic1FUbLAMDpNwJJJLQ 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] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 01 Apr 2015 20:12:19 -0000 On Wed, Apr 1, 2015 at 4:04 PM, Daniel Kahn Gillmor wrote: > On Wed 2015-04-01 14:56:16 -0400, Phillip Hallam-Baker wrote: >> The property we want to get from enrolling the endorsement in a log is >> to fix it in time. So we enroll the hash in the log rather than the >> endorsement itself. > > It sounds to me like what you're aiming for with the log to make a > first-come, first-served arrangement, maybe as a way to distinguish the > "correct" original key from some latecomer spoof that tries to usurp it. > Is that correct? (this is quite different from the goals of CT, as far > as i understand it) > > If FCFS is your goal, how does a user of this scheme considering > multiple keys for e-mail address alice@example.com distinguish the > inevitable legitimate transitions from the would-be usurper? > > Some examples of legitimate transitions: > > * Alice loses her personal root key due to fire/theft/flood/whatever > > * Example Corp. closes down, the example.com domain name goes up for > sale, and the new owner is a different Alice. > > (this is getting pretty far afield of openpgp at this point, i think, so > i'm happy to take this discusion someplace else (therightkey?) if you > prefer). Yeah we could go to RightKey. But I am not arguing for first com first served. I am arguing that the age of an endorsement is significant. An attacker can easily set up an endorsement cartel with 100 people signing each other's keys. But they can't backdate the endorsements to ten years before they decided they needed them. From nobody Wed Apr 1 13:31: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 3F5BF1A90FF for ; Wed, 1 Apr 2015 13:31: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 HtYlpHu_4b-Z for ; Wed, 1 Apr 2015 13:31:02 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 442891A92E2 for ; Wed, 1 Apr 2015 13:27:53 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 08B0BF984; Wed, 1 Apr 2015 16:27:50 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 91DF020191; Wed, 1 Apr 2015 15:27:37 -0500 (CDT) From: Daniel Kahn Gillmor To: Stephen Farrell , "openpgp\@ietf.org" In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 01 Apr 2015 16:27:37 -0400 Message-ID: <87d23negqu.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 01 Apr 2015 20:31:04 -0000 On Wed 2015-04-01 14:57:49 -0400, Stephen Farrell wrote: > option 2: do maintenance work on rfc4880 - produce a 4880bis > with better crypto options at least, and debate any further > detailed changes during chartering - the charter will contain > a list of specific things to do and other things will be out > of scope (for now) I think i favor this approach, ideally *without* adding trust model work into the mix. Trying to explicitly declare a standardized trust model would be a mistake for the WG. it's a huge rat hole, and a "one trust model fits all" approach is probably illegitimate at some deeper level, since different people have different adversaries. If there's any work to be done with trust models, it would be to write a document that tries to describe one or more of the more common approaches to trust models (e.g. the GnuPG default arrangement, or whatever sort of TOFU mechanism that PHB thinks is what everyone "actually uses"). I do *not* think that needs to be in the WG charter, that can be an independent submission any time by anyone with an interest in clarifying trust models they use. For option 2, i have the following specific items i'd like to see addressed (though they may not need to all be in a new charter): a) update the fingerprint format (avoid inclusion of creation date, use stronger digest algorithm; i'm dubious about embedding algorithm agility in the fingerprint itself, but explicit version info in the fingerprint might be reasonable so we don't have to keep guessing by fpr structure for future versions) b) get rid of keyids entirely -- when referring to a key, use the fingerprint where a compact hint is needed (e.g. in a replacement of the issuer subpacket) or the full primary key where it is more sensitive (e.g. in designated revoker). With EC keys, we could consider using the full key (not the full cert) even in the issuer subpacket case, which could make things cleaner. c) deprecate MD5, SHA1, and RIPEMD160 d) clarify that cleartext signatures should all use charset/encoding UTF-8. e) update S2K with something more modern (PBKDF2, HKDF, scrypt?), deprecate all the other mechnanisms explicitly f) standardize the two new curves coming out of the CFRG: 25519 and curve448 ("goldilocks") for both signatures and encryption (Werner has already started this process for 25519 signatures) g) remove compression entirely h) clean up the language: clearly distinguish between "public key" and "certificate", and ensure that the use of the terms "trust" and "validity", if still present, are used unambiguously. i) declare a literal data packet type "m" that means "MIME content" so that we can punt on the rest of the message structure/format/encoding/type craziness to MIME. j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can get away with. k) provide a modern streamable/chunkable AEAD replacement for Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD mechanism should be the baseline. Could be other incremental changes too, but that's the top of my stack at the moment. I know i was the one who brought the MIME message-structuring question ("memoryhole") to this list recently, but i'm now having second thoughts about whether this is the right place for it -- the above work seems concrete and reasonably well-scoped, and a lot of the feedback in Dallas seemed to be that e-mail header protection could be nice to handle more generally, possibly in collaboration with S/MIME people. I'm not sure where the right place to put that would be, but the work seems orthogonal to the discussions above. --dkg From nobody Wed Apr 1 13:33: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 7184D1A90B9 for ; Wed, 1 Apr 2015 13:33:16 -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 9NfnSdEILRJA for ; Wed, 1 Apr 2015 13:33:10 -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 6C07E1A8894 for ; Wed, 1 Apr 2015 13:30:40 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so57054887igc.0 for ; Wed, 01 Apr 2015 13:30: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 :content-type; bh=8XiFKeEqWMqRPsnTbkOlJSmBEbplwsGQHtoBixkFdNk=; b=Wz8xkjKn+sbIub7B1Vt8zNhEXwfnZk49gQ/bzRDw/oozIC0Iev5Ad/gS3a/zgMj/Ey zjMIgPYVXCd5deqgatDGEBMWakyyJwXJNpUEjUtbba6C3lIc1dO11Y7OpeC1mw6MI5vc ooUwo3xm4dmDOoIe+/zVQjcMFsRCbd1FaDgooy5Nam1HJYJwEmSAvOtpLGm9wxEfWXUN KKmc1BspaxciZ9QnUutLE8BCUIrECL42rD2zcdZV2ww785UGl1kDrXXNsYF3wTWe+vHC Y2mpwMXhHB+nta1I7tYqyc/Gt2o744m+Ck9aVRt+I8FOjgCmt+9yr9W/xZVKSOLaAr0d 9aRQ== X-Received: by 10.50.122.68 with SMTP id lq4mr14877166igb.10.1427920239918; Wed, 01 Apr 2015 13:30:39 -0700 (PDT) MIME-Version: 1.0 References: <551C3FAD.6040107@cs.tcd.ie> In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> From: Wyllys Ingersoll Date: Wed, 01 Apr 2015 20:30:38 +0000 Message-ID: To: Stephen Farrell , "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=089e015383fcab041f0512af96de Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 01 Apr 2015 20:33:16 -0000 --089e015383fcab041f0512af96de Content-Type: text/plain; charset=UTF-8 On Wed, Apr 1, 2015 at 2:58 PM Stephen Farrell > > It would also really help me (and I suspect others) evaluate > messages if you could say something about how you fit into > the openpgp universe (e.g. "I wrote the foo implementation" > or "I run a thing with N people using pgp" or whatever). An > essay on that is not useful here, but a line or two could > be really good. > $ whoami I wrote an independent implementation of 4880 for an iOS app ("ipgmail") in Objective-C. My preference would be option 2 (4880bis). I would eventually like to see a more standardized spec for the PGP trust model, but not as part of the core spec. -Wyllys Ingersoll --089e015383fcab041f0512af96de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 1, 2015 at 2:58= PM Stephen Farrell=C2=A0
It would also really help me (and I suspect others) evaluate
messages if you could say something about how you fit into
the openpgp universe (e.g. "I wrote the foo implementation"
or "I run a thing with N people using pgp" or whatever). An
essay on that is not useful here, but a line or two could
be really good.

$ whoami
I wr= ote an independent implementation of 4880 for an iOS app ("ipgmail&quo= t;) in Objective-C.


My preference w= ould be option 2 (4880bis).=C2=A0 I would eventually like to see a more sta= ndardized spec for the PGP trust model, but not as part of the core spec.

-Wyllys Ingersoll

--089e015383fcab041f0512af96de-- From nobody Wed Apr 1 14:54: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 E872E1A8760 for ; Wed, 1 Apr 2015 14:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3enzKRSuBJ1h for ; Wed, 1 Apr 2015 14:54:30 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (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 86C861A8863 for ; Wed, 1 Apr 2015 14:54:25 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 62C4B1EF73; Wed, 1 Apr 2015 21:54:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1427925265; bh=jpN23E/7JiG24Ol8IkQtXsjj7iS2YuIuxKfJO9R0ZL0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=K358iBgnA7+AjV+s/a3ba9hA++tQnFwnpisPvbdCGr/jfivvbusZ0dlnoM9C22HEd r1sQzt/1wGNf0UcxXpZdfSGBXuK3VfRt5Va10R/tLkdAxlM5rUZEz+VQOJ5xO4kSq2 fkWois7frGRtNjeSGqYXKwBJOy3poVrVetuQrUq8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id ACEC3106FD880; Wed, 1 Apr 2015 21:53:46 +0000 (UTC) From: James Cloos To: Stephen Farrell In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> (Stephen Farrell's message of "Wed, 01 Apr 2015 19:57:49 +0100") References: <551C3FAD.6040107@cs.tcd.ie> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 01 Apr 2015 17:53:46 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150401:stephen.farrell@cs.tcd.ie::9+Dz3C0KPkHNGh5J:00000000000000000000000000000000000655+s X-Hashcash: 1:28:150401:"openpgp\@ietf.org"::H8FqgxtEUEyM3cCJ:000000000000000000000000000000000000000002RqRo X-Hashcash: 1:28:150401:openpgp@ietf.org::49BJOxM2eHjg1mSU:3RPtv Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 01 Apr 2015 21:54:32 -0000 >>>>> "SF" == Stephen Farrell writes: SF> option 2: do maintenance work on rfc4880 - produce a 4880bis SF> with better crypto options at least, and debate any further SF> detailed changes during chartering - the charter will contain SF> a list of specific things to do and other things will be out SF> of scope (for now) That looks best. And dkg's list is a great summary of what is needed. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Apr 1 16:27: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 1BD621A3B9D for ; Wed, 1 Apr 2015 16:27:47 -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 YV1z5Hwp5962 for ; Wed, 1 Apr 2015 16:27:46 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::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 E70541AC3C6 for ; Wed, 1 Apr 2015 16:27:33 -0700 (PDT) Received: by lagg8 with SMTP id g8so48321760lag.1 for ; Wed, 01 Apr 2015 16:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=Ont8wK/HDVH+F5UmnRPj0ZFMySUEk9El2hgKGqL+XQI=; b=i09orznNu5uPToFLgOu4PMILNzj2uN87TKv9nAonmW/3JtpzjWcaKcnIj+utZvczx8 KYMPa9Goal379OqQ1yR9+qZPLG9L1MoqycZ6R8i5MjSxehjdlyJGTILc+HgfVK7kHBzf YrICkSTIZGwLocGEfEz4RszenVmaD4yQujoE+zfw3JR4RC3svTbcTgNo86Le1R4ok7bT nC8PpLuS3K/a5X3l0tr355QMimg+7Nc8/g00XEP9Ch8AK9HqnNLFwV3yOn1u9yFqCgNG H2c/pl21K5L/sA9o7xEXIR9j75NAVd7MDF20oxA1JZPYHxApiRSo+wVcpSbZnQ+KR4jh pFfw== MIME-Version: 1.0 X-Received: by 10.112.13.7 with SMTP id d7mr38131049lbc.79.1427930852481; Wed, 01 Apr 2015 16:27:32 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 1 Apr 2015 16:27:32 -0700 (PDT) Date: Wed, 1 Apr 2015 19:27:32 -0400 X-Google-Sender-Auth: Ck7EntXjRDevNsc1Qk2pjjGpmro Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" , Stephen Farrell Subject: [openpgp] Trust models... 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, 01 Apr 2015 23:27:47 -0000 On Wed, Apr 1, 2015 at 4:27 PM, Daniel Kahn Gillmor wrote: > On Wed 2015-04-01 14:57:49 -0400, Stephen Farrell wrote: > I think i favor this approach, ideally *without* adding trust model work > into the mix. > > Trying to explicitly declare a standardized trust model would be a > mistake for the WG. it's a huge rat hole, and a "one trust model fits > all" approach is probably illegitimate at some deeper level, since > different people have different adversaries. My conclusion exactly. I wrote this up in a draft. Some problems you want to do TOFU, some you want to have Web of Trust, others you want hierarchies. Web of Trust would not work well for the DoD etc. etc. > If there's any work to be done with trust models, it would be to write a > document that tries to describe one or more of the more common > approaches to trust models (e.g. the GnuPG default arrangement, or > whatever sort of TOFU mechanism that PHB thinks is what everyone > "actually uses"). http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-01 My point is that we have two separable issues. 1) What key and security policy should Alice use to contact Bob? 2) How does Alice decide she can trust the answer to 1? OpenPGP, PKIX, SPKI, etc, etc, disagree on answers to 2. Trans makes a difference, etc. etc. That is the research problem. We can't and shouldn't standardize the way that we arrive at the answer but we can agree on the delivery method. > a) update the fingerprint format (avoid inclusion of creation date, use > stronger digest algorithm; i'm dubious about embedding algorithm > agility in the fingerprint itself, but explicit version info in the > fingerprint might be reasonable so we don't have to keep guessing by > fpr structure for future versions) I certainly don't see a need for 'agility'. But I think we need a version number so we can change the algorithm infrequently If we can define the fingerprint format in a manner that is friendly to PKIX and OpenPGP then it will make convergence a lot easier. From nobody Thu Apr 2 07:29: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 F0BFD1ACEB3 for ; Thu, 2 Apr 2015 07:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.411 X-Spam-Level: * X-Spam-Status: No, score=1.411 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 21Rg3fXB47zF for ; Thu, 2 Apr 2015 07:29:23 -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 33D0E1A9113 for ; Thu, 2 Apr 2015 07:29:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E0E97E2038; Thu, 2 Apr 2015 10:29:20 -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 29457-09; Thu, 2 Apr 2015 10:29:18 -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 E4226E2036; Thu, 2 Apr 2015 10:29:18 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t32ETHTs025844; Thu, 2 Apr 2015 10:29:17 -0400 From: Derek Atkins To: Phillip Hallam-Baker 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: Thu, 02 Apr 2015 10:29:16 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Sat, 28 Mar 2015 15:24:38 -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: Christoph Anton Mitterer , Brian Sniffen , Daniel Kahn Gillmor , 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: Thu, 02 Apr 2015 14:29:24 -0000 Phillip Hallam-Baker writes: > By that I mean fixed in time. I agree that it does not need to be > public. Only the hash needs to be enrolled. Unfortunately it doesn't matter. As soon as you require any kind of "enrollment" the system fails. Period. This was (and still is, IMHO) the major issue with X509/SMIME -- My mother would need to jump through hoops that she doesn't understand how to jump through in order to get set up in the system. I.e., the system doesn't work until the user gets blessed by some CA. This is IMHO the power of the OpenPGP model -- generate and go. From a UI/UX perspective the system asks for some information (which technically it already has when you create your email account) and it generates a key pair for you. Maybe it uploads it to a keyserver (which I suppose some could consider "enrollment", but it's a far cry from X509 enrollment requirement). >From this point on the OpenPGP user can encrypt messages to other people and get encrypted messages to them. The can choose to get their key signed by others (or not). They could get it signed from their enterprise (if they are in a corporate environment -- my mother certainly is not). But the key (pun intended) is that the system works without any certifications. >From a usability perspective this is the model I would want to see. I honestly don't care if the actual messages are CMS or 4880 (although I have a large disdain for all things ASN1). So please, for all things sacred, let's not require any kind of "enrollment" for the system to operate. Now, if we want to talk about enrollment for "key lookup" properties, of (non-required) certifications, or anything like that ... I'm all ears. But it should not be a pre-requisite for a user to get up and running. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 2 07:53: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 401C11B2CC6 for ; Thu, 2 Apr 2015 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 wVEMZSjDAwF0 for ; Thu, 2 Apr 2015 07:53: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 239CF1B2CC4 for ; Thu, 2 Apr 2015 07:53:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 028F7E2039; Thu, 2 Apr 2015 10:53: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 29691-05; Thu, 2 Apr 2015 10:53: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 36C0DE2038; Thu, 2 Apr 2015 10:53:15 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t32ErETk026937; Thu, 2 Apr 2015 10:53:14 -0400 From: Derek Atkins To: Christoph Anton Mitterer References: <878uf2iehi.fsf@vigenere.g10code.de> <5510C26E.7070409@iang.org> <87mw32omzs.fsf@vigenere.g10code.de> <55134455.2070606@iang.org> <1427415236.24976.13.camel@scientia.net> Date: Thu, 02 Apr 2015 10:53:13 -0400 In-Reply-To: <1427415236.24976.13.camel@scientia.net> (Christoph Anton Mitterer's message of "Fri, 27 Mar 2015 01:13:56 +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: 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, 02 Apr 2015 14:53:25 -0000 Christoph Anton Mitterer writes: > On Wed, 2015-03-25 at 23:27 +0000, ianG wrote: >> 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? > 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. For now there's nothing that says we *NEED* an official working group. Although having one would make the process easier. > Cheers, > Chris. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 2 08:42: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 AAE2B1ACC82 for ; Thu, 2 Apr 2015 08:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 50TuY-aXb30k for ; Thu, 2 Apr 2015 08:42:25 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 23B711ACCFD for ; Thu, 2 Apr 2015 08:42:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6294A47715; Thu, 2 Apr 2015 15:42:23 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 56917476D5; Thu, 2 Apr 2015 15:42:23 +0000 (GMT) Received: from tereva.kendall.corp.akamai.com (unknown [172.19.32.198]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2BF9980047; Thu, 2 Apr 2015 15:42:23 +0000 (GMT) From: Brian Sniffen To: Phillip Hallam-Baker , Daniel Kahn Gillmor In-Reply-To: References: <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> <87ego3g3v8.fsf@alice.fifthhorseman.net> <87wq1vemp5.fsf@alice.fifthhorseman.net> <87iodf ehtu.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-apple-darwin14.0.0) Date: Thu, 02 Apr 2015 11:42:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 02 Apr 2015 15:42:27 -0000 > But I am not arguing for first com first served. I am arguing that the > age of an endorsement is significant. An attacker can easily set up an > endorsement cartel with 100 people signing each other's keys. But they > can't backdate the endorsements to ten years before they decided they > needed them. I don't expect to understand most of the hashes in a log of hashed signatures. I wonder how many cloned subsets would be buried in case they're later needed, and what can be done about that. The best I can think of is a transparency log---to not hash those. Big public signers should offer such logs. Private citizens signing each others keys probably won't, but it's still valuable to have a standard format for non-public endorsements. Presumably keys should be able to carry a note indicating that keysignatures should only be trusted if in a log. -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 Apr 2 09:10: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 140561B2D28 for ; Thu, 2 Apr 2015 09:10:19 -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 lIxBP9x0QJ7n for ; Thu, 2 Apr 2015 09:10:17 -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 63E1B1B2D24 for ; Thu, 2 Apr 2015 09:09:46 -0700 (PDT) Received: by labe2 with SMTP id e2so63627248lab.3 for ; Thu, 02 Apr 2015 09:09:44 -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=fzgtyomx90ExR5A0dMvalqDLrEOBA1xPg3q7b3IzI24=; b=fXo5/oporajtRC9PbfGwB6pqBU0Vyq+H59s5wskrFnuABNPqDPmF1W5vqS/gIQyleu xNnye8pkWvSHbkt+kosx3O197ZuXzEI1puhLI/WmVXue1iw69ScTjEKwhHmP0ngqIkKM 4eGXbx8R9YqQYp+8BFikg8lG/+Azn0YkNb6E1z/Q+LikC0v1EckJ4ajMlKO7ACdt+Epa ZmpG1PkyOwGleTX6y5t6bfOe9U2eHV/gGiqntpN8/23iSwx4AtRKIguR78yCu4sYyGkj 5eHpve3CHIEIAMR1K0lB+N4dm4HjK+8DPBVc+zkd6B7JtCjzP0IcMxMGUJzN9IHzLuuz 92Gw== MIME-Version: 1.0 X-Received: by 10.152.171.5 with SMTP id aq5mr18446738lac.91.1427990984833; Thu, 02 Apr 2015 09:09:44 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 2 Apr 2015 09:09:44 -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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> Date: Thu, 2 Apr 2015 12:09:44 -0400 X-Google-Sender-Auth: cug58RsqG4vNkbK_MhtxxjMAFGc Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , Brian Sniffen , Daniel Kahn Gillmor , 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: Thu, 02 Apr 2015 16:10:19 -0000 On Thu, Apr 2, 2015 at 10:29 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > >> By that I mean fixed in time. I agree that it does not need to be >> public. Only the hash needs to be enrolled. > > Unfortunately it doesn't matter. As soon as you require any kind of > "enrollment" the system fails. Period. This was (and still is, IMHO) > the major issue with X509/SMIME -- My mother would need to jump through > hoops that she doesn't understand how to jump through in order to get > set up in the system. I.e., the system doesn't work until the user gets > blessed by some CA. > > This is IMHO the power of the OpenPGP model -- generate and go. From a > UI/UX perspective the system asks for some information (which > technically it already has when you create your email account) and it > generates a key pair for you. Maybe it uploads it to a keyserver (which > I suppose some could consider "enrollment", but it's a far cry from X509 > enrollment requirement). Since the key servers won't allow me to revoke the cert for the private key I have no control over, I think that it would be more accurate to say that rather than having no enrollment mechanism, there is a broken one. I am not proposing use of X.509 here. In fact I think it is quite clear that CA issue and peer-peer endorsement have very different requirements and expectations. My point is that both can be greatly strengthened by enrolling the assertions in an append-only log. I would not suggest PKIX or even ACME to do this. But any Web service to support this approach should certainly follow the ACME style etc. > From this point on the OpenPGP user can encrypt messages to other people > and get encrypted messages to them. The can choose to get their key > signed by others (or not). They could get it signed from their > enterprise (if they are in a corporate environment -- my mother > certainly is not). But the key (pun intended) is that the system works > without any certifications. Which is exactly what I do in PrismProof for S/MIME. Enrollment is not only optional, it is not implemented yet (I got halfway before ACME hit and now I am redoing some stuff in the guts). All I need to send an encrypted mail is * The SMTP address to send it to * Either * The public key and encryption options * A fingerprint to resolve authenticate the above > From a usability perspective this is the model I would want to see. I > honestly don't care if the actual messages are CMS or 4880 (although I > have a large disdain for all things ASN1). I hate ASN1 just as much as the next guy. I do not care what format the messages are in. All I care about is who we can reach with them. There are a billion+ clients in existence with S/MIME built in. Every email client has to implement TLS these days to secure POP/IMAP/SUBMIT communications and CMS comes with practically every TLS library. If there is a message formatting option that lets us reach those billion+ clients with an OpenPGP message without compromising the trust model or anything else then lets take it. I would not try to change the 4880 format but we could probably document it more rigorously and remove options that are not needed. The focus for OpenPGPvnext should be to eliminate the cruft while enabling use of as much legacy infrastructure as possible. AFTER that is done we can consider how to design a secure messaging protocol that meets every communication need. Such a protocol will almost certainly be based on JSON with a minimal extension to support binary blobs and text blobs. > So please, for all things sacred, let's not require any kind of > "enrollment" for the system to operate. I certainly don't want an enrollment requirement for making the system operate. > Now, if we want to talk about enrollment for "key lookup" properties, of > (non-required) certifications, or anything like that ... I'm all ears. > But it should not be a pre-requisite for a user to get up and running. Absolutely. I am not actually a fan of using the cloud as a crutch to solve every UI issue. But there are a few problems that it is a really big help on. The analogy I would point to is the Web. One of the main reasons the Web caught on was that all you needed to do to get up and running was to download the server and run it. It didn't even need administrator privileges to run on port 8000. Today, anyone who wants to can set up their own Web server and have complete control. But the simplest approach for most folk is to have that done for them by a hosting provider. There are three functions where I see an advantage to the cloud: 1) Notarization (e.g. CT like things) 2) Discovery (How does Bob find Alice's key) 3) Escrow (Storing encrypted private key in the cloud) All three of these functions are optional. The only reason to do enrollment is to support these functions. So if you don't want any of them or you are planning to do some yourself then you don't need enrollment. The casual first time user is probably best advised to make use of all three at the start (yes even the third). From nobody Thu Apr 2 09:19: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 168E11B2CDF for ; Thu, 2 Apr 2015 09:19:11 -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 Q_fLQcbgeyCH for ; Thu, 2 Apr 2015 09:19:10 -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 9C46D1ACEE4 for ; Thu, 2 Apr 2015 09:19:09 -0700 (PDT) Received: by lahf3 with SMTP id f3so63181304lah.2 for ; Thu, 02 Apr 2015 09:19:08 -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=mg9CuObO7bQqxcqNSzYhTJJ6RBVB5BwVLZ9pFcg+SEs=; b=hsJGVP5FAot3qZ78ebTWtmV51Gn46NG7m3QEkUaKTpoU1Uv2aZVAFiiDljzPrCsZBK jLszLYGS9EgsUdyJcmFokxMTK9xvMs8Uq9WfdkGPEp4w5MRhJtufhcgBe44QTJGx2YoM N8HrciQXsFOmCDQNe3DD6v9Sgp+jL2eIxcxZU6G6PKP2cEbi9rZe0c6J9LiFTv8/6EMQ mkhp9Y3AbHhk26oIiw4PPg+EJy1qvfLj9GhGmm+PxNDgiBlAp9bPoP1hwrLLM2kSj2DI flEDJ9O7mznepLhsPpesnFLZUNOU2h+E/LB6dVXBjcU50OJEaNnRvK8tw5jvThBVuomM n+RA== MIME-Version: 1.0 X-Received: by 10.152.87.162 with SMTP id az2mr25341581lab.58.1427991548176; Thu, 02 Apr 2015 09:19:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 2 Apr 2015 09:19:08 -0700 (PDT) In-Reply-To: References: <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> <87ego3g3v8.fsf@alice.fifthhorseman.net> <87wq1vemp5.fsf@alice.fifthhorseman.net> Date: Thu, 2 Apr 2015 12:19:08 -0400 X-Google-Sender-Auth: qzcV7xNjdeBwJyiCLR2TPwESQ10 Message-ID: From: Phillip Hallam-Baker To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 02 Apr 2015 16:19:11 -0000 On Thu, Apr 2, 2015 at 11:42 AM, Brian Sniffen wrote: > >> But I am not arguing for first com first served. I am arguing that the >> age of an endorsement is significant. An attacker can easily set up an >> endorsement cartel with 100 people signing each other's keys. But they >> can't backdate the endorsements to ten years before they decided they >> needed them. > > I don't expect to understand most of the hashes in a log of hashed > signatures. I wonder how many cloned subsets would be buried in case > they're later needed, and what can be done about that. The best I can > think of is a transparency log---to not hash those. Big public signers > should offer such logs. Private citizens signing each others keys > probably won't, but it's still valuable to have a standard format for > non-public endorsements. It is still a hard problem. But using the log turns it from a hard problem with an infinite number of possible endorsements to a closed problem with a finite set of endorsements. Closing the problem also means raising the cost of exposure and forces the operator to think very carefully before each action. There is also a maintenance cost if you are doing this on Facebook etc. What I would start off doing is looking at the time span over which the endorsements in a ring were added. An organic web of trust will be established over a period of years. Facebook and Twitter have got a lot better at spotting fake cartels over the years. > Presumably keys should be able to carry a note indicating that > keysignatures should only be trusted if in a log. I don't see that, it is a relying party consideration. From nobody Thu Apr 2 10:55: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 6C2991B2D5C for ; Thu, 2 Apr 2015 10:55:01 -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 w3yDSMSyBCJR for ; Thu, 2 Apr 2015 10:54: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 9EB791ACEF3 for ; Thu, 2 Apr 2015 10:54:54 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1D9916D712; Thu, 2 Apr 2015 13:54:52 -0400 (EDT) Message-ID: <551D826B.3080406@iang.org> Date: Thu, 02 Apr 2015 18:54:51 +0100 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: <551C3FAD.6040107@cs.tcd.ie> In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 02 Apr 2015 17:55:01 -0000 On 1/04/2015 19:57 pm, Stephen Farrell wrote: > It would also really help me (and I suspect others) evaluate > messages if you could say something about how you fit into > the openpgp universe ... In the period 1995-2002 approx I managed a team called Cryptix which produced Java & Perl implementations of PGP 2 and then OpenPGP. This was originally written to support a payments system that based its crypto/security packets on PGP. (Sometime around 2012 I replaced the Cryptix & OpenPGP with a custom cut-down internal design I call SKF for SOX Key Format.) > option 4: move beyond openpgp (or smime) to develop a new > flavour of end-to-end security for interpersonal messaging, > possibly not that tightly coupled to email, but at least > supporting an email flavour ... > option 4t: option 4 + add some trust model/key management Option 4t is what I would favour. The reason being that I have since replaced all the direct OpenPGP code with my own design, because it's more efficient (lean, easier to hack), and it meets the needs of the late 2000s identity concept I work to. I wouldn't go backwards but I could possibly go forward to a newer design/architecture that incorporated much of the new knowledge. And, say options 3t or option 4 is also possible to a lesser extent. iang From nobody Thu Apr 2 10:55: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 269341B2DBB for ; Thu, 2 Apr 2015 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_35=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 dZQH3XnBbYPK for ; Thu, 2 Apr 2015 10:55:53 -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 8972F1B2DB3 for ; Thu, 2 Apr 2015 10:55:53 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id A76566D72E; Thu, 2 Apr 2015 13:55:52 -0400 (EDT) Message-ID: <551D82A7.1080905@iang.org> Date: Thu, 02 Apr 2015 18:55:51 +0100 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: <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> In-Reply-To: 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: Thu, 02 Apr 2015 17:55:55 -0000 On 26/03/2015 03:56 am, Phillip Hallam-Baker wrote: > 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. That's a very important observation. I don't take it as axiomatic, I take it as somewhere between very hard and the wrong question. Almost the whole problem comes down to time & knowledge. As I never tire of saying, what we knew in 1992 is no longer state of the art; we've moved on since then: Messaging is no longer the same: we need chat, voice & video, and these are challenging in formats, patterns and networking, but also open up possibilities for authentication. Including Tom Ritter's challenging post. PGP was designed for cut&paste email, that's not only the least interesting thing, it's also an older generation thing which might not be worth protecting at all in 20 years. With a nod to PHB's approach of toughest first. Storage has changed: we no longer consider a message over the wire as the same thing as a message at rest on disk. We do/don't keep video chat, we do/don't take naughty snaps using screen shots. We do/don't share huge files (movies) for which OpenPGP is entirely unsuited because it assumes everything is a datagram, and 16G datagrams aren't supported by any other software. Evidence has changed: we do/don't keep transcripts around for evidence. We do/don't think of digsigs as human signatures. We do/don't worry about removal of files. We do/don't consider the wire to be a threat and we do/don't consider our counterparty to be a threat. WoTs are no longer the same: we now have social networks, which love them or hate them, have raised the bar so substantially that the PGP's communal notions of WoT are vestigial. Value has changed: we now have serious and competing payment systems, all of whom want to integrate with all aspects of life. Computing & networking has changed: we can no longer rely on our own trusted platform. We can't rely on "one platform" and we can't rely on ownership, eg BYOD. Instead it's all mobile, and we're at the mercy of what we get given, and what they bring. Small factors, always present, always online, always travelling. Our models of shared computing are changing: As Derik mentioned, PGP started in a keys-in-pocket age, but we also had client-server + enrollment with S/MIME. Then there's social networking, and now there's cloud. Popular is blockchain, various groups are trying to put 'identity' onto a shared context, which also answers part of Derik's implied permissionless requirement. So, what do we want to use PGP for, and is that still good? In 1992, almost everything about securely using the Internet could be answered by saying "use PGP". In 2015, almost nothing about security using the Internet can be answered by "use PGP" at least the old one. iang > 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). > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Thu Apr 2 11:26: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 048D81A0191 for ; Thu, 2 Apr 2015 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 q5KkGUV7bf16 for ; Thu, 2 Apr 2015 11:26:31 -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 7292B1A0092 for ; Thu, 2 Apr 2015 11:26:31 -0700 (PDT) Received: by lbdc10 with SMTP id c10so65205040lbd.2 for ; Thu, 02 Apr 2015 11:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=RpENStnYWAdVcw71izJERMqG3WNlY3F4aAV9dLbXNaU=; b=rBppcp3CtNZdIbAuQlmeTx3HAA43JfaEvAZPIJAlYm2mDq27Le0D9K5A1RiGuyyT/2 zBUlCnKMCWfgdEjXO/BctFbRiO5EE+qd1O4V6Dte40Z9TuASQnNy0wQo+uJ6UVg+bAex hOcZiJUHYALk26Ff0B0F9UgDNG6qPjiYJOhEryZ3ztYsv+mXAdWAB2G1FwVcdVKb/Ul+ LX/zEw/ubzPzkBLA4eEWJGMY9Za+ftXgJN6FUowgEDp0cU9c4Fw8SWofcwNRpetf+rfM /NyHfGb0rKIMtzgsVKuXURHtwFec/fM9NNLvZtaIG9UWW7JOWulQtEhZ0sG5V/Rqhydr QOdQ== MIME-Version: 1.0 X-Received: by 10.152.18.225 with SMTP id z1mr42526528lad.124.1427999189786; Thu, 02 Apr 2015 11:26:29 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 2 Apr 2015 11:26:29 -0700 (PDT) Date: Thu, 2 Apr 2015 14:26:29 -0400 X-Google-Sender-Auth: 7PC6UCFcloXsCWMq5T1iWy_rnz8 Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: [openpgp] Option 4: Requirements vs. Solutions. 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, 02 Apr 2015 18:26:33 -0000 On Thu, Apr 2, 2015 at 1:55 PM, ianG wrote: > On 26/03/2015 03:56 am, Phillip Hallam-Baker wrote: > Storage has changed: we no longer consider a message over the wire as the > same thing as a message at rest on disk. We do/don't keep video chat, we > do/don't take naughty snaps using screen shots. We do/don't share huge > files (movies) for which OpenPGP is entirely unsuited because it assumes > everything is a datagram, and 16G datagrams aren't supported by any other > software. OK, so lets agree to a distinction here between requirements and solutions when it comes to scope. Contrary to what most folk accuse me of, I am very focused when it comes to solutions. Where I insist on a broad scope is when we consider requirements. So I don't want to work on design of a start from scratch messaging infrastructure in PGPvNext. However I do want PGPvNext to support the type of requirements that sort of work might anticipate. I find it really annoying when someone says 'there is no difference between options A and B, my friends and I prefer A so thats what we will do' and then when I point out that there are actually a lot of differences between the two because A can't support a large number of use cases that B does. Then they say "well those are not in scope". All requirements are always in scope as far as I am concerned. I might not be able to meet all of them. But having them on the table helps thinking about the problem at the right level of abstraction. So I don't want to do a protocol that combines push email (SMTP) with pull (e.g. dropbox) for a couple of years so certain patents expire (among other reasons). Or add real time video messaging, jabber etc. But I would like to make sure we don't foreclose the option. In particular I would like to see: * Convergence on JSON as the data model and JSON based encoding. * Data formats that handle very large chunks of data * Data formats that support real time streaming By large chunks of data, I mean Terabytes and up. If protocol convergence is achieved, I should be able to transfer the contents of my RAID-6 NAS with 4x6Tb drives by emailing them to its successor. I don't propose that we design such a protocol now. Unless you are living in one of the six houses served by the Google 100Gbs Ethernet you are going to be waiting a long time for ten Tb to move. But I do know folk at CERN who already have that size of problem and it won't be long before it does become relevant. > Evidence has changed: we do/don't keep transcripts around for evidence. We > do/don't think of digsigs as human signatures. We do/don't worry about > removal of files. We do/don't consider the wire to be a threat and we > do/don't consider our counterparty to be a threat. Looking at the current state of the art for collecting and maintaining digital evidence, I am appalled. The requirements for criminal cases are poor and the requirements for civil are practically non existent. From nobody Thu Apr 2 11:41: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 55F5D1A03C7 for ; Thu, 2 Apr 2015 11:41:02 -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 tcNtHmKEWP7D for ; Thu, 2 Apr 2015 11:40:56 -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 9C2CA1A1A2C for ; Thu, 2 Apr 2015 11:40:56 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id F2CB36D730; Thu, 2 Apr 2015 14:40:54 -0400 (EDT) Message-ID: <551D8D35.9020702@iang.org> Date: Thu, 02 Apr 2015 19:40:53 +0100 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] Option 4: Requirements vs. Solutions. 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, 02 Apr 2015 18:41:02 -0000 On 2/04/2015 19:26 pm, Phillip Hallam-Baker wrote: > On Thu, Apr 2, 2015 at 1:55 PM, ianG wrote: >> On 26/03/2015 03:56 am, Phillip Hallam-Baker wrote: > >> Storage has changed: we no longer consider a message over the wire as the >> same thing as a message at rest on disk. We do/don't keep video chat, we >> do/don't take naughty snaps using screen shots. We do/don't share huge >> files (movies) for which OpenPGP is entirely unsuited because it assumes >> everything is a datagram, and 16G datagrams aren't supported by any other >> software. > > OK, so lets agree to a distinction here between requirements and > solutions when it comes to scope. > > Contrary to what most folk accuse me of, I am very focused when it > comes to solutions. Where I insist on a broad scope is when we > consider requirements. With you all the way. > So I don't want to work on design of a start from scratch messaging > infrastructure in PGPvNext. However I do want PGPvNext to support the > type of requirements that sort of work might anticipate. I find it > really annoying when someone says 'there is no difference between > options A and B, my friends and I prefer A so thats what we will do' > and then when I point out that there are actually a lot of differences > between the two because A can't support a large number of use cases > that B does. Then they say "well those are not in scope". > > All requirements are always in scope as far as I am concerned. I might > not be able to meet all of them. But having them on the table helps > thinking about the problem at the right level of abstraction. +11 > So I don't want to do a protocol that combines push email (SMTP) with > pull (e.g. dropbox) for a couple of years so certain patents expire > (among other reasons). Or add real time video messaging, jabber etc. > But I would like to make sure we don't foreclose the option. In > particular I would like to see: > > * Convergence on JSON as the data model and JSON based encoding. > * Data formats that handle very large chunks of data > * Data formats that support real time streaming > > By large chunks of data, I mean Terabytes and up. If protocol > convergence is achieved, I should be able to transfer the contents of > my RAID-6 NAS with 4x6Tb drives by emailing them to its successor. That's great as a requirement. I agree. We need more like that. Now, may I make a humble suggestion as to process. How about you open up a google docs entitled "PGPvNext Requirements" and c&p the above paras under a heading "Data Formats". Then, make the google docs open edit. (Contrary to our historical claims, not everything we do is under attack by all of humanity all at the same time ... I've found that having an open-edit google docs does work and nobody seems to go in and muck around. And if they do, well, we can man-up and find another solution...) Or, I'm entirely open to any other solution eg github as long as it is widely accessible to everyone without requiring excessive enrollment (h/t to Derek). Does IETF have a favoured way of collaborating like a wiki? > I don't propose that we design such a protocol now. Unless you are > living in one of the six houses served by the Google 100Gbs Ethernet > you are going to be waiting a long time for ten Tb to move. But I do > know folk at CERN who already have that size of problem and it won't > be long before it does become relevant. Sure. Design it for the Petabyte. One day it will be needed. >> Evidence has changed: we do/don't keep transcripts around for evidence. We >> do/don't think of digsigs as human signatures. We do/don't worry about >> removal of files. We do/don't consider the wire to be a threat and we >> do/don't consider our counterparty to be a threat. > > Looking at the current state of the art for collecting and maintaining > digital evidence, I am appalled. The requirements for criminal cases > are poor and the requirements for civil are practically non existent. (offtopic) if it's a serious problem for you, you might want to talk to my friend Stephen who wrote the book on digital evidence. Contact me if you need an intro. http://www.stephenmason.eu/?page_id=10 iang From nobody Thu Apr 2 15:13: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 745D51A1BF8 for ; Thu, 2 Apr 2015 15:13:50 -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 2U-Ur7pgnp8w for ; Thu, 2 Apr 2015 15:13:49 -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 A1E7C1A01E2 for ; Thu, 2 Apr 2015 15:13:49 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so85105489igc.0 for ; Thu, 02 Apr 2015 15:13:49 -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=ZoJUQHV6wjGsZtLyGdCNbjLTNPWZiGsa1AR5oIxL3YY=; b=ikl9h1V8lRUwF9A12ca8EfKVvwalOAKo1sE2CIGx4pk5bbrCdRdIzqhgd+miOQYgq/ 6QKTYlQXCEKWR6hBo6sXrCt8qI48nyqNs69S43Ef7bBeUxiyBvswpuI5jK+w8CBc6eve kNTonkRRTt2eSVGBTXllwHOUzgBit6WqniDhE= 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=ZoJUQHV6wjGsZtLyGdCNbjLTNPWZiGsa1AR5oIxL3YY=; b=HrgrdWMsjLJpDgFdI1aMbEwFa0A1KLmbnweDcnPp+j/unzHOdLOPLxojlan+jnBTVS J1RXX9d4gl34PflL+2lROiW9aC8eeuLIJzeDPAtQ36Ed58W1V4SpGM5GC8yJM1VwlHVg LgeexQikvgbmvfaO7pycIt4/bWsC+XP2meBsU5/cbcsLeZigD6nb0XGdDaIYp0xvzkfe hZlR/cSPO5PDC73YWEaXPLXwhUuuVeKLIXFJON0+Ah3po4fYhAC/JpkNZcZGA36IRnsY jmBYgfql0trH7mVYTdUQQseIvRNDlCRNISgt+fiC0gs+bvjOd4PcCnvyDBbFxVXQYT9P L69w== X-Gm-Message-State: ALoCoQmGtEfwEIQlqdvkm1nKuCW5xoMsIrnbtKmtQaAoAY7YZHYcHPlpQQ/OQJWxHND7U+XT7gVZ X-Received: by 10.50.43.198 with SMTP id y6mr23723942igl.16.1428012828981; Thu, 02 Apr 2015 15:13:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.166.84 with HTTP; Thu, 2 Apr 2015 15:13:28 -0700 (PDT) In-Reply-To: <87d23negqu.fsf@alice.fifthhorseman.net> References: <551C3FAD.6040107@cs.tcd.ie> <87d23negqu.fsf@alice.fifthhorseman.net> From: Tom Ritter Date: Thu, 2 Apr 2015 17:13:28 -0500 Message-ID: To: Daniel Kahn Gillmor Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "openpgp@ietf.org" , Stephen Farrell Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 02 Apr 2015 22:13:50 -0000 I'm somewhere in between 2 & 3. I think dkg's list is quite good. -tom From nobody Fri Apr 3 00:35: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 076421A9164 for ; Fri, 3 Apr 2015 00:35: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 ZGoD_6GKZK61 for ; Fri, 3 Apr 2015 00:35:50 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c: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 C58171A9169 for ; Fri, 3 Apr 2015 00:35:49 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so131521087wib.1 for ; Fri, 03 Apr 2015 00:35:48 -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=EmVdsOA8g6v8QsgusakOMHS3p52uGktp/B8qDRwstts=; b=NyLbRRnbvvlMYGWMQnnKb2HTxHSqQ4XfIVLhFaWrQLG6/u55vRRWGrytXSbnqwMUiM cJ3wEx850M3ONkTpNJ5R6L+N5kvNBiuX40S0PjKaXQOViahQ4chmyCHyJmpKpjxuBbe/ Vp5bY4x5y1ow83HCoAw/B/SISouUpIgblmj0DpQB/bT5srnLPq6PcIZZExwoAq8wW7LO NjGCkW4c7c1vaKb1KK8xazSAsWpCwDoIgLDMx/S/scSPbErDViF0OVj6WqtMWxqZFW3J ZGMzoTurhBEDAIEmjwhMlSSunO3D0Nl2QHDyHvyTC/m2UgNqTZwabKtzg6mnPsGFd3xW seyA== X-Received: by 10.180.11.144 with SMTP id q16mr31964759wib.28.1428046548550; Fri, 03 Apr 2015 00:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.186.168 with HTTP; Fri, 3 Apr 2015 00:35:08 -0700 (PDT) From: Ryan Carboni Date: Fri, 3 Apr 2015 00:35:08 -0700 Message-ID: To: "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=001a11c24dd43fca670512ccffaa Archived-At: Subject: [openpgp] Is 64-bit blocks really insecure? 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, 03 Apr 2015 07:35:51 -0000 --001a11c24dd43fca670512ccffaa Content-Type: text/plain; charset=UTF-8 Given that the PKZIP cipher is a CRC stream cipher that requires 13 known bytes... but factoring in the deflate algorithm, this increases to gigabytes of data. This security of PKZIP was the reason why compression was included in PGP. --001a11c24dd43fca670512ccffaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given that the PKZIP cipher is a CRC stream cipher th= at requires 13 known bytes... but factoring in the deflate algorithm, this = increases to gigabytes of data.

This security of PKZIP was th= e reason why compression was included in PGP.
--001a11c24dd43fca670512ccffaa-- From nobody Fri Apr 3 02:48: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 34EF81A1B80 for ; Fri, 3 Apr 2015 02:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Fk2_USjnj6Co for ; Fri, 3 Apr 2015 02:48:03 -0700 (PDT) Received: from mail.pkware.com (mail.pkware.com [66.195.137.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709961A6EE9 for ; Fri, 3 Apr 2015 02:48:03 -0700 (PDT) Received: from MKEWIN-EXCHMBX.pkware.com ([fe80::3d97:334a:dd05:de6d]) by mkesrv-exchcas.pkware.com ([fe80::9499:c483:15e7:4032%10]) with mapi id 14.03.0224.002; Fri, 3 Apr 2015 04:48:02 -0500 From: Jim Peterson To: Ryan Carboni , "openpgp@ietf.org" Thread-Topic: [openpgp] Is 64-bit blocks really insecure? Thread-Index: AQHQbeDSJhZhhk6PdEWYxYhq6jNq5p07CLUg Date: Fri, 3 Apr 2015 09:48:01 +0000 Message-ID: <47A6DF37C2442A4BBDF41C82E041B5148DF50DF2@mkewin-exchmbx.pkware.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.108.85] Content-Type: multipart/alternative; boundary="_000_47A6DF37C2442A4BBDF41C82E041B5148DF50DF2mkewinexchmbxpk_" MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Is 64-bit blocks really insecure? 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, 03 Apr 2015 09:48:05 -0000 --_000_47A6DF37C2442A4BBDF41C82E041B5148DF50DF2mkewinexchmbxpk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFBLWklQIENSQyBhbGdvcml0aG0gd2FzIGRlc2lnbmVkIG9ubHkgYXMgYSBtZWFucyBmb3Ig Y2hlY2tzdW0gdmVyaWZpY2F0aW9uIHRvIGRldGVjdCBkcm9wcGVkIG9yIGRhbWFnZWQgYml0cyBp biBhIGNvbXByZXNzZWQgZmlsZS4gIFRoZSBQS1pJUCBjb21wcmVzc2VkIFpJUCBmaWxlIGZvcm1h dCBoYXMgZXZvbHZlZCB0byBpbmNsdWRlIHN1cHBvcnQgZm9yIHN0cm9uZyBlbmNyeXB0aW9uIGFs Z29yaXRobXMgKDNkZXMsIGFlcykgdXNpbmcgcHVibGljL3ByaXZhdGUga2V5IHBhaXJzIGZvbGxv d2luZyBlaXRoZXIgdGhlIFguNTA5IG9yIE9wZW5QR1Aga2V5IGZvcm1hdHMuDQoNCg0KRnJvbTog b3BlbnBncCBbbWFpbHRvOm9wZW5wZ3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJ5 YW4gQ2FyYm9uaQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwMywgMjAxNSAyOjM1IEFNDQpUbzogb3Bl bnBncEBpZXRmLm9yZw0KU3ViamVjdDogW29wZW5wZ3BdIElzIDY0LWJpdCBibG9ja3MgcmVhbGx5 IGluc2VjdXJlPw0KDQpHaXZlbiB0aGF0IHRoZSBQS1pJUCBjaXBoZXIgaXMgYSBDUkMgc3RyZWFt IGNpcGhlciB0aGF0IHJlcXVpcmVzIDEzIGtub3duIGJ5dGVzLi4uIGJ1dCBmYWN0b3JpbmcgaW4g dGhlIGRlZmxhdGUgYWxnb3JpdGhtLCB0aGlzIGluY3JlYXNlcyB0byBnaWdhYnl0ZXMgb2YgZGF0 YS4NClRoaXMgc2VjdXJpdHkgb2YgUEtaSVAgd2FzIHRoZSByZWFzb24gd2h5IGNvbXByZXNzaW9u IHdhcyBpbmNsdWRlZCBpbiBQR1AuDQo= --_000_47A6DF37C2442A4BBDF41C82E041B5148DF50DF2mkewinexchmbxpk_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIFBLWklQIENSQyBh bGdvcml0aG0gd2FzIGRlc2lnbmVkIG9ubHkgYXMgYSBtZWFucyBmb3IgY2hlY2tzdW0gdmVyaWZp Y2F0aW9uIHRvIGRldGVjdCBkcm9wcGVkIG9yIGRhbWFnZWQgYml0cyBpbiBhIGNvbXByZXNzZWQg ZmlsZS4mbmJzcDsgVGhlIFBLWklQIGNvbXByZXNzZWQNCiBaSVAgZmlsZSBmb3JtYXQgaGFzIGV2 b2x2ZWQgdG8gaW5jbHVkZSBzdXBwb3J0IGZvciBzdHJvbmcgZW5jcnlwdGlvbiBhbGdvcml0aG1z ICgzZGVzLCBhZXMpIHVzaW5nIHB1YmxpYy9wcml2YXRlIGtleSBwYWlycyBmb2xsb3dpbmcgZWl0 aGVyIHRoZSBYLjUwOSBvciBPcGVuUEdQIGtleSBmb3JtYXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IG9wZW5wZ3AgW21haWx0bzpvcGVucGdwLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlJ5YW4gQ2FyYm9uaTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDAz LCAyMDE1IDI6MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IG9wZW5wZ3BAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gW29wZW5wZ3BdIElzIDY0LWJpdCBibG9ja3MgcmVhbGx5IGluc2VjdXJlPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkdpdmVuIHRoYXQgdGhlIFBLWklQIGNpcGhlciBpcyBhIENSQyBzdHJl YW0gY2lwaGVyIHRoYXQgcmVxdWlyZXMgMTMga25vd24gYnl0ZXMuLi4gYnV0IGZhY3RvcmluZyBp biB0aGUgZGVmbGF0ZSBhbGdvcml0aG0sIHRoaXMgaW5jcmVhc2VzIHRvIGdpZ2FieXRlcyBvZiBk YXRhLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg c2VjdXJpdHkgb2YgUEtaSVAgd2FzIHRoZSByZWFzb24gd2h5IGNvbXByZXNzaW9uIHdhcyBpbmNs dWRlZCBpbiBQR1AuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_47A6DF37C2442A4BBDF41C82E041B5148DF50DF2mkewinexchmbxpk_-- From nobody Fri Apr 3 16:36: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 526141A90C0 for ; Fri, 3 Apr 2015 16:36:18 -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 fCBnok5hu5Dc for ; Fri, 3 Apr 2015 16:36:16 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 43C341A907B for ; Fri, 3 Apr 2015 16:36:16 -0700 (PDT) Received: by wgdm6 with SMTP id m6so121036276wgd.2 for ; Fri, 03 Apr 2015 16:36:15 -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=km9aBdkcEXaBpPDdEr27Ql0kG11eWcKLBSfOfTF67Bs=; b=TE7wEFfpb3ZEYWU6Y8dr9UAt2uxK4v1+uTLf/pdzk73PpalXuJI/CKIXaApue4/8fP MI0i3xAabIwOOkZ2NRgZc/nAObCRdoIopYko0zQi5v1fjTEopE+eVsgzXr/95eWKlUGw QusuuXQyF6klsON67DY18Ivmy4RnfLCySiKhY5SIFQg4JwRvMRcMzjYp48qXpno3wLTj H/0O9V5g41Oz+cQrrcPPtEeq4YkhUo05CbtiELHFLWBhVOmifztv7zUICLUIFTF9wDVo cTcejgVoqvkJiOOLIgSo/MvbUAXBYJ+GMzx12HLWLNMC9uXAm8XVUBwHlD4HYcUR79HH i5cQ== X-Received: by 10.194.79.226 with SMTP id m2mr9204232wjx.60.1428104175040; Fri, 03 Apr 2015 16:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.186.168 with HTTP; Fri, 3 Apr 2015 16:35:34 -0700 (PDT) In-Reply-To: <47A6DF37C2442A4BBDF41C82E041B5148DF50DF2@mkewin-exchmbx.pkware.com> References: <47A6DF37C2442A4BBDF41C82E041B5148DF50DF2@mkewin-exchmbx.pkware.com> From: Ryan Carboni Date: Fri, 3 Apr 2015 16:35:34 -0700 Message-ID: To: Jim Peterson Content-Type: multipart/alternative; boundary=047d7bf0c5380e40e90512da6a76 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Is 64-bit blocks really insecure? 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, 03 Apr 2015 23:36:18 -0000 --047d7bf0c5380e40e90512da6a76 Content-Type: text/plain; charset=UTF-8 "Most zippers available today implement only one of the compression methods defined in APPNOTE.TXT, called deflate. Deflate uses Huffman coding followed by a variant of Lempel-Ziv. Once the dictionary reaches a certain size, the process starts over. Since the Huffman codes for any of the data depend on a great deal of surrounding data, one is forced to guess the plaintext unless one has the original data. The difficulty of getting known plaintext was one reason Phil Zimmerman decided to use deflate in PGP [PGP98]. Practically speaking, if one has enough of the original file to get the thirteen bytes of plaintext required for the attack in [BK94], one has enough to break the encryption almost instantly." "The PKZIP stream cipher was designed by Roger Schaffely and is fully described in the file APPNOTE.TXT found in most PKZIP distributions. The internal state of the cipher consists of three 32-bit words: key0, key1, and key2. These values are initialized to 0x12345678, 0x23456789, and 0x34567890, respectively. The internal state is updated by mixing in the next plaintext byte. The first and third words are updated using the linear feedback shift register known as CRC- 32; the second word is updated using a truncated linear congruential generator. The output byte is the result of a truncated pseudo-squaring operation. (See Figure 1.) unsigned char " On Fri, Apr 3, 2015 at 2:48 AM, Jim Peterson wrote: > The PKZIP CRC algorithm was designed only as a means for checksum > verification to detect dropped or damaged bits in a compressed file. The > PKZIP compressed ZIP file format has evolved to include support for strong > encryption algorithms (3des, aes) using public/private key pairs following > either the X.509 or OpenPGP key formats. > > > > > > *From:* openpgp [mailto:openpgp-bounces@ietf.org] *On Behalf Of *Ryan > Carboni > *Sent:* Friday, April 03, 2015 2:35 AM > *To:* openpgp@ietf.org > *Subject:* [openpgp] Is 64-bit blocks really insecure? > > > > Given that the PKZIP cipher is a CRC stream cipher that requires 13 known > bytes... but factoring in the deflate algorithm, this increases to > gigabytes of data. > > This security of PKZIP was the reason why compression was included in PGP. > --047d7bf0c5380e40e90512da6a76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"Most zippers available today implement only one of t= he compression methods
defined in APPNOTE.TXT, called deflate. Deflate u= ses Huffman coding followed
by a variant of Lempel-Ziv. Once the diction= ary reaches a certain size, the process
starts over. Since the Huffman c= odes for any of the data depend on a great deal of
surrounding data, one= is forced to guess the plaintext unless one has the original
data. The = difficulty of getting known plaintext was one reason Phil Zimmerman
deci= ded to use deflate in PGP [PGP98]. Practically speaking, if one has enough<= br>of the original file to get the thirteen bytes of plaintext required for= the attack
in [BK94], one has enough to break the encryption almost ins= tantly."

"The PKZIP stream cipher was designed by Roger Sc= haffely and is fully described
in the file APPNOTE.TXT found in most PKZ= IP distributions. The internal
state of the cipher consists of three 32-= bit words: key0, key1, and key2. These
values are initialized to 0x12345= 678, 0x23456789, and 0x34567890, respectively.
The internal state is upd= ated by mixing in the next plaintext byte. The first and
third words are= updated using the linear feedback shift register known as CRC-
32; the = second word is updated using a truncated linear congruential generator.
= The output byte is the result of a truncated pseudo-squaring operation. (Se= e
Figure 1.)
unsigned char "

On Fri, Apr 3, 2015 at 2:48 AM, Jim Peterso= n <Jim.Peterson@pkware.com> wrote:

The PKZIP CRC algorithm w= as designed only as a means for checksum verification to detect dropped or = damaged bits in a compressed file.=C2=A0 The PKZIP compressed ZIP file format has evolved to include support for strong encryption algor= ithms (3des, aes) using public/private key pairs following either the X.509= or OpenPGP key formats.

=C2=A0

=C2=A0

From: openpgp = [mailto:openp= gp-bounces@ietf.org] On Behalf Of Ryan Carboni
Sent: Friday, April 03, 2015 2:35 AM
To: openpgp@ie= tf.org
Subject: [openpgp] Is 64-bit blocks really insecure?

=C2=A0

Given that the PKZIP = cipher is a CRC stream cipher that requires 13 known bytes... but factoring= in the deflate algorithm, this increases to gigabytes of data.

This security of PKZIP was the reason why compressio= n was included in PGP.


--047d7bf0c5380e40e90512da6a76-- From nobody Mon Apr 6 15:44: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 70C0B1ACD10 for ; Mon, 6 Apr 2015 15:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 mu3qOOvaID6f for ; Mon, 6 Apr 2015 15:44:37 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 764531ACD14 for ; Mon, 6 Apr 2015 15:44:35 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id A41D911C0164 for ; Tue, 7 Apr 2015 08:44:33 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YtjEe2cleZ8Z for ; Tue, 7 Apr 2015 08:44:19 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id DDE0111C0161 for ; Tue, 7 Apr 2015 08:44:13 +1000 (EST) Message-ID: <55230C3D.2070002@adversary.org> Date: Tue, 07 Apr 2015 08:44:13 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <551C3FAD.6040107@cs.tcd.ie> In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iUN54FlNoLgOTPDin78Lnoix8DIFgAbUD" Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 06 Apr 2015 22:44:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iUN54FlNoLgOTPDin78Lnoix8DIFgAbUD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/04/2015 5:57 am, Stephen Farrell wrote: > > So I think the volume and content of discussions over the > last few weeks clearly indicates a desire to do something > about openpgp, but that discussion doesn't seem to be closing > in on exactly what to do, in the IETF context. It'd help me > to try figure that out if folks would respond to this saying > which of the options below you think can make sense. Picking > more than one is fine, but if so, please say which you prefer. > Annotating/explaining your choice(s) is very welcome but > please try resist the temptation to change this into a chat > about a different set of options:-) Sure ... why not break my silence with this. > It would also really help me (and I suspect others) evaluate > messages if you could say something about how you fit into > the openpgp universe (e.g. "I wrote the foo implementation" > or "I run a thing with N people using pgp" or whatever). An > essay on that is not useful here, but a line or two could > be really good. I'm a long time user of PGP and GPG (about 20 years, I began with PGP 2.3a for DOS), co-founder of CryptoParty in Melbourne, privacy & civil liberties campaigner, current Treasurer of Pirate Party Australia, former Vice President of Linux Users of Victoria and professional geek (former Sun Systems Engineer). I've been training people with using GPG specifically for several years across a variety of industries. I've been lurking on this list for a while, a few years at least. > Anyway here's the options: >=20 > option 1: do nothing - there's nothing much to do or at least > not in the IETF or not within the IETF for the next >6 months. Ah, nope, I believe there are some things to do to some extent. Particularly in light of the legislation recently passed in my country (see below). > option 2: do maintenance work on rfc4880 - produce a 4880bis > with better crypto options at least, and debate any further > detailed changes during chartering - the charter will contain > a list of specific things to do and other things will be out > of scope (for now) I think this is the most viable option at the moment. We all know, for example, that there are significant changes coming with ECC becoming a viable option, so there are some things which could be tightened at the same time. I think the top of my list would have to be incorporating more of what's usually classed as SMTP headers in the encrypted portion of a (presumably PGP/MIME) message. Ideally everything after the data command is delivered to the SMTP server, but that might be pushing it a bit (though mail from and rcpt to commands should be all said server needs to do what it has to do). Obviously the WGs dealing with SMTP and probably POP3 and IMAP might have a thing or two to say about that. > option 3: do a major revision to openpgp - take rfc4880 as a > starting point but question all design decisions in the process > of developing a successor version of openpgp and write a > charter that allows for all such design decisions to be > questioned Maybe, there's no harm in questioning things, but the intended outcome would need to be clear. > option 4: move beyond openpgp (or smime) to develop a new > flavour of end-to-end security for interpersonal messaging, > possibly not that tightly coupled to email, but at least > supporting an email flavour I believe this is called starting a new WG to create and/or implement some new thing. While I've got nothing against that, there's a point where you just have to say, "hey this is a new project, but we've been inspired by what came before." > For options 2-4 one could include more or less work related to trust > models or key hierarchies/key distribution. If you would like to > include that kind of work please pick one of those below. If > pursuing any of these, we'd need a separate discussion about the > scope of that work and whether or not one specific approach ought be > standardised, but please let's not yet have that discussion until we > see that one of the "t" options below has a good bit of support. Maybe. Trust models always get a bit contentious because people inevitably don't consider some obscure use case or policy set that is not encountered often in their social or professional environs. I'm happy to have the discussion, but I suspect that a better approach would be to step back and provide recommendations for end users or communities to develop their own policies, but with a standardised method of communicating those policies to others. > Option 1 is easy. The list can continue to debate stuff, but there's > no IETF process stuff needed and no new RFCs on the horizon. I get > off the hook:-) Sorry dude, you're outta luck there. ;) > For option 2, or 2t we could start crafting a charter on the list > once we've gotten agreement that that's the goal. I don't think a > face-to-face BoF would be needed before forming a working group > unless the scope of the "t" part of 2t was proving hard to pin > down. (We could arrange some virtual audio meetings if that'd help > of course.) That could mean a working group is formed quite soon, > and that working group might choose to meet face-to-face in Prague > in July, or might prefer to work on the list only, or with some > audio meetings. I'd be in the latter camp, primarily contributing via email where possible, but this is Australia and in addition to the time difference we've just had mandatory data retention foisted on us, so a lot more of my energy is going to both political and technical solutions to dealing with a country where we're all suspects. Who'd've thought we'd come half-way around the globe and struggle through two centuries only to brand ourselves convicts again? Incredible. > And lastly, please let's not have an IETF process discussion or a > discussion about why the IETF is great or crap. If we see that > there's IETF stuff folks want to do and if those folks are willing > and able to implement/deploy the results then that's enough to be > going on with. If that happens I'll be sure to go play with my political party, there are actual problems which need solving all over the place and I don't have the time for kindergarden krap. Regards, Ben --=20 Ben McGinnes http://www.adversary.org/ Twitter: benmcginnes Writer, Systems Administrator, Trainer, ICT Consultant Encrypted email preferred, primary OpenPGP/GPG key: 0x321E4E2373590E5D OpenPGP/GPG key here: http://goo.gl/GVGwT and http://goo.gl/SDs0D OpenPGP/GPG key transition: http://www.adversary.org/keyswitch.txt.asc --iUN54FlNoLgOTPDin78Lnoix8DIFgAbUD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVIww9AAoJEH/y03E1x1U8LrgL/05UsoyRZygfFvuZJZviGzmV ccwYFovJOIjiA4vqExzj7ka9Pl5IJRt9DWEj9CFJ3KZhtOrBhQXxlPyDVDWdo2KI poi8ytU9TZSc/IsiHSQm6pfsRh/fFBIry/SYG3AMUgVMFc81A8Ki7uhcS8yfIuqc Mg/YAvjrrTPRUm/l1MB78uz4TPAj3Sw7VqtiCTl+sC4PURnj2hemJMFBaNYJ1Tw5 nTLdAzNgz43zx+ht1ETMC00onXjjWpmwu3oPrSnM7NQHLBh6UE+yQB9GBtasu7Vx KbgshF5snIadxAxl9fqF0EQLp7klGk4LmGx9i3mL6zSAMCzB6CVfge0ShCYufR6/ EDF4P6L/mij/qFSHcDQSX3mb5+JJbigy9vsUS7nrcfgVb6gupPdRQHaXswl8u8Ck Jhf4abkIeUPKrCNLoYH7VsyJDGKxbE+IUe6nfCZu4FdqENnZ4FylBswA7xqYik7T B/x7V97MoUG2i4/Z5F9NPeapzJt9huroWIe4QLZk8w== =wwyk -----END PGP SIGNATURE----- --iUN54FlNoLgOTPDin78Lnoix8DIFgAbUD-- From nobody Mon Apr 6 21:57: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 44E1C1B29B9 for ; Mon, 6 Apr 2015 21:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 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, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, 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 5yUlH84lPSIz for ; Mon, 6 Apr 2015 21:57:53 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 61E041B29C0 for ; Mon, 6 Apr 2015 21:57:34 -0700 (PDT) Received: by wiax7 with SMTP id x7so2302214wia.0 for ; Mon, 06 Apr 2015 21:57: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:from:date:message-id:subject:cc :content-type; bh=WeN47gSP9J9gkM3UOaZBvTTEZatDIiuIbV/ExWTTxqE=; b=YNMhVMo32181MJI9YhjsAC3jkSadGUe6Nm6V0S7kS6D54A8rjCnEN4PvZxOBN4FZVk W8kfZRquoMPbUESPuCk1wfC6aKY67n7GSb7d0SgbQC2KfGevsMCzwtclbMI5rLr3A/L5 IZTZI7B7LniHYk8riI9Rw28Gvuqkyo4csVdEPQHFXcFCuITxHLFz+Sj6bbO3numIo8qc GHiTsRA93P3GRUtqxx/+HyPCsvrdGmBIC7HLOfiljeXX6zPu3tG10SWiYEeMElcgf1Rf qsrXyHphCSTZ+LIuwbRczEJnX2bXIlhK2InbSZ37TcFGHPLCfPnRS9tpZX3kEqCCtfgm oOng== X-Received: by 10.180.90.243 with SMTP id bz19mr1020460wib.47.1428382653143; Mon, 06 Apr 2015 21:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.186.169 with HTTP; Mon, 6 Apr 2015 21:56:53 -0700 (PDT) In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> From: Ryan Carboni Date: Mon, 6 Apr 2015 21:56:53 -0700 Message-ID: Cc: "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=f46d0402dd6ea4e10505131b404e Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 07 Apr 2015 04:57:54 -0000 --f46d0402dd6ea4e10505131b404e Content-Type: text/plain; charset=UTF-8 I learned how to use PGP within the past 11 months. All I have to say is this: PGP will always be a kludge, it is best as a manual method of transmitting files through insecure means. Anything more requires a total rewrite of the standard. I support option two. I'm going to disappear after this, but I suggest the following language: something something encrypting more than 2^35 bytes through a 64-bit block cipher, warn the user that the cipher is less than theoretically secure, particularly if the data is not compressed. something something PGP encryption should default to AES. --f46d0402dd6ea4e10505131b404e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I learned how to use PGP within the past 11= months.

All I have to say is this: PGP will always be a kludg= e, it is best as a manual method of transmitting files through insecure mea= ns. Anything more requires a total rewrite of the standard.
I support op= tion two. I'm going to disappear after this, but I suggest the followin= g language:

something something encrypting more than 2^35 byte= s through a 64-bit block cipher, warn the user that the cipher is less than= theoretically secure, particularly if the data is not compressed.
something something PGP encryption should default to AES.
--f46d0402dd6ea4e10505131b404e-- From nobody Mon Apr 6 22:11: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 47EA31B29E2 for ; Mon, 6 Apr 2015 22:11:14 -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 aIwX4IfwkLs0 for ; Mon, 6 Apr 2015 22:11:13 -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 E8E801B29E1 for ; Mon, 6 Apr 2015 22:11:12 -0700 (PDT) Received: by layy10 with SMTP id y10so33807130lay.0 for ; Mon, 06 Apr 2015 22:11: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 :cc:content-type; bh=I9+qjuKjQdM8hXXPzykw60hB22yqlgg1MzBOYjliuA4=; b=PevtcMdjQQWQAGZ06I3PR4b7Ncr6TwSgyo2A3gKqscx1KmQ3EGr6uNWB4Pa3AQJ0wf azctuZdJY366umPGTvFZeyMLvBQuKOizebSMCN54peE4Gv5s6TVUacAfH4px3/MNEt+v Eu1+++CVPg478FVdmXbNrrjMGDw18Ct6KhTBl7Sl0tLDGh8oO4fm+6YqvvO8A4xtiRDC 1WsJrmDRV7s7JYBVI9sHrS1sLFkhVGRIEU7iu7aX5v85Ky9FL2I0yHJ+ttE6kpCjm4mW L1866tbJT120q/6uS/lfLYrNXxhXBRL7u2Aug/4et9rD/ARRgjRNEAa96S6X2Zo485Gj 683A== MIME-Version: 1.0 X-Received: by 10.152.23.99 with SMTP id l3mr16350736laf.61.1428383471268; Mon, 06 Apr 2015 22:11:11 -0700 (PDT) Received: by 10.25.43.19 with HTTP; Mon, 6 Apr 2015 22:11:11 -0700 (PDT) In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> Date: Tue, 7 Apr 2015 01:11:11 -0400 Message-ID: From: DataPacRat To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 07 Apr 2015 05:11:14 -0000 On Wed, Apr 1, 2015 at 2:57 PM, Stephen Farrell wrote: > how you fit into the openpgp universe I'm a random internet citizen with a long-standing interest in cryptography and a suspicion of centralized certificate authorities. > Anyway here's the options: My chief preference would be for 2t; at least improving the RFC seems to be worth doing, but I suspect improving the trust model and key distribution system would make an even more positive impact. (My secondary choices would be for 3t and 4t.) Thank you for your time, -- DataPacRat "Then again, I could be wrong." From nobody Tue Apr 7 02:10: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 C4E2C1B3345 for ; Tue, 7 Apr 2015 02:10:06 -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 gSJjjSLd_b2T for ; Tue, 7 Apr 2015 02:10:04 -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 01D751B3347 for ; Tue, 7 Apr 2015 02:10:03 -0700 (PDT) Received: by lagv1 with SMTP id v1so37244818lag.3 for ; Tue, 07 Apr 2015 02:10:02 -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=mkQvAFCXyYrNnlPKvoZSqIjc8v+TTplhjMjTkmDWals=; b=ND8IchBUKPPoO1VrzbvcTja0JTfTQjiXfAbVezRH5HiYudUrGtXUgHKD0Pl4MlGiB5 P6hK79zeqK5bAIPIxfu76CnulSLGI48zgEElWhxKgG+mlblbaRE4ZisE6t+JxVfwljJ4 RCB6RVELyxPonT+9kGRsVDaxykNylNzwIgMnQNNUMP1042QC2XkKICqDcKp6JPit+0Us ttH/Hdr7972zkdOVz7e2Rt9XXMZgtScVGAF9LGRWvkxPBMyb4vM0StBJMr0zUWEN9xSb 0mUt5kllGCETvL5qY5eh35ph6eOTCWMEf3V36Mmvb1YEe8VMy8tzGH0UKmxFAxsVZDyX CyBA== X-Gm-Message-State: ALoCoQmklw1Ygwvq44+lehTORuzxFj0HWEQbGsJ8QWnACIiWNvUTalauI2gx1jyZLY/f6FM1Xh5F X-Received: by 10.113.4.105 with SMTP id cd9mr17223292lbd.38.1428397802286; Tue, 07 Apr 2015 02:10:02 -0700 (PDT) Received: from [192.168.1.157] (77.18.0.36.tmi.telenormobil.no. [77.18.0.36]) by mx.google.com with ESMTPSA id j3sm443616laf.22.2015.04.07.02.10.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2015 02:10:01 -0700 (PDT) Message-ID: <55239EE7.5080003@sumptuouscapital.com> Date: Tue, 07 Apr 2015 11:09:59 +0200 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 , Stephen Farrell , "openpgp@ietf.org" References: <551C3FAD.6040107@cs.tcd.ie> <87d23negqu.fsf@alice.fifthhorseman.net> In-Reply-To: <87d23negqu.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 07 Apr 2015 09:10:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/01/2015 10:27 PM, Daniel Kahn Gillmor wrote: > On Wed 2015-04-01 14:57:49 -0400, Stephen Farrell wrote: >> option 2: do maintenance work on rfc4880 - produce a 4880bis with >> better crypto options at least, and debate any further detailed >> changes during chartering - the charter will contain a list of >> specific things to do and other things will be out of scope (for >> now) > > I think i favor this approach, ideally *without* adding trust model > work into the mix. > > Trying to explicitly declare a standardized trust model would be a > mistake for the WG. it's a huge rat hole, and a "one trust model > fits all" approach is probably illegitimate at some deeper level, > since different people have different adversaries. > I agree with DKG on both favoring Option 2 and avoiding definition of trust model as part of this update; if anything this can be provided as an informative rfc outside of the scope of this WG, it is only relevant to the extent we would need additional mechanisms to implement them, and the current mechanism provide good flexibility for various implementations already. DKGs list of things to look into seems like a good starting point (although I haven't reviewed it in detail), I also seem to recall discussion about whether a hard expiry should be introduced that should be possible within option 2 if we want to. whoami: Running https://sks-keyservers.net and one of the SKS developers. - -- - ---------------------------- 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 - ---------------------------- "Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital." (Aaron Levenstein) -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVI57iAAoJEP7VAChXwav69DQIALEm1b3LV/P9xMltRPaPE6O4 augOw9kV2a1r11za6nAPqUxKTnfkZZqGU/MFwvScIO1rtoy8VQnrYIVJp5WRP6iK QRuWoq0JFaIXgwHZC5oYiNSOHiT03Qx67dy1qCvL0Cp1j5OxkautmUImnrsnZmPH cwgisGoLJXkITp+MJbLMzOctc2rbgLhJ38gsToV2+Zu679TVv8WmUw25Oc0yPyLO O/9bUqUWbZdof9rX7uGf8Zv665d3c3r+5Dlwkrqnduy61lo/fwtQ65IvVq2tKU1F D8t0RBVnjz1J9esNfTDyvEj7Vlo3Hpz2Lowb8bIv8GxWWmR1TQEyNgZaLxUE3AY= =cQG/ -----END PGP SIGNATURE----- From nobody Tue Apr 7 06:02: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 B05601A87B8 for ; Tue, 7 Apr 2015 06:02: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 YHGgIF4qX2aM for ; Tue, 7 Apr 2015 06:02:31 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 20DD31A87AF for ; Tue, 7 Apr 2015 06:02:31 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so41921902lbb.0 for ; Tue, 07 Apr 2015 06:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=pl437PL94chVFGVGuOSyUC9Jee40TYA1tA5O7kMr6BM=; b=A9nlY+OYnqRruweHfAPwpa01XZtOvBW4qtpsYlNBvyMvpF+Lv+fatYgwhFwQlOUBPh fKucLvtBgQqOQKy0L3RpGV6b+t38yvHgXZJ1QrYP/VrPtKnlhBxM3MPJo1rgWKqWt9Vu kvl9JHcf0b3R8ib+Oa3afOZrH7KoeFt0/+stSAyE2gBkFkJEwFEQiel/ft+czRjsIn7Y p3VDKVyaI1mTrGIk0mjAqt3UciLLLjJmFFmOnBBLhgD/6Akxb7r3VDHn4kSlDoOFSwsf 4iFqfKhvUHewSWYhGRzAhWZCYIUxvPyE81urXizZht6m9lKrDWOjwVwLV3NeoSrAed+r dl2w== MIME-Version: 1.0 X-Received: by 10.112.42.233 with SMTP id r9mr18452266lbl.58.1428411749581; Tue, 07 Apr 2015 06:02:29 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Tue, 7 Apr 2015 06:02:29 -0700 (PDT) Date: Tue, 7 Apr 2015 09:02:29 -0400 X-Google-Sender-Auth: eStp21gcFrXNVCBSr_S-UygiAIA Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] MIME signature impact 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, 07 Apr 2015 13:02:32 -0000 If we are doing an overhaul of PGP, one of the things that needs fixing is a way to send signed messages that does not get in the way. http://www.explainxkcd.com/wiki/index.php/1181:_PGP 'If this is there, its probably fine'. Problem with the ASCII approach is that most of the important stuff in mail is in the attachments. When PGP was invented, mail had huge amounts of lossage that would break things for no reason. That is no longer the case. Most mail transport is 8-bit clean. A way to use a PGP key for DKIM would be nice. And PGP should make use of the same code paths in MIME that mean that S/MIME headers don't get in the way. From nobody Tue Apr 7 10:36: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 E2F451B38B8 for ; Tue, 7 Apr 2015 10:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBmsFydaHNfC for ; Tue, 7 Apr 2015 10:35:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF21B38F2 for ; Tue, 7 Apr 2015 10:35:37 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 9643BF984 for ; Tue, 7 Apr 2015 13:35:35 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6238A20088; Tue, 7 Apr 2015 12:35:24 -0500 (CDT) From: Daniel Kahn Gillmor To: IETF OpenPGP In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 07 Apr 2015 13:35:24 -0400 Message-ID: <87d23f4zab.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] MIME signature impact 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, 07 Apr 2015 17:36:00 -0000 On Tue 2015-04-07 09:02:29 -0400, Phillip Hallam-Baker wrote: > If we are doing an overhaul of PGP, one of the things that needs > fixing is a way to send signed messages that does not get in the way. I think you're saying we need to figure out how to make cleartext signatures that can live somewhere that non-compatible mail user agents won't show them to the (presumably confused) user. (this is not at all about encrypted+signed messages, right? I'll leave those for a separate discussion) [ i also think this might not be in-scope for the revised OpenPGP working group if we're just going to work on 4880bis -- it could be relevant for CMS messages as well, and maybe we should find some other place to have this discussion. that said, more clarifications below ] I agree with you that securing only the text part (and not even the character encoding) of an e-mail message is insufficient today. It also sounds to me like you think that PGP/MIME clearsigned messages do "get in the way". In particular, confused MUAs will present them as attachments that confused users then try to download and "open", and they "don't work". Is that right? Placing the signature in the message header is problematic when any intermediary modifies the content of a message. RFC 2015 makes it quite clear that multipart/signed message parts should be treated as bytewise opaque -- mail transfer agents should not modify them. Moving the signature to the header and leaving the rest of the message undecorated seems likely to encourage in MTAs the temptation to fiddle with the content. The more that message signatures fail due to MTA fiddling, the more users will become careless about bad-signature alerts, so i think that's a pretty risky outcome. Do you see some way that we can effectively signal the need for message (or message-part) opacity to MTAs while not causing UI/UX confusion for users trapped on ignorant MUAs? --dkg From Neil_Hunsperger@symantec.com Tue Apr 7 10:39: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 C75641B38FE for ; Tue, 7 Apr 2015 10:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ObQiYRQuGD4S for ; Tue, 7 Apr 2015 10:39:03 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E281B38F4 for ; Tue, 7 Apr 2015 10:39:03 -0700 (PDT) X-AuditID: d80ac3f3-f791d6d0000019a4-cd-5524163694ff Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 8A.FA.06564.63614255; Tue, 7 Apr 2015 18:39:02 +0100 (BST) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1YfXSm-0000qM-Kp; Tue, 07 Apr 2015 13:39:00 -0400 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.2.96]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 7 Apr 2015 10:38:39 -0700 From: Neil Hunsperger To: Phillip Hallam-Baker , IETF OpenPGP Date: Tue, 7 Apr 2015 10:38:38 -0700 Thread-Topic: [openpgp] MIME signature impact Thread-Index: AdBxMyCbkC5D7BQQQBe4aOrCD9UqJgAIroxw Message-ID: <14D026C7F297AD44AC82578DD818CDD038F0C36BC5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RouteViaPGP: true X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsXCZeB6StdMTCXU4MhxSYuGfw/ZLSZ+mM3o wORxYfVXJo8lS34yBTBFcdmkpOZklqUW6dslcGXc3n+OpeAEd8XJOQUNjGs5uxg5OSQETCRu nm1hhLDFJC7cW8/WxcjFISTwjlHi098HjBDOW0aJu9172CGc5YwS7V/ngbWwAbWvnd7GBGKL CARLzJ0/mQ3EZhFQkfi45zELiC0soCPxb8IJRogaXYk9DUtYIWwjiXlLFrOD2LwCURLvL18G 6xUSCJB4Pv02UC8HB6dAoMS9W2BhRqDrvp9aA7aKWUBc4taT+UwQVwtILNlznhnCFpV4+fgf K0S9qMSd9vWMEPU6Egt2f2KDsLUlli18zQyxVlDi5MwnLBC9whJtv16zT2AUn4VkxSwk7bOQ tM9C0r6AkWUVo0xJabFhcW5JfmlJQWqFgbFecWVuIjDCkvWS83M3MQKj7AbX4c87GH/vcTzE KMDBqMTDe4tdJVSINbEMqPIQowQHs5II7y8BoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeP52i oUIC6YklqdmpqQWpRTBZJg5OqQZG2frK2BTeM98Z/C4eLfl3gn2RUtnX8OeBr7g7TLyeK75Z P33lvQ8J5xSuO8hppJ15VnPy9Z4+n8frtz1VUD/juudT+LQpmxJ2db89X3Y1a1pZnLrVy/P6 TFf/Riz8fkhonsD0/pYvFm/n9uS4GXGs5O17OrfG+q6rqMiNuM9fS47OE3oxY/mXx0osxRmJ hlrMRcWJALu5A9uuAgAA Archived-At: Subject: Re: [openpgp] MIME signature impact 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, 07 Apr 2015 17:41:30 -0000 > From: openpgp [mailto:openpgp-bounces@ietf.org] On Behalf Of Phillip > Hallam-Baker >=20 > If we are doing an overhaul of PGP, one of the things that needs > fixing is a way to send signed messages that does not get in the way. >=20 > http://www.explainxkcd.com/wiki/index.php/1181:_PGP >=20 > 'If this is there, its probably fine'. >=20 > Problem with the ASCII approach is that most of the important stuff in > mail is in the attachments. >=20 One solution is PGP Partitioned format, which supports in-line signatures f= or ASCII bodies and detached signatures for other email content: http://www.ietf.org/mail-archive/web/openpgp/current/msg01811.html >=20 > When PGP was invented, mail had huge amounts of lossage that would > break things for no reason. That is no longer the case. Most mail > transport is 8-bit clean. >=20 > A way to use a PGP key for DKIM would be nice. And PGP should make use > of the same code paths in MIME that mean that S/MIME headers don't get > in the way. There is a standard for PGP/MIME clear-signing content and the result looks= a lot like S/MIME. Major S/MIME enabled mail clients (e.g. Microsoft Outlo= ok and Mozilla Thunderbird) render it nicely when PGP/MIME-aware software i= s absent so I would consider that staying out of the way. See: https://tools.ietf.org/rfc/rfc3156.txt Using the above as a starting point, what aspect of a MIME signature's impa= ct is left to solve? Cheers, -Neil From nobody Tue Apr 7 16:15: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 047C51A8704 for ; Tue, 7 Apr 2015 16:15:15 -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 2MrLJq9FRP2i for ; Tue, 7 Apr 2015 16:15:12 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 18FB81A7014 for ; Tue, 7 Apr 2015 16:15:12 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6DFBB4767B; Tue, 7 Apr 2015 23:15:11 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4293447676; Tue, 7 Apr 2015 23:15:11 +0000 (GMT) Received: from tereva.kendall.corp.akamai.com (sfo-wp8n3.kendall.corp.akamai.com [172.19.34.11]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 22E5F8003C; Tue, 7 Apr 2015 23:15:11 +0000 (GMT) From: Brian Sniffen To: Stephen Farrell , "openpgp\@ietf.org" In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Apr 2015 19:15:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 07 Apr 2015 23:15:15 -0000 > messages if you could say something about how you fit into > the openpgp universe (e.g. "I wrote the foo implementation" I run a thing with 50-200 people using PGP, all scattered GnuPG implementations. At some level I care about GnuPG cross-version compatibility, and have little need for a standard for today's needs. I would like to have an OpenPGP-like standard for authentication and secrecy of detached objects---for example, for subresource integrity on the Web, and in ways that support and cooperate with TLS trust models. I am hopeful but not optimistic about JOSE getting this right in its first years. Both of those would be improved by standardized support for modern cryptographic choices, and for getting past some of the older choices that haven't held up well. Therefore, I prefer option 2. I'd be happy with the eventual results of option 3, but I expect it to take an awfully long time. I don't think option 4 is helped by standardization---yet. > option 2t: option 2 + add some trust model/key management > option 3t: option 3 + add some trust model/key management > option 4t: option 4 + add some trust model/key management I value having a *different* trust model than X.509/TLS in the space of available designs. I'm not sure whether that means (t): it's good to have a standard way of endorsing a binding of name to key, and it's good to have a standard language for use in describing names. A finer grain for user ID packets would be nice. If that's a (t) conversation, then I think [2t,3t] is wise. Otherwise, [2,3], in that order. -Brian > > For options 3, 3t, 4 or 4t I do think we'd likely need to > have a face-to-face BoF meeting as there'd be a lot to > consider and pin down and higher bandwidth is much better > for that. In that case, the important date is June 5th > which is the next cutoff date for requesting such a meeting > for the Prague IETF to be held July 19-24. [1] (June 5th > might seem like a long way off, but it's not really so if > we needed such a meeting then starting to work towards that > soon would be much better than doing so late.) > > Also, some of this can be done sequentially. For example, > as an area director I'm very happy re-chartering existing > working groups to add more tasks where those groups have > demonstrated the ability to be productive. In my experience > that can work better than starting out with the hard/ambitious > stuff as the very first thing to do. That might argue for > starting with option 2 and then, if all goes well, discussing > whether or how to tackle option 3 or 4. (We could even charter > a group to do the maintenance work for option 2 and when that's > done to then discuss how to re-charter for one of the more > complicated choices.) I'd suggest however, we ignore such > sequential processing for now, see what folks prefer as a > goal, and then think about whether there's a way to get to > what people want via sequencing things cleverly. So, just > for now, please don't suggest "2, followed by 3" even if > that's something you like the sound of - I think folks' > initial responses will probably make it obvious if we need > a chat about that. > > And lastly, please let's not have an IETF process discussion > or a discussion about why the IETF is great or crap. If we > see that there's IETF stuff folks want to do and if those > folks are willing and able to implement/deploy the results > then that's enough to be going on with. > > Thanks, > S. > > [1] https://www.ietf.org/meeting/important-dates-2015.html#ietf93 > > > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- Brian Sniffen Akamai Technologies From nobody Wed Apr 8 01:06: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 206E61B2DBA for ; Wed, 8 Apr 2015 01:06:36 -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 LaCgfRn3haFw for ; Wed, 8 Apr 2015 01:06:34 -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 278001B2DB7 for ; Wed, 8 Apr 2015 01:06:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yfl0K-0002yB-Fo for ; Wed, 08 Apr 2015 10:06:32 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YfkvI-0005vS-MY; Wed, 08 Apr 2015 10:01:20 +0200 From: Werner Koch To: Stephen Farrell References: <551C3FAD.6040107@cs.tcd.ie> 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, 08 Apr 2015 10:01:20 +0200 In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> (Stephen Farrell's message of "Wed, 01 Apr 2015 19:57:49 +0100") Message-ID: <87y4m31227.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] ways forward wrt IETF wg - please try answer by Apr 8th 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, 08 Apr 2015 08:06:36 -0000 On Wed, 1 Apr 2015 20:57, stephen.farrell@cs.tcd.ie said: > option 2: do maintenance work on rfc4880 - produce a 4880bis > with better crypto options at least, and debate any further > detailed changes during chartering - the charter will contain > a list of specific things to do and other things will be out > of scope (for now) I prefer this option. > option 2t: option 2 + add some trust model/key management I would like to see an _informational_ RFC describing the trust models currently in use. Trust models should not be part of OpenPGP because I fear that we would end up like PKIX by trying to unify the demands of many different parties. Shalom-Salam, Werner p.s. I wrote and maintain most parts of GnuPG (which includes a complete PKIX implementation in addition to OpenPGP). -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 8 03:56: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 3DBFC1B2F7F for ; Wed, 8 Apr 2015 03:56:40 -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 4xq4DI607QRB for ; Wed, 8 Apr 2015 03:56:38 -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 D368B1B2F86 for ; Wed, 8 Apr 2015 03:56:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yfner-0004i4-Bg for ; Wed, 08 Apr 2015 12:56:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yfnbs-0006Ym-Lu; Wed, 08 Apr 2015 12:53:28 +0200 From: Werner Koch To: Phillip Hallam-Baker 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> 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, 08 Apr 2015 12:53:28 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 2 Apr 2015 12:09:44 -0400") Message-ID: <87mw2i28nr.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: Christoph Anton Mitterer , Brian Sniffen , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 10:56:40 -0000 On Thu, 2 Apr 2015 18:09, phill@hallambaker.com said: > Since the key servers won't allow me to revoke the cert for the > private key I have no control over, I think that it would be more They allow that but you need to have a key prepared for this: 5.2.3.15. Revocation Key (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of fingerprint) Authorizes the specified key to issue revocation signatures for this key. Class octet must have bit 0x80 set. If the bit 0x40 is set, then this means that the revocation information is sensitive. Other bits are for future expansion to other kinds of authorizations. This is found on a self-signature. ("gpg --edit-key, addrevoker" to set such a key and "gpg --desig-revoke" to issue a revocation) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 8 05:11: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 667FB1B30B1 for ; Wed, 8 Apr 2015 05:11:43 -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 obJLmQjYGpUb for ; Wed, 8 Apr 2015 05:11:41 -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 A628E1B30A4 for ; Wed, 8 Apr 2015 05:11:33 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YfopQ-0005Lc-3S for ; Wed, 08 Apr 2015 14:11:32 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YfonF-0006li-4c; Wed, 08 Apr 2015 14:09:17 +0200 From: Werner Koch To: Neil Hunsperger References: <14D026C7F297AD44AC82578DD818CDD038F0C36BC5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.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: Wed, 08 Apr 2015 14:09:16 +0200 In-Reply-To: <14D026C7F297AD44AC82578DD818CDD038F0C36BC5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> (Neil Hunsperger's message of "Tue, 7 Apr 2015 10:38:38 -0700") Message-ID: <87iod6255f.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: Phillip Hallam-Baker , IETF OpenPGP Subject: [openpgp] MIME micalg aparemter (was: MIME signature impact) 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, 08 Apr 2015 12:11:43 -0000 On Tue, 7 Apr 2015 19:38, Neil_Hunsperger@symantec.com said: > One solution is PGP Partitioned format, which supports in-line > signatures for ASCII bodies and detached signatures for other email That was a kludge to support Outlook. With Outlook < 2010 it was not possible to send/receive arbitrary MIME mails because Outlook's crypto layer processed all multipart/{encrypted,signed} mail before a plugin could get it hands on it. Well, there is a hack to work around that which we used in GpgOL but it is using non-documented behaviour. With Outlook 2010 a new API exists to get the raw unprocessed mail before the crypto layer kicks in and thus it very likely that one can implement PGP/MIME without resorting to the above hack. IIRC, the Partitioned format has no means to guarantee the integrity of the entire message and thus you can replace attachments. > Using the above as a starting point, what aspect of a MIME signature's > impact is left to solve? The micalg parameter should be removed or made optional. The micalg needs to be emitted before the signed data and the signature. It is useless for OpenPGP and a major hassle for any one-pass creation of signatures because only the signing tool can determine the used hash algorithm from the set of signing keys. This should not be controversial because may MUAs use a fixed string anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 8 06:06: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 776221A6EF1 for ; Wed, 8 Apr 2015 06:06:03 -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 6p4A7uXuUfrS for ; Wed, 8 Apr 2015 06:06:02 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010: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 8D3831A1EF6 for ; Wed, 8 Apr 2015 06:05:46 -0700 (PDT) Received: by lagv1 with SMTP id v1so65409252lag.3 for ; Wed, 08 Apr 2015 06:05:45 -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=k13lB5F0L4q03oLk1R8QW86JyfpcaUBOKxLnRlG+CVU=; b=AGsTHR3RB37UtJtMcha4AtHgVMaTDv6TRWvMMBDyPS5qY9zehrwiDZ72j+wfPekl6k HuFmRE6QYTaps2LMtJGyHc4LX+RxCGwmrQ4a659Zm31oXAigwQfgsP1YLkogEuc9ELyK J15Q7nRnHVH2dhIgk0jnv9khkWYnx9KLIyIcDrs37nPQQ3QdUzPWi+RNr0gTtdaOrAi7 Vs5ZXzjUsXJTpFkr8D9prw1Q837JDI1mnqy621FvV9xovsz4dDQLZ/199l9aK79pi7hI ZAKAaOXL0sqwiQ8BEIM8as6PK0sWvGGNhWpR7cXegTPaSLTYdPAMnDekplxx+R/zZkqe uyeg== MIME-Version: 1.0 X-Received: by 10.152.6.1 with SMTP id w1mr16127962law.91.1428498345083; Wed, 08 Apr 2015 06:05:45 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 06:05:44 -0700 (PDT) In-Reply-To: <87mw2i28nr.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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> Date: Wed, 8 Apr 2015 09:05:44 -0400 X-Google-Sender-Auth: Xjv1dxFIIG_JHNsnHrzV1skDyy8 Message-ID: From: Phillip Hallam-Baker To: Werner Koch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , Brian Sniffen , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 13:06:03 -0000 On Wed, Apr 8, 2015 at 6:53 AM, Werner Koch wrote: > On Thu, 2 Apr 2015 18:09, phill@hallambaker.com said: > >> Since the key servers won't allow me to revoke the cert for the >> private key I have no control over, I think that it would be more > > They allow that but you need to have a key prepared for this: > > 5.2.3.15. Revocation Key > > (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of > fingerprint) > > Authorizes the specified key to issue revocation signatures for this > key. Class octet must have bit 0x80 set. If the bit 0x40 is set, > then this means that the revocation information is sensitive. Other > bits are for future expansion to other kinds of authorizations. This > is found on a self-signature. > > ("gpg --edit-key, addrevoker" to set such a key and "gpg --desig-revoke" > to issue a revocation) If I could remember my passphrase then I would not need to revoke. My point here is that if we want to get a billion people using encrypted mail then it has to offer iPhone class usability, not OK for 1990s usability. There are plenty of ways that the scheme could be fixed. Since key server enrollment can be made automatic, it would be pretty easy to renew the enrollment once every n months and discard keys that have not been renewed for 5 years or for more than a year if there is a replacement key. Having the key servers continue to regurgitate false or stale data forever because there is no way to stop them does not seem like an acceptable plan to me. From nobody Wed Apr 8 06:11: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 B0E2A1A6F27 for ; Wed, 8 Apr 2015 06:11:41 -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 T1Mte1bzWYf5 for ; Wed, 8 Apr 2015 06:11:39 -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 3857F1A1EF6 for ; Wed, 8 Apr 2015 06:11:39 -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 9595F5FB39 for ; Wed, 8 Apr 2015 13:11:37 +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 5bF4F-rJIj1z for ; Wed, 8 Apr 2015 13:11:35 +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 ; Wed, 8 Apr 2015 13:11:35 +0000 (UTC) Message-ID: <1428498695.5137.17.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 08 Apr 2015 15:11:35 +0200 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-hRTpsXzz8kPLebMKQll/" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 13:11:41 -0000 --=-hRTpsXzz8kPLebMKQll/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-08 at 09:05 -0400, Phillip Hallam-Baker wrote:=20 > If I could remember my passphrase then I would not need to revoke. Which is why people are ever since suggested to create their revocation when the create their key. > My point here is that if we want to get a billion people using > encrypted mail then it has to offer iPhone class usability, not OK for > 1990s usability. Crypto is not an iPhone. Just accept that you can't make a system securely usable if people aren't willing to learn how it works and put some effort into it. > Since key > server enrollment can be made automatic, it would be pretty easy to > renew the enrollment once every n months and discard keys that have > not been renewed for 5 years or for more than a year if there is a > replacement key. Removing a key (and its associated information like revocations or other signatures) from the keyservers is generally a break of security, as it allows for blocking or similar attacks. And attacker could make a valid key removed just by blocking keys that haven't been "renewed". Chris. --=-hRTpsXzz8kPLebMKQll/ 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwODEzMTEz NVowTwYJKoZIhvcNAQkEMUIEQFQBwJ/LLAQhVTBOHSVBPTJqpaSRccGtIdDo6VF2dDOglq0+xd/i eudKPBcMoP+TiHCryo5rnczOMapk61Nf+9MwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCwAYyRchs5s6zx5LBAzspwj6/TWEXK R23PqkGtSfreKSECpmrEj1xCsIijpI0J3mFGEZfCSJ7JwcDTNAygaxo4WJpu12+/uq/jfyGX1/Ji uyQAvHzQA1BxFnkoX+E3vKlmQdYyyRV5gYci94WdZMw2T50b/UWB/9UAIBo/A10XZehtctcG720e zn+8tyl/tKkqy+CtoZ4tPXxMt4G0K2WhHLbncd75xviynJdqprS8yq8UL2wX5Fp4WlAQ5nzBPfun MaAd3SoVN3/ubDXkFcYcnmUy8U31jYnHW3iUON3m3NY925ciqhmhJuHfbkjyft+s3gVFSiKUQt87 df1a2+ylAAAAAAAA --=-hRTpsXzz8kPLebMKQll/-- From nobody Wed Apr 8 06:23: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 9A0811A6F33 for ; Wed, 8 Apr 2015 06:23:38 -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 783Y7l471ZLT for ; Wed, 8 Apr 2015 06:23:37 -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 C484E1A6F2B for ; Wed, 8 Apr 2015 06:23:36 -0700 (PDT) Received: by labbd9 with SMTP id bd9so54356861lab.2 for ; Wed, 08 Apr 2015 06:23:35 -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=woQzpr1Oxj35oSvzu4dBNVgKywv1lYfBgxUcUSECUvc=; b=miS7R6azT0KjjiYuPNgQCXc8D550S6IUw+gWQsMyL51mnhbfZI+qkjqJhcpVcUKjLK C2tQ8qmRx5U8/K3zThkbaWQtoBfYO5aEYvy77ynRqwcf1OnjlH3x108ApYq8K7JZxsoh 2JeLrbDIZhc2OJnFJtUMRfghzdle003Kkk4NtK1lIDOOJ9zvPFPCkBO2Yd8On7+6Zkrz LG0Uc44nSu2Yt1L47NhGCe4Sy/VWrbYkhPAJ2gC78oMyM1ZrLEkBmU5FxdpIG5RyYQZA TdRP2Cug2IINy/wvKrwDFdzasl070QKTP+4VgwQsUrtIigFwGSeeANlI7B+jEM2dIsAJ aH+Q== MIME-Version: 1.0 X-Received: by 10.112.83.234 with SMTP id t10mr11714009lby.118.1428499415188; Wed, 08 Apr 2015 06:23:35 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 06:23:35 -0700 (PDT) In-Reply-To: <1428498695.5137.17.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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <1428498695.5137.17.camel@scientia.net> Date: Wed, 8 Apr 2015 09:23:35 -0400 X-Google-Sender-Auth: ifcU495pEMnIEwujWkkCQgXtohc 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] OpenPGP private certification 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, 08 Apr 2015 13:23:38 -0000 On Wed, Apr 8, 2015 at 9:11 AM, Christoph Anton Mitterer wrote: > On Wed, 2015-04-08 at 09:05 -0400, Phillip Hallam-Baker wrote: >> If I could remember my passphrase then I would not need to revoke. > Which is why people are ever since suggested to create their revocation > when the create their key. > > >> My point here is that if we want to get a billion people using >> encrypted mail then it has to offer iPhone class usability, not OK for >> 1990s usability. > Crypto is not an iPhone. Mine is. Mine has no impact at all unless the user is asking 'is this secure'. I have code that shows this is possible and practical. > Just accept that you can't make a system securely usable if people > aren't willing to learn how it works and put some effort into it. I don't accept that because it isn't true. > >> Since key >> server enrollment can be made automatic, it would be pretty easy to >> renew the enrollment once every n months and discard keys that have >> not been renewed for 5 years or for more than a year if there is a >> replacement key. > Removing a key (and its associated information like revocations or other > signatures) from the keyservers is generally a break of security, as it > allows for blocking or similar attacks. > And attacker could make a valid key removed just by blocking keys that > haven't been "renewed". And what is to stop someone maliciously loading up a broken key or an entirely fraudulent key? I don't think that you can make a good case for circulating bad data in case it might be good. From nobody Wed Apr 8 06:33: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 2DC7A1A86E0 for ; Wed, 8 Apr 2015 06:33: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 x3jcxMMkH7S5 for ; Wed, 8 Apr 2015 06:33:53 -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 1D8521A86F4 for ; Wed, 8 Apr 2015 06:33: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 mailgw02.dd24.net (Postfix) with ESMTP id A33D15FB11; Wed, 8 Apr 2015 13:33:51 +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 HTm7iNn7nTCF; Wed, 8 Apr 2015 13:33: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 mailgw02.dd24.net (Postfix) with ESMTPSA; Wed, 8 Apr 2015 13:33:49 +0000 (UTC) Message-ID: <1428500028.5137.26.camel@scientia.net> From: Christoph Anton Mitterer To: Phillip Hallam-Baker Date: Wed, 08 Apr 2015 15:33:48 +0200 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <1428498695.5137.17.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-ZuJfPBhQ8dtkTPiaXEeH" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 13:33:58 -0000 --=-ZuJfPBhQ8dtkTPiaXEeH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-08 at 09:23 -0400, Phillip Hallam-Baker wrote:=20 > > Crypto is not an iPhone. > Mine is. Believing that you're secure with a proprietary driven system, from a company which is known to have worked with mass surveillance organisation (and if it's just because they were forced so by law), is naive - at best. > > Removing a key (and its associated information like revocations or othe= r > > signatures) from the keyservers is generally a break of security, as it > > allows for blocking or similar attacks. > > And attacker could make a valid key removed just by blocking keys that > > haven't been "renewed". >=20 > And what is to stop someone maliciously loading up a broken key or an > entirely fraudulent key? Nothing, but neither would these be trusted nor has it anything to do with the security breaches that arise from removing data from the keyservers. > I don't think that you can make a good case for circulating bad data > in case it might be good. A key and associated information doesn't become "bad" just because the user didn't "renew" it. We have explicit mechanisms for users to mark their keys as no longer be usable, either by revocation signatures or by giving them an expiration date. Both methods let the decision in the hand of the user and don't place it into the hand of potentially evil other parties. And if with "bad data" you mean corrupted keys in the sense of broken uploads or that like, then this is obviously something different. Such key would immediately be ruled out and not because someone decided that it suddenly doesn't match some criteria anymore. Regardless of how you put it, removal of valid keys (valid in the sense of "conforming to the OpenPGP format" is a break of security. C. --=-ZuJfPBhQ8dtkTPiaXEeH 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwODEzMzM0 OFowTwYJKoZIhvcNAQkEMUIEQHmz4PLoCL/GUeyhPIavsGnLb1ytfce0NXv/mFDCJ9E1HzNWAOpq 6Mhp5qgYhF+lBoLK805y8LAMT5R4+zWmv+wwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAd2tL45WXYpojSiU/cATlCH8WgJMJs uSkKY/YK1I3eQTpGZ74yEkYMhDm7Zg0wkGr6n6JFU9xmyvmNaCF+ANFMWZbBoTy04nkFls8Gtk6v WTXKVSsuCqwMHHX7kdWHkxoxd/FVI5Dasi3KbxknkbwMlRVLYxvYB/mo945N9Q7hp+ErG1nGU2c2 Vx7w5tJVo8eCzcgNcnbuuk3MlS1aIsTeBTuYv+VWayL8bv9Ytr7GDj6psVewB2sY73QMnJzF5FNm nf9yGiw3yVr0+6t73dYw6ZL8yHjqNo5BfApFsX9hAfWVhkEPLzA/JEKnDoyjCgCR8blpGSn8J1tG xMshnZbKAAAAAAAA --=-ZuJfPBhQ8dtkTPiaXEeH-- From nobody Wed Apr 8 06:41: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 164181A873D for ; Wed, 8 Apr 2015 06:41:38 -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 oUbCaOAcA45e for ; Wed, 8 Apr 2015 06:41:34 -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 A26EC1A8718 for ; Wed, 8 Apr 2015 06:41:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YfqEX-0006xQ-1Y for ; Wed, 08 Apr 2015 15:41:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yfq8L-00072F-MC; Wed, 08 Apr 2015 15:35:09 +0200 From: Werner Koch To: Phillip Hallam-Baker 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> <87mw2i28nr.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, 08 Apr 2015 15:35:09 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 8 Apr 2015 09:05:44 -0400") Message-ID: <87vbh6zqsy.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: Christoph Anton Mitterer , Brian Sniffen , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 13:41:38 -0000 On Wed, 8 Apr 2015 15:05, phill@hallambaker.com said: > My point here is that if we want to get a billion people using > encrypted mail then it has to offer iPhone class usability, not OK for > 1990s usability. If that is the goal you only need to care about 140 character messages or other useless status messages ;-). Actually I prefer 1990s use of mail instead of todays 50% of mails are going through Compuserve^WGmail. But yeah, I am on a lost position with that. > There are plenty of ways that the scheme could be fixed. Since key > server enrollment can be made automatic, it would be pretty easy to > renew the enrollment once every n months and discard keys that have It is about mail. Mail addresses are defined by the DNS. Bind the keys to the DNS and your are done. This needs support from the mail providers, though. I doubt that we will be able to deploy a large, encrypted, anonymous, and decentralized mail network unless we can build upon a transport layer to solve the basic problems of todays Internet. For now we need the help of some central services to get things going. > Having the key servers continue to regurgitate false or stale data > forever because there is no way to stop them does not seem like an > acceptable plan to me. Think of signature verification. It should work even after a mail/key association has been disolved for example after a provider change. I agree that this is onluy a problem for a smaller group but this is something a keyserver network can be useful even after the migration of the public key store from keyserver to more controlled service (DNS, Web, whatever). Deleting keys from the keyservers is thus not going to work. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 8 06: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 8820A1A875E for ; Wed, 8 Apr 2015 06:44:04 -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 rmUWGAZyNniZ for ; Wed, 8 Apr 2015 06:44:03 -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 D2C4F1A8755 for ; Wed, 8 Apr 2015 06:44:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 58251E2036; Wed, 8 Apr 2015 09:44:01 -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 09328-04; Wed, 8 Apr 2015 09:43:59 -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 4E935E203A; Wed, 8 Apr 2015 09:43:59 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t38Dhv2Z013086; Wed, 8 Apr 2015 09:43:57 -0400 From: Derek Atkins To: Phillip Hallam-Baker 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> <87mw2i28nr.fsf@vigenere.g10code.de> Date: Wed, 08 Apr 2015 09:43:57 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 8 Apr 2015 09:05:44 -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: IETF OpenPGP , Christoph Anton Mitterer , Werner Koch , Brian Sniffen , Derek Atkins , Daniel Kahn Gillmor Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 13:44:04 -0000 Phillip Hallam-Baker writes: > On Wed, Apr 8, 2015 at 6:53 AM, Werner Koch wrote: >> On Thu, 2 Apr 2015 18:09, phill@hallambaker.com said: >> >>> Since the key servers won't allow me to revoke the cert for the >>> private key I have no control over, I think that it would be more >> >> They allow that but you need to have a key prepared for this: >> >> 5.2.3.15. Revocation Key >> >> (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of >> fingerprint) >> >> Authorizes the specified key to issue revocation signatures for this >> key. Class octet must have bit 0x80 set. If the bit 0x40 is set, >> then this means that the revocation information is sensitive. Other >> bits are for future expansion to other kinds of authorizations. This >> is found on a self-signature. >> >> ("gpg --edit-key, addrevoker" to set such a key and "gpg --desig-revoke" >> to issue a revocation) > > If I could remember my passphrase then I would not need to revoke. > > My point here is that if we want to get a billion people using > encrypted mail then it has to offer iPhone class usability, not OK for > 1990s usability. Werner's point is that you can set up anyone to be your designated revoker. It doesn't have to be *YOUR* key, you can designate your mother, your wife, your child, or even your, gasp, CA!! to be a designated revoker. > There are plenty of ways that the scheme could be fixed. Since key > server enrollment can be made automatic, it would be pretty easy to > renew the enrollment once every n months and discard keys that have > not been renewed for 5 years or for more than a year if there is a > replacement key. That's not the same thing as actually *revoking* the key. > Having the key servers continue to regurgitate false or stale data > forever because there is no way to stop them does not seem like an > acceptable plan to me. This is also a reasonable goal, but completely separate from revoking your key. Revocation is (as you well know) a cryptographic assertion, not a "database" concept. Indeed, you would want to continue to distribute a revoked key so that people who have it cached locally will update with the revocation data! -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 8 07:00: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 6147A1AC39F for ; Wed, 8 Apr 2015 07:00:35 -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 2WdjSDLMAGoX for ; Wed, 8 Apr 2015 07:00:29 -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 632B71A9174 for ; Wed, 8 Apr 2015 07:00:16 -0700 (PDT) Received: by laat2 with SMTP id t2so59563769laa.1 for ; Wed, 08 Apr 2015 07:00: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=F/qq5CxkGQjvc+CY7YcgPU3f7EcggHKL/qjNQZDhM8Y=; b=DAIYRBOPx3FtpSdYCexWM0ifF/a7j2wC9vfHEJdBQSQrwgUo9B2I31A33CFRVqnRki RTLfS1MKHs9cCiVT5T0Uu79ZA1WpilpcJkshx6RH2TsTz7gzXn1ukLabnZwWBjHcxNnI ggsZhMMH3wI8e9iEpkysGN6sPMMxgMhMD+RMYBVzAQfXMzwWPZ2lk0fXUobZvYjyIzw9 Bege0NPBA5DNWg4rK4iTug4TBO0fVGLeoGZT1d8+c3r8FPjNTtsPZKIkWNYcilXHN0GP zOwbcyPmReLvUf6RghzWv3MS1TSJuL1EmG+TrqNkj+wQlbIRR7lbX4CMxcpf2bQ2ctIQ sWbw== MIME-Version: 1.0 X-Received: by 10.112.161.66 with SMTP id xq2mr23426078lbb.103.1428501614830; Wed, 08 Apr 2015 07:00:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 07:00:14 -0700 (PDT) In-Reply-To: <1428500028.5137.26.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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <1428498695.5137.17.camel@scientia.net> <1428500028.5137.26.camel@scientia.net> Date: Wed, 8 Apr 2015 10:00:14 -0400 X-Google-Sender-Auth: Lav6EjmumPcM1uxB7YnFmDpdnHA 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] OpenPGP private certification 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, 08 Apr 2015 14:00:35 -0000 On Wed, Apr 8, 2015 at 9:33 AM, Christoph Anton Mitterer wrote: > On Wed, 2015-04-08 at 09:23 -0400, Phillip Hallam-Baker wrote: >> > Crypto is not an iPhone. >> Mine is. > Believing that you're secure with a proprietary driven system, from a > company which is known to have worked with mass surveillance > organisation (and if it's just because they were forced so by law), is > naive - at best. All the code is up on sourceforge and always has been. http://prismproof.org/ As for working with folk involved in mass surveillance, that is inevitable in our industry. All of us have, yourself included. CERN has always been a prime target of intelligence agencies. Putting all the boffins in one place so they could be watched was one of the primary reasons it was funded in the first place. From nobody Wed Apr 8 07:15: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 1252C1B30EB for ; Wed, 8 Apr 2015 07:15:45 -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 QWGSAylgs2pv for ; Wed, 8 Apr 2015 07:15:44 -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 8E7141B30DB for ; Wed, 8 Apr 2015 07:15:43 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so64586554lbb.2 for ; Wed, 08 Apr 2015 07:15:42 -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=hcntff9u+Mn3sAYlo9dnVudtUhIXx1dzE9RGNitXO1w=; b=MBfCbCjqAfH8NVFBXOn0baPuC/SXlkOImrCOhZQCeQ9y5FFPmeNRpLrB7Z0qBNLZ5R 1a+x7toq24S5TD9F0WiUBzCyGLqMBxNVKdIqPUBRp8z8TVTAJsfBbZsOsYhe1XfNHfk1 f1R0k7fqwXzGGzDGUFSCDTb45fzsfziuKv0q0ltj/rigB0Rz+KpVK84MCOWz/IrZoC1z yvOdWpjW9Z2+W9YTFZWAWS6TKdGYiCADGwOB9OojKLTYgNbcW2ux8Ka5M9b9oiDi3yH9 BIkuWOcVprWVZIInlY2DpNwkg+vXOL7A0+IfEHfPlb/xaszMPW+4Sc96wKIVuFtdK/Hn UDlg== MIME-Version: 1.0 X-Received: by 10.112.151.226 with SMTP id ut2mr23820630lbb.55.1428502542076; Wed, 08 Apr 2015 07:15:42 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 07:15:41 -0700 (PDT) In-Reply-To: <87vbh6zqsy.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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <87vbh6zqsy.fsf@vigenere.g10code.de> Date: Wed, 8 Apr 2015 10:15:41 -0400 X-Google-Sender-Auth: Gahud3c39zHcc2c_bwxBsygHlP0 Message-ID: From: Phillip Hallam-Baker To: Werner Koch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , Brian Sniffen , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 14:15:45 -0000 On Wed, Apr 8, 2015 at 9:35 AM, Werner Koch wrote: > On Wed, 8 Apr 2015 15:05, phill@hallambaker.com said: > >> My point here is that if we want to get a billion people using >> encrypted mail then it has to offer iPhone class usability, not OK for >> 1990s usability. > > If that is the goal you only need to care about 140 character messages > or other useless status messages ;-). > > Actually I prefer 1990s use of mail instead of todays 50% of mails are > going through Compuserve^WGmail. But yeah, I am on a lost position with > that. > >> There are plenty of ways that the scheme could be fixed. Since key >> server enrollment can be made automatic, it would be pretty easy to >> renew the enrollment once every n months and discard keys that have > > It is about mail. Mail addresses are defined by the DNS. Bind the keys > to the DNS and your are done. This needs support from the mail > providers, though. I really don't like the use of the DNS for any scheme requiring more than host level granularity. We have tried to put user email addresses in the DNS from the very start [RFC1035]. It has never worked. Personally, I believe that owning your personal DNS name is as important for security as having a keypair. I have a huge part of my brand invested in hallam@gmail.com which I don't own. Which is why I switched to phill@hallambaker.com for ietf work. But I have yet to win that argument. I really don't like having ICANN as my root CA either. DNSSEC is a monolithic, single rooted scheme which I don't consider very trustworthy because of that. We do need trust hierarchies for key management. But each individual should be the root of their personal hierarchy. >> Having the key servers continue to regurgitate false or stale data >> forever because there is no way to stop them does not seem like an >> acceptable plan to me. > > Think of signature verification. It should work even after a mail/key > association has been disolved for example after a provider change. I > agree that this is onluy a problem for a smaller group but this is > something a keyserver network can be useful even after the migration of > the public key store from keyserver to more controlled service (DNS, > Web, whatever). Deleting keys from the keyservers is thus not going to > work. I don't think anyone has signature validation done right today. All signatures are broken unless they are enrolled in an append-only log. To verify a signature, you need to go back in time to the point where the signature was created and check the signature in that time context. This implies that all the cryptographic credentials should be enrolled as well. Which is something I am working on right now. But in JSON, not ASN.1. The expiry of the hash chain patent is an opportunity to do interesting stuff that was encumbered before. From nobody Wed Apr 8 08:32: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 6A4A71B3230 for ; Wed, 8 Apr 2015 08:32: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 pAYFBSDfUTlp for ; Wed, 8 Apr 2015 08:32:08 -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 30FC21A1B0D for ; Wed, 8 Apr 2015 08:32:08 -0700 (PDT) Received: by igblo3 with SMTP id lo3so41561284igb.0 for ; Wed, 08 Apr 2015 08:32:07 -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=LrPPXoUZ4QPE+WYNChK5yd4vpX36eYu1Kk5vKrssdFc=; b=z5B0GRD6OkOyRa0PJGzi9WW+tILOP/4eI7U4Mi3pgxkliMs8uMk6m4sHGVJBbzPQLK hyBLt5k4vnFBHPcQeNttDDlZ/qEU+Uv1YCdNVzmO2c/f7kAQjAzGmw6EAC5d1W36mEvK 1uJhw3UvFo3sR03vRGRyAHMBxIgtrwav8G+8NzwDglpCFWvCUH3fvLRU0eslbPFcdQJz LAU/tdi+Y9UiaLWKnO4gAFUm5DVUhVz2gjN8tSOIu8yRXkx2+E/3vxxvu64ezngJ/DLw 6zOA3aPO1wbidq586d+ullYKWdduNLoHROyDosYg46HG49aoN3XergHlDecqReyUt5cl IO8g== X-Received: by 10.50.97.41 with SMTP id dx9mr12661393igb.1.1428507127741; Wed, 08 Apr 2015 08:32:07 -0700 (PDT) MIME-Version: 1.0 References: <1427138741.10191.48.camel@scientia.net> In-Reply-To: <1427138741.10191.48.camel@scientia.net> From: David Leon Gil Date: Wed, 08 Apr 2015 15:32:07 +0000 Message-ID: To: Christoph Anton Mitterer , openpgp@ietf.org Content-Type: multipart/alternative; boundary=047d7b10cd53e886070513383b7a 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, 08 Apr 2015 15:32:13 -0000 --047d7b10cd53e886070513383b7a Content-Type: text/plain; charset=UTF-8 Brief update on plans for deprecation: The tracking issue is at https://github.com/yahoo/end-to-end/issues/31 Please feel free to open another issue if you have specific objections. I will either be convinced by your arguments, and change the plan, or explain why I don't. On Mon, Mar 23, 2015 at 12:25 PM Christoph Anton Mitterer < calestyo@scientia.net> wrote: > On Tue, 2015-03-17 at 11:04 -0400, Derek Atkins wrote: > > 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. > > 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. > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --047d7b10cd53e886070513383b7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brief update on plans for deprecation: The tracking issue is at https://github.com/yahoo/end= -to-end/issues/31

Please feel free to open another issue if you = have specific objections. I will either be convinced by your arguments, and= change the plan, or explain why I don't.

On Mon, Mar 23, 2015 at 12:25 PM Christoph Anton Mitterer <calestyo@scientia.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Tue, 2015-03-17 at 11:04 -0400, Derek Atki= ns wrote:
> Show me an MUA that does this, please?=C2=A0 None of the OpenPGP-aware= MUAs
> I've ever used have this feature, as far as I know.=C2=A0 I suppos= e 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 a= bility
> 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.
_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--047d7b10cd53e886070513383b7a-- From nobody Wed Apr 8 08:41: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 524661B3299 for ; Wed, 8 Apr 2015 08:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_41=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 FJGvQMzMWR5C for ; Wed, 8 Apr 2015 08:41:50 -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 64AE01B3284 for ; Wed, 8 Apr 2015 08:41:44 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so77572811ieb.0 for ; Wed, 08 Apr 2015 08:41:43 -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=73cP5C8NwilIPwWH1PVFOecIBJhCxk4KeCKwAIQN30s=; b=EY1QybbFU8D+JXGk7iC8xu/+8zMwBvh072CfmTVNzCvcVCyZOOsYDPGLuqCvGRZCtl +vvMEzywia+kg4NsW1X+kZIzUL6YjkWAu7q/pPngmqgcfw+wrmtom1Hv1jcaxm3WkL+d e6mirdci/5Mp7ik/qoZoOH+B9S+fOpt69P1+ygQqa3eY3RQ3MIVxaaoPU3aNTs1xLBw4 oHFPfs7xYW2ZNoNPzvv8xXADkYYCEdOX1yqrNufVJ6+YvV3n+3vvb93YWqRekPY8da70 mZk8hqxl7Ee+vNSQux8GLrJcxbj3AUrxEayRddhrRBSxs0Q8VfJyuSWtK7M16+C+vMFv eliw== X-Received: by 10.107.14.141 with SMTP id 135mr39464614ioo.15.1428507703843; Wed, 08 Apr 2015 08:41:43 -0700 (PDT) MIME-Version: 1.0 References: <551C3FAD.6040107@cs.tcd.ie> In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> From: David Leon Gil Date: Wed, 08 Apr 2015 15:41:43 +0000 Message-ID: To: Stephen Farrell , "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=001a113fefc23f201e0513385e55 Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 08 Apr 2015 15:41:54 -0000 --001a113fefc23f201e0513385e55 Content-Type: text/plain; charset=UTF-8 Stephen: Thank you for the terrific summary! -- As several people have pointed this out: I wanted to apologize for my absurd pomposity on the list: Saying 'Yahoo requests' is clearly inappropriate for an IETF discussion. I'm very glad that the IETF places a high value on technical arguments. So...mea maxima culpa. (In my partial defense, I was kind of blindsided by the pace of discussion; I had a mandate to get something out about our deprecation plans prior to OSS release of our branch of E2E. Which is at github.com/yahoo/end-to-end, by the way.) -- So: I work for Yahoo on their side of the End-to-End project, in close collaboration with Google. Yahoo's goal is to provide E2E email encryption 'for the 90%': typical webmail users, who aren't familiar with crypto. We're hopeful that -- in the 1 year timeframe -- E2E encryption will be available for all Yahoo webmail users. (This would be a somewhat larger deployment than the ~ 1.5m recentish keys in the SKS system.) I'd really like to limit the scope of the OpenPGP WG to email (possibly, for the moment, email sans attachments[*]), where there's a clear interoperability story. Unfortunately, with, e.g., Google's recent pull-out from XMPP, the interoperability story for instant messaging is really unclear right now. I don't want to see the interoperability of end-to-end encrypted email be negatively affected by that: email remains really, really important. [*]: Given that both Google and Yahoo are moving to 'out-of-band' attachments via cloud storage, I may not be able to get much buy-in on anything other than a spec for distributing symmetric file-encrypting-keys and download URLs along with email. (I'm thinking, here, of something resembling Pond's 'detachments'.) -- Responses to options, in (weak) order of preference: Preferred: Option 3: Major revision. The goals of OpenPGP are relevant. But -- after four incremental revisions -- the spec has grown from something simple to something unmanageably complex. I think that experience from the TLS WG shows that changes of (at least) the scale of TLS1.3 will be required. Risk: This will be a lot of work for Stephen...and the rest of us. And there are a lot of issues that will be really controversial. -- Preferred: Option 1: Talk for another six months. Get some more deployment experience from Yahoo, Google, and similar projects using 1. OpenPGPv4 2. and things designed to be concrete proposals for OpenPGPv5 and then take action. Risks: Half-a-dozen new message formats in the interim, potential for participant 'lock-in' to drive later discussion rather than technical merits. -- Acceptable, depending on scope: Option 2: Minor revisions to OpenPGPv4 in the interim, specification of a 'simple' OpenPGPv4 profile, and then discussion of OpenPGPv5 in six months. My main concern is that this will require a lot of effort, which may distract from the bigger picture issues. If this happens, specific things I'd like to see: 1. One of curve448 (per IRTF I-D), E-521, or E/Fq(M607) specified as an alternative for ECDH, possibly with a better KDF (for the first two, implemented by Mike Hamburg's 'decaf' library, there's working, MIT-licensed code) 2. A revision to WK's Ed25519 spec to require that inputs are always from SHA2-512. (I and our cryptographers are unhappy with anything else.) 3. A backwards-compatible extension to SEIPD packets that is a sound(ish) AEAD mode for modern implementations. (This appears to be feasible, though a bit of a hack.) 4. A spec for HTML-mail-friendly signatures that *doesn't* require PGP/MIME support. (PHB has pointed out that base64 confuses non-crypto-geeks. This has been Yahoo's experience as well.) -- Unacceptable: Option 4. This would include IM, as I understand it. Three issues: 1. Likely requires different approach to crypto than in the email case. (E.g., Axolotl, MAC-and-continue.) 2. Implementations will have completely different APIs. 3. No real point without interoperability at the messaging layer, which largely no longer exists...regrettably.[*] [*] I'm hopeful that some of the WebRTC work may eventually result in a return to interoperability, but they already have a security model compatible with 'End-to-End' security. -- Probably unacceptable: Any of the 't' options. (Except, perhaps, an informational RFC about the web of trust, provided that it takes into account the incentives against key rotation it creates.) Both Google and Yahoo have committed to building out a key transparency system for our users. And Yahoo is expending significant resources to ensure that it will be viable for providers smaller than us to participate in such a system. This work will likely eventually be in scope for Transparency-WG, but we're not far enough along to be able to commit to any specific proposal at this time. Limited exception: Jelle van den Hooof of MIT has a clever proposal to use DKIM+a form of KT for bootstrapping trust in the interim. (This could be adapted to TOFU, as well.) A proposal along those lines might be interesting as a stopgap. - David On Wed, Apr 1, 2015 at 11:58 AM Stephen Farrell wrote: > > Hi all, > > So I think the volume and content of discussions over the > last few weeks clearly indicates a desire to do something > about openpgp, but that discussion doesn't seem to be closing > in on exactly what to do, in the IETF context. It'd help me > to try figure that out if folks would respond to this saying > which of the options below you think can make sense. Picking > more than one is fine, but if so, please say which you prefer. > Annotating/explaining your choice(s) is very welcome but > please try resist the temptation to change this into a chat > about a different set of options:-) > > It would also really help me (and I suspect others) evaluate > messages if you could say something about how you fit into > the openpgp universe (e.g. "I wrote the foo implementation" > or "I run a thing with N people using pgp" or whatever). An > essay on that is not useful here, but a line or two could > be really good. > > Please try respond to this if you can before Wed April 8th > and I'll try summarise whatever we get back to the list after > that, and we may or may not have a plan of action at that > point - we'll see I guess. > > And pretty please do change the message subject if you want > to follow up and discuss something from someone else's response. > That'll at least make my life a little easier when it comes > to trying to summarise back to the list but it'll also make it > easier for folks to check if I've mucked up in how I summarise > (and I muck up a lot, sadly:-). > > Anyway here's the options: > > option 1: do nothing - there's nothing much to do or at least > not in the IETF or not within the IETF for the next >6 months. > > option 2: do maintenance work on rfc4880 - produce a 4880bis > with better crypto options at least, and debate any further > detailed changes during chartering - the charter will contain > a list of specific things to do and other things will be out > of scope (for now) > > option 3: do a major revision to openpgp - take rfc4880 as a > starting point but question all design decisions in the process > of developing a successor version of openpgp and write a > charter that allows for all such design decisions to be > questioned > > option 4: move beyond openpgp (or smime) to develop a new > flavour of end-to-end security for interpersonal messaging, > possibly not that tightly coupled to email, but at least > supporting an email flavour > > For options 2-4 one could include more or less work related > to trust models or key hierarchies/key distribution. If you > would like to include that kind of work please pick one of > those below. If pursuing any of these, we'd need a separate > discussion about the scope of that work and whether or not > one specific approach ought be standardised, but please > let's not yet have that discussion until we see that one of > the "t" options below has a good bit of support. > > option 2t: option 2 + add some trust model/key management > option 3t: option 3 + add some trust model/key management > option 4t: option 4 + add some trust model/key management > > So that's for choices. Remember it's ok to pick more than > one with which you could live, but please be clear about > which you prefer. > > I'd also like to talk about how we might process some of > the above if we establish rough consensus for one of 'em. > > Option 1 is easy. The list can continue to debate stuff, > but there's no IETF process stuff needed and no new RFCs > on the horizon. I get off the hook:-) > > For option 2, or 2t we could start crafting a charter on > the list once we've gotten agreement that that's the goal. > I don't think a face-to-face BoF would be needed before > forming a working group unless the scope of the "t" part of > 2t was proving hard to pin down. (We could arrange some > virtual audio meetings if that'd help of course.) That > could mean a working group is formed quite soon, and that > working group might choose to meet face-to-face in Prague > in July, or might prefer to work on the list only, or > with some audio meetings. > > For options 3, 3t, 4 or 4t I do think we'd likely need to > have a face-to-face BoF meeting as there'd be a lot to > consider and pin down and higher bandwidth is much better > for that. In that case, the important date is June 5th > which is the next cutoff date for requesting such a meeting > for the Prague IETF to be held July 19-24. [1] (June 5th > might seem like a long way off, but it's not really so if > we needed such a meeting then starting to work towards that > soon would be much better than doing so late.) > > Also, some of this can be done sequentially. For example, > as an area director I'm very happy re-chartering existing > working groups to add more tasks where those groups have > demonstrated the ability to be productive. In my experience > that can work better than starting out with the hard/ambitious > stuff as the very first thing to do. That might argue for > starting with option 2 and then, if all goes well, discussing > whether or how to tackle option 3 or 4. (We could even charter > a group to do the maintenance work for option 2 and when that's > done to then discuss how to re-charter for one of the more > complicated choices.) I'd suggest however, we ignore such > sequential processing for now, see what folks prefer as a > goal, and then think about whether there's a way to get to > what people want via sequencing things cleverly. So, just > for now, please don't suggest "2, followed by 3" even if > that's something you like the sound of - I think folks' > initial responses will probably make it obvious if we need > a chat about that. > > And lastly, please let's not have an IETF process discussion > or a discussion about why the IETF is great or crap. If we > see that there's IETF stuff folks want to do and if those > folks are willing and able to implement/deploy the results > then that's enough to be going on with. > > Thanks, > S. > > [1] https://www.ietf.org/meeting/important-dates-2015.html#ietf93 > > > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a113fefc23f201e0513385e55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephen: Thank you for the terrific summary!

--

As several p= eople have pointed this out: I wanted to apologize for my absurd pomposity = on the list: Saying 'Yahoo requests' is clearly inappropriate for a= n IETF discussion. I'm very glad that the IETF places a high value on t= echnical arguments. So...mea maxima culpa.

(In my partial defense, I= was kind of blindsided by the pace of discussion; I had a mandate to get s= omething out about our deprecation plans prior to OSS release of our branch= of E2E. Which is at github.= com/yahoo/end-to-end, by the way.)

--

So: I work for Yaho= o on their side of the End-to-End project, in close collaboration with Goog= le. Yahoo's goal is to provide E2E email encryption 'for the 90%= 9;: typical webmail users, who aren't familiar with crypto. We're h= opeful that -- in the 1 year timeframe -- E2E encryption will be available = for all Yahoo webmail users. (This would be a somewhat larger deployment th= an the ~ 1.5m recentish keys in the SKS system.)

I'd really like= to limit the scope of the OpenPGP WG to email (possibly, for the moment, e= mail sans attachments[*]), where there's a clear interoperability story= .

Unfortunately, with, e.g., Google's recent pull-out from XMPP,= the interoperability story for instant messaging is really unclear right n= ow. I don't want to see the interoperability of end-to-end encrypted em= ail be negatively affected by that: email remains really, really important.=

[*]: Given that both Google and Yahoo are moving to 'out-of-ban= d' attachments via cloud storage, I may not be able to get much buy-in = on anything other than a spec for distributing symmetric file-encrypting-ke= ys and download URLs along with email. (I'm thinking, here, of somethin= g resembling Pond's 'detachments'.)

--

Responses = to options, in (weak) order of preference:

Preferred: Option 3: Majo= r revision. The goals of OpenPGP are relevant. But -- after four incrementa= l revisions -- the spec has grown from something simple to something unmana= geably complex. I think that experience from the TLS WG shows that changes = of (at least) the scale of TLS1.3 will be required.

Risk: This will = be a lot of work for Stephen...and the rest of us. And there are a lot of i= ssues that will be really controversial.

--

Preferred: Option= 1: Talk for another six months. Get some more deployment experience from Y= ahoo, Google, and similar projects using

1. OpenPGPv4
2. and thin= gs designed to be concrete proposals for OpenPGPv5

and then take act= ion.

Risks: Half-a-dozen new message formats in the interim, potenti= al for participant 'lock-in' to drive later discussion rather than = technical merits.

--

Acceptable, depending on scope: Option 2= : Minor revisions to OpenPGPv4 in the interim, specification of a 'simp= le' OpenPGPv4 profile, and then discussion of OpenPGPv5 in six months. = My main concern is that this will require a lot of effort, which may distra= ct from the bigger picture issues.

If this happens, specific things = I'd like to see:

1. One of curve448 (per IRTF I-D), E-521, or E/= Fq(M607) specified as an alternative for ECDH, possibly with a better KDF (= for the first two, implemented by Mike Hamburg's 'decaf' librar= y, there's working, MIT-licensed code)

2. A revision to WK's= Ed25519 spec to require that inputs are always from SHA2-512. (I and our c= ryptographers are unhappy with anything else.)

3. A backwards-compat= ible extension to SEIPD packets that is a sound(ish) AEAD mode for modern i= mplementations. (This appears to be feasible, though a bit of a hack.)
<= br>4. A spec for HTML-mail-friendly signatures that *doesn't* require P= GP/MIME support. (PHB has pointed out that base64 confuses non-crypto-geeks= . This has been Yahoo's experience as well.)

--

Unaccepta= ble: Option 4. This would include IM, as I understand it. Three issues:
=
1. Likely requires different approach to crypto than in the email case.= (E.g., Axolotl, MAC-and-continue.)

2. Implementations will have com= pletely different APIs.

3. No real point without interoperability at= the messaging layer, which largely no longer exists...regrettably.[*]
<= br>[*] I'm hopeful that some of the WebRTC work may eventually result i= n a return to interoperability, but they already have a security model comp= atible with 'End-to-End' security.

--

Probably unacce= ptable: Any of the 't' options. (Except, perhaps, an informational = RFC about the web of trust, provided that it takes into account the incenti= ves against key rotation it creates.)

Both Google and Yahoo have com= mitted to building out a key transparency system for our users.

And = Yahoo is expending significant resources to ensure that it will be viable f= or providers smaller than us to participate in such a system.

This w= ork will likely eventually be in scope for Transparency-WG, but we're n= ot far enough along to be able to commit to any specific proposal at this t= ime.

Limited exception: Jelle van den Hooof of MIT has a clever prop= osal to use DKIM+a form of KT for bootstrapping trust in the interim. (This= could be adapted to TOFU, as well.) A proposal along those lines might be = interesting as a stopgap.

- David
On W= ed, Apr 1, 2015 at 11:58 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi all,

So I think the volume and content of discussions over the
last few weeks clearly indicates a desire to do something
about openpgp, but that discussion doesn't seem to be closing
in on exactly what to do, in the IETF context. It'd help me
to try figure that out if folks would respond to this saying
which of the options below you think can make sense. Picking
more than one is fine, but if so, please say which you prefer.
Annotating/explaining your choice(s) is very welcome but
please try resist the temptation to change this into a chat
about a different set of options:-)

It would also really help me (and I suspect others) evaluate
messages if you could say something about how you fit into
the openpgp universe (e.g. "I wrote the foo implementation"
or "I run a thing with N people using pgp" or whatever). An
essay on that is not useful here, but a line or two could
be really good.

Please try respond to this if you can before Wed April 8th
and I'll try summarise whatever we get back to the list after
that, and we may or may not have a plan of action at that
point - we'll see I guess.

And pretty please do change the message subject if you want
to follow up and discuss something from someone else's response.
That'll at least make my life a little easier when it comes
to trying to summarise back to the list but it'll also make it
easier for folks to check if I've mucked up in how I summarise
(and I muck up a lot, sadly:-).

Anyway here's the options:

option 1: do nothing - there's nothing much to do or at least
not in the IETF or not within the IETF for the next >6 months.

option 2: do maintenance work on rfc4880 - produce a 4880bis
with better crypto options at least, and debate any further
detailed changes during chartering - the charter will contain
a list of specific things to do and other things will be out
of scope (for now)

option 3: do a major revision to openpgp - take rfc4880 as a
starting point but question all design decisions in the process
of developing a successor version of openpgp and write a
charter that allows for all such design decisions to be
questioned

option 4: move beyond openpgp (or smime) to develop a new
flavour of end-to-end security for interpersonal messaging,
possibly not that tightly coupled to email, but at least
supporting an email flavour

For options 2-4 one could include more or less work related
to trust models or key hierarchies/key distribution. If you
would like to include that kind of work please pick one of
those below. If pursuing any of these, we'd need a separate
discussion about the scope of that work and whether or not
one specific approach ought be standardised, but please
let's not yet have that discussion until we see that one of
the "t" options below has a good bit of support.

option 2t: option 2 + add some trust model/key management
option 3t: option 3 + add some trust model/key management
option 4t: option 4 + add some trust model/key management

So that's for choices. Remember it's ok to pick more than
one with which you could live, but please be clear about
which you prefer.

I'd also like to talk about how we might process some of
the above if we establish rough consensus for one of 'em.

Option 1 is easy. The list can continue to debate stuff,
but there's no IETF process stuff needed and no new RFCs
on the horizon. I get off the hook:-)

For option 2, or 2t we could start crafting a charter on
the list once we've gotten agreement that that's the goal.
I don't think a face-to-face BoF would be needed before
forming a working group unless the scope of the "t" part of
2t was proving hard to pin down. (We could arrange some
virtual audio meetings if that'd help of course.) That
could mean a working group is formed quite soon, and that
working group might choose to meet face-to-face in Prague
in July, or might prefer to work on the list only, or
with some audio meetings.

For options 3, 3t, 4 or 4t I do think we'd likely need to
have a face-to-face BoF meeting as there'd be a lot to
consider and pin down and higher bandwidth is much better
for that. In that case, the important date is June 5th
which is the next cutoff date for requesting such a meeting
for the Prague IETF to be held July 19-24. [1] (June 5th
might seem like a long way off, but it's not really so if
we needed such a meeting then starting to work towards that
soon would be much better than doing so late.)

Also, some of this can be done sequentially. For example,
as an area director I'm very happy re-chartering existing
working groups to add more tasks where those groups have
demonstrated the ability to be productive. In my experience
that can work better than starting out with the hard/ambitious
stuff as the very first thing to do. That might argue for
starting with option 2 and then, if all goes well, discussing
whether or how to tackle option 3 or 4. (We could even charter
a group to do the maintenance work for option 2 and when that's
done to then discuss how to re-charter for one of the more
complicated choices.) I'd suggest however, we ignore such
sequential processing for now, see what folks prefer as a
goal, and then think about whether there's a way to get to
what people want via sequencing things cleverly. So, just
for now, please don't suggest "2, followed by 3" even if
that's something you like the sound of - I think folks'
initial responses will probably make it obvious if we need
a chat about that.

And lastly, please let's not have an IETF process discussion
or a discussion about why the IETF is great or crap. If we
see that there's IETF stuff folks want to do and if those
folks are willing and able to implement/deploy the results
then that's enough to be going on with.

Thanks,
S.

[1] https://www.ietf.org/meeting/important-dates-20= 15.html#ietf93





_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a113fefc23f201e0513385e55-- From nobody Wed Apr 8 09:15: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 1A6651B33A2 for ; Wed, 8 Apr 2015 09:15:16 -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 zVMaYfu_INRU for ; Wed, 8 Apr 2015 09:15:15 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001: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 8B7161B3395 for ; Wed, 8 Apr 2015 09:15:13 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so78531048ieb.3 for ; Wed, 08 Apr 2015 09:15:13 -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=nWJgAtgMUeUJNUKjk7CEcQJ7H+oBoMj3fk6Iyb1OC78=; b=YFw82iRzTdSAYEQvQ8GG9ay8eahkZUOjXZ8FZ/hPBGcaytguJMrHKJduGuCxKRQX1F P5yMGN+P17EvgizWLKKkmoq2zYL9TB0IpkPDDCrdKApbENjAO8u8L94+CBmlSwZR55Fk CFt9y8GNDEw1kBdveK02Zhh6030ez3Fx/l91c= 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=nWJgAtgMUeUJNUKjk7CEcQJ7H+oBoMj3fk6Iyb1OC78=; b=E0wjK2omV99xSnwDRpNnd25ZnIW1EZfXJ5mPF9sttpV486xgLg5Jl3GnFopwHiwLFI jNyjXqTF1FHRCHyzC/IQz9ZR79rxXuJ3mGwuZx7T2HStfHxOKgQYxn/+BzTPL66nbTVu BCeCP4IHDHuU9Tcvt8A7jGzmX8Dn7z2BQ5QqwbYGDpFU7dZLinh+mW9/KqFJ6IsJsH6W CGgsTQwWKnkw7Qja8THkMAlpDer1V4BRSmm94k8p9nrfBzfy8SQcSCRlLGfswjO3BQjT emzUcjrXLlGeq5IpEovQRJ/7sfwQx2nEH9u4y3V3LpgvYnoNL5U0L4/QK1Zm9cBpY+k7 T/Dg== X-Gm-Message-State: ALoCoQlhDpk++C/R80HJPOEHXNuFf/DElmnawh+NG22xq3t2vE2w5YEu3GqCYBin4T7d0hLTXRfS X-Received: by 10.50.78.130 with SMTP id b2mr13011171igx.42.1428509712990; Wed, 08 Apr 2015 09:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.188.196 with HTTP; Wed, 8 Apr 2015 09:14:51 -0700 (PDT) In-Reply-To: References: <551C3FAD.6040107@cs.tcd.ie> From: Tom Ritter Date: Wed, 8 Apr 2015 11:14:51 -0500 Message-ID: To: David Leon Gil Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "openpgp@ietf.org" , Stephen Farrell Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 08 Apr 2015 16:15:16 -0000 A suggestion I have, that would dovetail nicely with Google's and Yahoo's plans of getting deployment experience and iterating based on it, would be to essentially solicit full-scale proposals from individuals or teams of individuals, and using those as a base. This was something that did not happen in the TLS WG but I thought made a good amount of sense. We could discuss a wide range of ideas[0], and set a date (perhaps IETF 94 in November?) to present all the proposals. It doesn't have to be a complete textual proposal but a complete outline makes people think through what they want and how to get there - that can be greatly beneficial. -tom [0] If it was me, I'd use a wiki to copy some ideas cross and clean them up into a less threaded summary From nobody Wed Apr 8 10:56: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 B36DD1A8899 for ; Wed, 8 Apr 2015 10:55: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 nPoKbxSSGHlt for ; Wed, 8 Apr 2015 10:55: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 59E311A888F for ; Wed, 8 Apr 2015 10:55:56 -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 373445FB2C for ; Wed, 8 Apr 2015 17:55:55 +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 4iJKy7aSZlQW for ; Wed, 8 Apr 2015 17:55:53 +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 ; Wed, 8 Apr 2015 17:55:53 +0000 (UTC) Message-ID: <1428515752.5137.28.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Wed, 08 Apr 2015 19:55:52 +0200 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <1428498695.5137.17.camel@scientia.net> <1428500028.5137.26.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-7WfeexbjshPau5niVMzK" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 17:55:58 -0000 --=-7WfeexbjshPau5niVMzK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-08 at 10:00 -0400, Phillip Hallam-Baker wrote:=20 > All the code is up on sourceforge and always has been. >=20 > http://prismproof.org/ So? Gnupg is available as well, but this doesn't make it necessarily secure to use it under a closed OS, cause it's the later who has ultimately all control. Cheers, Chris. --=-7WfeexbjshPau5niVMzK 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwODE3NTU1 MlowTwYJKoZIhvcNAQkEMUIEQPTIpm2xekVa3DIWjh+MijIqzKn4GbpVchuzIenu9hI4rsWWhDIq 2a95ZP0HOkaXfLxeC8XI5zZO7b2ILAcQhqgwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQActkbYtNtu5ljjYzw2iAy1wMQY3onz EnqDACWs5FViOoDj3SWJfDN0lxC4yA470yI6w+bSpXiVq+sZjum0An2gRckrepL1Hv6iBMo55rvd p6gCYYkW6Br8bFbPtKlpGpNqkm/eGukhvZ2p7a+AcjhiDrqSuGm8qvT/yrWv7LDsUROlyl+OKyQ5 jK9rpBfVzs+hylax8ywSsZUKl1JaIKo2Ii3R2jHRsG/eSjAERROConotLB6B0NCj86gMi9BXedmX 4B0EEI8bdb4Loanusa2GMNlbbbFOKVh63DWrAOvflNsg1U4ejHoBKQJzAiiuSDpM0KFiKF/EM3Vk 5jw6uCxIAAAAAAAA --=-7WfeexbjshPau5niVMzK-- From nobody Wed Apr 8 11:05: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 38B0F1A8912 for ; Wed, 8 Apr 2015 11:05: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 W3mlGu5Wr9no for ; Wed, 8 Apr 2015 11:05: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 C48DE1A8905 for ; Wed, 8 Apr 2015 11:05:12 -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 A15525FB0C for ; Wed, 8 Apr 2015 18:05:11 +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 tV8afm2wRO1w for ; Wed, 8 Apr 2015 18:05:06 +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, 8 Apr 2015 18:05:06 +0000 (UTC) Message-ID: <1428516305.5137.36.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 08 Apr 2015 20:05:05 +0200 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <87vbh6zqsy.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-XVJRqgUsCy7CETosEhvY" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 18:05:19 -0000 --=-XVJRqgUsCy7CETosEhvY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-08 at 10:15 -0400, Phillip Hallam-Baker wrote:=20 > Personally, I believe that owning your personal DNS name is as > important for security as having a keypair. Why should it give you any security? > I have a huge part of my > brand invested in hallam@gmail.com which I don't own. Which is why I > switched to phill@hallambaker.com for ietf work. But I have yet to win > that argument. It only gives you that some company cannot easily take away your mail address, but OTOH it's probably an illusion to believe that your own domain name protects you much more from this. See cases like the German person called "Shell", who had shell.de and guess who has it now. > I really don't like having ICANN as my root CA either. DNSSEC is a > monolithic, single rooted scheme which I don't consider very > trustworthy because of that. Sure, it has similar problems like the X.509 PKI, just on a less extreme scale. But no one should try to impose a strict hierarchical trust model on OpenPGP anyway. So I don't think it's a particularly good idea to somehow combine OpenPGP with DNS/DNSSEC/DANE. If at all that would mostly only interesting for securing TOFU like systems at least a tiny bit - but OTOH, we shouldn't follow TOFU, it's basically a big lie as I pointed out in a recent lengthy thread on one of the gnupg mailing lists. > We do need trust hierarchies for key management. But each individual > should be the root of their personal hierarchy. +1 > I don't think anyone has signature validation done right today. All > signatures are broken unless they are enrolled in an append-only log. > To verify a signature, you need to go back in time to the point where > the signature was created and check the signature in that time > context. I don't get the point here. At least it doesn't sound like anything in the responsibility of the crypto system, rather something for higher level programs. Cheers, Chris. --=-XVJRqgUsCy7CETosEhvY 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwODE4MDUw NVowTwYJKoZIhvcNAQkEMUIEQDs3HB+XFO/uQQuk6w2+wVVLESr5su1XOJtAGRhnLgdt8oqugRFo 8bOD14Y422tOJJugTa3IOcnFzwTx+G2JO40wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAca0mYKc/Xa6wSr4uA1w/6OULPKsgc meFXvyhdNHvopYMJ3g8MGQKZ+ThhwfAfQ2MN4XwGDHmnwFWf/hmEPYRe7TZpUmAJJBfpL1zul+mI iSxPgIzUPPoDhxgFBaZh4Hek39XHav/pDYOECAMWGVdRDE/mw3/wg7ESEZk+/u5HnnJAst2nMQRu s9B49tnDR3j109WgxrBBMLiZPPpMZhaOb5p/CbgVSd+/YIvKAOuuT3CbXYdeqhowrVIv/ukqVslk FwzdQTUBPn+8SQ4/VDx9LCJLlJNZF6glZ7XaWy8Flzw53r/fkNqJ9v3KbepJ1jI0UTX332Ba5E7+ lZdLNRjuAAAAAAAA --=-XVJRqgUsCy7CETosEhvY-- From nobody Wed Apr 8 11:05: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 CEC391A8928 for ; Wed, 8 Apr 2015 11:05:48 -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 aQVLC51HIW7f for ; Wed, 8 Apr 2015 11:05:47 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4DD1A891F for ; Wed, 8 Apr 2015 11:05:42 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-71-55256df5931f 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2B.34.03493.5FD65255; Wed, 8 Apr 2015 14:05:41 -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 t38I5eGS005243; Wed, 8 Apr 2015 14:05:40 -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 t38I5cSo010130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Apr 2015 14:05:39 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t38I5bOt021685; Wed, 8 Apr 2015 14:05:37 -0400 (EDT) Date: Wed, 8 Apr 2015 14:05:37 -0400 (EDT) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> Message-ID: References: <551C3FAD.6040107@cs.tcd.ie> 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+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrPs1VzXU4HanhEXDv4fsFtP3XmN3 YPJY232VzWPJkp9MAUxRXDYpqTmZZalF+nYJXBlHdzYyFSzjqXh0PKeB8SJnFyMnh4SAicT/ rfeZIGwxiQv31rN1MXJxCAksZpKY9WwnM4SzgVFi4fs2VgjnIJPE1C8TmEFahATqJVrn3GUE sVkEtCR+vbsCNopNQEVi5puNbCC2iIC+xN7N59hBbGYBTYkX56aC9QoLBEhcXzmVFcTmBIo3 /+ljAbF5BRwl7t14yggxX0Ni1Y7tYL2iAjoSq/dPgaoRlDg58wkLxEwtieXTt7FMYBSchSQ1 C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJNjKBAZXdR2cHYfEjpEKMA B6MSD6/AYpVQIdbEsuLK3EOMkhxMSqK8kcmqoUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeLNA crwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErzywIgUEixKTU+tSMvM KUFIM3FwggznARp+KwdkeHFBYm5xZjpE/hSjopQ47ySQhABIIqM0D64XlkheMYoDvSLMGwVS xQNMQnDdr4AGMwEN5n+mBDK4JBEhJdXA2J4QkBPR5xry+kYFe7/UxfnfZy8TcvNefL/S5HDT rOCgw3vOH/z3+nHavrqX6iVVmgd3Sun8ja2dZJxZ9/HFrohg75TD0feyPNmTl7jGrM6+VN1X t+1/jEd+qtz0mUaGMt9+vgkOvxa51TwxNIqXRWK5+ZNNj92Pb/q6zt0m1OPyl10/j7w0VmIp zkg01GIuKk4EAM1phxn/AgAA Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 08 Apr 2015 18:05:49 -0000 Nothing like a deadline to motivate replies... On Wed, 1 Apr 2015, Stephen Farrell wrote: > It would also really help me (and I suspect others) evaluate > messages if you could say something about how you fit into > the openpgp universe (e.g. "I wrote the foo implementation" > or "I run a thing with N people using pgp" or whatever). An > essay on that is not useful here, but a line or two could > be really good. I consume PGP for encrypted discussion of embargoed security issues, e.g., in my role as a maintainer of MIT Kerberos. > Anyway here's the options: > > option 1: do nothing - there's nothing much to do or at least > > option 2: do maintenance work on rfc4880 - produce a 4880bis > > option 3: do a major revision to openpgp - take rfc4880 as a > starting point but question all design decisions in the process > > option 4: move beyond openpgp (or smime) to develop a new > flavour of end-to-end security for interpersonal messaging, > I think 2 is the most feasible so far, and we could get agreement on what to do without too much teeth-gnashing. Option 3 is tempting, but it may be a larger project than there is energy to take on. Option 4 seems like it ought to be a new working group (and is additionally unlikely to gain much adoption barring a bit player pushing it to users), so I don't think we should tackle it here. I also would prefer to not try to mandate a specific trust model or models, though we can certainly have some in mind to ensure that what we come up with is compatible with them. -Ben From nobody Wed Apr 8 11:29:18 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 BD7D31A8AD9 for ; Wed, 8 Apr 2015 11:29:16 -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 IVG4CIiC6jJ1 for ; Wed, 8 Apr 2015 11:29:15 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 DC1E21A8A60 for ; Wed, 8 Apr 2015 11:29:14 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so65018350lbb.3 for ; Wed, 08 Apr 2015 11:29: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=WHopKEohkmYknwzYsAiJ48Cv1fiP40xL/bIYcJbzMbI=; b=EJAo3iFOM0w515v4dOWsyC7ePqm01sHpbhojdCXOb+h7r0YprgLWICySuRxE0k8v9J TkAD9DEq9tscIMy4nbhQjDS+p6LRZj2V2iWKlu052rgdpr6tH4f7yiQMHN/hZ0Z5mhuU FgRxizSCnrBubYW3BdxN7zfjYFvxPC2Qz0S23f0EvHnZo2ZTLBhUbdw9AoVN5MsVHrl/ M9AjWFAuI22WUQ5Ly2dA5EVOsycMTFAFLK82Bq0G8DJ+17c8ZLpi7WBXkaHFp71me3Kc Jhn3IAinx0xPN2gHgupeUpPYMqphOvgXY40cBrBxWj76ZHvvZMWauU2g/Avz2ToLFQt0 y0lw== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr1086104lab.79.1428517753413; Wed, 08 Apr 2015 11:29:13 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 11:29:13 -0700 (PDT) In-Reply-To: <1428516305.5137.36.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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <87vbh6zqsy.fsf@vigenere.g10code.de> <1428516305.5137.36.camel@scientia.net> Date: Wed, 8 Apr 2015 14:29:13 -0400 X-Google-Sender-Auth: nb2qakKVLV9IF3zjF7vhnWzxhEg 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] OpenPGP private certification 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, 08 Apr 2015 18:29:17 -0000 On Wed, Apr 8, 2015 at 2:05 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-04-08 at 10:15 -0400, Phillip Hallam-Baker wrote: >> Personally, I believe that owning your personal DNS name is as >> important for security as having a keypair. > Why should it give you any security? Same reason that backing up your files is the number one security priority: security means being able to assess and control risks to your assets. Confidentiality is only one concern and one that is fairly low down. Integrity is almost always more important. If I invest in hallam@gmail.com then I am making myself vulnerable to a change of policy. I have little choice but to pay if they decide to start charging $50/month. >> I have a huge part of my >> brand invested in hallam@gmail.com which I don't own. Which is why I >> switched to phill@hallambaker.com for ietf work. But I have yet to win >> that argument. > It only gives you that some company cannot easily take away your mail > address, but OTOH it's probably an illusion to believe that your own > domain name protects you much more from this. > > See cases like the German person called "Shell", who had shell.de and > guess who has it now. Which is one reason I don't trust ICANN's vision of DNSSEC. But still, security is risk control and not risk elimination - something I have been saying for over 20 years now. >> I really don't like having ICANN as my root CA either. DNSSEC is a >> monolithic, single rooted scheme which I don't consider very >> trustworthy because of that. > Sure, it has similar problems like the X.509 PKI, just on a less extreme > scale. If trades one set of problems for another. > But no one should try to impose a strict hierarchical trust model on > OpenPGP anyway. So I don't think it's a particularly good idea to > somehow combine OpenPGP with DNS/DNSSEC/DANE. I think there are ways to combine PGP ideas with DNS and DNSSEC in a useful manner, DANE is not one of them. The approach I have been using most recently is an extension of the .onion idea. But instead of making a key fingerprint a subdomain, I make it the root. So example.com. becomes an assertion 'the names in example.com as controlled by a valid, current security policy signed by a key matching . Now that is an approach I can tie servers to in admin files. From nobody Wed Apr 8 11:36: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 506F41A8F38 for ; Wed, 8 Apr 2015 11:36:34 -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 DchU8TAB29jB for ; Wed, 8 Apr 2015 11:36:32 -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 4EA3A1A8BC5 for ; Wed, 8 Apr 2015 11:36:32 -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 2DE335FB4C for ; Wed, 8 Apr 2015 18:36:31 +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 NPrviEDlBBn5 for ; Wed, 8 Apr 2015 18:36:29 +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, 8 Apr 2015 18:36:29 +0000 (UTC) Message-ID: <1428518188.5137.61.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 08 Apr 2015 20:36:28 +0200 In-Reply-To: References: <1427138741.10191.48.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-IteE4pmBpLQLp3AneUu0" 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: Wed, 08 Apr 2015 18:36:34 -0000 --=-IteE4pmBpLQLp3AneUu0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-08 at 15:32 +0000, David Leon Gil wrote: > Brief update on plans for deprecation: The tracking issue is at > https://github.com/yahoo/end-to-end/issues/31 >=20 > Please feel free to open another issue if you have specific > objections. I will either be convinced by your arguments, and change > the plan, or explain why I don't. Look, as I've pointed out previously, I personally think that crypto, done as a web app is inherently untrustworthy. Maybe I just got something wrong, but AFAIU the idea of "e2e" projects like your's is to add e2e crypto into your webapps, e.g. via javascript. Thus the software doing crypto is each time downloaded again from the server by the client, right? So ultimately control is again fully at the vendor (at any time he could send other code and no one would notice), and fully dependent on a working https (which is as we should all know by now inherently insecure due to the issues of the CA system). So to me, the whole e2e crypto campaigns run by some of the bigger vendors is just a marketing thing, at best. Actually, if I'd be part of organisations doing mass surveillance, fearing that people could now switch to properly used crypto, then these would be the two things I'd tried to do as a countermeasure: - TOFU and - propagating actually weak e2e crypto systems on a broad scale, giving people a wrong sense of being secure[0]. That being said, at least I probably won't focus myself on what Yahoo, Google or any other big company does. Looking at the the ticket you mention, *some* things you plan to deprecate are definitely a good idea, for others I'd see simply no good reason that anyone would follow these now. Especially some of the "eventually" things seem a bit crude. And I guess my personal opinion about algorithm diversity is known as well. But more important: Implementations have always been free to implement what they like (even if, strictly speaking, they may have lost the status of a conforming implementation). But you shouldn't expect that others follow your steps, just because big-company-xyz is doing so now. However, the more you depart from "standard" usage of OpenPGP, the more you should probably call it something else. This would especially apply for anyone who would think he drives the standardisation process and not the community of real/serious OpenPGP users. And even more important, none of the big companies which add that IMHO at best questionable web-based e2e crypto to their services, should expect that this would make them represent the majority of OpenPGP users and thus would give them a strong voice in decisions. Just because e.g. google would automatically enable questionable e2e crypto for millions of their gmail users, doesn't mean that one as a real "legitimate" OpenPGP user base there. For all the above reasons, I personally feel, that it's not appropriate here at the OpenPGP WG list, to discuss single unilateral decisions made by an OpenPGP implementation[1]. If one says "hey, let's discuss whether we should deprecate twofish in OpenPGP" that's totally fine,... but informing the standardisation body "hey we drop now support for x, y and z" with an implicit "and since we represent n users, you better follow our decision" is not appropriate. Cheers, Chris. [0] Ever wondered why nearly each totalitarian regime still carries out elections? It still gives people a little feeling of having choice. [1] And exception might be GnuPG, simply because *it* likely actually represents the majority of all serious users of OpenPGP. --=-IteE4pmBpLQLp3AneUu0 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwODE4MzYy OFowTwYJKoZIhvcNAQkEMUIEQJkI4BGY8I9H9cZA2oegkKCHiE/fxmujx7lwFAHAbLwsTix0kQo1 Fge3Z8CONgE+g84j1cRM+KJBV63zhNSG0UkwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCcQpZmWUZLoSwRCzwNJ2cLdMAFf8Bg UxzPkh1y69mzu6syH/13yTwvsw8x92Ju0oj706eKBiCHZxW6HQ4BsEqmQgKF0ECUFk+VRXNNtS26 beetcN0Jzmio22EMn0zY0aeVcxaqWHB0ftg1ND381wKfnihRMwHC21bxR9bb2h/9QA040PNdcEG/ Y4JA9UK+qaO4WmNIC7BjWPwNGmElqUhbKIUKh6h4ZvpKCcps4bYvLjZ9JBAm2F/fERy2PfTo5Fog Za4oO3Cz3WbhZxl4UiXL9cvl1FKWiWTv0KY4CgnwlUWKRqQtDtV2Av85R14hyiboE3R+6K5kwtYW E+1O0tq/AAAAAAAA --=-IteE4pmBpLQLp3AneUu0-- From nobody Wed Apr 8 11:39: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 494A81A8F41 for ; Wed, 8 Apr 2015 11:39:05 -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 MHbzH5r6SzmE for ; Wed, 8 Apr 2015 11:39:04 -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 E88291A8F3E for ; Wed, 8 Apr 2015 11:39:03 -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 C536E5FACA for ; Wed, 8 Apr 2015 18:39:02 +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 MHkky0K1AmJk for ; Wed, 8 Apr 2015 18:39:01 +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 ; Wed, 8 Apr 2015 18:39:00 +0000 (UTC) Message-ID: <1428518340.5137.63.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Wed, 08 Apr 2015 20:39:00 +0200 In-Reply-To: References: <551C3FAD.6040107@cs.tcd.ie> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-9kli/QKS+88VyOXBcpnd" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 08 Apr 2015 18:39:05 -0000 --=-9kli/QKS+88VyOXBcpnd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable btw: > > Anyway here's the options: > > > > option 1: do nothing - there's nothing much to do or at least > > > > option 2: do maintenance work on rfc4880 - produce a 4880bis > > > > option 3: do a major revision to openpgp - take rfc4880 as a > > starting point but question all design decisions in the process > > > > option 4: move beyond openpgp (or smime) to develop a new > > flavour of end-to-end security for interpersonal messaging, I'd probably chose the following options in decreasing priority: 3, 2, 1, 4 Cheers, Chris. --=-9kli/QKS+88VyOXBcpnd 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwODE4Mzkw MFowTwYJKoZIhvcNAQkEMUIEQJedoh0MhP5IpblxkvxI5j2DEiAj0hZYxo9ila8fb9oy4Spv0crk x7pYwV4ZiDAZiPby2Tfed+Fh8xH1CqUsYaswagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAkC8pKl19Tr74E9ibgI4s0o8bmwd8f X3GipZ1TeAdcWAzwaMPJOoy9UJC1rpcCIB43jyd0mSpknyvzkGcJ9xiFEgz6XOyB/FtNa8ZJLpeP 7WdlGaQuvZx+SWOo28JraXANcZs9JOO1Hq0lvHHfcSHcNyCewPgdHx6zvN0TTsT9X0Fj7ggOrciR a5fqOhOgtxLpunCbyWYNdNb1nme02eABw+6oI1wS7660xmSziR6DsSMN5BKLWqLBtSeifWLoXpvq k62qlxTZ9+qjFEZkGKokDqhQloflLRXcHKVOC+JKMZXYcypgmYhNAb+TUsJLkfh8ouAOyqW8Nqb/ hjzOeoqaAAAAAAAA --=-9kli/QKS+88VyOXBcpnd-- From nobody Wed Apr 8 11:41: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 EF0DC1A8F45 for ; Wed, 8 Apr 2015 11:41:45 -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 g1q3RqOms7J2 for ; Wed, 8 Apr 2015 11:41:44 -0700 (PDT) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 165531A8BC0 for ; Wed, 8 Apr 2015 11:41:44 -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 mx1.mailbox.org (Postfix) with ESMTPS id 9C1D3404FA for ; Wed, 8 Apr 2015 20:41:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id HSTX-oroWsg5 for ; Wed, 8 Apr 2015 20:41:41 +0200 (CEST) Message-ID: <5525765F.70902@dominikschuermann.de> Date: Wed, 08 Apr 2015 20:41:35 +0200 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: openpgp@ietf.org References: <551C3FAD.6040107@cs.tcd.ie> In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QMvAPXkgAHAsCQDUxGPtksfcULtGtqPLo" Archived-At: Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 08 Apr 2015 18:41:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QMvAPXkgAHAsCQDUxGPtksfcULtGtqPLo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I am in favor of option 2, a 4880bis with fixed crypto primitives and modes. Everything else sounds like creating a new standard instead of fixing OpenPGP. I work on OpenKeychain, an OpenPGP implementation for Android. Regards Dominik --QMvAPXkgAHAsCQDUxGPtksfcULtGtqPLo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVJXZlAAoJEHGMBwEAASKCVHAH/RQJ6dFzUEsj2Zx5lmZeXcus 1uhku5UyPNfCTHuxJCxj2iscu79/bGFLsr1y/u5ttNM7gyD7rRY/pVSCcdLK2IbK oinplSDlrK3FiUoyCFbpy2JuD7/XYD2x01LbYJQYefz5j+cGGRYSOPHiperf1ZWP NVfTFTa1f1EjLWGWySryP8ZSeGgbb8fmcjyVxbL0ZIazJBv3gpwiN30m5pJOBRic JL2vfzEDVTRNc1bwhDC4Gh4FLvwfQM+rOfQp8FkAv6zQwnFSCslsBC1q83d27SVx MC23B7KdobBpy4CGQTwaZlFx3+F34zkO6O9MfPdxUVr9faUmCl+HkEhAamC+mF4= =Y6Ej -----END PGP SIGNATURE----- --QMvAPXkgAHAsCQDUxGPtksfcULtGtqPLo-- From nobody Wed Apr 8 11:54: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 EB6E01B34FD for ; Wed, 8 Apr 2015 11:54: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 8w_f6mvDjdgp for ; Wed, 8 Apr 2015 11:54: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 C1EFF1B34FA for ; Wed, 8 Apr 2015 11:54: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 95C235FB58; Wed, 8 Apr 2015 18:54:45 +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 0bUD3MNbCw0g; Wed, 8 Apr 2015 18:54:43 +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; Wed, 8 Apr 2015 18:54:43 +0000 (UTC) Message-ID: <1428519282.5137.78.camel@scientia.net> From: Christoph Anton Mitterer To: Phillip Hallam-Baker Date: Wed, 08 Apr 2015 20:54:42 +0200 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> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <87vbh6zqsy.fsf@vigenere.g10code.de> <1428516305.5137.36.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-OCHuRd0yvrfiZiZ2jFIX" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification 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, 08 Apr 2015 18:54:49 -0000 --=-OCHuRd0yvrfiZiZ2jFIX Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-08 at 14:29 -0400, Phillip Hallam-Baker wrote:=20 > > Why should it give you any security? > Same reason that backing up your files is the number one security > priority: security means being able to assess and control risks to > your assets. Confidentiality is only one concern and one that is > fairly low down. Integrity is almost always more important. I don't think that either you or me can decide which of the aspects of "data security" is most important to a user. It completely depends on the usage scenario and for some integrity may be actually less important. But in terms of our discussions here we probably mostly deal with confidentiality, integrity and authenticity. And I can't see how a own domain name helps here. > If I invest in hallam@gmail.com then I am making myself vulnerable to > a change of policy. I have little choice but to pay if they decide to > start charging $50/month. Sure, but it doesn't improve your confidentiality, integrity and authentici= ty. Just make a new UID with another address, publish it, bon. > >> I have a huge part of my > >> brand invested in hallam@gmail.com which I don't own. Which is why I > >> switched to phill@hallambaker.com for ietf work. But I have yet to win > >> that argument. > > It only gives you that some company cannot easily take away your mail > > address, but OTOH it's probably an illusion to believe that your own > > domain name protects you much more from this. > > > > See cases like the German person called "Shell", who had shell.de and > > guess who has it now. >=20 > Which is one reason I don't trust ICANN's vision of DNSSEC. Well but that has happened before DNSSEC, it's more a problem of DNS itself or rather of courts being able to rule about the cyberspace. > > Sure, it has similar problems like the X.509 PKI, just on a less extrem= e > > scale. > If trades one set of problems for another. Which problems would it have that X.509 PKI wouldn't have? > So example.com. becomes an assertion 'the names in > example.com as controlled by a valid, current security policy signed > by a key matching . Uhm that probably only works when you chain als signatures of the respective domain (i.e. NSEC instead of NSEC3), right? But to me this isn't a integration of DNS into OpenPGP, like in the sense of using DNS to implement a certain trust model (yes Werner, trust models are not part of OpenPGP ;-P) It's vice versa an integration of OpenPGP into DNS,... which is IMHO again totally fine (at least per se and form the OpenPGP PoV). > Now that is an approach I can tie servers to in admin files. AFAIU, you basically just tried to secure your zones via DNSSEC and OpenPGP, right? I think that approach is unnecessarily complex, since AFAIU it requires to fully walk through the zone. Why don't you just use the openpgp key to sign the DNSKEY RRs (+put the result in some special RR) and validate that in your resolver before making any further use of DNSSEC? Of course, for that being really secure, you'd need to tell your resolver which domains he should expect to be signed that way, just relying on the presence of the RR that holds the signature is obviously not enough (blocking attacks)... and relying on DNSSEC for that obviously defeats the purpose. Signatures must obviously also use expiration times. Also, the method of just adding the fingerprint as an indicator smells very strong like "replay and downgrade attacks". Cheers, Chris. --=-OCHuRd0yvrfiZiZ2jFIX 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQwODE4NTQ0 MlowTwYJKoZIhvcNAQkEMUIEQHTjTbGI6tvVGxdp3lwACGJVAG/3BZqP380Fz5qOU4eqSMwaRZZd 7C8cb/HM4uLj6AgILFwCXXwNjF8+VjSoQyQwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBymMGuWhIkqPdotAs5TV5zsg66DGrt xC65ThjB+V1Xb3Va9eJvPhO0ihbzIfXkPQjUbj7CV9HONyEQ/g4I+zhZPlG5McNs+a7iAi6Jr1cF KYIpUozS82ojmgrWyoLy0Ygg2QhNZnEWgXDTJ8wfoMvoSE2c7+ccn0hs8nDXAfFM1MFsgIrJYVBB JW45YA5bm1Lluim9MKxMoBUwd8g0mdL/OL1gr2AiguzRlvMG9orj6hC/Fl9n98nJLZnb3cIyDDxa 8Gkw5tY+w0MRhuWTOfbKuYivHjICEuuMUEwqmVIot/7E5T72YbJAhmykCzsj5OBR6hOkFyW8U5hp +LCFZ5E6AAAAAAAA --=-OCHuRd0yvrfiZiZ2jFIX-- From nobody Wed Apr 8 15:03: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 AC3261A8F36 for ; Wed, 8 Apr 2015 15:03:30 -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 U1L5PD_fDLsH for ; Wed, 8 Apr 2015 15:03:28 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1FE1A8F4E for ; Wed, 8 Apr 2015 15:03:28 -0700 (PDT) X-AuditID: a66201d2-f79866d000002a36-53-5525a5ae4eee Received: from tus1smtintpin01.ges.symantec.com (tus1smtintpin01.ges.symantec.com [192.168.215.101]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 53.DF.10806.FA5A5255; Wed, 8 Apr 2015 22:03:27 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Yfy4E-0005ZO-PL; Wed, 08 Apr 2015 22:03:26 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.2.96]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Wed, 8 Apr 2015 15:03:26 -0700 From: Neil Hunsperger To: Werner Koch Date: Wed, 8 Apr 2015 15:03:25 -0700 Thread-Topic: MIME micalg aparemter (was: MIME signature impact) Thread-Index: AdBx9SmAWEh5G9jFQBylJbRBVUaPrQANE62w Message-ID: <14D026C7F297AD44AC82578DD818CDD038F0C37355@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <14D026C7F297AD44AC82578DD818CDD038F0C36BC5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <87iod6255f.fsf_-_@vigenere.g10code.de> In-Reply-To: <87iod6255f.fsf_-_@vigenere.g10code.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RouteViaPGP: true X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsVyYMX1VN31S1VDDU6u4rFo+PeQ3WLih9mM Fp9X7mVxYPbY+eQBq8eF1V+ZPJYs+ckUwBzFZZOSmpNZllqkb5fAlXF6/kOmgon8FX8n6jYw zufpYuTkkBAwkdj+6wIThC0mceHeerYuRi4OIYGPjBK/F/1ggXDeMkr0/L3OBOEsZ5R4veMI G0gLG1D72ultQAkODhEBOYm/hyNAwswCwRJPmvazgNgsAioSD96cYgSxhQXsJV4/+w3WKiLg IPFs+08mCNtIYtXiU2D1vAJREiue3oK64jSjxPW5G5lB5nMC7eo/VwxSwwh06fdTa5ggdolL 3HoyH+oDAYkle84zQ9iiEi8f/2OFqBeVuNO+nhGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YQF oldYou3Xa/YJjBKzkKyYhaR9FpL2WUjaFzCyrGKUSU3OMcwtScwvLSlIrTAw0iuuzE0ERmOy XnJ+7iZGYEQuS2K8tIPx/mHdQ4wCHIxKPLyP5quGCrEmlgFVHmKU4GBWEuG9PRMoxJuSWFmV WpQfX1Sak1p8iFGag0VJnPdhp2iokEB6YklqdmpqQWoRTJaJg1OqgbFje5umsvJuvRt7Slc9 Ybh297Po4swjSyeznr352Wj2cU4NTWcp03WuX7ly+ZQ/nlGbcqbg4s4Y1TW87668XvaG4d37 uOdHvL7q7Vu9bfn5uTq/5kyI3RkuYbokfYPGtPPC39jrffycpVV7ZvL09+QYGXs/1161gsV9 v374qq+sazY6PN3gwvhGiaU4I9FQi7moOBEAK1LLGcQCAAA= Archived-At: Cc: Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] MIME micalg aparemter (was: MIME signature impact) 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, 08 Apr 2015 22:03:30 -0000 > From: Werner Koch [mailto:wk@gnupg.org] >=20 > On Tue, 7 Apr 2015 19:38, Neil_Hunsperger@symantec.com said: >=20 > > One solution is PGP Partitioned format, which supports in-line > > signatures for ASCII bodies and detached signatures for other email > IIRC, the Partitioned format has no means to guarantee the integrity of > the entire message and thus you can replace attachments. To clarify, one can remove attachments, re-arrange them, or change any MIME= property except for the file name. Replacing attachments would require a s= ignature of the new file made by the same key at about the same time. Up until the recent spate of new UIs implementing OpenPGP I would have expe= cted the discussion of encrypted email formats to die out, with the compara= tively simple PGP/MIME format (or perhaps a variant with secure subject lin= es) becoming ubiquitous. Now implementers seem to be asking for something t= hat simultaneously meets the needs of existing back-end message decompositi= on and existing front-end usability. The OpenPGP v4 format seems to provide= enough flexibility to solve these use cases so I'd consider tackling OpenP= GP v5 and email as separate tasks with the advantage of having separate tim= elines. > > Using the above as a starting point, what aspect of a MIME signature's > > impact is left to solve? >=20 > The micalg parameter should be removed or made optional. The micalg > needs to be emitted before the signed data and the signature. It is > useless for OpenPGP and a major hassle for any one-pass creation of > signatures because only the signing tool can determine the used hash > algorithm from the set of signing keys. This should not be > controversial because may MUAs use a fixed string anyway. +1. PGP Desktop actually used a fixed string until ~5 years ago when Enigma= il reported it was causing signature verification failures. -Neil From nobody Fri Apr 10 04:37: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 CCAE11A016B for ; Fri, 10 Apr 2015 04:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.889 X-Spam-Level: * X-Spam-Status: No, score=1.889 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 x4c9YNEZAxq5 for ; Fri, 10 Apr 2015 04:37:32 -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 985801ACEF2 for ; Fri, 10 Apr 2015 04:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD8C9BEE8 for ; Fri, 10 Apr 2015 12:37:30 +0100 (IST) 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 959qCjyvBp-M for ; Fri, 10 Apr 2015 12:37:29 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3E862BE87 for ; Fri, 10 Apr 2015 12:37:29 +0100 (IST) Message-ID: <5527B5F9.3080502@cs.tcd.ie> Date: Fri, 10 Apr 2015 12:37:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "openpgp@ietf.org" References: <551C3FAD.6040107@cs.tcd.ie> In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [openpgp] it's option 2 (was: Re: ways forward wrt IETF wg - please try answer by Apr 8th) 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, 10 Apr 2015 11:37:35 -0000 Hi all, Many thanks for the set of reasoned responses. I think the outcome is clear (see below for notes I took while re-reading the thread) and is to go with option 2 - develop a 4880bis. Starting more-or-less from DKG's list as an initial proposed set of changes seemed to resonate with a few folks. What I'd like to do next is to get a sense of whether we have enough volunteer cycles to deliver option 2 (unless people volunteer to do stuff, and actually do stuff, then stuff won't happen). That means some folks who can do chair-like things and help organise, and some folks who'll do editing and review work. Please send me an offlist mail if you'd be willing and able to help co-chair a re-formed openpgp WG chartered to do a 4880bis. If you're going to do that, please do so before Tuesday next April 14th. (Sending that to the list disqualifies you from chairing btw:-) If you're not sure, send me a mail anyway and we can chat. Please send a mail to the list if you're willing and able to do editing or review of drafts during this calendar year. (Say which or both.) If you'd also be implementing in roughly that timeframe feel free to say that too. Doing that in the next week would be a fine thing. (So deadline: April 17th.) If we appear to have sufficient volunteer cycles and I can identify a couple of chair-like beings, then what I'd like is for those to manage the discussion that ends up with a WG charter that'd get us to option 2. And if that all goes smoothly, then we can just proceed with chartering a WG. Optimistically, we could have that all done and dusted by sometime in May and the WG could fire ahead from there. In terms of chairs, I'd prefer to get two, at least one of whom has done the IETF WG chairing thing before and at least one of whom knows the subject matter very well. Various combinations of people and skills can satisfy that ask. I'm also checking separately with a few folks to see if I can find any victims^H^H^H^H^H^Hvolunteers with chairing experience who're not on this list but are willing to help out. (But also sane, etc:-) In terms of charter, there are a few options to consider, e.g. how much detail of the planned work to put in a charter, whether or not to mention a possible re-charter for broader work and whether or not to let folks write non-normative documents that describe some trust models. Probably a few more things too. If we seem to have chairs and editor/reviewers then we can start in on that week after next, so no need to worry about that for a little bit. It's probably worth clarifying one thing too: if we form a WG, then the WG chairs are the people who pick the editors of WG drafts. So we don't need to decide that now, we just need to know there're sensible choices from which the chairs can pick, and that there's a bunch of folks who'll review text. But if you're feeling motivated enough to start now on writing a draft then please go ahead and do so! And lastly, I'll also start a thread where folks can discuss what bits of work to include in scope of option 2. Partly that's to give you all something to do while we work on the process crap:-) But we also need to give folks a chance to make the case that their favourite things be included in a 4880bis. Cheers, S. Notes I made when re-reading the responses: 17 responses from: cole,phb,dkg,ingersoll, cloos,iang,ritter,mcginnes, carboni,datapacrat,fiskerstrand,sniffen, koch,gil,kaduk,mitterer, schuermann Those were split as follows (CAPS used for preferred option where someone said >1 was ok) 1: gil,mitterer 2: cole, phb, dkg, ingersoll, cloos,ritter,mcginnes,carboni, fiskerstrand,SNIFFEN,koch, gil,kaduk,mitterer,schuermann 3: phb,ritter,sniffen,GIL,MITTERER 4: iang, mitterer 2t: DATAPACRAT 3t: PHB,iang,datapacrat 4t: IANG,datapacrat - dkg's list referred to a couple of times - informational (non-normative) trust model RFC idea liked by a few - option 2 now, maybe more later, liked by a few - "t" options (or one-such as normative) disliked by a good few From nobody Fri Apr 10 04:38: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 17ED31A016B for ; Fri, 10 Apr 2015 04:38:13 -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 Ta6CsF7obA1f for ; Fri, 10 Apr 2015 04:38:11 -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 A66111B2C93 for ; Fri, 10 Apr 2015 04:38:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76B68BE87 for ; Fri, 10 Apr 2015 12:38:10 +0100 (IST) 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 8T5BIT5Z6Kzu for ; Fri, 10 Apr 2015 12:38:09 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 392A6BEEE for ; Fri, 10 Apr 2015 12:38:09 +0100 (IST) Message-ID: <5527B621.3040104@cs.tcd.ie> Date: Fri, 10 Apr 2015 12:38:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "openpgp@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] details of 4880bis work 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, 10 Apr 2015 11:38:13 -0000 Hiya, here's the 2nd thread, starting from DKG's list. Please discuss... (We don't need +1's for this, just tweaks, corrections, additions etc.) If someone wanted to put this on github or somewhere else the group can edit it, that'd also be fine. Ta, S. a) update the fingerprint format (avoid inclusion of creation date, use stronger digest algorithm; i'm dubious about embedding algorithm agility in the fingerprint itself, but explicit version info in the fingerprint might be reasonable so we don't have to keep guessing by fpr structure for future versions) b) get rid of keyids entirely -- when referring to a key, use the fingerprint where a compact hint is needed (e.g. in a replacement of the issuer subpacket) or the full primary key where it is more sensitive (e.g. in designated revoker). With EC keys, we could consider using the full key (not the full cert) even in the issuer subpacket case, which could make things cleaner. c) deprecate MD5, SHA1, and RIPEMD160 d) clarify that cleartext signatures should all use charset/encoding UTF-8. e) update S2K with something more modern (PBKDF2, HKDF, scrypt?), deprecate all the other mechnanisms explicitly f) standardize the two new curves coming out of the CFRG: 25519 and curve448 ("goldilocks") for both signatures and encryption (Werner has already started this process for 25519 signatures) g) remove compression entirely h) clean up the language: clearly distinguish between "public key" and "certificate", and ensure that the use of the terms "trust" and "validity", if still present, are used unambiguously. i) declare a literal data packet type "m" that means "MIME content" so that we can punt on the rest of the message structure/format/encoding/type craziness to MIME. j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can get away with. k) provide a modern streamable/chunkable AEAD replacement for Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD mechanism should be the baseline. From nobody Fri Apr 10 05:21: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 7EF6A1B2DD7 for ; Fri, 10 Apr 2015 05:21:37 -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 6_02NjUp2VBr for ; Fri, 10 Apr 2015 05:21:35 -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 52F2A1B2DD3 for ; Fri, 10 Apr 2015 05:21:35 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YgXwD-00028J-Km for ; Fri, 10 Apr 2015 14:21:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YgXuU-0006Yh-W8; Fri, 10 Apr 2015 14:19:47 +0200 From: Werner Koch To: Stephen Farrell References: <5527B621.3040104@cs.tcd.ie> 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, 10 Apr 2015 14:19:46 +0200 In-Reply-To: <5527B621.3040104@cs.tcd.ie> (Stephen Farrell's message of "Fri, 10 Apr 2015 12:38:09 +0100") Message-ID: <87bniwqiot.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] details of 4880bis work 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, 10 Apr 2015 12:21:37 -0000 On Fri, 10 Apr 2015 13:38, stephen.farrell@cs.tcd.ie said: > additions etc.) If someone wanted to put this on github or > somewhere else the group can edit it, that'd also be fine. I you don't mind you may use the GnuPG wiki https://wiki.gnupg.org/rfc4880bis However, you need an account from bugs.gnupg.org as an anti-spam measure. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Apr 10 05:41: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 7ADA51B31A1 for ; Fri, 10 Apr 2015 05:41:35 -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 O0Zf2dVQXTbB for ; Fri, 10 Apr 2015 05:41:34 -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 43A411B31A0 for ; Fri, 10 Apr 2015 05:41:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YgYFY-0002Nk-OD for ; Fri, 10 Apr 2015 14:41:32 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YgYE4-0006bx-0F for ; Fri, 10 Apr 2015 14:40:00 +0200 From: Werner Koch To: "openpgp\@ietf.org" References: <5527B621.3040104@cs.tcd.ie> 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, 10 Apr 2015 14:39:59 +0200 In-Reply-To: <5527B621.3040104@cs.tcd.ie> (Stephen Farrell's message of "Fri, 10 Apr 2015 12:38:09 +0100") Message-ID: <877ftkqhr4.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] 4880bis: Update S2K 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, 10 Apr 2015 12:41:35 -0000 Hi, this is about this item from dkg's list: > e) update S2K with something more modern (PBKDF2, HKDF, scrypt?), > deprecate all the other mechnanisms explicitly I agree that all options except for iterated+salted should be removed and if we settle for a new MUST hash algorithm that one should als be a MUST for S2K. We may also dicuss whether the float encoded COUNT could be updated with something simpler. This is related to a other packet length header fields. Why do you think that the S2K thing is worse than PBKDF2? Is there any paper comparing these two KDFs? We have two use cases for KDFs: a) Protection of the secret key. This is important most mostly a local issue. Sending secret keys over the the wire requires a lot of precautions anyway and thus I think there is no need to put strin extra protection into it. It is better to convey secret keys using another secure method. b) Symmetric-Key Encrypted Session Key Packets. I don't know how often this is used. I assume that in most use cases the passphrase is taken from external key management system and thus we can expect that it has full entropy and the KDF does not add to the security. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Apr 10 06:23: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 DC8CD1B354E for ; Fri, 10 Apr 2015 06:23:21 -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 VUjU2Ho4z1qc for ; Fri, 10 Apr 2015 06:23:20 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 3F9841B3538 for ; Fri, 10 Apr 2015 06:23:20 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so13533614lbb.2 for ; Fri, 10 Apr 2015 06:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=VC8zEni9TZacoDMrp8h3H90X2lTMwf+ePuE8g2IoFLk=; b=YOC6crx+Daoz7aSMHj86OK5VqqdM4urofnIQ5oGDB30XyGdDXvzYbhHqsHgRg+/Gjv 5VLG+QDrjpoKLHb2d4e3wHvK++EWio8oGDdk7pLYtRBApcdtGqFQdJvPeEnjIRTTRM2g 6bsmn3iJ+/YYmxzf+pAB2BIr9MpkA/5jkZWLT5EajS/ZOThQ4FU4SYqb98B+omc+DeNB jL2ZJFRt6a93CIyCcP/AHZaSNUlCn9uPGn9/vuwpph6UZ0AU+W7cETxXoTfaWI4B/qTd BxRHMSmbEfDuRhJSDZ1w8nR+vDSGOtPH0rwPt/sgMfu3URy4Z3h+RfE7inS58uNK4bZv B9dA== MIME-Version: 1.0 X-Received: by 10.152.120.8 with SMTP id ky8mr1399348lab.118.1428672198806; Fri, 10 Apr 2015 06:23:18 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Fri, 10 Apr 2015 06:23:18 -0700 (PDT) Date: Fri, 10 Apr 2015 09:23:18 -0400 X-Google-Sender-Auth: ssnSXCSzzkCe4IJPvtWd2_-oj0c Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: [openpgp] Fingerprints 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, 10 Apr 2015 13:23:22 -0000 On Fri, Apr 10, 2015 at 7:38 AM, Stephen Farrell wrote: > > > Hiya, here's the 2nd thread, starting from DKG's list. Please > discuss... (We don't need +1's for this, just tweaks, corrections, > additions etc.) If someone wanted to put this on github or > somewhere else the group can edit it, that'd also be fine. > > Ta, > S. > > a) update the fingerprint format (avoid inclusion of creation date, use > stronger digest algorithm; i'm dubious about embedding algorithm > agility in the fingerprint itself, but explicit version info in the > fingerprint might be reasonable so we don't have to keep guessing by > fpr structure for future versions) I would like to get started on this bit ASAP as it is the one that has the most long term consequences. There is no need to have an algorithm field, a version field is sufficient because we should only be using one algorithm at a given time. There is no need for a length field either. Right now, I am using a one byte version field for my scheme. I am also using SHA512 and truncating to 128 bits, then base 32 encoding. The rationale for this is * Case sensitivity breaks in many applications where fingerprints might be used. Reading over the telephone, putting them in the DNS, etc. * Fingerprints are the root of trust, there is an outside chance that SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits is a lot harder because it has 80 rounds rather than 64. * The birthday attack is not relevant, nor are key substitution attacks for most situations where you might want to use a fingerprint. Occasionally however, they do matter. Using SHA-2-512 and truncating makes it possible to 'upgrade' the fingerprint by just adding back the bits that were omitted. This has particular advantages when enrolling fingerprints in a TRANS like log. We can enroll the full 512 bit fingerprint without impact on things like business cards. The bit that will probably be controversial is how I am calculating them, over an X.509v3 KeyInfo block. There is method to the madness however: First, fingerprints and key hashes are appearing in many different IETF specs. We have them in HTTP key pinning and in many other specs. I would like to be able to use one key fingerprint in any situation. Adding a key or fingerprint into an identifier allows it to be 'hardened', basically we have a self authenticating identifier. This is very powerful. To have one fingerprint format that supports every protocol requires that we have a single registry of identifiers that can be used for any protocol. There will always be an OID for any protocol the IETF uses and this mechanism requires no maintenance by either IETF or IANA. If people want to use vanity crypto, they can and they don't need to come to us with a draft. They don't get to claim IETF endorsement either. As a practical matter, the impact on coding is virtually nil. The conversion between the ASCII and byte format of OIDs is a bit of a pain but it results in a byte sequence that can just be prepended to the key bytes. It is not necessary to implement a DER encoder just to calculate KeyInfo blobs any more than it is necessary to do this for implementing PKCS #1 for RSA. Low level crypto has always involved bits of ad-hoc ASN.1 and probably always will. And quite often it turns out that even the crypto libraries that contain full ASN.1 parser/encoders implement these particular structures by hand. Now if the group really wants to do something different, then I could do that. But I want to start shipping my stuff and getting people using the code. If people really can't stomach ASN.1 code then we could do some other key format. But the problem then becomes having to specify how to express new algorithms in that format. From nobody Fri Apr 10 07:01: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 DD6491B3643 for ; Fri, 10 Apr 2015 07:01:39 -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 eZtQnOleIt9Z for ; Fri, 10 Apr 2015 07:01:35 -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 3C5011B3640 for ; Fri, 10 Apr 2015 07:01:35 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YgZUz-0003XL-G8 for ; Fri, 10 Apr 2015 16:01:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YgZQs-0006qW-5U; Fri, 10 Apr 2015 15:57:18 +0200 From: Werner Koch To: Phillip Hallam-Baker 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: Phillip Hallam-Baker , Stephen Farrell , "openpgp\@ietf.org" Date: Fri, 10 Apr 2015 15:57:18 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 10 Apr 2015 09:23:18 -0400") Message-ID: <87y4m0ozlt.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" , Stephen Farrell Subject: Re: [openpgp] Fingerprints 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, 10 Apr 2015 14:01:40 -0000 On Fri, 10 Apr 2015 15:23, phill@hallambaker.com said: > There is no need to have an algorithm field, a version field is > sufficient because we should only be using one algorithm at a given Right. However an algorithm field is as good as a version field because they have the same purpose in this context. An algorithm field saves us a mapping to the actual algorithm. Recall that OpenPGP uses an one-octet indentifier and not an OID. > time. There is no need for a length field either. Agreed. It is often useful to have a keyid to quickly (but insecure) refer to a key. I suggest to take it from the fingerprint bytes 1 to 4 (ignoring the algorithm byte). There is no need for a long keyid. However, we may also suggest a use like in git where you may abbreviate it as you like - however the keyid should be non-normative because the protocol should not make any use of it. > I am also using SHA512 and truncating to 128 bits, then base 32 > encoding. The rationale for this is Because there are several versions of BASE-32 I suggest the use of z-base-32 which is used by Tahoe-LAFS and ZRTP. The truncation length of the hash should be match a best match for the base 32 encoding. > * Fingerprints are the root of trust, there is an outside chance that > SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits > is a lot harder because it has 80 rounds rather than 64. I think that should be discussed in the context of the new default hash algorithm. > The bit that will probably be controversial is how I am calculating > them, over an X.509v3 KeyInfo block. There is method to the madness X.509 has no definition for a fingerprint but OpenPG already uses a well defined method to compute the fingerprint. You can't compare the two protocols or define a unique fingerprint method. > If people really can't stomach ASN.1 code then we could do some other > key format. But the problem then becomes having to specify how to We want to do an rfc4880bis and not an entire new protocol. Thus any ASN.1 encoding is not an option. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Apr 10 07:06: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 787031B3673 for ; Fri, 10 Apr 2015 07:06:37 -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 V01eT1lO7lax for ; Fri, 10 Apr 2015 07:06:36 -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 2D97B1B3670 for ; Fri, 10 Apr 2015 07:06:35 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YgZZp-0003YY-Mr for ; Fri, 10 Apr 2015 16:06:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YgZVz-0006rY-Kw; Fri, 10 Apr 2015 16:02:35 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <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> <87mw2i28nr.fsf@vigenere.g10code.de> <87vbh6zqsy.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: Phillip Hallam-Baker , Christoph Anton Mitterer , Brian Sniffen , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Date: Fri, 10 Apr 2015 16:02:35 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 8 Apr 2015 10:15:41 -0400") Message-ID: <87twwoozd0.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: Christoph Anton Mitterer , Brian Sniffen , Derek Atkins , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] OpenPGP private certification 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, 10 Apr 2015 14:06:37 -0000 On Wed, 8 Apr 2015 16:15, phill@hallambaker.com said: > Personally, I believe that owning your personal DNS name is as > important for security as having a keypair. I have a huge part of my Although I agree with you, it will not work for the billion users we are aiming for. > We do need trust hierarchies for key management. But each individual > should be the root of their personal hierarchy. GNUnet's GNS is what you want. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Apr 10 07:40: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 5F7881A0371 for ; Fri, 10 Apr 2015 07:40:53 -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 A07XgDpBbxBP for ; Fri, 10 Apr 2015 07:40:50 -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 52E401A0369 for ; Fri, 10 Apr 2015 07:40:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CCA54E2038; Fri, 10 Apr 2015 10:40:48 -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 23796-07; Fri, 10 Apr 2015 10:40:45 -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 A39ECE2036; Fri, 10 Apr 2015 10:40:45 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3AEegWm022098; Fri, 10 Apr 2015 10:40:42 -0400 From: Derek Atkins To: Stephen Farrell References: <551C3FAD.6040107@cs.tcd.ie> Date: Fri, 10 Apr 2015 10:40:41 -0400 In-Reply-To: <551C3FAD.6040107@cs.tcd.ie> (Stephen Farrell's message of "Wed, 01 Apr 2015 19:57:49 +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: "openpgp@ietf.org" Subject: Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th 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, 10 Apr 2015 14:40:53 -0000 Hi, I realize you've already summed up your responses, but I want to respond for the record too. (Yes, I realize it's been 9 days since you sent this, so I missed your "please try to answer by the 8th" request). In terms of the options, I think option 2 is best and closest matches what can realistically be done. Some others might want 3 or 4. I doubt anyone wants 1. I think we should not do any of the 't' options -- I think 2440 and 4880 got it right by only specifying how to make signatures but not what they mean. I.e., it doesn't even define the 'web of trust'. Now, I do think it would be reasonable to have *separate* documents that explain, e.g., how to do web-of-trust in OpenPGP, how to do CA assertions in OpenPGP, etc. Indeed, I'd probably even be willing to author a draft on how to specify and implement "name constraints" in OpenPGP using assertion signature notifications. -derek Stephen Farrell writes: > Hi all, > > So I think the volume and content of discussions over the > last few weeks clearly indicates a desire to do something > about openpgp, but that discussion doesn't seem to be closing > in on exactly what to do, in the IETF context. It'd help me > to try figure that out if folks would respond to this saying > which of the options below you think can make sense. Picking > more than one is fine, but if so, please say which you prefer. > Annotating/explaining your choice(s) is very welcome but > please try resist the temptation to change this into a chat > about a different set of options:-) > > It would also really help me (and I suspect others) evaluate > messages if you could say something about how you fit into > the openpgp universe (e.g. "I wrote the foo implementation" > or "I run a thing with N people using pgp" or whatever). An > essay on that is not useful here, but a line or two could > be really good. > > Please try respond to this if you can before Wed April 8th > and I'll try summarise whatever we get back to the list after > that, and we may or may not have a plan of action at that > point - we'll see I guess. > > And pretty please do change the message subject if you want > to follow up and discuss something from someone else's response. > That'll at least make my life a little easier when it comes > to trying to summarise back to the list but it'll also make it > easier for folks to check if I've mucked up in how I summarise > (and I muck up a lot, sadly:-). > > Anyway here's the options: > > option 1: do nothing - there's nothing much to do or at least > not in the IETF or not within the IETF for the next >6 months. > > option 2: do maintenance work on rfc4880 - produce a 4880bis > with better crypto options at least, and debate any further > detailed changes during chartering - the charter will contain > a list of specific things to do and other things will be out > of scope (for now) > > option 3: do a major revision to openpgp - take rfc4880 as a > starting point but question all design decisions in the process > of developing a successor version of openpgp and write a > charter that allows for all such design decisions to be > questioned > > option 4: move beyond openpgp (or smime) to develop a new > flavour of end-to-end security for interpersonal messaging, > possibly not that tightly coupled to email, but at least > supporting an email flavour > > For options 2-4 one could include more or less work related > to trust models or key hierarchies/key distribution. If you > would like to include that kind of work please pick one of > those below. If pursuing any of these, we'd need a separate > discussion about the scope of that work and whether or not > one specific approach ought be standardised, but please > let's not yet have that discussion until we see that one of > the "t" options below has a good bit of support. > > option 2t: option 2 + add some trust model/key management > option 3t: option 3 + add some trust model/key management > option 4t: option 4 + add some trust model/key management > > So that's for choices. Remember it's ok to pick more than > one with which you could live, but please be clear about > which you prefer. > > I'd also like to talk about how we might process some of > the above if we establish rough consensus for one of 'em. > > Option 1 is easy. The list can continue to debate stuff, > but there's no IETF process stuff needed and no new RFCs > on the horizon. I get off the hook:-) > > For option 2, or 2t we could start crafting a charter on > the list once we've gotten agreement that that's the goal. > I don't think a face-to-face BoF would be needed before > forming a working group unless the scope of the "t" part of > 2t was proving hard to pin down. (We could arrange some > virtual audio meetings if that'd help of course.) That > could mean a working group is formed quite soon, and that > working group might choose to meet face-to-face in Prague > in July, or might prefer to work on the list only, or > with some audio meetings. > > For options 3, 3t, 4 or 4t I do think we'd likely need to > have a face-to-face BoF meeting as there'd be a lot to > consider and pin down and higher bandwidth is much better > for that. In that case, the important date is June 5th > which is the next cutoff date for requesting such a meeting > for the Prague IETF to be held July 19-24. [1] (June 5th > might seem like a long way off, but it's not really so if > we needed such a meeting then starting to work towards that > soon would be much better than doing so late.) > > Also, some of this can be done sequentially. For example, > as an area director I'm very happy re-chartering existing > working groups to add more tasks where those groups have > demonstrated the ability to be productive. In my experience > that can work better than starting out with the hard/ambitious > stuff as the very first thing to do. That might argue for > starting with option 2 and then, if all goes well, discussing > whether or how to tackle option 3 or 4. (We could even charter > a group to do the maintenance work for option 2 and when that's > done to then discuss how to re-charter for one of the more > complicated choices.) I'd suggest however, we ignore such > sequential processing for now, see what folks prefer as a > goal, and then think about whether there's a way to get to > what people want via sequencing things cleverly. So, just > for now, please don't suggest "2, followed by 3" even if > that's something you like the sound of - I think folks' > initial responses will probably make it obvious if we need > a chat about that. > > And lastly, please let's not have an IETF process discussion > or a discussion about why the IETF is great or crap. If we > see that there's IETF stuff folks want to do and if those > folks are willing and able to implement/deploy the results > then that's enough to be going on with. > > Thanks, > S. > > [1] https://www.ietf.org/meeting/important-dates-2015.html#ietf93 > > > > > > _______________________________________________ > 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 Apr 10 07:58: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 25F4B1A0275 for ; Fri, 10 Apr 2015 07:58:21 -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 ga8mNt5TqKWz for ; Fri, 10 Apr 2015 07:58:19 -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 C20CB1A0364 for ; Fri, 10 Apr 2015 07:58:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 71031E2038; Fri, 10 Apr 2015 10:58:16 -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 23796-10; Fri, 10 Apr 2015 10:58:14 -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 D17A9E2036; Fri, 10 Apr 2015 10:58:13 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3AEwCQ5022518; Fri, 10 Apr 2015 10:58:12 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <87y4m0ozlt.fsf@vigenere.g10code.de> Date: Fri, 10 Apr 2015 10:58:11 -0400 In-Reply-To: <87y4m0ozlt.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 10 Apr 2015 15:57:18 +0200") 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" , Stephen Farrell Subject: Re: [openpgp] Fingerprints 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, 10 Apr 2015 14:58:21 -0000 Werner Koch writes: > On Fri, 10 Apr 2015 15:23, phill@hallambaker.com said: > >> There is no need to have an algorithm field, a version field is >> sufficient because we should only be using one algorithm at a given > > Right. However an algorithm field is as good as a version field because > they have the same purpose in this context. An algorithm field saves us > a mapping to the actual algorithm. Recall that OpenPGP uses an > one-octet indentifier and not an OID. I'm with Werner on this one. There's not a significant difference between a version field and an algorithm field. Either option adds a single byte to the data structure, but using a version field requires additional lookup map (from fingerprint version # to hash algorithm). Maybe that's useful to make sure an attacker doesn't use a "bad" hash algorithm for a fingerprint? But I'd rather just use the hash algorithm directly. >> time. There is no need for a length field either. > > Agreed. > > It is often useful to have a keyid to quickly (but insecure) refer to a > key. I suggest to take it from the fingerprint bytes 1 to 4 (ignoring > the algorithm byte). There is no need for a long keyid. However, we > may also suggest a use like in git where you may abbreviate it as you > like - however the keyid should be non-normative because the protocol > should not make any use of it. I presume here you are referring to the "printed" fingerprint, and not the "internal" fingerprint? Internally we'd still use the full length, right? Or would we need to somehow know when (and how) to truncate the hash? >> I am also using SHA512 and truncating to 128 bits, then base 32 >> encoding. The rationale for this is > > Because there are several versions of BASE-32 I suggest the use of > z-base-32 which is used by Tahoe-LAFS and ZRTP. The truncation length of > the hash should be match a best match for the base 32 encoding. Similarly, I think we should be clear that we're talking about two different things here. Internally (e.g. in a signature packet) it should be the binary result, not hex- or base-32 encoded. >> * Fingerprints are the root of trust, there is an outside chance that >> SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits >> is a lot harder because it has 80 rounds rather than 64. > > I think that should be discussed in the context of the new default hash > algorithm. > > >> The bit that will probably be controversial is how I am calculating >> them, over an X.509v3 KeyInfo block. There is method to the madness > > X.509 has no definition for a fingerprint but OpenPG already uses a well > defined method to compute the fingerprint. You can't compare the two > protocols or define a unique fingerprint method. I think "how you take the fingerprint of an X509 key block" should be out of scope for the OpenPGP WG. I think that you can (and should) write a separate document that does that. >> If people really can't stomach ASN.1 code then we could do some other >> key format. But the problem then becomes having to specify how to > > We want to do an rfc4880bis and not an entire new protocol. Thus any > ASN.1 encoding is not an option. Ditto. If the goal here is to have the same key material result in the same fingerprint regardless of whether it's encoded in OpenPGP or X.509, I think the answer is going to be "X.509 people are going to need to convert their key material to OpenPGP packet format and feed into the hash algorithm". I see no other way, and frankly any other way is madness (for the OpenPGP group). I'm sure Phill wont like that answer, but I think it's the right answer for this (potential) working group. > > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 10 08:15: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 0B3DD1A1AE3 for ; Fri, 10 Apr 2015 08:15:33 -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 YpErCyBUv2sj for ; Fri, 10 Apr 2015 08:15:31 -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 010BA1A1A8C for ; Fri, 10 Apr 2015 08:15:30 -0700 (PDT) Received: by layy10 with SMTP id y10so15596025lay.0 for ; Fri, 10 Apr 2015 08:15:28 -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:content-type; bh=d7w5zDcAg3XQpaE++UHlemqDHMHqcD2oXGdd3jl70mI=; b=bvghggLxg5we87BBKjNURBGbX4IBrOuLrZig5fe4ihm//jEC2wIDk500yWOskNHrmm O4FxDnjQtrJQYgFKT0B9h1KYDzwbXMXyB3JSSWZwJ5h6q0VPCASXru6nUNvrEHPUj602 D6bNAW9kXhUYmsmvmqoibl7f0X9DgAhNGkMdibhyeEbCt8Vg7vFaHQUkDHZZUroclZge fZnEPjh2yiKbUg8RpLWF1Ol8kszjkvE2CAlK9jcxucJuM+ctrnYLTdt9msACMETIK/yW 7EPhWG2CmKd+eLtiy6G4s4WuyuBW78F5GfTS/KPJ3zoCLP8lhi0X1CoqQniNoaua4Ttu W2YA== MIME-Version: 1.0 X-Received: by 10.152.6.1 with SMTP id w1mr1808227law.91.1428678928431; Fri, 10 Apr 2015 08:15:28 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Fri, 10 Apr 2015 08:15:28 -0700 (PDT) In-Reply-To: <87y4m0ozlt.fsf@vigenere.g10code.de> References: <87y4m0ozlt.fsf@vigenere.g10code.de> Date: Fri, 10 Apr 2015 11:15:28 -0400 X-Google-Sender-Auth: wqDK2PbGfsCGIq_wEojU9i_6s0g Message-ID: From: Phillip Hallam-Baker To: Phillip Hallam-Baker , Stephen Farrell , "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 10 Apr 2015 15:15:33 -0000 On Fri, Apr 10, 2015 at 9:57 AM, Werner Koch wrote: > On Fri, 10 Apr 2015 15:23, phill@hallambaker.com said: > >> There is no need to have an algorithm field, a version field is >> sufficient because we should only be using one algorithm at a given > > Right. However an algorithm field is as good as a version field because > they have the same purpose in this context. An algorithm field saves us > a mapping to the actual algorithm. Recall that OpenPGP uses an > one-octet indentifier and not an OID. > >> time. There is no need for a length field either. > > Agreed. > > It is often useful to have a keyid to quickly (but insecure) refer to a > key. I suggest to take it from the fingerprint bytes 1 to 4 (ignoring > the algorithm byte). There is no need for a long keyid. However, we > may also suggest a use like in git where you may abbreviate it as you > like - however the keyid should be non-normative because the protocol > should not make any use of it. > >> I am also using SHA512 and truncating to 128 bits, then base 32 >> encoding. The rationale for this is > > Because there are several versions of BASE-32 I suggest the use of > z-base-32 which is used by Tahoe-LAFS and ZRTP. The truncation length of > the hash should be match a best match for the base 32 encoding. That is the one I am using already. Truncating to a multiple of 5 bits makes sense to me (32 = 2^5). If we truncate to a multiple of 5 characters as well, we can break at the segment boundaries: 100 bit fingerprint: opgp:xxxxx-xxxxx-xxxxx-xxxxx 125 bit fingerprint: opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx 200 bit fingerprint: opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx 250 bit fingerprint: opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx The version field will steal a few bits. We might want to consider using a 5 bit field rather than 8 and set it up so that the first character gives the version number. Future generations can always decide to add bits if they start to run out. >> * Fingerprints are the root of trust, there is an outside chance that >> SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits >> is a lot harder because it has 80 rounds rather than 64. > > I think that should be discussed in the context of the new default hash > algorithm. OK, fair enough. >> The bit that will probably be controversial is how I am calculating >> them, over an X.509v3 KeyInfo block. There is method to the madness > > X.509 has no definition for a fingerprint but OpenPG already uses a well > defined method to compute the fingerprint. You can't compare the two > protocols or define a unique fingerprint method. The objective here is to be able to establish the fingerprint as the interface between the trust model and the protocol. X.509 does not have that concept at the moment. But introducing that concept into the PKIX world is how I think we can get to convergence between the two models. >> If people really can't stomach ASN.1 code then we could do some other >> key format. But the problem then becomes having to specify how to > > We want to do an rfc4880bis and not an entire new protocol. Thus any > ASN.1 encoding is not an option. For approved algorithms, I really don't care. I will need to implement the existing key format in any case. What I would like to avoid is having to review drafts describing vanity crypto. The fingerprint is going to need to include some sort of algorithm identifier key in the data being hashed to prevent algorithm substitution attacks. So one option would be to specify how to encode the algorithms we plan to approve and recommend and then reserve one code for 'X.509 KeyInfo Blob' just treating it as an algorithm. Then when the Russians come looking to get a PGP RFC issued describing how to use GOST, the NSA come along wanting code points for Suites A, B and C, Fred comes round with Power One Time Pad, etc. etc. They can be told they don't need it. This has the major advantage that there would be no need to shift away from the existing one byte registries and it would reduce the risk of having them filled up with junk. One of the things I would like the IETF to adopt as a general policy is to have one Mandatory to Implement algorithm and one backup algorithm that are supported by all IETF crypto protocols that are in active use and to avoid having working groups dragging on for five years after they were really finished as people bikeshed algorithm choices. From nobody Fri Apr 10 08:19: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 475191A1B1E for ; Fri, 10 Apr 2015 08:19:26 -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 RrhQaPqUfyTr for ; Fri, 10 Apr 2015 08:19:24 -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 28D341A1AF0 for ; Fri, 10 Apr 2015 08:19:24 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 89DA86D782; Fri, 10 Apr 2015 11:19:22 -0400 (EDT) Message-ID: <5527E9F9.7010505@iang.org> Date: Fri, 10 Apr 2015 16:19:21 +0100 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: <5527B621.3040104@cs.tcd.ie> In-Reply-To: <5527B621.3040104@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 10 Apr 2015 15:19:26 -0000 Some thoughts, none really need answering. On 10/04/2015 12:38 pm, Stephen Farrell wrote: > a) update the fingerprint format (avoid inclusion of creation date, use > stronger digest algorithm; i'm dubious about embedding algorithm > agility in the fingerprint itself, but explicit version info in the > fingerprint might be reasonable so we don't have to keep guessing by > fpr structure for future versions) In the past, where I've had a very occasional need to indicate version/alg in fingerprint like material, and full tagging wasn't justified, I've used the length to do that. E.g., 16 bytes was MD5, 18 was NAH, 20 was SHA1. Clunky, but it served. Just a thought. > d) clarify that cleartext signatures should all use charset/encoding > UTF-8. Are calculated over cleartext UTF-8 plaintext document as the default? OK. (Not, the cleartext sigs are now to be delivered in UTF-8, or, the cleartext sigs will be parsable unchanged and therefore compatible with both US-ASCII and UTF-8.) > f) standardize the two new curves coming out of the CFRG: 25519 and > curve448 ("goldilocks") for both signatures and encryption (Werner > has already started this process for 25519 signatures) Why two curves? Is this just the algorithm agility discussion or is there an actual difference between them? Why not just use the stronger one and be done with it? (Not wishing to start the algorithm agility debate, I'm sure everyone's familiar with the basics there, just wondering if there is any other motivation.) > h) clean up the language: clearly distinguish between "public key" and > "certificate", and ensure that the use of the terms "trust" and > "validity", if still present, are used unambiguously. It would be nice if we could eliminate the term "trust" altogether. Humans trust, software agents cannot. Calling some bit a "trust bit" is therefore almost guaranteed to become ambiguous, and the resultant self-deception is one of the root causes of PKI failure in both x.509 and pgp circles. In "theory" we might be better off replacing it with "policy" which is a word that clearly indicates there should be some wider document that describes what the bit is trying to record. In the alternate, if we don't like the word "policy" perhaps "claim" or "statement" or even "relationship graph link" or "edge" or... > i) declare a literal data packet type "m" that means "MIME content" so > that we can punt on the rest of the message > structure/format/encoding/type craziness to MIME. > > j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can > get away with. > > k) provide a modern streamable/chunkable AEAD replacement for > Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets > > l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD > mechanism should be the baseline. No RSA? Is there consensus amongst devs that enough of us aren't going to implement RSA anyway? We're ready to make a clean break, and actually mitigate against it? (I'm happy to join the witch-burning party, but it's had such long legs, it saw off the DSA challenger even tho many tried to kill it.) iang From nobody Fri Apr 10 08:31: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 A5E461A1BB9 for ; Fri, 10 Apr 2015 08:31:37 -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 3lfejesbcrJR for ; Fri, 10 Apr 2015 08:31:35 -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 5DDEF1A1AF0 for ; Fri, 10 Apr 2015 08:31:35 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Ygau5-0004Hu-Sb for ; Fri, 10 Apr 2015 17:31:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YgapU-00076s-89; Fri, 10 Apr 2015 17:26:48 +0200 From: Werner Koch To: Derek Atkins References: <87y4m0ozlt.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: Derek Atkins , Phillip Hallam-Baker , "openpgp\@ietf.org" , Stephen Farrell Date: Fri, 10 Apr 2015 17:26:47 +0200 In-Reply-To: (Derek Atkins's message of "Fri, 10 Apr 2015 10:58:11 -0400") Message-ID: <87iod4ovgo.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 Farrell , Phillip Hallam-Baker , "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 10 Apr 2015 15:31:37 -0000 On Fri, 10 Apr 2015 16:58, derek@ihtfp.com said: > I presume here you are referring to the "printed" fingerprint, and not > the "internal" fingerprint? Internally we'd still use the full length, > right? Or would we need to somehow know when (and how) to truncate the Sure, just for the printed one. Internally we should alway use the full fingerprint with algorithm id. If we want to have the smallest possible signature it is possible to not emit the new IssuerFingerprint signature subpacket. > Similarly, I think we should be clear that we're talking about two > different things here. Internally (e.g. in a signature packet) it > should be the binary result, not hex- or base-32 encoded. Sure. Although this is not part of the wire format it is important to have a standard on how a fingerprint is presented to the user. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Apr 10 08:36: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 E264E1A1EF6 for ; Fri, 10 Apr 2015 08:36:19 -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 cjoiOQaJPP7k for ; Fri, 10 Apr 2015 08:36:18 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 2565C1A1BE3 for ; Fri, 10 Apr 2015 08:36:18 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so16531306lbc.1 for ; Fri, 10 Apr 2015 08:36:16 -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=IpQ31NutVRG88kYBX9FTh+m81j2yiuCdR54m/AfySZI=; b=GDR+9rB6WavfP9x/Xv0HBD39aiMqu024lKpopoPJq9ZruxJ6J7hv2+P5R00UcCFasO IqOUN0ldhDEL00q61vpxf4Hz5kcfAW29REelG8mGmCZ2Fi/+nq2hzDfRnQRXXiW861Ox zR50r8z/tm0xENUAcN+Por/62dE1XYog0AQFVLWzdD33xABsn3BcVzwJr1uc6MSDI8KR FDEIGYcGs2v0Iag9dnecj0lPnIjbrMA3omBGdBYvy/BFC++rw6RmNX6H0shbWxz1OTNo k17akfzH4EsvtPAhDVBlPeTAbiaurWo2BO0Q5Mykaqbr/uH+bVsoXVH096mERQNwPJuB b1wg== MIME-Version: 1.0 X-Received: by 10.112.13.7 with SMTP id d7mr1948139lbc.79.1428680176650; Fri, 10 Apr 2015 08:36:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Fri, 10 Apr 2015 08:36:16 -0700 (PDT) In-Reply-To: References: <87y4m0ozlt.fsf@vigenere.g10code.de> Date: Fri, 10 Apr 2015 11:36:16 -0400 X-Google-Sender-Auth: 0pJJeZBUXs5BWkak1uvoRplEALQ Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" , Stephen Farrell Subject: Re: [openpgp] Fingerprints 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, 10 Apr 2015 15:36:20 -0000 On Fri, Apr 10, 2015 at 10:58 AM, Derek Atkins wrote: > Werner Koch writes: > >> On Fri, 10 Apr 2015 15:23, phill@hallambaker.com said: >> >>> There is no need to have an algorithm field, a version field is >>> sufficient because we should only be using one algorithm at a given >> >> Right. However an algorithm field is as good as a version field because >> they have the same purpose in this context. An algorithm field saves us >> a mapping to the actual algorithm. Recall that OpenPGP uses an >> one-octet indentifier and not an OID. > > I'm with Werner on this one. There's not a significant difference > between a version field and an algorithm field. Either option adds a > single byte to the data structure, but using a version field requires > additional lookup map (from fingerprint version # to hash algorithm). > > Maybe that's useful to make sure an attacker doesn't use a "bad" hash > algorithm for a fingerprint? But I'd rather just use the hash algorithm > directly. Well if we are all going to use the same algorithm, having the leading byte be 8 (SHA-2-256) or 10 (SHA-2-512) versus 0 hardly makes a difference. In fact I could continue to use 0 for my OID based scheme and achieve interop :) The only downside of this approach is that divergence is easier. > I presume here you are referring to the "printed" fingerprint, and not > the "internal" fingerprint? Internally we'd still use the full length, > right? Or would we need to somehow know when (and how) to truncate the > hash? We would need something to tell us how many bits we should require in particular circumstances. So for example, if I am wanting to send you an email, I should probably require at least 100 bits. If I am deciding whether to accept a request to connect to my home network from a set top box, 25 bits is probably sufficient as only one device is likely to be making a request at a time and a 1 in a million chance of being fooled is probably OK. >>> I am also using SHA512 and truncating to 128 bits, then base 32 >>> encoding. The rationale for this is >> >> Because there are several versions of BASE-32 I suggest the use of >> z-base-32 which is used by Tahoe-LAFS and ZRTP. The truncation length of >> the hash should be match a best match for the base 32 encoding. > > Similarly, I think we should be clear that we're talking about two > different things here. Internally (e.g. in a signature packet) it > should be the binary result, not hex- or base-32 encoded. Yes, definitely. Base32 is just for display. >>> * Fingerprints are the root of trust, there is an outside chance that >>> SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits >>> is a lot harder because it has 80 rounds rather than 64. >> >> I think that should be discussed in the context of the new default hash >> algorithm. >> >> >>> The bit that will probably be controversial is how I am calculating >>> them, over an X.509v3 KeyInfo block. There is method to the madness >> >> X.509 has no definition for a fingerprint but OpenPG already uses a well >> defined method to compute the fingerprint. You can't compare the two >> protocols or define a unique fingerprint method. > > I think "how you take the fingerprint of an X509 key block" should be > out of scope for the OpenPGP WG. I think that you can (and should) > write a separate document that does that. As long as the identifier is reserved in the OpenPGP registry so there is no risk of ambiguity, that is OK. I think that where any draft is discussed is really an issue for the AD and the WG chairs. It might well be simpler for me if it is outside the WG. >>> If people really can't stomach ASN.1 code then we could do some other >>> key format. But the problem then becomes having to specify how to >> >> We want to do an rfc4880bis and not an entire new protocol. Thus any >> ASN.1 encoding is not an option. > > Ditto. If the goal here is to have the same key material result in the > same fingerprint regardless of whether it's encoded in OpenPGP or X.509, > I think the answer is going to be "X.509 people are going to need to > convert their key material to OpenPGP packet format and feed into the > hash algorithm". I see no other way, and frankly any other way is > madness (for the OpenPGP group). > > I'm sure Phill wont like that answer, but I think it's the right answer > for this (potential) working group. Phill cares more about the timing of a decision rather than what the decision is. From nobody Fri Apr 10 09:46: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 5E6051AD34C for ; Fri, 10 Apr 2015 09:46: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 9It3fMoTLZpu for ; Fri, 10 Apr 2015 09:46: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 6AF061A86F6 for ; Fri, 10 Apr 2015 09:46:17 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 3E4366D78D; Fri, 10 Apr 2015 12:46:16 -0400 (EDT) Message-ID: <5527FE57.5020305@iang.org> Date: Fri, 10 Apr 2015 17:46:15 +0100 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: <1427138741.10191.48.camel@scientia.net> <1428518188.5137.61.camel@scientia.net> In-Reply-To: <1428518188.5137.61.camel@scientia.net> 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: Fri, 10 Apr 2015 16:46:19 -0000 On 8/04/2015 19:36 pm, Christoph Anton Mitterer wrote: > On Wed, 2015-04-08 at 15:32 +0000, David Leon Gil wrote: >> Brief update on plans for deprecation: The tracking issue is at >> https://github.com/yahoo/end-to-end/issues/31 >> >> Please feel free to open another issue if you have specific >> objections. I will either be convinced by your arguments, and change >> the plan, or explain why I don't. > > Look, as I've pointed out previously, I personally think that crypto, > done as a web app is inherently untrustworthy. Which is out of scope for this list, right? > If one says "hey, let's discuss whether we should deprecate twofish in > OpenPGP" that's totally fine,... but informing the standardisation body > "hey we drop now support for x, y and z" with an implicit "and since we > represent n users, you better follow our decision" is not appropriate. I saw no such implication. I personally appreciate it when vendors actually do tell us what they are doing when that effects the way many users are going to be using the product. In our fishbowl, we sometimes lack the context of what happens out in the field, so news of that nature - hopefully concise and clear - is welcome. To me at least. iang From nobody Fri Apr 10 10:06: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 911D11B29C3 for ; Fri, 10 Apr 2015 10:06:08 -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 uA0VSE68dujX for ; Fri, 10 Apr 2015 10:06: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 C4BFC1B29C7 for ; Fri, 10 Apr 2015 10:05:59 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 947456D78D; Fri, 10 Apr 2015 13:05:58 -0400 (EDT) Message-ID: <552802F5.5030501@iang.org> Date: Fri, 10 Apr 2015 18:05:57 +0100 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: <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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Fri, 10 Apr 2015 17:06:08 -0000 On 2/04/2015 17:09 pm, Phillip Hallam-Baker wrote: > On Thu, Apr 2, 2015 at 10:29 AM, Derek Atkins wrote: >> From a usability perspective this is the model I would want to see. I >> honestly don't care if the actual messages are CMS or 4880 (although I >> have a large disdain for all things ASN1). > > I hate ASN1 just as much as the next guy. > > I do not care what format the messages are in. All I care about is who > we can reach with them. > > There are a billion+ clients in existence with S/MIME built in. Every > email client has to implement TLS these days to secure POP/IMAP/SUBMIT > communications and CMS comes with practically every TLS library. > > If there is a message formatting option that lets us reach those > billion+ clients with an OpenPGP message without compromising the > trust model or anything else then lets take it. Personally I think this is the wrong blockage. Yes, I recognise that the existence of that code inside those 1bn+ clients is potentially valuable. But in practice it is not the key blockage, not even close to being a relevant issue. IMHO the key blockage is politics / commercial control within the vendors over the "trust model". In order to get those clients to open up, Mozo and Microsoft need to be incentivised to go in a different direction. In practice this is a much bigger barrier. As a historical observation, there is always a steady queue of hopefuls asking Mozilla to implement TOFU & pinning trust models within x.509 products for which *all the code is present* but they won't go there. These hopefuls have all gone off depressed and angry, mostly because they never understood that Mozilla is a commercial project at that level, and has bought into the CA model 100%. It is for this reason I'm actually very happy that Yahoo and Google are doing e2e pgp in their web mail stuff. The fact that we all know the 'hushmail' attack is .. unimportant in the scheme of things. What's important is deployment, not perfection in security models. (all very much IMO, YMMV) iang From nobody Fri Apr 10 10:25: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 AFF121A885B for ; Fri, 10 Apr 2015 10:25:03 -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 qJdc60n0RLlr for ; Fri, 10 Apr 2015 10:25: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 5DACA1A8833 for ; Fri, 10 Apr 2015 10:25:02 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id CBF576D78E; Fri, 10 Apr 2015 13:25:00 -0400 (EDT) Message-ID: <5528076B.4040302@iang.org> Date: Fri, 10 Apr 2015 18:24:59 +0100 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: <1427243451.10191.375.camel@scientia.net> <5512F137.80702@iang.org> <1427343948.23692.14.camel@scientia.net> <87vbhlt8tg.fsf@alice.fifthhorseman.net> <87mw2i28nr.fsf@vigenere.g10code.de> <1428498695.5137.17.camel@scientia.net> <1428500028.5137.26.camel@scientia.net> In-Reply-To: <1428500028.5137.26.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] OpenPGP private certification 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, 10 Apr 2015 17:25:03 -0000 On 8/04/2015 14:33 pm, Christoph Anton Mitterer wrote: > On Wed, 2015-04-08 at 09:23 -0400, Phillip Hallam-Baker wrote: >>> Crypto is not an iPhone. >> Mine is. > Believing that you're secure with a proprietary driven system, from a > company which is known to have worked with mass surveillance > organisation (and if it's just because they were forced so by law), is > naive - at best. No, it's security modelling. It all depends on what the business model is, which defines the threats that one has to deal with. There are plenty of people out there that don't care about the mass surveillance and there are plenty of people in here who do care about it. The reason that people out there don't care about mass surveillance is because they (a) don't see the harm or (b) have bigger harms to worry about. Sometimes valid reasons, sometimes not. We have to remember that the old CIA was something that was taught to us back in the 1990s out of military models. E.g., it made sense to consider the MITM as a big commsec threat when our only experience was MITMs in aggressive military actions -- armies against armies. But the Internet was different, we had different threat actors, different values under protection, and different incentives. There are probably more people out there that don't want authentication than do, or more precisely they want nymity. Canonically, recall all the people (eg) Manning who were caught over the net, and had recorded chat sessions used as evidence against. Having unattributable, untraceable content is actually a goal for many. And things like twitter show how confidentiality isn't really the thing, but they still put everything over the HTTPS so that at least the passive surveillance is turned into active surveillance. etc etc. Your enemy may be the NSA. But for most people most of the time, it's others: aggressive ex-spouses, parents who spy, business partners stealing money, teenagers getting into trouble with photos, etc etc. iang ps; And to echo Phil, my crypto is iPhone too - end-to-end secure payments systems. 'cept, Java only runs on Android ;) From nobody Fri Apr 10 12:57: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 4B0C31A86FD for ; Fri, 10 Apr 2015 12:57:25 -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 IKA2OGGO2P0y for ; Fri, 10 Apr 2015 12:57:23 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4441A86EC for ; Fri, 10 Apr 2015 12:57:23 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-6d-55282b227889 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id F0.FA.03355.22B28255; Fri, 10 Apr 2015 15:57:22 -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 t3AJvLG6016129; Fri, 10 Apr 2015 15:57:22 -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 t3AJvJ7e010862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Apr 2015 15:57:21 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3AJvJii017562; Fri, 10 Apr 2015 15:57:19 -0400 (EDT) Date: Fri, 10 Apr 2015 15:57:19 -0400 (EDT) From: Benjamin Kaduk To: Werner Koch In-Reply-To: <877ftkqhr4.fsf@vigenere.g10code.de> Message-ID: References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> 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+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrKukrRFqMOWGjEXDv4fsFp9X7mVx YPLY+eQBq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKONfWxFzxirlj+/g57A+Nnpi5GTg4JAROJ WW9WMUPYYhIX7q1n62Lk4hASWMwk8bXpHiOEs5FRYu327UwQziEmiZeTnzBDOA2MErM6ToD1 swhoSzy70ckIYrMJqEjMfLMRaBYHh4iAnMTfwxEgYWYBTYkX56aClQsLaEls+X0BzOYUMJS4 ceAeC4jNK+AosWT7S7C4kICvxOTPs9lAbFEBHYnV+6dA1QhKnJz5hAVippbE8unbWCYwCs5C kpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK6SZGcKhK8u1g/HpQ6RCj AAejEg/vgzT1UCHWxLLiytxDjJIcTEqivBacGqFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhf qwPleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeHM0gRoFi1LTUyvS MnNKENJMHJwgw3mAhp8HqeEtLkjMLc5Mh8ifYtTluDPl/yImIZa8/LxUKXHeaJAiAZCijNI8 uDmwFPOKURzoLWHeCyBVPMD0BDfpFdASJqAlzw3VQJaUJCKkpBoYhd9ttU4q8Qmdw58dvpfb fansO9bVFSkLy/Mf3frQ5Z9hH/OgTvHsE5/jbg1xeQlWL76z1RmrJmgfknQX8ePZ+c1cc42F Outlj64FzZNftAdfuGvWPHvfN5WSdL3Lfd+nSXnsOWun8CH3cRnvkcKqxamPo79FvBWze3Fe Zs/+o41nzu8/ryimxFKckWioxVxUnAgA+yoqOQwDAAA= Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Update S2K 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, 10 Apr 2015 19:57:25 -0000 On Fri, 10 Apr 2015, Werner Koch wrote: > b) Symmetric-Key Encrypted Session Key Packets. I don't know how often > this is used. I assume that in most use cases the passphrase is > taken from external key management system and thus we can expect > that it has full entropy and the KDF does not add to the security. I have used gpg -c to password-encrypt data with a human-generated (i.e., not-great) password fairly recently, as a single anecdote. -Ben From nobody Fri Apr 10 13: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 24ADD1A88C7 for ; Fri, 10 Apr 2015 13:34:34 -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 Z9ujbMdm4Rwe for ; Fri, 10 Apr 2015 13:34:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A44C11A88C4 for ; Fri, 10 Apr 2015 13:34:32 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 944E9F984; Fri, 10 Apr 2015 16:34:28 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1695F2023A; Fri, 10 Apr 2015 15:34:17 -0500 (CDT) From: Daniel Kahn Gillmor To: Stephen Farrell , "openpgp\@ietf.org" In-Reply-To: <5527B5F9.3080502@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> <5527B5F9.3080502@cs.tcd.ie> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 10 Apr 2015 16:34:13 -0400 Message-ID: <87mw2fzpru.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] it's option 2 (was: Re: ways forward wrt IETF wg - please try answer by Apr 8th) 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, 10 Apr 2015 20:34:34 -0000 --=-=-= Content-Type: text/plain On Fri 2015-04-10 07:37:29 -0400, Stephen Farrell wrote: > Please send a mail to the list if you're willing and able to do > editing or review of drafts during this calendar year. (Say which > or both.) If you'd also be implementing in roughly that timeframe > feel free to say that too. Doing that in the next week would be > a fine thing. (So deadline: April 17th.) I'm willing and able to do editing and review of drafts related to RFC 4880bis during this calendar year. I'm not directly responsible for any particular OpenPGP implementation upstream, but i would be willing to supply patches to free software (to the extent of my ability and time) that implement sensible decisions within the next calendar year as well, and would be happy to try to help good free software implementations get wider distribution and testing via my involvement in Debian. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVKDPGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcRFoQANs1VxIdAoyieLGQvqbCbstK /GrqLFRoxOICxMdyOzvm1UB4key9bPaqYOCsINH723fmXqHNnsP3n6G+efls3Wvd elSoBEIlFYa3qbUzpbVEtoaHpl9498iQMoFuv+avZxevcIN7lqTQJjKK/SD60lsn WNDCd3QHB3rVOTI9RXMRReZjVZ3Vppaf7t+PY30b0IQBEEpmq3OznPJYFveUpq5R ZR7GhxOVoAH2SxZWn6diR58g62HBOdX+/H+/Xb69IvoZvStBfVWIBeZyJVJgaxqK S6EGPiLNDIF7Z0VSV8D3iz3IRLg7Crcf9Srju5RsS6+NHGXSx2zl3uiO4zFhncp+ +hLxc16cjz3yhLruETklhnQbfiRy3FGdv6oF0TxfO9Vy2tEl+NCy8D2Mo5AXSIWr mulBcLR5qYCCe8ZNlC1xCdF/CGhuIatAjIvW2Y9Uez3bfayumnRjhwHLK+eJg8LB h96jhejEkA3Oe23ksIuNrV/xa84omEkV1Zr3Y3O+Wtv+C9iivzUfqV5DhTgA9XO4 y3/OX334IzsRChGlYzCChyokbjLX0vj7hAnC7F9xlVQR4/gujP5VE1HQt/3EqBSC ko15x919co0BTj0tlV9j9yHCSAqH0vnltSzFIn32WY01TksLCn18PG8bjCXJbgPa oD/NnSBRvpQ9FlBAVpX9 =/1w0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 10 14:37: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 86DDE1A8AA9 for ; Fri, 10 Apr 2015 14:37:24 -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 WB8USW01iU-Q for ; Fri, 10 Apr 2015 14:37:22 -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 278A21A8A89 for ; Fri, 10 Apr 2015 14:37:22 -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 9FF755FB49 for ; Fri, 10 Apr 2015 21:37:20 +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 YwmamIsu0BIw for ; Fri, 10 Apr 2015 21:37:18 +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, 10 Apr 2015 21:37:18 +0000 (UTC) Message-ID: <1428701837.6212.145.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Fri, 10 Apr 2015 23:37:17 +0200 In-Reply-To: <87y4m0ozlt.fsf@vigenere.g10code.de> References: <87y4m0ozlt.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-IYjSwb8PjFP0nWGrJuIt" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 10 Apr 2015 21:37:24 -0000 --=-IYjSwb8PjFP0nWGrJuIt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-04-10 at 15:57 +0200, Werner Koch wrote:=20 > > There is no need to have an algorithm field, a version field is > > sufficient because we should only be using one algorithm at a given > Right. Why? Isn't that exactly what the past has taught us? That using one fixed fingerprint algo leads into all kinds of troubles? And not just from the engineering side (i.e. that applications simply take it for granted that the data will be SHA1, e.g. when parsing output of programs). Looking at other areas (e.g. SSH) tendency seems to be rather to support multiple fingerprint algos, and people can chose what they want. And from the crypto side, we also see how bad it was/is, to have fixed algos,... first with MD5 now with SHA1. It's simply naive to believe that current or future algos won't meet the same fate ultimately. > It is often useful to have a keyid to quickly (but insecure) refer to a > key. And it caused also issues, when people *did* assume they'd be secure. > I think that should be discussed in the context of the new default hash > algorithm. SHA2 and Keccak? Cheers. --=-IYjSwb8PjFP0nWGrJuIt 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxMDIxMzcx N1owTwYJKoZIhvcNAQkEMUIEQK8jyGjp2rQZ7ZZdBQOoN+46RnSgtWcSaUlH5PDy6cwCMr4HU6h3 nJXHj10wzQzXZHNWyzSx9uOcEyXvZa8o2IkwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDbo/yufB6U4sSd1brR3ziGjn+Cw2qO speUysvu4UXDqD69Y31VUvLBBG9+xf483WrR6ph5GYYMHVDDv0wAId/1RLnZG5h1nDREBMTm6IA9 BhS5/MnDs1ag6tHMWaQZhnNvA8uhywIcDwNYpjRYA9qrYZ/J3Cyg+6PhGDrobc5IWs869OD1r2Ru 3PdkcjMRA/Y03p82jag/Nkn13PgYZKrsyoV8x2VrV/qgDIzlT2emmuRTFzd+C6qIpfYdANegPKKW Db1MuBkdMzA5/QgyvHFFCloGYdZJMnOnL4J3Q5GKKJPY2x3cyF46s4TKYrsNvL6GPtc8iGUJ5nAn MxL04LSqAAAAAAAA --=-IYjSwb8PjFP0nWGrJuIt-- From nobody Fri Apr 10 14:51: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 D96251A9023 for ; Fri, 10 Apr 2015 14: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 UjqqnSTi40mC for ; Fri, 10 Apr 2015 14:51:53 -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 071401A8F40 for ; Fri, 10 Apr 2015 14:51: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 mailgw02.dd24.net (Postfix) with ESMTP id D9C665FB55 for ; Fri, 10 Apr 2015 21:51:51 +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 Hy_QLLGIqJdj for ; Fri, 10 Apr 2015 21:51: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 ; Fri, 10 Apr 2015 21:51:50 +0000 (UTC) Message-ID: <1428702709.6212.156.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Fri, 10 Apr 2015 23:51:49 +0200 In-Reply-To: <5527B621.3040104@cs.tcd.ie> References: <5527B621.3040104@cs.tcd.ie> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-9qgMKiPJO8Qwh62j7owh" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 10 Apr 2015 21:51:56 -0000 --=-9qgMKiPJO8Qwh62j7owh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-04-10 at 12:38 +0100, Stephen Farrell wrote:=20 > a) update the fingerprint format (avoid inclusion of creation date I wouldn't do that,... actually I think creating/expiration times (and some other base properties) of a key should be immutable. > f) standardize the two new curves coming out of the CFRG: 25519 and > curve448 ("goldilocks") for both signatures and encryption (Werner > has already started this process for 25519 signatures) I haven't followed CFRG the last weeks,... are the plans for anything at/beyond the 512 level dead? > i) declare a literal data packet type "m" that means "MIME content" so > that we can punt on the rest of the message > structure/format/encoding/type craziness to MIME. For what exactly do we need this? Maybe I just don't understand what you plan, but we should try to be as independent from other layers as possible. > l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD > mechanism should be the baseline. Keccack? Everything else seems good to me. Cheers, Chris. --=-9qgMKiPJO8Qwh62j7owh 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxMDIxNTE0 OVowTwYJKoZIhvcNAQkEMUIEQLx+SDC4L1amJWw4JhXfg4/aciPLJqT9XKWNmm5xO1k/jexvX240 V+qgd4bF8hDSCFuBwCtP0k7xStImaz4vZbAwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB0q9h+lDt4dfRRcOM9TcMarRX97uqa dHUyeFuYrw/2sgNTSdGSonC+bTC3K0UMSOsBZG5Hj5PaqDhBS4giwbZlorGaHoVKNTSBn8T414sq EKLJEiiK1/HTE0qkH7HCiE78aXfCDyyVsisryiKqk6nmZJ3euZmPnFgP1HGqa+HxNhaQ407GKg+s BLcaFnQXDD7ZCR1kSiBP2YkvoB6aQBeMgLveV9I5Bvo098rwTRbtARvOZ4awtObSh9qJZ8hDlm8Z vUXnBFJwNxK31jOvqs6g/5rjiGFn3Ej2v3VphpfEcMN+zteYif/W0yi7Yl1TgeyHHPAcACqR44/7 jJkmf8TcAAAAAAAA --=-9qgMKiPJO8Qwh62j7owh-- From nobody Sat Apr 11 03:51: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 0E1701A8F42 for ; Sat, 11 Apr 2015 03:51:37 -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 GdsMSjUY37IV for ; Sat, 11 Apr 2015 03:51:35 -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 317D31A8772 for ; Sat, 11 Apr 2015 03:51:35 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Ygt0f-0005iD-Ix for ; Sat, 11 Apr 2015 12:51:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Ygsw5-0001vy-0K; Sat, 11 Apr 2015 12:46:49 +0200 From: Werner Koch To: Christoph Anton Mitterer References: <87y4m0ozlt.fsf@vigenere.g10code.de> <1428701837.6212.145.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 Mail-Followup-To: Christoph Anton Mitterer , openpgp@ietf.org Date: Sat, 11 Apr 2015 12:46:48 +0200 In-Reply-To: <1428701837.6212.145.camel@scientia.net> (Christoph Anton Mitterer's message of "Fri, 10 Apr 2015 23:37:17 +0200") Message-ID: <87vbh3ndrb.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] Fingerprints 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, 11 Apr 2015 10:51:37 -0000 On Fri, 10 Apr 2015 23:37, calestyo@scientia.net said: > Why? Isn't that exactly what the past has taught us? That using one > fixed fingerprint algo leads into all kinds of troubles? Trouble with a fingerprint? I am interested to hear about such a case. (ssh's default use of MD5 does not count). >> key. > And it caused also issues, when people *did* assume they'd be secure. Yeah, similar to the common behaviour of only comparing the first and last 2 bytes of SHA-1 fingerprints and checksums. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat Apr 11 07:30: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 EDF1E1B2B97 for ; Sat, 11 Apr 2015 07:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[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 wL8yTWnwXzVm for ; Sat, 11 Apr 2015 07:30:28 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 5A79C1B2B96 for ; Sat, 11 Apr 2015 07:30:28 -0700 (PDT) Received: by wgso17 with SMTP id o17so42051680wgs.1 for ; Sat, 11 Apr 2015 07:30:26 -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=3hFAkh6cwmyivAKb2G+bkhoqMaKqtotHBEveVGKUH8I=; b=hCYeXY4D5d1DZbJLw9sIb55bNruQpGSEhsIlR0YUTYGzwBNcmShdyo+OEFDQ0DoQGd gPIXQCeJ+aBoOQ8d6p6fRLb7wnFB/Oxg4cKxXo75YLZFCnwEP1jmxqRP6s2LVESUtLt3 58Zn2u7RwDCqGr9b+nnj+GUVKkPRP07fiF+2U= 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=3hFAkh6cwmyivAKb2G+bkhoqMaKqtotHBEveVGKUH8I=; b=k97n57KL3brYsNvHLFUxiZ3daVSqho1PZ5AWEIc4dnQ53Ul9AZgPjnaZAb6dYeV1PZ cJZ9Ix6yP7I9kt3YHCKOkzFm4Sx1n3KPM+JcpCa6NpduDFXGCvbAIcISUEHNNFAYFVUu oR/Gqr3YdZjGXos9qJ0VmmCe5vIJcFII4D2PeZn6ADLcAYlhE/wALfjLFlLMXBQVUe6X T9XCJv51Imf0fKq26lD6Vxq67PG+5CCwi7/SfxrEE0AgblkZuKT/RZa10Bwb7uwVeUsC ibtwDuLlOAvipsNU6Q9YWF6BFaH4a6FvFKWS75MbfDVrDQpYuo8fWQjbdr3LgGiOFtbW d/NQ== X-Gm-Message-State: ALoCoQlS/yfMpWEJNQRb/Ii/5Cuoqtlqe5lwYIGqkXjzy0so4kwAAeSNNtXc5rmWZCuUgrYYPIN2 X-Received: by 10.194.109.97 with SMTP id hr1mr11570531wjb.10.1428762626653; Sat, 11 Apr 2015 07:30:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.137 with HTTP; Sat, 11 Apr 2015 07:30:05 -0700 (PDT) In-Reply-To: <1428518188.5137.61.camel@scientia.net> References: <1427138741.10191.48.camel@scientia.net> <1428518188.5137.61.camel@scientia.net> From: Tom Ritter Date: Sat, 11 Apr 2015 09:30:05 -0500 Message-ID: To: Christoph Anton Mitterer Content-Type: text/plain; charset=ISO-8859-1 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, 11 Apr 2015 14:30:30 -0000 On 8 April 2015 at 13:36, Christoph Anton Mitterer wrote: > On Wed, 2015-04-08 at 15:32 +0000, David Leon Gil wrote: >> Brief update on plans for deprecation: The tracking issue is at >> https://github.com/yahoo/end-to-end/issues/31 >> >> Please feel free to open another issue if you have specific >> objections. I will either be convinced by your arguments, and change >> the plan, or explain why I don't. > > Look, as I've pointed out previously, I personally think that crypto, > done as a web app is inherently untrustworthy. > > Maybe I just got something wrong, but AFAIU the idea of "e2e" projects > like your's is to add e2e crypto into your webapps, e.g. via javascript. > Thus the software doing crypto is each time downloaded again from the > server by the client, right? No. Most (and by most I mean the more high-profile ones that try to do it as correct as possible[0]) have moved virtually all operations into a browser extension. It is downloaded and installed once, updated based on how the browser updates extensions, and (for better or worse) mediates through a third party (the browser's add store) to prevent individual targeting of users by the plugin author. > So ultimately control is again fully at the vendor (at any time he could > send other code and no one would notice), and fully dependent on a > working https (which is as we should all know by now inherently insecure > due to the issues of the CA system). No, as above, and regarding the CA system - Which itself is addressed by some projects and services using HPKP. On 10 April 2015 at 11:46, ianG wrote: >> Look, as I've pointed out previously, I personally think that crypto, >> done as a web app is inherently untrustworthy. > > Which is out of scope for this list, right? Agreed. But I feel compelled to correct factual inaccuracies. > I saw no such implication. I personally appreciate it when vendors actually > do tell us what they are doing when that effects the way many users are > going to be using the product. In our fishbowl, we sometimes lack the > context of what happens out in the field, so news of that nature - hopefully > concise and clear - is welcome. To me at least. Double agreed. I wouldn't want a working group to be an -announce list of product releases, but since I literally found a completely new OpenPGP plugin yesterday (gpg4o), I'm happy to read concise reports on how different plugins/tools operate at the standard layer, and that nebulous 'above-standard' layer like PGP/MIME quirks. One day one of them may help me figure out how my Outlook server is broken wrt to mac's gpgtools and some-but-not-all other PGP clients. -tom [0] Yahoo and Google's E2E, CryptoCat, Mailvelope From nobody Sat Apr 11 08: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 465611B2BE7 for ; Sat, 11 Apr 2015 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_95=3, RCVD_IN_DNSWL_LOW=-0.7] 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 oEf84tPN1Izh for ; Sat, 11 Apr 2015 08:42:19 -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 8007A1B2BE6 for ; Sat, 11 Apr 2015 08:42: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 mailgw01.dd24.net (Postfix) with ESMTP id AA8C25FB41 for ; Sat, 11 Apr 2015 15:42:17 +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 io8f9tYvAzZd for ; Sat, 11 Apr 2015 15:42:15 +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 ; Sat, 11 Apr 2015 15:42:15 +0000 (UTC) Message-ID: <1428766935.4956.0.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Sat, 11 Apr 2015 17:42:15 +0200 In-Reply-To: <87vbh3ndrb.fsf@vigenere.g10code.de> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <1428701837.6212.145.camel@scientia.net> <87vbh3ndrb.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-XUH6eojrOFMF/EhGBKAO" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 11 Apr 2015 15:42:21 -0000 --=-XUH6eojrOFMF/EhGBKAO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2015-04-11 at 12:46 +0200, Werner Koch wrote:=20 > > Why? Isn't that exactly what the past has taught us? That using one > > fixed fingerprint algo leads into all kinds of troubles? > Trouble with a fingerprint? I am interested to hear about such a case. > (ssh's default use of MD5 does not count). Isn't it one main reasons for all these efforts now to get rid of SHA1 on OpenPGP? Cheers, Chris. --=-XUH6eojrOFMF/EhGBKAO 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxMTE1NDIx NVowTwYJKoZIhvcNAQkEMUIEQMIkHA02DbHVg4+BHDEda0e4bmTriM+ksFbOLdKSrKi2XOvjq0rc 1RZGbG/Q0TlCtjvMEqbouwTilvFUS2vOVZ4wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB62qFRqRUaOoTiEyYZm+1FXCfH/+/G PLu3m/K+Wp/PjMgjxdHBDaILytTVRpyGb0jfB0+XMR2QTPLeMNMXe7UWeYKSVDs8AuspHoytuLcC +3lEAqdJr21Kv/BTmSA5/cOkCVD9a+/Ws35e/GkqDsQXIA/c9KhebybaK2A6iUygyTRjXdOJ8Po+ CZbmyZf/9fL5zKamLYMx6zWhCHWE2X2s8YxPok+YzCcVH7BRP2ImXzqoiMWvnfDQMEBcneL+6ORC ohM3EV3VGVVzFm2r0ySqjx/ibSfzjXMc3u5Hn7/SdgOOrChf/kA4TJZ7vwIunwT6uLTTv0CB+Q8W 1LXJ3ahcAAAAAAAA --=-XUH6eojrOFMF/EhGBKAO-- From nobody Sat Apr 11 09:14: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 3B6861A1A46 for ; Sat, 11 Apr 2015 09:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.5 X-Spam-Level: *** X-Spam-Status: No, score=3.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5] 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 b9IINXKJAF0B for ; Sat, 11 Apr 2015 09:14:51 -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 C70411A1A3B for ; Sat, 11 Apr 2015 09:14:51 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 6D01A6D7AA; Sat, 11 Apr 2015 12:14:50 -0400 (EDT) Message-ID: <55294878.7000900@iang.org> Date: Sat, 11 Apr 2015 17:14:48 +0100 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: <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> <87ego3g3v8.fsf@alice.fifthhorseman.net> <87wq1vemp5.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 11 Apr 2015 16:14:53 -0000 On 1/04/2015 19:56 pm, Phillip Hallam-Baker wrote: > OK, this is what I am planning to do for PrismProof email. > > After trying a number of approaches I have concluded that the best > approach today is to insist that each keypair have exactly one > purpose. Concur. > So Alice will always have a personal root key and an intermediate key > signing key and the fingerprint of this PKI is the hash of the keyinfo > block of the personal root. to do key endorsement she will also need a > key endorsement key on each device she wants to use for endorsements. > > Alice-Personal-Root -> Key Signing Key -> Key Endorsement Key[s] OK. (at least, it mirrors what I do.) > [One reason for the no sharing rule for KEKs is that it makes dealing > with a stolen phone etc. much easier] By that you mean, one KEK per device, not the common proxy SSL device rule of one cert shared across all. OK, agreed if so. However I'm not sure you'll hit the mark on the stolen phone. Much of the world only has a phone, so it also has to deal with the full hierarchy. A more comprehensive solution is needed. In my work, I duplicate the phone's (encrypted) db onto server (cloud) and then try to recover that and get her up and going when Alice loses her phone. But I freely admit it is flawed as it is weakening the entire security to the level of her password/pin, in some shared or non-shared form, and relying on a bunch of assumptions that for anyone but a security geek look exceedingly mushy. > Each cert in this chain would be enrolled in an append-only > cryptographic log which provides proof that it existed at a particular > point in time. But none of these certs requires an email address. > > For various reasons, we probably want these certs to be enrolled in a > transparent log that publishes both the block chain and the input > data. It is not necessary for a log to publish the input values to fix > them in time however. You're saying that the KEKs are published in their entirety, but they do not include any sensitive information. Just a signing hash that points back up to the cert hierarchy. So what is your motive for timestamping / proof of existence here - to stop people creating sybils? > When Alice endorses Bob, this is not an operation currently supported > by PKIX and so the 'no new ASN.1' rule applies. The endorsement is > probably some sort of JSON structure: > > {"name":"Bob", > "email":"bob@example.com", > fingerprint":"phb:qweflkqwhjdflkjhasdlkjhasdvlkjhlksajvh", > "date":"2015-04-01:01:23Z", > "blind":"askfasjkldhkjashdvkjhsadkjh"} > <...Signature data...> > > This is of course simply another form of certificate but it is a very > different type of cert so its best to use a different term. Yes. But it in itself is also quite defined. So, in the above, Alice endorses Bob lacks any sense of "for what?" Do we need a different endorsement for each "what" or are we looking for a general endorsement and a "what policy" or a "what statement" ? > Alice is > not going to commit to managing the endorsement lifecycle. Agreed. But she is going to be pissed when it breaks on her. > The property we want to get from enrolling the endorsement in a log is > to fix it in time. So we enroll the hash in the log rather than the > endorsement itself. So, a log can be used for: fixing in time, publishing, proof of existence without time, proof of revocation, ... possibly other things. Do you have a sense that we know enough about the endorsement to be able to tie down those benefits? Reason I ask is this: in my work, the endorsements are shared amongst a group, but not further. They are replaceable. And they are analisable. So they aren't really private but they aren't published. (They are also wrapped up in a legal context.) My question then comes down to finding the low layer endorsement brick that allows me to build my castle of trust. > The value "blind" is a random value that leaks Alice's RNG to the > NSA^h^h^h^h^h^h^h^h prevents dictionary attacks. :) iang From nobody Sat Apr 11 11:51: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 E10A91ACE71 for ; Sat, 11 Apr 2015 11:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ksa2FJbCWkA3 for ; Sat, 11 Apr 2015 11:51:08 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010: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 248711ACE6F for ; Sat, 11 Apr 2015 11:51:08 -0700 (PDT) Received: by lagv1 with SMTP id v1so33028166lag.3 for ; Sat, 11 Apr 2015 11:51:06 -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=07s1G+D2yFCKUrOwZXd3LN9/lPXAzUvZhhHAFnJEQxY=; b=qwWnakUo12Ev51EWAGTicvGF/BM1aIQC65NULIhY4r/Lm1ORBb+4rUyva6vERDTV7v C1tAXVw90FfbLjwkzvWmjJ2gIppBsC/U5Ahy8m1B5jj+AlrnKYhxBIvKl/9YwmyZabbJ W3G6kRYIchfgnD1APNOvcotsjZWBxU3HlfkAv9EPL3gH456IwdSj2vnWitGR1EqioFzl L+HjBs36kJPSIO8JXqPW9FSaMi5Hv7oFlrKczDIPoIa/vvKbTs93GULnthdxy5RA4LeX GpPhjr5+4iyBn0sri2pY4UCDhNfNCjCGHwJlwruW4Iqb4MbQQZf2ZQMkxGYyBmOaD0fW WEgw== MIME-Version: 1.0 X-Received: by 10.112.161.66 with SMTP id xq2mr6461261lbb.103.1428778266660; Sat, 11 Apr 2015 11:51:06 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Sat, 11 Apr 2015 11:51:06 -0700 (PDT) In-Reply-To: <55294878.7000900@iang.org> References: <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> <87ego3g3v8.fsf@alice.fifthhorseman.net> <87wq1vemp5.fsf@alice.fifthhorseman.net> <55294878.7000900@iang.org> Date: Sat, 11 Apr 2015 14:51:06 -0400 X-Google-Sender-Auth: RmX0ESdwgx9sXvWgjKTgk5Rg_CQ Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] public logging of e-mail certificates [was: Re: OpenPGP private certification] 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, 11 Apr 2015 18:51:10 -0000 On Sat, Apr 11, 2015 at 12:14 PM, ianG wrote: > On 1/04/2015 19:56 pm, Phillip Hallam-Baker wrote: >> [One reason for the no sharing rule for KEKs is that it makes dealing >> with a stolen phone etc. much easier] > > > By that you mean, one KEK per device, not the common proxy SSL device rule > of one cert shared across all. OK, agreed if so. > > However I'm not sure you'll hit the mark on the stolen phone. Much of the > world only has a phone, so it also has to deal with the full hierarchy. A > more comprehensive solution is needed. In my work, I duplicate the phone's > (encrypted) db onto server (cloud) and then try to recover that and get her > up and going when Alice loses her phone. But I freely admit it is flawed as > it is weakening the entire security to the level of her password/pin, in > some shared or non-shared form, and relying on a bunch of assumptions that > for anyone but a security geek look exceedingly mushy. I am doing the same. While I agree that this might look like a lot of unnecessary keys for people with only one device, it is much simpler to give everyone the full hierarchy than deal with 'luxury' and 'economy' versions. Devices break. Devices have a limited life. Thinking poor people have fewer devices than rich people is probably mistaken. > You're saying that the KEKs are published in their entirety, but they do not > include any sensitive information. Just a signing hash that points back up > to the cert hierarchy. > > So what is your motive for timestamping / proof of existence here - to stop > people creating sybils? If someone presents you with a key endorsement for a Barry Obama email at Harvard.edu that could have been created five minutes ago it is worthless. If you have the same endorsement and can prove that it was published twenty years ago when he was a student it is worth a great deal more. Enrolling endorsements in notary logs has a dramatic impact on the trust model. The cost of forging that endorsement goes from zero to essentially infinity at the time it is created. That is real power. > Yes. But it in itself is also quite defined. So, in the above, Alice > endorses Bob lacks any sense of "for what?" Do we need a different > endorsement for each "what" or are we looking for a general endorsement and > a "what policy" or a "what statement" ? Yes, understanding that is useful. And so is binding to process. An endorsement created by an iphone app and enrolled is a particular quantity, etc. >> The property we want to get from enrolling the endorsement in a log is >> to fix it in time. So we enroll the hash in the log rather than the >> endorsement itself. > > So, a log can be used for: fixing in time, publishing, proof of existence > without time, proof of revocation, ... possibly other things. Do you have a > sense that we know enough about the endorsement to be able to tie down those > benefits? The internet draft I wrote describes some of the benefits in terms of a timed work factor model. > Reason I ask is this: in my work, the endorsements are shared amongst a > group, but not further. They are replaceable. And they are analisable. So > they aren't really private but they aren't published. (They are also > wrapped up in a legal context.) > > My question then comes down to finding the low layer endorsement brick that > allows me to build my castle of trust. Trying to work with casual endorsements alone is a mistake. There is no grounding at any point. The value of endorsements quickly dwindles to zero through generation loss. If there are a just a few endorsements that are tied to a specific process (i.e. a CA process) then the work factor becomes stable and objective. From ndurner@googlemail.com Sat Apr 11 12:17: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 C55461A90F2 for ; Sat, 11 Apr 2015 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 WIlcJii-30FT for ; Sat, 11 Apr 2015 12:17:25 -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 1F6231A9044 for ; Sat, 11 Apr 2015 12:17:25 -0700 (PDT) Received: by wiun10 with SMTP id n10so29216609wiu.1 for ; Sat, 11 Apr 2015 12:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Xvqz5f5gUoA1Gy/9eTdWxchy2SfpstWn9qb+RmiC6xk=; b=tyEaWMe5NY/ZktDrWSg2/eLpHOHCdNtvWP24yPbDAYaeY5zCxf4HLBuEV6JUJQnPwt GZ5OFPqYSUJ2Fx2tOIlo/tU8lS6MMFUxYbJKWcagh0HAR8HL2P8KHzePRCJYERdqq09l iqpXvEtWE0CF87Chgn4Lx4vnyjML3XgSd3Z8KMO564GiOWtglhxFxB4l0Y0vXQ1aHRqk RDp6ikP87hz0Q3fhAmMhC0R0cc82ERd3w7hcwRk13UeU32MG67q1//ofgigQcMHh2Lzw msNMCqotvA64hJzubBp+nfBvv2wPwsospp1yoa48qJLOOTQ9IrGGR5MpsrMiHrFPlqKf Bu3w== X-Received: by 10.180.198.110 with SMTP id jb14mr7812417wic.57.1428779843809; Sat, 11 Apr 2015 12:17:23 -0700 (PDT) Received: from [192.168.188.20] (x55b405be.dyn.telefonica.de. [85.180.5.190]) by mx.google.com with ESMTPSA id kc4sm3995995wjc.2.2015.04.11.12.17.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Apr 2015 12:17:22 -0700 (PDT) Message-ID: <55297341.8020208@googlemail.com> Date: Sat, 11 Apr 2015 21:17:21 +0200 From: Nils Durner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "openpgp@ietf.org" References: <5527B621.3040104@cs.tcd.ie> In-Reply-To: <5527B621.3040104@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 11 Apr 2015 19:18:07 -0000 Hi, > e) update S2K with something more modern (PBKDF2, HKDF, scrypt?), My understanding is that the HKDF authors recommend against using HKDF as a PBKDF. From RFC 5869[0]: > In the case of password-based KDFs, a main goal is > to slow down dictionary attacks using two ingredients: a salt value, > and the intentional slowing of the key derivation computation. HKDF > naturally accommodates the use of salt; however, a slowing down > mechanism is not part of this specification. Applications interested > in a password-based KDF should consider whether, for example, [PKCS5] > meets their needs better than HKDF. scrypt, on the other hand, exhibits collisions with long input values - something that yescrypt addresses[1]. I think it is worthwhile to wait for the Password Hashing Competition[2] to conclude in Q2 this year before considering more modern S2K alternatives. Regards, Nils [0] https://tools.ietf.org/html/rfc5869, section 4, paragraph 2 [1] http://www.openwall.com/presentations/PHDays2014-Yescrypt/mgp00009.html, last point [2] https://password-hashing.net/ From nobody Sat Apr 11 12:45:56 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E591B2A95 for ; Sat, 11 Apr 2015 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 khBcu4wrLUAs for ; Sat, 11 Apr 2015 12:45:54 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCAC1B2AC5 for ; Sat, 11 Apr 2015 12:45:53 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 4961711C173E for ; Sun, 12 Apr 2015 05:45:52 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7y1yv5aDc6np for ; Sun, 12 Apr 2015 05:45:45 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id B2E5C11C174B for ; Sun, 12 Apr 2015 05:45:45 +1000 (EST) Message-ID: <552979DE.1090106@adversary.org> Date: Sun, 12 Apr 2015 05:45:34 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1427138741.10191.48.camel@scientia.net> <1428518188.5137.61.camel@scientia.net> In-Reply-To: <1428518188.5137.61.camel@scientia.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Gq7DMO9EQjSV0UrEP81G0GtGf8qoGu25A" 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, 11 Apr 2015 19:45:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Gq7DMO9EQjSV0UrEP81G0GtGf8qoGu25A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/04/2015 4:36 am, Christoph Anton Mitterer wrote: > On Wed, 2015-04-08 at 15:32 +0000, David Leon Gil wrote: >> Brief update on plans for deprecation: The tracking issue is at >> https://github.com/yahoo/end-to-end/issues/31 >> >> Please feel free to open another issue if you have specific >> objections. I will either be convinced by your arguments, and change >> the plan, or explain why I don't. >=20 > Look, as I've pointed out previously, I personally think that crypto, > done as a web app is inherently untrustworthy. >=20 > Maybe I just got something wrong, but AFAIU the idea of "e2e" projects > like your's is to add e2e crypto into your webapps, e.g. via javascript= =2E > Thus the software doing crypto is each time downloaded again from the > server by the client, right? > So ultimately control is again fully at the vendor (at any time he coul= d > send other code and no one would notice), and fully dependent on a > working https (which is as we should all know by now inherently insecur= e > due to the issues of the CA system). Yes, that's precisely the case and in the OpenPGP world we've already seen precisely this situation occur with Hushmail. IIRC it was at the insistence of the FBI that they replaced bits of their code in order to harvest passphrases and access messages. Even with private keys on the user's system it still wouldn't take too much more to compromise the system given enough pressure from a third party (i.e. government) source. > And even more important, none of the big companies which add that IMHO > at best questionable web-based e2e crypto to their services, should > expect that this would make them represent the majority of OpenPGP user= s > and thus would give them a strong voice in decisions. > Just because e.g. google would automatically enable questionable e2e > crypto for millions of their gmail users, doesn't mean that one as a > real "legitimate" OpenPGP user base there. Damn straight. I note, for example, that my key would be arbitrarily not supported by the proposed model simply for including an ELG-E subkey with the RSA master key for no apparent reason. Well, presumably the reason is Yahoo! doesn't want to pay people to write a solid enough implementation that they can actually use without breaking some kind of license. I suspect the same is true with regards to TWOFISH since, even though THREEFISH exists, there's been no indication that it is broken or ought to be deprecated. > For all the above reasons, I personally feel, that it's not appropriate= > here at the OpenPGP WG list, to discuss single unilateral decisions mad= e > by an OpenPGP implementation[1]. >=20 > If one says "hey, let's discuss whether we should deprecate twofish in > OpenPGP" that's totally fine,... but informing the standardisation body= > "hey we drop now support for x, y and z" with an implicit "and since we= > represent n users, you better follow our decision" is not appropriate. Absolutely. Regards, Ben --Gq7DMO9EQjSV0UrEP81G0GtGf8qoGu25A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVKXneAAoJEH/y03E1x1U8bNIMALMLwSLq7/S9qlmNDXFaT5BN t+X6vkE8nujVCl6pe5G0xg3GRFjvT/zSAaKqJ86ZI5PN+c/VlBPNQm5DD9LCUZEG pU0Ui1LjxXAS863a7Pujk/lkSf4e7V7/k9EKBub1aceoOts5pZ2jc/qig1FwSTPQ Ujp7VHJdgjjNkduqW2UAbXm+IrXzvW1cu2/IpzP9F4SZONwg28TlIp3buLQ0uKvD dVay474PAl3XiSYp3wQCu+0Gj73BJxGYGUVZgWHynWdTbX7gUh+mF5yf6x/VsVEk NreO4f9T4UXmkYDYG7zgTXHDDALODljEzSy1KyMB/pgExpCS+NW3VE2t9O16dktR zl/VKP3TivDmvnUwfHgcEfB8eTQrwUaR8MGXT87njqtZZZYtSyhAWz5X+Nmze2p+ +1IWIS1DVegTxydILnH4kns6syShczD8gyZ5pymuHdfjzWUz9tj4fPyM6DeRhGxC 22aNSITyy64h4Z35TkY13SQn1rD2kH1pub/VXwC0aw== =hzin -----END PGP SIGNATURE----- --Gq7DMO9EQjSV0UrEP81G0GtGf8qoGu25A-- From nobody Sat Apr 11 19:31: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 ACDC01B2F06 for ; Sat, 11 Apr 2015 19:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 N5VrrJkFbBsq for ; Sat, 11 Apr 2015 19:30:57 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 9E9E41B2EBB for ; Sat, 11 Apr 2015 19:30:57 -0700 (PDT) Received: by widdi4 with SMTP id di4so35365812wid.0 for ; Sat, 11 Apr 2015 19:30:56 -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=A4hs7cUMzxnwBILoTMPROAw9xWvDund20UjM1YfeGs0=; b=pTC3E8s3xzWCDv2AXSWMS6C/qMEcPxuE7IScOxg6y5PFP8yQYItMbvNslYrwI8BFhy RoUC99FeGlfewKYpRtw6fhspBvxu437e+SrhVwmQJ8ggBcHap9wXHUBeDgwOTjX8jCfX UyBKxELgIJ/T3aqU8KFca9CquM04IBGlKUr6A= 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=A4hs7cUMzxnwBILoTMPROAw9xWvDund20UjM1YfeGs0=; b=E3tJ2zH9S0gWCDXmogUmcEWk5majwnFqSmEQBKJ6Cbbr7LLLs3kHHfBzZMo348rjJh 8svq5spGLTdAWQ+1gbgLnMRi7oime0Cd9t0NiTOigJDd8pm/9M0hv2VOEyCQtTT4Ye0v ekJHTPm0CxrYdMcUpIjjutZDbdMqzqJVxP3tOD46MXOJO+8KEhbVAVT3tnqr+wo0tAa5 1U2QwNAzktOHNraiybtWovY67IpPB0IrW0adaIarN16ORGoia5MbC64evDNUU9oyC6dm 8Pw46r+jeCnD71NxiKkctQNh71csU4+Vk5nJAGj2203DRhBswz9HzDJ5Kcjb6FEHGRa/ BLrg== X-Gm-Message-State: ALoCoQkxttxChEPeoPjUZ3GdZU3lMxcUkIC7lg3kRQT+j+Z3alSSg//FaoMngDIkphrm9jdj+cuq X-Received: by 10.194.234.40 with SMTP id ub8mr15802852wjc.100.1428805856328; Sat, 11 Apr 2015 19:30:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.137 with HTTP; Sat, 11 Apr 2015 19:30:36 -0700 (PDT) In-Reply-To: <5527B5F9.3080502@cs.tcd.ie> References: <551C3FAD.6040107@cs.tcd.ie> <5527B5F9.3080502@cs.tcd.ie> From: Tom Ritter Date: Sat, 11 Apr 2015 21:30:36 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] it's option 2 (was: Re: ways forward wrt IETF wg - please try answer by Apr 8th) 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, 12 Apr 2015 02:30:58 -0000 On 10 April 2015 at 06:37, Stephen Farrell wrote: > Please send a mail to the list if you're willing and able to do > editing or review of drafts during this calendar year. (Say which > or both.) If you'd also be implementing in roughly that timeframe > feel free to say that too. Doing that in the next week would be > a fine thing. (So deadline: April 17th.) I can definitely commit to reviewing. If the drafts are maintained in a collaborative format (I like TLS' github model) I will make my suggestions even easier to integrate and will be encouraged to do more of them ;) -tom From nobody Sun Apr 12 06:28: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 C46A31ACCE6 for ; Sun, 12 Apr 2015 06:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 91m7Xmat9SII for ; Sun, 12 Apr 2015 06:28:05 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 DB3001ACCE5 for ; Sun, 12 Apr 2015 06:28:04 -0700 (PDT) Received: by wgsk9 with SMTP id k9so56738591wgs.3 for ; Sun, 12 Apr 2015 06:28:03 -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=e1SmWAI2JxSGarcEHwMnVHRjCVhhaDsChY0umdnyXOo=; b=kHAD1eqk0ti4D1b8j0JkB98YGjvdgU+SCvntG5jPwHesSvznReSE/cEy7WAd8SJINx U7ecwAwv6YpC2np07cXHoJIS5CS1DHIVgnrbHPDsA2ukjDdxoRxIUjUjWYOZefPG/oxq I49UYokgqJB6hqTKpiQ48ZtGwaVD6/AxpOERE= 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=e1SmWAI2JxSGarcEHwMnVHRjCVhhaDsChY0umdnyXOo=; b=Jsb/ZLtNNnVMo65phg5Uug5VytPoQaD9n2j+Njcqong1nZ6/A1AwBAD+pSLaQZJUSH YuKDh8+1+vd81LSHILN0IGmQEFTl2o0R6sb7yFzg+KC5ESRYYX8AUj1X3AermcXYxham 4UevbjsQv0egNmgtf6Smv4OAwnKZjLt3jJHqlcoiBaLC4YijlbuziL49jHVfQTz+8a7U JafDTHKPoeWxB1Sf5C4d4pbAt0II9rItBEJZ/wp2Q2XdHnkPmeEPqVH/A95JEZAAxemH tHNa9l36wKDE9BQuPGBEpzj4qcZSzs3f2odW8GssYFcsQTGcD/WCRDHrcj+StH7Ku6h7 NmvA== X-Gm-Message-State: ALoCoQnMwRHR6pfpI8MZhOd+YbUKOVXabrUrWjSEyeGWaPFaxI5xa4p0ZN7c0v2Jjkqc8yaBa7pf X-Received: by 10.180.102.130 with SMTP id fo2mr13213276wib.30.1428845283528; Sun, 12 Apr 2015 06:28:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.137 with HTTP; Sun, 12 Apr 2015 06:27:43 -0700 (PDT) In-Reply-To: <5527B621.3040104@cs.tcd.ie> References: <5527B621.3040104@cs.tcd.ie> From: Tom Ritter Date: Sun, 12 Apr 2015 08:27:43 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] details of 4880bis work 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, 12 Apr 2015 13:28:06 -0000 On 10 April 2015 at 06:38, Stephen Farrell wrote: > > > Hiya, here's the 2nd thread, starting from DKG's list. Please > discuss... (We don't need +1's for this, just tweaks, corrections, > additions etc.) If someone wanted to put this on github or > somewhere else the group can edit it, that'd also be fine. I would suggest adding the following: m) Update the allowable OpenPGP Message types in 11.3. "Encrypted Data" should not be considered a valid OpenPGP message and has been deprecated, I think, since 1991. n) Deprecate (remove?) older packet types and versions that should not be used anymore. I think I would want to completely remove most of the language here, but OpenPGP is a different beast from TLS, so some of it should stay because while we may specify someone SHOULD NOT or MUST NOT use it, it will be important for actually inter-operating with vastly deployed install bases. But it seems like we could at least enumerate all of the SHOULD NOT/MUST NOTs and evaluate them on a case-by-case for removal. -tom From nobody Sun Apr 12 07:17: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 CA8EF1ACE2C for ; Sun, 12 Apr 2015 07:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 BCU6N7FxNo7N for ; Sun, 12 Apr 2015 07:17:48 -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 572AE1ACE1D for ; Sun, 12 Apr 2015 07:17:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 12B42BEF7; Sun, 12 Apr 2015 15:17:46 +0100 (IST) 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 5js9j15DQ8fa; Sun, 12 Apr 2015 15:17:45 +0100 (IST) Received: from [10.87.48.73] (unknown [86.41.51.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D299ABEF1; Sun, 12 Apr 2015 15:17:44 +0100 (IST) Message-ID: <552A7E88.4070902@cs.tcd.ie> Date: Sun, 12 Apr 2015 15:17:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christoph Anton Mitterer , "openpgp@ietf.org" References: <5527B621.3040104@cs.tcd.ie> <1428702709.6212.156.camel@scientia.net> In-Reply-To: <1428702709.6212.156.camel@scientia.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 12 Apr 2015 14:17:52 -0000 Hiya, Just on one point, and apologies in advance to those for whom this is repetitive, but I guess not everyone here is on the CFRG list... On 10/04/15 22:51, Christoph Anton Mitterer wrote: >> > f) standardize the two new curves coming out of the CFRG: 25519 and >> > curve448 ("goldilocks") for both signatures and encryption (Werner >> > has already started this process for 25519 signatures) > I haven't followed CFRG the last weeks,... are the plans for anything > at/beyond the 512 level dead? CFRG have reached consensus on the "goldilocks" curve which has a 448-bit prime as it's higher work-factor curve (448 presumably meaning a work factor of about 2^224). That's in addition to curve25519 which has work factor ~2^128. I don't believe there is likely to be an even higher work-factor curve documented by CFRG as part of its current phase of work as they are focused on meeting the immediate needs of TLS and other IETF WGs (and W3C) at present, and they have a bunch of work to do to specify, and get consensus on, a signatures scheme for the two curves they've so far selected. A number of people also made the argument that if a curve with work factor ~2^224 is ever busted then it'd not be at all a surprise if whatever approach worked for that also worked just fine for a work-factor 2^256 curve. In other words, that there's no really good reason to want a curve based on a 512 bit prime if one has goldilocks. Cheers, S. > > >> > From nobody Sun Apr 12 20:12: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 73F161A8AC6 for ; Sun, 12 Apr 2015 20:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 qc8hy-Hmgj_Q for ; Sun, 12 Apr 2015 20:12:18 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 6D69C1A8AC5 for ; Sun, 12 Apr 2015 20:12:18 -0700 (PDT) Received: by wgyo15 with SMTP id o15so66918384wgy.2 for ; Sun, 12 Apr 2015 20:12:17 -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=HkCgHz4EKaJZ4YHsaZLOC/+7JXGgHYMjMGG4/sTphSs=; b=ScGJUklW5YbdeI4LcGNC8PMEOIcYta5gtyMK+bq3R9FpDos1ZFClyDfbfzvqlY2wem O0yEsiIMKKVaG5qI5QM04tg7wpOa27fCFNTbUpXZu5mfiUJd6rljb/++W4cOk4WUDcgh aagVITgwdF4EIxIL72z0gMjVZ9Qm5ioEmOFEs= 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=HkCgHz4EKaJZ4YHsaZLOC/+7JXGgHYMjMGG4/sTphSs=; b=byrxxuQ5cvLgLGDqr3O1WKDyGD16hYbldNCJ0EnAmcP2TNV0Kec8YjrzjV51rpJlT1 b9n2zNDZqNJOJh9P7jV9bDCyoLG+Bnl+EnG0GU8Td5MWi0FdAfQ3lnREDILcyhMlZNme c2VItMgaAlTKlPKB85MME0k3jGASzl1PXeA2VjKZNYQfgOEb5Y8fzlUlt3cPf/viCdJz Qu4/zPCEvSBocQKTc45G/HTemODzQzqxUaVHiCUW0b92c9ajMprwOkFO4EgvFSDJwH/0 tW512PhwY4sb9KyYyyo/pcj+09e0Ofk2eQ14H0AKSpmUdbp8TrL1pCKBBDnyObODOfQW 7AYg== X-Gm-Message-State: ALoCoQmIWqfzagv+h42k0o9mes3sWX7nwITO+Z8qlcwclitvz9p8zMMIkZbapJ7+zDIq8mjldGRe X-Received: by 10.180.81.104 with SMTP id z8mr4448581wix.5.1428894737080; Sun, 12 Apr 2015 20:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.137 with HTTP; Sun, 12 Apr 2015 20:11:56 -0700 (PDT) In-Reply-To: References: <87y4m0ozlt.fsf@vigenere.g10code.de> From: Tom Ritter Date: Sun, 12 Apr 2015 22:11:56 -0500 Message-ID: To: Derek Atkins Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Stephen Farrell , Phillip Hallam-Baker , "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 13 Apr 2015 03:12:20 -0000 On 10 April 2015 at 09:58, Derek Atkins wrote: > Werner Koch writes: > >> On Fri, 10 Apr 2015 15:23, phill@hallambaker.com said: >> >>> There is no need to have an algorithm field, a version field is >>> sufficient because we should only be using one algorithm at a given >> >> Right. However an algorithm field is as good as a version field because >> they have the same purpose in this context. An algorithm field saves us >> a mapping to the actual algorithm. Recall that OpenPGP uses an >> one-octet indentifier and not an OID. > > I'm with Werner on this one. There's not a significant difference > between a version field and an algorithm field. Either option adds a > single byte to the data structure, but using a version field requires > additional lookup map (from fingerprint version # to hash algorithm). Well, say we choose SHA-3, and say Algorithm 1 is SHA-3. In 5 years, where we learned our lesson and want to hash a different set of data for the fingerprint, but SHA-3 is still fine, wouldn't that be a problem? -tom From nobody Sun Apr 12 20:38: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 3424E1A9086 for ; Sun, 12 Apr 2015 20:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 dxBJAN-gKCGy for ; Sun, 12 Apr 2015 20:38:53 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB0F1A9085 for ; Sun, 12 Apr 2015 20:38:52 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-19-552b3a4b81cd Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id F5.5F.03488.B4A3B255; Sun, 12 Apr 2015 23:38:51 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t3D3coJw025484; Sun, 12 Apr 2015 23:38:51 -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 t3D3cmdW011908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Apr 2015 23:38:50 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3D3cmOA020869; Sun, 12 Apr 2015 23:38:48 -0400 (EDT) Date: Sun, 12 Apr 2015 23:38:47 -0400 (EDT) From: Benjamin Kaduk To: Tom Ritter In-Reply-To: Message-ID: References: <5527B621.3040104@cs.tcd.ie> 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+NgFmphleLIzCtJLcpLzFFi42IRYrdT1/W20g41uPxByaLh30N2i+l7r7Fb rDt2nNGB2WNt91U2jyVLfjJ5vHzZwhbAHMVlk5Kak1mWWqRvl8CVMWHTIdaCP2wVy3cfY25g PM7axcjJISFgInF/+RsmCFtM4sK99WxdjFwcQgKLmSTuH9/KAuFsZJRomTObGcI5xCRx6jBM WQOjRP+jv8wg/SwC2hL3Vt9lAbHZBFQkZr7ZyAZiiwjISZw6+BdsB7NAvMTm6R1g9cICehLv Lq4Fu4NTIFDi77srYPW8Ao4SHbe6weJCArkSx7fvZAexRQV0JFbvn8ICUSMocXLmExaImVoS y6dvY5nAKDgLSWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFukZ6uZkleqkppZsYQQHM Kcm7g/HdQaVDjAIcjEo8vBfuaIUKsSaWFVfmHmKU5GBSEuUt1dMOFeJLyk+pzEgszogvKs1J LT7EKMHBrCTCu+gPUDlvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTv KwugoYJFqempFWmZOSUIaSYOTpDhPEDDF4DU8BYXJOYWZ6ZD5E8x6nLcmfJ/EZMQS15+XqqU OO8LkCIBkKKM0jy4ObDE84pRHOgtYV51S6AqHmDSgpv0CmgJE9CSLBWQD4pLEhFSUg2MG6pe 3H4ketG13etppa/B0RPvPnmqRfArf5pRvCK0Q/VE9dlvK/9arlrqlJX0keGCgFpIj/ymtZvn PF53e5Puu4hstv6/zz/dXne+9Wbwv6SbISZNXfd8bya8/ybd122n9dvjW1VF0uQ1/Selbmot /8+/uSPz4drQT6zvVzG2Ock++fXFZpZ3tRJLcUaioRZzUXEiAJs2PQoXAwAA Archived-At: Cc: "openpgp@ietf.org" , Stephen Farrell Subject: Re: [openpgp] details of 4880bis work 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, 13 Apr 2015 03:38:54 -0000 On Sun, 12 Apr 2015, Tom Ritter wrote: > On 10 April 2015 at 06:38, Stephen Farrell wrote: > > n) Deprecate (remove?) older packet types and versions that should not > be used anymore. I think I would want to completely remove most of the > language here, but OpenPGP is a different beast from TLS, so some of > it should stay because while we may specify someone SHOULD NOT or MUST > NOT use it, it will be important for actually inter-operating with > vastly deployed install bases. But it seems like we could at least > enumerate all of the SHOULD NOT/MUST NOTs and evaluate them on a > case-by-case for removal. What we're considering (if we go ahead with the deprecation) over in kitten is to move the deprecated content to an appendix with a note that it should only be provided for compatibility with older versions, if at all. -Ben From nobody Mon Apr 13 00:46: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 CEFE61A1BFF for ; Mon, 13 Apr 2015 00:46:38 -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 aNAmjuaxLgDE for ; Mon, 13 Apr 2015 00:46:36 -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 C02B61A1EED for ; Mon, 13 Apr 2015 00:46:36 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YhZ4l-00044U-3u for ; Mon, 13 Apr 2015 09:46:35 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YhYzz-0002rO-3p; Mon, 13 Apr 2015 09:41:39 +0200 From: Werner Koch To: Tom Ritter References: <87y4m0ozlt.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: Tom Ritter , Derek Atkins , Stephen Farrell , Phillip Hallam-Baker , "openpgp\@ietf.org" Date: Mon, 13 Apr 2015 09:41:38 +0200 In-Reply-To: (Tom Ritter's message of "Sun, 12 Apr 2015 22:11:56 -0500") Message-ID: <87sic4jwzx.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" , Phillip Hallam-Baker , Derek Atkins , Stephen Farrell Subject: Re: [openpgp] Fingerprints 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, 13 Apr 2015 07:46:39 -0000 On Mon, 13 Apr 2015 05:11, tom@ritter.vg said: > Well, say we choose SHA-3, and say Algorithm 1 is SHA-3. In 5 years, > where we learned our lesson and want to hash a different set of data > for the fingerprint, but SHA-3 is still fine, wouldn't that be a > problem? That would require a new key packet format anyway and any old key can't be used with that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 13 08:07: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 74FC51ACCFC for ; Mon, 13 Apr 2015 08:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 HTPk-fE8dkEh for ; Mon, 13 Apr 2015 08:07:18 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 D33D41ACCF3 for ; Mon, 13 Apr 2015 08:07:17 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so61504899lbb.2 for ; Mon, 13 Apr 2015 08:07:16 -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=kttx6UHuBCW7X4hXHTB9J55VnZGYdrMH3YulELYwowk=; b=JfrPLCKuJ9ctMIISEmoPExpSzfzm3D9n5T0kmPCK3GyazqltIEqqKg7j1ds6l29W/e 2Ak3Jbm7VGTP7OhilBEJC8X+Um3dE9EhZQW+A2zmsK8GjUXRqwJ0gmUNScPsZAXaBV4V biQBsg0MqAf2H66KOaFAsoZfFqq/1uiAJbX4AMT4e4CzojkjqjdDjqwiGZuGEGeHvxdX e3OEcj46EWCApIXUHZyCZqnZMZxKhjqpVXCn329313FKjalax7ZKF238sSPLk8pV+hCt O0E8qZcW7NzjhTo6iMdC2LV3HOO/0MmfvTaIT6/V2yte0wE7AA7qU5Vou/GsQr3A2HAT /pcA== X-Gm-Message-State: ALoCoQk+QIshHGS0mXifkGyYb+UL/R7BXKEgi82S33MjvrJjpimdq9ccXU11N/jJKKtmYRM5wAQl X-Received: by 10.152.36.2 with SMTP id m2mr13551238laj.72.1428937636233; Mon, 13 Apr 2015 08:07:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.18.36 with HTTP; Mon, 13 Apr 2015 08:06:55 -0700 (PDT) X-Originating-IP: [24.84.235.32] From: Tim Bray Date: Mon, 13 Apr 2015 08:06:55 -0700 Message-ID: To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=089e0158b82836d68b05139c78ab Archived-At: Subject: [openpgp] Another candidate pgp wg item: Media type 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, 13 Apr 2015 15:07:19 -0000 --089e0158b82836d68b05139c78ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I submitted this and just remembered because it=E2=80=99s about to expire: https://tools.ietf.org/html/draft-bray-pgp-message-00 This was motivated by work on an OpenPGP, an Android app, which deals in PGP messages as chunks of text and uses the built-in Android =E2=80=9Cshare= =E2=80=9D option to route them around. No MIME, no multipart. It would be nice to be able to specify that the chunk-of-text is a PGP message to facilitate dispatching to the right software. --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --089e0158b82836d68b05139c78ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I s= ubmitted this and just remembered because it=E2=80=99s about to expire:=C2= =A0https:= //tools.ietf.org/html/draft-bray-pgp-message-00

This was motivated by work on an OpenPGP, an And= roid app, which deals in PGP messages as chunks of text and uses the built-= in Android =E2=80=9Cshare=E2=80=9D option to route them around.=C2=A0 No MI= ME, no multipart. =C2=A0

= It would be nice to be able to specify that the chunk-of-text is a PGP mess= age to facilitate dispatching to the right software.

--=
- Tim Bray (If yo= u=E2=80=99d like to send me a private message, see https://keybase.io/timbray)
--089e0158b82836d68b05139c78ab-- From nobody Mon Apr 13 08: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 5BEF41ACD97 for ; Mon, 13 Apr 2015 08:40:58 -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 TEH6eBIcbvm7 for ; Mon, 13 Apr 2015 08:40: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 9570D1ACD9C for ; Mon, 13 Apr 2015 08:40: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 EF86F5FB09 for ; Mon, 13 Apr 2015 15:40: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 0VPVhJgyuIRT for ; Mon, 13 Apr 2015 15:40:46 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 13 Apr 2015 15:40:45 +0000 (UTC) Message-ID: <1428939645.12460.1.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Mon, 13 Apr 2015 17:40:45 +0200 In-Reply-To: <87sic4jwzx.fsf@vigenere.g10code.de> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <87sic4jwzx.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-h1Vr9cM5k9WU4xQKEqJd" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 13 Apr 2015 15:40:58 -0000 --=-h1Vr9cM5k9WU4xQKEqJd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-13 at 09:41 +0200, Werner Koch wrote:=20 > That would require a new key packet format anyway and any old key can't > be used with that. Wouldn't it be possible to make that completely independent of the used fingerprint? --=-h1Vr9cM5k9WU4xQKEqJd 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxMzE1NDA0 NVowTwYJKoZIhvcNAQkEMUIEQAlpHBB8b5djRUgTe3qPpe/YiBryS+C51pzQE52utksZAiEKO2TN d9okbRKbCG0Csdb6c1CAfHedLdYwGl/fs60wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCM1OeElwDK8muhxhsVv6GTifjEXlDZ mSEYxY0X/8frzSsUgbXe/YnQ8q8USirz27Ap1TEF4tvhVXRiEwaERXXZxYFZdKUinpuEnDShvSJ8 2L2g2kaVd4ceGN/KyrZ+NP/lDqBU1EyekbH5Uty2DBMydXdZCWRpoacvbuW4GtdNhWvw1EXRr0AS gMuNYxbSGnOQn3hHCoaY8FcJOIMQlxWbzXmqy71qt4fnrLMjKeyZK3yLVXB2/vud9SKwBMUx96N4 LL0a4sQ3WTrZHMjGdkXfnPjCOBpBUM612Fcamnb0P7+Uh8J8owRpR7qZvuUJ78EAgRVdansLH98f A259li0wAAAAAAAA --=-h1Vr9cM5k9WU4xQKEqJd-- From nobody Mon Apr 13 08:44: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 768731ACDC6 for ; Mon, 13 Apr 2015 08:44:17 -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 KiNiw-QYxF4P for ; Mon, 13 Apr 2015 08:44:15 -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 6F9B11ACDC3 for ; Mon, 13 Apr 2015 08:44:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5507EBF25; Mon, 13 Apr 2015 16:44:13 +0100 (IST) 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 L9bMt3vkZUAS; Mon, 13 Apr 2015 16:44:13 +0100 (IST) 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 343D3BEBC; Mon, 13 Apr 2015 16:44:13 +0100 (IST) Message-ID: <552BE44E.90704@cs.tcd.ie> Date: Mon, 13 Apr 2015 16:44:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Ritter References: <551C3FAD.6040107@cs.tcd.ie> <5527B5F9.3080502@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] it's option 2 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, 13 Apr 2015 15:44:17 -0000 On 12/04/15 03:30, Tom Ritter wrote: > On 10 April 2015 at 06:37, Stephen Farrell wrote: >> Please send a mail to the list if you're willing and able to do >> editing or review of drafts during this calendar year. (Say which >> or both.) If you'd also be implementing in roughly that timeframe >> feel free to say that too. Doing that in the next week would be >> a fine thing. (So deadline: April 17th.) > > I can definitely commit to reviewing. If the drafts are maintained in > a collaborative format (I like TLS' github model) I will make my > suggestions even easier to integrate and will be encouraged to do more > of them ;) Thanks. More indications like that to the list would be welcome. Even if you feel it's obvious, it may help the IESG when it comes time to evaluate whether or not there's sufficient interest to form a new WG. Thanks, S. > > -tom > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Mon Apr 13 09:46: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 9D7601ACEB0 for ; Mon, 13 Apr 2015 09:46:38 -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 WmFaBuMq2aus for ; Mon, 13 Apr 2015 09:46:36 -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 A03A41ACE4E for ; Mon, 13 Apr 2015 09:46:36 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YhhVL-00056m-19 for ; Mon, 13 Apr 2015 18:46:35 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YhhPB-0004NF-2q; Mon, 13 Apr 2015 18:40:13 +0200 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 Mail-Followup-To: Tim Bray , openpgp@ietf.org Date: Mon, 13 Apr 2015 18:40:12 +0200 In-Reply-To: (Tim Bray's message of "Mon, 13 Apr 2015 08:06:55 -0700") Message-ID: <87vbh0hthv.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] Another candidate pgp wg item: Media type 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, 13 Apr 2015 16:46:38 -0000 On Mon, 13 Apr 2015 17:06, tbray@textuality.com said: > It would be nice to be able to specify that the chunk-of-text is a PGP > message to facilitate dispatching to the right software. That is what a Content-Type is used for. This is part of MIME but also used by HTTP and other protocols. No need to invent yet another content type description. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 13 10:25: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 29D231ACF1C for ; Mon, 13 Apr 2015 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-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 5RAB5PKxjJah for ; Mon, 13 Apr 2015 10:25:10 -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 51F041ACF5E for ; Mon, 13 Apr 2015 10:25:04 -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 5AE0742070 for ; Mon, 13 Apr 2015 19:25:01 +0200 (CEST) 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 S9nQ0fQg3orZ for ; Mon, 13 Apr 2015 19:25:00 +0200 (CEST) Message-ID: <552BFBEB.8040208@dominikschuermann.de> Date: Mon, 13 Apr 2015 19:24:59 +0200 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: openpgp@ietf.org References: <87vbh0hthv.fsf@vigenere.g10code.de> In-Reply-To: <87vbh0hthv.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Another candidate pgp wg item: Media type 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, 13 Apr 2015 17:25:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2015 06:40 PM, Werner Koch wrote: > On Mon, 13 Apr 2015 17:06, tbray@textuality.com said: > >> It would be nice to be able to specify that the chunk-of-text is >> a PGP message to facilitate dispatching to the right software. > > That is what a Content-Type is used for. This is part of MIME but > also used by HTTP and other protocols. No need to invent yet > another content type description. The problem here is that Android does not allow to set a Content-Type when sharing data between applications. A MIME type however is the most preferred way of indicating the type of data that is being shared. See http://developer.android.com/guide/components/intents-filters.html#Examp leSend Applications can receive data based on a filter that is defined in most cases by a MIME type: http://developer.android.com/guide/components/intents-filters.html#Examp leFilters So Android is heavily based on these Intent sharing actions and tries to get away from a traditional file based OS. So instead of relying on file endings it would be nice to have a MIME type indicating the content . I hope this provides more insight into the interoperability issue we are facing. Regards Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVK/vrAAoJEHGMBwEAASKCuPoH+weSZqQUTMQRZVB7dcFGfqdW bgjRvZSyksaxeqOyF2dIbiws5r+hYHxZtQwlTmktYyLfG3kIMFjuvaosFx0rKULP hVxNnMjtTNJDXedRR+JRx4fiy82Vyi5LNwPMWJS8SbfJzCoJXu58+xCqurp9qsjG eSgG9fQdJDADrs9KICifrQluv3lEYXW/QIOxT4OKevnRIAKJ55EKfgqi5Ehoqcay X5ZL+iv4p7iKxtcXfJeoUZ22DSlKFCAt7tfStLanDxvuSEUJHHAV0/7bug4YmUF4 7WQu9tM7/TWhQtAtaTDRUSAiSZF/MUytvpOBgKVj7oZLD6+PTStimTKewoA1irg= =iwUC -----END PGP SIGNATURE----- From nobody Mon Apr 13 10:32: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 AFEE71AD06A for ; Mon, 13 Apr 2015 10:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0I5ASswCB7xT for ; Mon, 13 Apr 2015 10:32:24 -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 3469E1AD067 for ; Mon, 13 Apr 2015 10:32:24 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so65042368lbb.2 for ; Mon, 13 Apr 2015 10:32:22 -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=ep4SmkfIkWHcb3H9rXKFG1s30K/y/Okvvb+zjcph23w=; b=LBbkYs4JbTgPY9ewF+2cl8rw69pqftkdeRXTdrZKUvA1/7J4c0Zv4WyWLtCCKvqiEA b20RqAvjVE4cQjqwoFFxOmSGXxGSlrkMNl8U9Vl6ax1l/l3IletTcrKIq48B6VvGjJ9b 1sm2MV++k+PAtgqXCo+JKZnddUlK1NYK37yhSrC6O1lA0Pbo60KuvlYk8Op5gSq81uNZ JD+KedThiLs65RFEPdDDN2mc0/myoVE23mbMOJMVVEHt5MPZx87uMYUe3ACdWJODKOYS y2cUrBgkpgTIqziAj+dwj58E/m9zSeQ5o6Ar3J8Y4F7fB3JNYQPITNyuXqZALA8G6Or+ Cz0w== MIME-Version: 1.0 X-Received: by 10.152.87.162 with SMTP id az2mr14631912lab.58.1428946342629; Mon, 13 Apr 2015 10:32:22 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Mon, 13 Apr 2015 10:32:22 -0700 (PDT) In-Reply-To: <1428939645.12460.1.camel@scientia.net> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <87sic4jwzx.fsf@vigenere.g10code.de> <1428939645.12460.1.camel@scientia.net> Date: Mon, 13 Apr 2015 13:32:22 -0400 X-Google-Sender-Auth: V5otEMgbA2DkogojbTwnuUVhM1E Message-ID: From: Phillip Hallam-Baker To: Christoph Anton Mitterer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 13 Apr 2015 17:32:25 -0000 I think what the discussion of the fingerprint issue is demonstrating is that there is actually a semantic difference between the hash algorithm ID and the fingerprint ID. While this does not make a difference to the bits on the wire, we should probably maintain the distinction or else confusion will be introduced. It is settled practice that if you are going to sign any important piece of data then you had better sign (Content-Type + Data) and not just Data. Otherwise there is a substitution attack waiting. The same principle applies to fingerprints. With a fingerprint we have to distinguish: 1) The hash algorithm used to create a fingerprint 2) The packaging format that converts (AlgorithmID, PublicKeyBytes) -> PackedBytes Right now (2) is a PGP format. But it is not impossible that we would want to switch to a different format down the road. The chief limitation in the PGP format is that all the slots and structures are essentially fixed. The chief benefit of JSON is that it the slots in a structure are not fixed and unlike previous attempts (ASN.1, XML) making use of the extension mechanism does not completely suck. Given the way fingerprints are used, there is an intense pressure to use a single algorithm for everything. That is why I think that we should pick either SHA-2-512 or SHA-3-512 and truncate as necessary. As a practical matter, I could care less about the code points people choose. But this really is a separate registry from the hash algorithms. We don't need to do anything to identify legacy fingerprints because they are a different size. But totting up all the expected needs, I can only see the need for 3 entries in the next 20 years, maximum: Code, Packaging, Algorithm 10, PGP, SHA-?-512 0, X.509 KeyInfo, SHA-2-512 42, JSON-y, SHA-3-512 The type 10 fingerprint would be used for all keys that have a PGP algorithm identifier code assigned and type 0 would be used for vanity crypto, etc. I picked 10 for PGP because that is the code for the SHA-2-512 algorithm which I think is probably the best choice right now and 42 for some future packing because why not and 0 because that is what I am using now. I don't think we are likely to need code 42 for a decade. It is the sort of thing that you do AFTER all the other structures are converted. And even then only if you have to. But the point is that this is a registry with 3 entries maximum. It is not equivalent to the hash registry. From nobody Mon Apr 13 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 053101AD241 for ; Mon, 13 Apr 2015 10:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kO9hhkVoOWG for ; Mon, 13 Apr 2015 10:58:42 -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 569F11AD190 for ; Mon, 13 Apr 2015 10:58:42 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id D540A6D784; Mon, 13 Apr 2015 13:58:40 -0400 (EDT) Message-ID: <552C03CF.3020001@iang.org> Date: Mon, 13 Apr 2015 18:58:39 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4m0ozlt.fsf@vigenere.g10code.de> <87sic4jwzx.fsf@vigenere.g10code.de> <1428939645.12460.1.camel@scientia.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 13 Apr 2015 17:58:44 -0000 On 13/04/2015 18:32 pm, Phillip Hallam-Baker wrote: > Given the way fingerprints are used, there is an intense pressure to > use a single algorithm for everything. That is why I think that we > should pick either SHA-2-512 or SHA-3-512 and truncate as necessary. If SHA-2-512, then I'm happy to truncate as necessary. If SHA-3, it is a sponge function internally so it is designed to do the "truncation" or rather "expansion" already and it'd be a shame not to use that feature directly. (as an aside, I think we should go with Keccak entirely as it'll be out soon enough in NIST form as SHA-3, and it has substantial other benefits.) iang From nobody Mon Apr 13 11:14: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 A33461B2A12 for ; Mon, 13 Apr 2015 11:14:54 -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 otAFufg_PAOM for ; Mon, 13 Apr 2015 11:14:51 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 5F4E11B29BA for ; Mon, 13 Apr 2015 11:14:51 -0700 (PDT) Received: by widdi4 with SMTP id di4so83657716wid.0 for ; Mon, 13 Apr 2015 11:14:50 -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=WxwxFlYkTsOglR5kBGDbU5vQH/lPM8RYlMpCtURM7xU=; b=KzgYiF8jwvp3PuHBapT8hiJrgsVI7dHalZbpTNxruH/5cq2jbVtG23+lzS+7rNuveF DGhh0r/LUfYr18CxccPus10VftQoAcEVozEP6MVdDsCxYwwCJUxuNYQrR+yPdVagi0Di SvYfVJrR/e+/wL0IY3uBIPoyd83GUgRQbEqnMgobi4ehbTDL67FDCPCy8SfLx49p0xKx BBbQD6/mIEiEJGDxDCJzK70q9jrGD7ZBzoeJMa7WTuG1up9DJ+xRvyWIGUAgHmMjDsCX jqVEidefmWrjEnOz2CdCDDwTnoXH4mroj1w5d/h22qKaWAA3JsvutQUK0aA3ZgT80uLf p0/Q== X-Gm-Message-State: ALoCoQkmZGdjOC+Or2mvOO4J4Hpos/wn/707v3LtHI+XZi1ASMbxf3b2a9Ur/y1nKSqHco9lm7y8 X-Received: by 10.194.78.144 with SMTP id b16mr29832139wjx.18.1428948890158; Mon, 13 Apr 2015 11:14:50 -0700 (PDT) Received: from [192.168.55.120] (business-178-48-2-49.business.broadband.hu. [178.48.2.49]) by mx.google.com with ESMTPSA id mc20sm12531309wic.15.2015.04.13.11.14.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Apr 2015 11:14:49 -0700 (PDT) Message-ID: <552C0777.9010404@epointsystem.org> Date: Mon, 13 Apr 2015 20:14:15 +0200 From: "Daniel A. Nagy" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4m0ozlt.fsf@vigenere.g10code.de> <87sic4jwzx.fsf@vigenere.g10code.de> <1428939645.12460.1.camel@scientia.net> <552C03CF.3020001@iang.org> In-Reply-To: <552C03CF.3020001@iang.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 13 Apr 2015 18:14:54 -0000 +1 On 04/13/2015 07:58 PM, ianG wrote: > On 13/04/2015 18:32 pm, Phillip Hallam-Baker wrote: > >> Given the way fingerprints are used, there is an intense pressure to >> use a single algorithm for everything. That is why I think that we >> should pick either SHA-2-512 or SHA-3-512 and truncate as necessary. > > > If SHA-2-512, then I'm happy to truncate as necessary. > > If SHA-3, it is a sponge function internally so it is designed to do the > "truncation" or rather "expansion" already and it'd be a shame not to > use that feature directly. > > (as an aside, I think we should go with Keccak entirely as it'll be out > soon enough in NIST form as SHA-3, and it has substantial other benefits.) > > > > > iang > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Tue Apr 14 06:59: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 BF7591A00C2 for ; Tue, 14 Apr 2015 06:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 mVs97A_ShzcB for ; Tue, 14 Apr 2015 06:59:19 -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 537FD1A00F7 for ; Tue, 14 Apr 2015 06:59:19 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so9093764lbb.3 for ; Tue, 14 Apr 2015 06:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=HzeI2mlmxKG+zFuPhv7oJPrXECjiuGZ+EcCAHLOHLBk=; b=EIGx5JZUiozWsCO2u845wpcf5uiXl2dw7R1dwz/h/xZNi8aZxOK6fTzysD3KpxsaR9 M4qcPDQUSWG/UVVm43d2lTfs9biIX3Gl5KCPC5Msn8BDFtRKFpfDWU6RYMSCs8HsX/JJ NwYQ26eS4uGjnDT8Tku4lzuEXpSDsVoJ+DnHL/AUH33l25t8/BZ6PqsFnL8qPE5tbZP8 tO+v7UZjYMnH8jZkYtD2/bgDQ+reBQmP0m1my1NzttkheMsZ9rLLR1QRFeHIaJkYYUU/ 4Zvu/VrnwzxWwIF03WTRY3Lv+xUUtn6ADN2ND8OMmRe/HNq8MIMk3ZRN6PfWRVtm7ZPi ysxQ== MIME-Version: 1.0 X-Received: by 10.112.161.66 with SMTP id xq2mr18838646lbb.103.1429019957843; Tue, 14 Apr 2015 06:59:17 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Tue, 14 Apr 2015 06:59:17 -0700 (PDT) Date: Tue, 14 Apr 2015 09:59:17 -0400 X-Google-Sender-Auth: k3rocihwg3x4Oo-uLLYWm6vUQuI Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] So if we ever did redo the mail system from scratch... 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, 14 Apr 2015 13:59:20 -0000 OK so like most folk, I see no point in redoing the mail system. Or rather I didn't till I sent a message without an attachment. Then it hit me. There is only one feature that is powerful enough to justify a whole new mail protocol and it is the ability to change a message after it is 'sent' but before it is read. Implementing this would require a complete break with SMTP. We would have to junk all the idiot crud of forwarding and relays etc. All the stuff the mail folk love that makes sending mail inefficient and unreliable. I don't want to do that right now. But if there is going to be a change, that is the place I would look for it. From nobody Tue Apr 14 08:46: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 DCDA61B2D2B for ; Tue, 14 Apr 2015 08:46:16 -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 mm2tuBstl19q for ; Tue, 14 Apr 2015 08:46:15 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 40BF41B2D4B for ; Tue, 14 Apr 2015 08:46:15 -0700 (PDT) Received: by widjs5 with SMTP id js5so91551868wid.1 for ; Tue, 14 Apr 2015 08:46:14 -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=ulpyWqeCv+hvDsaXHjYWaEGX9eOQ4wYgmkeM7fZd5K0=; b=uRw5b3ul30tvnoj7dRNDa/8v8rflyh2DvuP0mVwsF419i8I1Vm3mqssFS9rRHpMlRX oqOlPgLC7oVKyi5/twgXZBgrfPBWm5UDO0jLV3IY96bsG9L2aKEc+leQe2FVSYYAJfgz dPhPa3ZoczPzJKEDshagsCuF7EZcmkDwRuQIKXO98d3O4K8LYJWl6Qa5UgCTCUzZHDf3 nwo9ONTywCeRCfZUGgipo8REkHK3Lr6B2GKKbYi25DsdqHn9cXchyN2p1zMkCD7oO+sR gtrI4uqd1BjoarUeE6EA57V1q0vONWCZed0APvCHLg5rdCc6BZhXGba/c0wLyYhgrMol STaw== X-Received: by 10.180.231.40 with SMTP id td8mr31194601wic.9.1429026373995; Tue, 14 Apr 2015 08:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.186.169 with HTTP; Tue, 14 Apr 2015 08:45:33 -0700 (PDT) In-Reply-To: References: From: Ryan Carboni Date: Tue, 14 Apr 2015 08:45:33 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a1134cc5065939a0513b12191 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] So if we ever did redo the mail system from scratch... 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, 14 Apr 2015 15:46:17 -0000 --001a1134cc5065939a0513b12191 Content-Type: text/plain; charset=UTF-8 I use gmail with the undo send feature. On Tue, Apr 14, 2015 at 6:59 AM, Phillip Hallam-Baker wrote: > OK so like most folk, I see no point in redoing the mail system. Or > rather I didn't till I sent a message without an attachment. Then it > hit me. There is only one feature that is powerful enough to justify a > whole new mail protocol and it is the ability to change a message > after it is 'sent' but before it is read. > > Implementing this would require a complete break with SMTP. We would > have to junk all the idiot crud of forwarding and relays etc. All the > stuff the mail folk love that makes sending mail inefficient and > unreliable. > > I don't want to do that right now. But if there is going to be a > change, that is the place I would look for it. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1134cc5065939a0513b12191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I use gmail with the undo send feature.

On Tue, Apr 14, 2015 at 6:59 A= M, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
OK so like most folk, I see no point in re= doing the mail system. Or
rather I didn't till I sent a message without an attachment. Then it hit me. There is only one feature that is powerful enough to justify a
whole new mail protocol and it is the ability to change a message
after it is 'sent' but before it is read.

Implementing this would require a complete break with SMTP. We would
have to junk all the idiot crud of forwarding and relays etc. All the
stuff the mail folk love that makes sending mail inefficient and
unreliable.

I don't want to do that right now. But if there is going to be a
change, that is the place I would look for it.

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

--001a1134cc5065939a0513b12191-- From nobody Tue Apr 14 09:04: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 F398E1B2D97 for ; Tue, 14 Apr 2015 09:04:22 -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 51hM8ZOVzqHs for ; Tue, 14 Apr 2015 09:04:18 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 377461B2E07 for ; Tue, 14 Apr 2015 09:01:49 -0700 (PDT) Received: by wgsk9 with SMTP id k9so17190832wgs.3 for ; Tue, 14 Apr 2015 09:01: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=79s+J60TQkAt7jm4WHKgBDLgqAfAVtyuFGGGmNPgZZU=; b=sfD+BI6dc6sqLe4jzdLIuxbDKowH3kaZG2Lqo1Y7LtTMZ360tEs2NEK0ngK1HF6Vm0 eflUNredhWZ9KWlVvNqd0Grl2jRm9lKfEUj4V8sT0OAfyMok4ouyzk3FQ6hPsFW82h1u L3lXQy8Fv+XHZOjVT/K4V12iPdUnMZC03Tiyg= 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=79s+J60TQkAt7jm4WHKgBDLgqAfAVtyuFGGGmNPgZZU=; b=cXONbAmLw98g1cRlA1xx9YjD34eeMPggzm6ruPyHhYWhL9ae2Y/DLhpuZgbjpWHbuQ QvngkfsL/e0fXE7dRLXVVzsZk8paB6RVIWHSPBERSVboL/Q/c/TucFioDOu2rz9AUu/c pWiNGzXX+hq2Vi8lIBFNfrYVgTzc0i51LMDVALZI0uJiT5MzOm2Fm3puRl/suO2aIhuQ d87OvyAKFZ9U/YHkOW0RDmW0Vc3DtelitDooyJkL0C2wVQ216YGob5l73aGmGsj/jBHh LOd0G8b6AHZpzSQ28/b/ceAT2DaP67adStRVPtYl+iVyvrXBsWt5H051lxCJVBaGBHBv IU7w== X-Gm-Message-State: ALoCoQlg2Ali/8u/qvrjZzs8ByGUjSv+LKtOWMyexlFjhAfF9dLiPHRhKT4EVRJVYHKMYjqGf5EL X-Received: by 10.180.88.72 with SMTP id be8mr26641768wib.45.1429027307982; Tue, 14 Apr 2015 09:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.137 with HTTP; Tue, 14 Apr 2015 09:01:27 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Tue, 14 Apr 2015 11:01:27 -0500 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] So if we ever did redo the mail system from scratch... 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, 14 Apr 2015 16:04:23 -0000 On 14 April 2015 at 08:59, Phillip Hallam-Baker wrote: > OK so like most folk, I see no point in redoing the mail system. Or > rather I didn't till I sent a message without an attachment. Then it > hit me. There is only one feature that is powerful enough to justify a > whole new mail protocol and it is the ability to change a message > after it is 'sent' but before it is read. Like the concept of 'Self-Destructing Messages' and Read Receipts - this requires the cooperation of the receiver. And, like both of these, one of the first features built is going to be the option to disable it, or better yet, view the request to edit and allow the receiver to accept the request or reject it. And I think Outlook & Exchange has both this feature and the ability to view that an edit took place (and maybe what it was)... On 14 April 2015 at 10:45, Ryan Carboni wrote: > I use gmail with the undo send feature. Which works by delaying the message in your outbox. You can write a client-side rule to do this on outlook clients as well. For many years I had a rule that would delay any message signed "-tom" for 1-2 minutes for me to edit it. (And to immediately send any message signed "-tom.") -tom From nobody Tue Apr 14 09:27: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 353661B2E3D for ; Tue, 14 Apr 2015 09:27:26 -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 nZwdGB82WQ_t for ; Tue, 14 Apr 2015 09:27:24 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::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 3CDC31B2E0A for ; Tue, 14 Apr 2015 09:27:24 -0700 (PDT) Received: by wgyo15 with SMTP id o15so18204505wgy.2 for ; Tue, 14 Apr 2015 09:27:23 -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=Vg+nmdoV0V7NtrqFPWacu7lFOtTiwMtENUON9e+sbdA=; b=f91HajER8uj7CtJyT5xnqgq1B7fzweRHDNM8AXXb6/2tNxmh8etNCeN/Sw5XexIkDx N/0u9XCCEF6fYiEkCoDK0g67af6ua+IdVAqKOIl97QAyzsoq48zVFly5I8RvE4eSr5i8 u1YyXJhH2JnGj866ZvfkiPCgCR/qk3YwACm236Tc6ZjUcd8RPyulhmGgmomZK2Sy1JmG bFvGUy6TtXmjjKaqC+7fHuire0xhZTRnfgQKelbKF8oHB0WGIjHUQ39wN8IP6aXD3ewq RFNigCotbbqWVZZ7iTUubtVGPiYymSXQ+66k15HrDlNZ7wCYy++ZRcn2jdeU6Hq9+G9g L4Uw== X-Received: by 10.194.143.20 with SMTP id sa20mr39537069wjb.16.1429028842989; Tue, 14 Apr 2015 09:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.186.169 with HTTP; Tue, 14 Apr 2015 09:26:42 -0700 (PDT) In-Reply-To: References: From: Ryan Carboni Date: Tue, 14 Apr 2015 09:26:42 -0700 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=089e0122ece28f6fdf0513b1b400 Archived-At: Cc: Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] So if we ever did redo the mail system from scratch... 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, 14 Apr 2015 16:27:26 -0000 --089e0122ece28f6fdf0513b1b400 Content-Type: text/plain; charset=UTF-8 Given that everything is in the cloud, it might be best that an email's contents is not downloaded until a user opens the email. The attachments too will be opened when a user clicks on it. But this would be biased against small email servers. On Tue, Apr 14, 2015 at 9:01 AM, Tom Ritter wrote: > On 14 April 2015 at 08:59, Phillip Hallam-Baker > wrote: > > OK so like most folk, I see no point in redoing the mail system. Or > > rather I didn't till I sent a message without an attachment. Then it > > hit me. There is only one feature that is powerful enough to justify a > > whole new mail protocol and it is the ability to change a message > > after it is 'sent' but before it is read. > > Like the concept of 'Self-Destructing Messages' and Read Receipts - > this requires the cooperation of the receiver. And, like both of > these, one of the first features built is going to be the option to > disable it, or better yet, view the request to edit and allow the > receiver to accept the request or reject it. > > And I think Outlook & Exchange has both this feature and the ability > to view that an edit took place (and maybe what it was)... > > > On 14 April 2015 at 10:45, Ryan Carboni wrote: > > I use gmail with the undo send feature. > > Which works by delaying the message in your outbox. You can write a > client-side rule to do this on outlook clients as well. For many years > I had a rule that would delay any message signed "-tom" for 1-2 > minutes for me to edit it. (And to immediately send any message > signed "-tom.") > > -tom > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --089e0122ece28f6fdf0513b1b400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given that everything is in the cloud, it might be best th= at an email's contents is not downloaded until a user opens the email. = The attachments too will be opened when a user clicks on it.

=
But this would be biased against small email servers.

On Tue, Apr 14, 2015 a= t 9:01 AM, Tom Ritter <tom@ritter.vg> wrote:
On 14 April 2015 at 08:59, Phillip Hallam-B= aker <phill@hallambaker.com= > wrote:
> OK so like most folk, I see no point in redoing the mail system. Or > rather I didn't till I sent a message without an attachment. Then = it
> hit me. There is only one feature that is powerful enough to justify a=
> whole new mail protocol and it is the ability to change a message
> after it is 'sent' but before it is read.

Like the concept of 'Self-Destructing Messages' and Read Rec= eipts -
this requires the cooperation of the receiver.=C2=A0 And, like both of
these, one of the first features built is going to be the option to
disable it, or better yet, view the request to edit and allow the
receiver to accept the request or reject it.

And I think Outlook & Exchange has both this feature and the ability to view that an edit took place (and maybe what it was)...


On 14 April 2015 at 10:45, Ryan Carboni <ryacko@gmail.com> wrote:
> I use gmail with the undo send feature.

Which works by delaying the message in your outbox.=C2=A0 You can wr= ite a
client-side rule to do this on outlook clients as well. For many years
I had a rule that would delay any message signed "-tom" for 1-2 minutes for me to edit it.=C2=A0 (And to immediately send any message
signed "-tom.")

-tom

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

--089e0122ece28f6fdf0513b1b400-- From nobody Tue Apr 14 10:06: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 DDB8E1A00B2 for ; Tue, 14 Apr 2015 10:06:38 -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 ahipWVbbgLQP for ; Tue, 14 Apr 2015 10:06:36 -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 B7F431A00A8 for ; Tue, 14 Apr 2015 10:06:36 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yi4IF-0001jJ-1n for ; Tue, 14 Apr 2015 19:06:35 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yi4Gf-0000EQ-Vw; Tue, 14 Apr 2015 19:04:58 +0200 From: Werner Koch To: Dominik Schuermann References: <87vbh0hthv.fsf@vigenere.g10code.de> <552BFBEB.8040208@dominikschuermann.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: Dominik Schuermann , openpgp@ietf.org Date: Tue, 14 Apr 2015 19:04:57 +0200 In-Reply-To: <552BFBEB.8040208@dominikschuermann.de> (Dominik Schuermann's message of "Mon, 13 Apr 2015 19:24:59 +0200") Message-ID: <87bniqej46.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] Another candidate pgp wg item: Media type 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, 14 Apr 2015 17:06:39 -0000 On Mon, 13 Apr 2015 19:24, dominik@dominikschuermann.de said: > The problem here is that Android does not allow to set a Content-Type > when sharing data between applications. A MIME type however is the > most preferred way of indicating the type of data that is being So what is the problem for an OpenPGP parser to do that on the decrypted and de-mimed plaintext? Why inventing another mechanism when we already have a matured one. Assume your suggestion is added: Soon after that someone else may request that license information is important enough that it needs to go into OpenPGP. We would end up with our own meta data system. With MIME all that is instantly available. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 14 11:59: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 D283C1ACD9A for ; Tue, 14 Apr 2015 11:59:35 -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 3_AtKNcEERfc for ; Tue, 14 Apr 2015 11:59:32 -0700 (PDT) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 896D11ACD90 for ; Tue, 14 Apr 2015 11:59:07 -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 mx1.mailbox.org (Postfix) with ESMTPS id 5CECA4002B for ; Tue, 14 Apr 2015 20:59:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id gkX1Jf5eMWZF for ; Tue, 14 Apr 2015 20:59:04 +0200 (CEST) Message-ID: <552D6377.1090507@dominikschuermann.de> Date: Tue, 14 Apr 2015 20:59:03 +0200 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: openpgp@ietf.org References: <87vbh0hthv.fsf@vigenere.g10code.de> <552BFBEB.8040208@dominikschuermann.de> <87bniqej46.fsf@vigenere.g10code.de> In-Reply-To: <87bniqej46.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Another candidate pgp wg item: Media type 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, 14 Apr 2015 18:59:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We somehow talked past each other :D I will try to explain the problem with a scenario: 1. You encrypt an image with OpenKeychain, so you open OpenKeychain and go to "encrypt". The way it works in Android is that you now call a method to open everything with MIME type "image/*". Then all applications that serve images, like the gallery application pop up and can be used to open an image. 2. You select the image from one of the apps which then returns the data stream to OpenKeychain. OpenKeychain encrypts it using a protected file storage. 3. Now the crucial step: Now this encrypted blob is shared to other applications. Maybe you want to upload it via Dropbox. You are not really supposed to save it anywhere on the disk, that's not Android's model. So what MIME type should now be used to share this encrypted blob? Following the RFC3156 we use "application/octet-stream" but that's really unspecific. Recall that we are using no ASCII armor here. The other way round it gets more problematic. Consider decryption: You open OpenKeychain and want to decrypt a file. So you only want to see the apps that serve the PGP-encrypted blobs. Again, we can only use "application/octet-stream" per RFC, because there is no specific MIME type for encrypted PGP-blobs. Regards Dominik On 04/14/2015 07:04 PM, Werner Koch wrote: > On Mon, 13 Apr 2015 19:24, dominik@dominikschuermann.de said: > >> The problem here is that Android does not allow to set a >> Content-Type when sharing data between applications. A MIME type >> however is the most preferred way of indicating the type of data >> that is being > > So what is the problem for an OpenPGP parser to do that on the > decrypted and de-mimed plaintext? Why inventing another mechanism > when we already have a matured one. > > Assume your suggestion is added: Soon after that someone else may > request that license information is important enough that it needs > to go into OpenPGP. We would end up with our own meta data system. > With MIME all that is instantly available. > > > Shalom-Salam, > > Werner > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVLWN2AAoJEHGMBwEAASKCc00H/3HP0p/ghQUQQaJHsEGn1K97 iQ30/3I03fHi9kJSVWD8zqGsvvmGISyKKry0tCeiIVW2F/dhiJphcJSrcPteSOCz qIvRSs4uqC/kwDeWeG9idZL/sdxjwnSug8IlaEBq8Vy6x//2JEpL1udbUQ9If2Dw 7/LYi6XFBZyRU84NAX7go80C3e334oymnV8sEvmSQdtNPRMlMOIWdwoJiddGdOnM riujZ5mEHBU8i/YSdJQ7ZjUNmSHPVf+oZFq9Oe+sTG7XUq4iSgViQln17CsqrlP3 VeKzyXHafKm6HQhdsWCEq5DUUQHLGG0BKvjftuQRTdpAtgwDS8iS3qII9xZd0YY= =ZPoY -----END PGP SIGNATURE----- From nobody Tue Apr 14 13:21: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 01C141AD2B2 for ; Tue, 14 Apr 2015 13:21:39 -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 yVAk50Eu477p for ; Tue, 14 Apr 2015 13:21:37 -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 F3E9F1AD272 for ; Tue, 14 Apr 2015 13:21:36 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yi7Kx-0004bk-Av for ; Tue, 14 Apr 2015 22:21:35 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yi7Ep-0000nJ-AD; Tue, 14 Apr 2015 22:15:15 +0200 From: Werner Koch To: Dominik Schuermann References: <87vbh0hthv.fsf@vigenere.g10code.de> <552BFBEB.8040208@dominikschuermann.de> <87bniqej46.fsf@vigenere.g10code.de> <552D6377.1090507@dominikschuermann.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: Dominik Schuermann , openpgp@ietf.org Date: Tue, 14 Apr 2015 22:15:15 +0200 In-Reply-To: <552D6377.1090507@dominikschuermann.de> (Dominik Schuermann's message of "Tue, 14 Apr 2015 20:59:03 +0200") Message-ID: <87r3rmcvqk.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] Another candidate pgp wg item: Media type 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, 14 Apr 2015 20:21:39 -0000 On Tue, 14 Apr 2015 20:59, dominik@dominikschuermann.de said: > model. So what MIME type should now be used to share this encrypted > blob? Following the RFC3156 we use "application/octet-stream" but > that's really unspecific. Recall that we are using no ASCII armor here. Okay, so your comments are about PGP/MIME. I assumed you were talking about 5.9. Literal Data Packet (Tag 11) [...] - A one-octet field that describes how the data is formatted. where we discussed to add an 'm' format to describe that the content is a MIME message. If you want to indicate that the content is some OpenPGP data you should use the the MIME types "application/pgp-encrypted" etc. along with the above suggested format specifier. You can of course do the same at the outer level. What needs to be changed for this? Updating PGP/MIME to avoid the required multipart/encrypted container is a topic we should discuss. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 14 13:43: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 64D991B2F98 for ; Tue, 14 Apr 2015 13:43:40 -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 JZHFlee-1bQj for ; Tue, 14 Apr 2015 13:43:38 -0700 (PDT) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 8F53F1B2A7D for ; Tue, 14 Apr 2015 13:43:36 -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 mx1.mailbox.org (Postfix) with ESMTPS id C051E4004B for ; Tue, 14 Apr 2015 22:43:34 +0200 (CEST) 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 XVaSsZMl_Z6X for ; Tue, 14 Apr 2015 22:43:33 +0200 (CEST) Message-ID: <552D7BF4.4000203@dominikschuermann.de> Date: Tue, 14 Apr 2015 22:43:32 +0200 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: openpgp@ietf.org References: <87vbh0hthv.fsf@vigenere.g10code.de> <552BFBEB.8040208@dominikschuermann.de> <87bniqej46.fsf@vigenere.g10code.de> <552D6377.1090507@dominikschuermann.de> <87r3rmcvqk.fsf@vigenere.g10code.de> In-Reply-To: <87r3rmcvqk.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Another candidate pgp wg item: Media type 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, 14 Apr 2015 20:43:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/14/2015 10:15 PM, Werner Koch wrote: > On Tue, 14 Apr 2015 20:59, dominik@dominikschuermann.de said: > >> model. So what MIME type should now be used to share this >> encrypted blob? Following the RFC3156 we use >> "application/octet-stream" but that's really unspecific. Recall >> that we are using no ASCII armor here. > > Okay, so your comments are about PGP/MIME. I assumed you were > talking about > > 5.9. Literal Data Packet (Tag 11) [...] - A one-octet field that > describes how the data is formatted. > > where we discussed to add an 'm' format to describe that the > content is a MIME message. Not sure what this has to do with my problem. The Literal Data Packet indicates the type of the data that is inside the encrypted blob not the type of the encrypted blob. The Literal Data Packet together with the actual data is encrypted and can not be accessed before decryption. But yes, this is another problem for us and adding an "m" format together with a MIME type would fix this. So +1 for this. > If you want to indicate that the content is some OpenPGP data you > should use the the MIME types "application/pgp-encrypted" etc. > along with the above suggested format specifier. You can of course > do the same at the outer level. > > What needs to be changed for this? Maybe I misunderstand the RFC3156, but "application/pgp-encrypted" only contains the version number not the encrypted blob. The actual blob is inside "application/octet-stream". Where is it specified that "application/pgp-encrypted" can also directly contain the data? Please point me to the line in the RFC. I think this comes from the fact that RFC3156 only talks about ASCII armored data for email transfer. Regards Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVLXv0AAoJEHGMBwEAASKCuqsIAI6bG709cIIxZHQ153IEHSZ/ icjPVUhi21pMN0SyIZtg+FnzJwPeLlK68e3T8GJ/LMEISHOdvL/2WJDS1AbR1Dgz PHMjFNl14A3CwQ2mMQ8TTbv5tlTf4TeLDYLm4S6T0gmL7ouO248DXLNbEraT/Uu8 7BBXEatWsjHQIxEMTMVeSehnaJYbtToo1AUwxz4nxBRQZWfEYBeDo9HVUtGzvYVH 204LhY4t+2iqkiSDbCzCX0RIc4SlsWjTJ6F4Y/Qy4kgRX0hvONUHXcsALyNkIWAF 1eYta3k25j+vekWz3t+HMTjjredPZ51JA3YylI4SrwsaJwzFxXuW2iNysc7ccmE= =Z5MC -----END PGP SIGNATURE----- From nobody Tue Apr 14 14:01: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 A94291B2FB7 for ; Tue, 14 Apr 2015 14:01:40 -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 vIXLEj7zVYtr for ; Tue, 14 Apr 2015 14:01:39 -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 08D071B2FBC for ; Tue, 14 Apr 2015 14:01:37 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yi7xf-0005BC-DB for ; Tue, 14 Apr 2015 23:01:35 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yi7sk-0000vM-Ao; Tue, 14 Apr 2015 22:56:30 +0200 From: Werner Koch To: Dominik Schuermann References: <87vbh0hthv.fsf@vigenere.g10code.de> <552BFBEB.8040208@dominikschuermann.de> <87bniqej46.fsf@vigenere.g10code.de> <552D6377.1090507@dominikschuermann.de> <87r3rmcvqk.fsf@vigenere.g10code.de> <552D7BF4.4000203@dominikschuermann.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: Dominik Schuermann , openpgp@ietf.org Date: Tue, 14 Apr 2015 22:56:30 +0200 In-Reply-To: <552D7BF4.4000203@dominikschuermann.de> (Dominik Schuermann's message of "Tue, 14 Apr 2015 22:43:32 +0200") Message-ID: <87d236cttt.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] Another candidate pgp wg item: Media type 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, 14 Apr 2015 21:01:41 -0000 On Tue, 14 Apr 2015 22:43, dominik@dominikschuermann.de said: > Where is it specified that "application/pgp-encrypted" can also > directly contain the data? Please point me to the line in the RFC. You are right, it is not formally specified: MIME media type name: application MIME subtype name: pgp-encrypted Required parameters: none Optional parameters: none Encoding considerations: Currently this media type always consists of a single 7bit text string. but I see no strong reason not to use it for amored data unless it is enclosed by multipart/encrypted. We could update rfc-3156 to formally define an OpenPGP container or improve the defintion of this media type. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 14 14:43: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 239FC1A1ADA for ; Tue, 14 Apr 2015 14:43:41 -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 v2m1t6vHUoDi for ; Tue, 14 Apr 2015 14:43:39 -0700 (PDT) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 E47C41A1B92 for ; Tue, 14 Apr 2015 14:43:38 -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 mx1.mailbox.org (Postfix) with ESMTPS id 7EEE8402D6 for ; Tue, 14 Apr 2015 23:43:37 +0200 (CEST) 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 z5bLXcbJyLlY for ; Tue, 14 Apr 2015 23:43:36 +0200 (CEST) Message-ID: <552D8A08.80504@dominikschuermann.de> Date: Tue, 14 Apr 2015 23:43:36 +0200 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: openpgp@ietf.org References: <87vbh0hthv.fsf@vigenere.g10code.de> <552BFBEB.8040208@dominikschuermann.de> <87bniqej46.fsf@vigenere.g10code.de> <552D6377.1090507@dominikschuermann.de> <87r3rmcvqk.fsf@vigenere.g10code.de> <552D7BF4.4000203@dominikschuermann.de> <87d236cttt.fsf@vigenere.g10code.de> In-Reply-To: <87d236cttt.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Another candidate pgp wg item: Media type 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, 14 Apr 2015 21:43:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/14/2015 10:56 PM, Werner Koch wrote: > On Tue, 14 Apr 2015 22:43, dominik@dominikschuermann.de said: > >> Where is it specified that "application/pgp-encrypted" can also >> directly contain the data? Please point me to the line in the >> RFC. > > You are right, it is not formally specified: > > MIME media type name: application MIME subtype name: pgp-encrypted > Required parameters: none Optional parameters: none > > Encoding considerations: > > Currently this media type always consists of a single 7bit text > string. > > but I see no strong reason not to use it for amored data unless it > is enclosed by multipart/encrypted. > > We could update rfc-3156 to formally define an OpenPGP container > or improve the defintion of this media type. Yes we should do that. Again: We need a MIME type for _non_-armored data, so if we would use "pgp-encrypted" we would definitely not follow RFC3156. I am also not convinced that it is a good idea to use "pgp-encrypted" for anything other than the version, it would require a parser to differentiate "pgp-encrypted" with version-only and "pgp-encrypted" with data. So I would propose (following Tim Bray): pgp-message as a new MIME type for data-only. Regards Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVLYoHAAoJEHGMBwEAASKCwiMIAJFqyK5sxXlnfnHO9JAsaZe7 lo4megd3mRVijyT07D9UUOZYjnZZ9RGY3is/dt4dT9rmm/Mgy+Zz6wpth3RMg58v Dsb+fp2SMj1ESF4zCkrwjgtN4NC9F5m4UtLnq9XKvIfEDDrQ+wzUhynOfoRxJAri s5v3qem21j9QQumX5aHqR+byOJZZMSXTrYUKmU3P4VxKAlG+v2FOQFqKL30EwpUq vNz33wocWSja7EJcoJrokW5MjxR981Y/N6lDui0CxHOFJbz/l1HlLjKwOswUn30X pU56gECsco3hBLpr/CnUsjJBlss/lesHo1MaUrPydtUsLjq4zRzPd+WWuwTgtKs= =0ta+ -----END PGP SIGNATURE----- From nobody Tue Apr 14 16:12: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 E88761B3055 for ; Tue, 14 Apr 2015 16:12: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, 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 EQYfP4tcfeqM for ; Tue, 14 Apr 2015 16:12:32 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 27FB01B305B for ; Tue, 14 Apr 2015 16:12:30 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so52675093igb.0 for ; Tue, 14 Apr 2015 16:12:29 -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=P4wN4wJNupLhsOwlqI0tE46V1aUy40JHU3YbBdeeASk=; b=Y2NQF7VMDN7QXXGAOXWZGpY6I4DcC4u0nLjiS1bq2Vo9FwdXIlK1DFplCdgDa0HYMT x/JnsPfBbpIxp9pdVvOeGko6751ejOLRjF8SdTKk7Hc8cthfSowaeNxPxkBtm52uNtQ+ kY+wVpPwuAWiPFq9+vuUhrP4qgHxC01295pAT9DJRFZaQpg+o1yh6086sGL7cYIuQV+h TT5INLbxxWN16u/tEt2pmBRHrHsdV0A/At3W+mx8eajlWLPUuiP2+sy8PwSkTW4h75Eo iPZsnL0u/fD/xMFN1E78OafKp/lzppibmNeNlNxRPhLs3/nbQpwvDUwKFX8bwl724poh D4vg== X-Received: by 10.50.97.41 with SMTP id dx9mr27359979igb.1.1429053149643; Tue, 14 Apr 2015 16:12:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.109.67 with HTTP; Tue, 14 Apr 2015 16:12:09 -0700 (PDT) In-Reply-To: References: From: David Leon Gil Date: Tue, 14 Apr 2015 16:12:09 -0700 Message-ID: To: Ryan Carboni Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , Tom Ritter , IETF OpenPGP Subject: Re: [openpgp] So if we ever did redo the mail system from scratch... 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, 14 Apr 2015 23:12:34 -0000 On Tue, Apr 14, 2015 at 9:26 AM, Ryan Carboni wrote: > Given that everything is in the cloud, it might be best that an email's > contents is not downloaded until a user opens the email. The attachments too > will be opened when a user clicks on it. W.r.t. attachments, this has already largely happened via webmail providers' integration with cloud storage services. Alas -- as Daniel Bernstein has also noted -- sender-stores is in many respects better; but SMTP does not seem likely to go away soon. From nobody Tue Apr 14 17:36: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 DDF7E1AD36C for ; Tue, 14 Apr 2015 17:36: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 9LkjVWlJ1wdn for ; Tue, 14 Apr 2015 17:36:14 -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 8EB9A1ACE9D for ; Tue, 14 Apr 2015 17:36:13 -0700 (PDT) Received: by laat2 with SMTP id t2so21068273laa.1 for ; Tue, 14 Apr 2015 17:36:12 -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=J5+wT72dAAPZ1TGVA8R9uYFZM1eoTUyR98isnLXfctM=; b=0KN1Tnv9OmpymkrEATxHGOuqU6GiPIPUKW/6laqcF/iHFgnPyp6eVdwkL1Te0NhjR/ xgAKGwvSKEp/Wnf68mwSD7KUko4h0+uKnOw405lnts3Huu+X3htduDdzxw3GVT5IN9RJ m2W2T7Elv+MbMWWIlvyxTXp9CvYvvRAG+lp9ORFOI0ga3H901tMidvb5i/jSct9ayYeY ToOzX3m0Ad3YOmYp6vUbQrxoYAuIR2QZDFi0ydAgB9SqrOQoP/EfrFmpEvv3DFq0r4zq 80sfC70PvF5kt2cG6o4xJVAr6c9shvnHxPoTm/B0OSBFqBztRCTNLXgvDWTDhYJXg8CP TWvA== MIME-Version: 1.0 X-Received: by 10.112.198.225 with SMTP id jf1mr20777345lbc.91.1429058172109; Tue, 14 Apr 2015 17:36:12 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Tue, 14 Apr 2015 17:36:11 -0700 (PDT) In-Reply-To: <552C03CF.3020001@iang.org> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <87sic4jwzx.fsf@vigenere.g10code.de> <1428939645.12460.1.camel@scientia.net> <552C03CF.3020001@iang.org> Date: Tue, 14 Apr 2015 20:36:11 -0400 X-Google-Sender-Auth: 1HOk-oEvNjttDW5sDoKpCHNePz0 Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 00:36:15 -0000 On Mon, Apr 13, 2015 at 1:58 PM, ianG wrote: > On 13/04/2015 18:32 pm, Phillip Hallam-Baker wrote: > >> Given the way fingerprints are used, there is an intense pressure to >> use a single algorithm for everything. That is why I think that we >> should pick either SHA-2-512 or SHA-3-512 and truncate as necessary. > > > > If SHA-2-512, then I'm happy to truncate as necessary. > > If SHA-3, it is a sponge function internally so it is designed to do the > "truncation" or rather "expansion" already and it'd be a shame not to use > that feature directly. It makes no difference to the security and requires specific features most libraries are unlikely to support. Digging in to the internal functions of crypto algorithms is very much to be avoided. Besides which, it loses the convenience of small fingerprints being the first few digits of a long one. From nobody Tue Apr 14 18:36: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 330251B2B3E for ; Tue, 14 Apr 2015 18:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 lJ-bX4oRXPoe for ; Tue, 14 Apr 2015 18:36:30 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id B50001B2B3A for ; Tue, 14 Apr 2015 18:36:29 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 664C711C16EA for ; Wed, 15 Apr 2015 11:36:28 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AzDgL1sESSV8 for ; Wed, 15 Apr 2015 11:36:22 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 72F2111C16E8 for ; Wed, 15 Apr 2015 11:36:22 +1000 (EST) Message-ID: <552DC08B.60700@adversary.org> Date: Wed, 15 Apr 2015 11:36:11 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pDejOund6RBlw3ewC6xdahm0H47X95Q4r" Archived-At: Subject: Re: [openpgp] So if we ever did redo the mail system from scratch... 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, 15 Apr 2015 01:36:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pDejOund6RBlw3ewC6xdahm0H47X95Q4r Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/04/2015 11:59 pm, Phillip Hallam-Baker wrote: > > OK so like most folk, I see no point in redoing the mail system. Or > rather I didn't till I sent a message without an attachment. Then it > hit me. There is only one feature that is powerful enough to justify > a whole new mail protocol and it is the ability to change a message > after it is 'sent' but before it is read. For all of SMTP's faults, and there are many, not adjusting for user error in hitting "send" at an inappropriate juncture is *not* amongst them. The recall or burn option included in some email servers (e.g. MS Exchange) is not something worth encouraging. In part, as others have said, because it relies upon the complicity of the receiving server, but also because it lends itself towards abuse. The classic case (and I have seen this in action) is a manager of some company issuing an instruction to a subordinate, subsequently deleting the message and the subordinate left carrying the can regarding an action which was apparently "unauthorised". If a feature of your mail system can get someone fired, or even jailed, then that's not a feature - it's a law suit in waiting. > Implementing this would require a complete break with SMTP. Well, SMTP is certainly living up to its name in application: it is simple. Regards, Ben --pDejOund6RBlw3ewC6xdahm0H47X95Q4r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVLcCWAAoJEH/y03E1x1U8MgYMAKL1AZLU20f92pNCpROEWwOc nyQPL0H5RY8W6oKxzh9Nosr7Z6XHpHp8ysfYlI0KWkq9ye8l+Na58UrSyvZWD5Wg /1wYP8jEeDpjzls8n4L5Sx4pplcfoA+rfQPpPXkVgYMMy1kTjYBvLYF3431Ypxt6 W9ToE4UfyetrVSfoo4PkyLl7YOY9PQd5hFTHUpyslkskSf3f/5qS/MeEKe2joHI4 yGlTzPhR0Hlq6VAta7AtYjBEiFhTjTl1p2rZ+mcP7Pj20PfSrTDVROy24rtu8r/u fvQWa86Hl3SEIq2WJoOZCCqn/DsSJ6nnB3gP51IV56VKoGJkgF+TKkHhfU6NYte1 a+6Gal8Hpiz02Yl+ohjCQKhvTBFveMSTTDVvDZ3/ST0EyqN30SWFf2kmXV05jnd+ fUC2leN7JNYd5XH/uNZupd3bbT90WzZ6OO8dtoMdE2zTpcZMj40nqiCIj2A/86Xr Y09nCZ7LtmImPvXZY8rww6nbq163XBxTtp43ckPNvw== =f2RN -----END PGP SIGNATURE----- --pDejOund6RBlw3ewC6xdahm0H47X95Q4r-- From nobody Tue Apr 14 23:41: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 D83D81B29A7 for ; Tue, 14 Apr 2015 23:41:39 -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 RTNodSu_drpG for ; Tue, 14 Apr 2015 23:41:38 -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 CE4041A88A1 for ; Tue, 14 Apr 2015 23:41:37 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YiH0y-0006o5-0G for ; Wed, 15 Apr 2015 08:41:36 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YiGvs-0002aX-Vq; Wed, 15 Apr 2015 08:36:21 +0200 From: Werner Koch To: Dominik Schuermann References: <87vbh0hthv.fsf@vigenere.g10code.de> <552BFBEB.8040208@dominikschuermann.de> <87bniqej46.fsf@vigenere.g10code.de> <552D6377.1090507@dominikschuermann.de> <87r3rmcvqk.fsf@vigenere.g10code.de> <552D7BF4.4000203@dominikschuermann.de> <87d236cttt.fsf@vigenere.g10code.de> <552D8A08.80504@dominikschuermann.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: Dominik Schuermann , openpgp@ietf.org Date: Wed, 15 Apr 2015 08:36:20 +0200 In-Reply-To: <552D8A08.80504@dominikschuermann.de> (Dominik Schuermann's message of "Tue, 14 Apr 2015 23:43:36 +0200") Message-ID: <87zj69c2zf.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] Another candidate pgp wg item: Media type 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, 15 Apr 2015 06:41:40 -0000 On Tue, 14 Apr 2015 23:43, dominik@dominikschuermann.de said: > So I would propose (following Tim Bray): pgp-message as a new MIME > type for data-only. To be used for binary OpenPGP data so that standard MIME encoding can be used? Not distinguishing between signed and encrypted data is okay because that avoid conflicts between the MIME type and the actual OpenPGP message type. What about keys? Should they also be allowed in pgp-message? I tend to say no. However 7. Distribution of OpenPGP public keys Content-Type: application/pgp-keys Required parameters: none Optional parameters: none A MIME body part of the content type "application/pgp-keys" contains ASCII-armored transferable Public Key Packets as defined in [1], section 10.1. which is unfortunate because it requires armored data and thus the standard MIME encoding can't be used. Add an "application/pgp-keydata" ? Along with the removal of the micalg parameter this could be part of 3156bis or another RFC to extend 3156. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 15 02: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 D621E1B33A3 for ; Wed, 15 Apr 2015 02:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 g8yS8xooPLVK for ; Wed, 15 Apr 2015 02:13:55 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 311041B33AA for ; Wed, 15 Apr 2015 02:13:50 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 2011F11C189F for ; Wed, 15 Apr 2015 19:13:49 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UqmxP5RX1qWb for ; Wed, 15 Apr 2015 19:13:37 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 4DFE311C189E for ; Wed, 15 Apr 2015 19:13:37 +1000 (EST) Message-ID: <552E2BC0.9020908@adversary.org> Date: Wed, 15 Apr 2015 19:13:36 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <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> <87mw2i28nr.fsf@vigenere.g10code.de> <87vbh6zqsy.fsf@vigenere.g10code.de> In-Reply-To: <87vbh6zqsy.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KJ7KIgAsQixVf5loa2PG3OkcU9elfk6SQ" Archived-At: Subject: Re: [openpgp] OpenPGP private certification 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, 15 Apr 2015 09:13:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KJ7KIgAsQixVf5loa2PG3OkcU9elfk6SQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/04/2015 11:35 pm, Werner Koch wrote: > On Wed, 8 Apr 2015 15:05, phill@hallambaker.com said: >=20 >> My point here is that if we want to get a billion people using >> encrypted mail then it has to offer iPhone class usability, not OK for= >> 1990s usability. >=20 > If that is the goal you only need to care about 140 character messages > or other useless status messages ;-). Drop SMS in favour of MMS and use that to sent ASCII-armoured OpenPGP messages. TextSecure? Yes *and* no ... > Actually I prefer 1990s use of mail instead of todays 50% of mails are > going through Compuserve^WGmail. But yeah, I am on a lost position wit= h > that. Oh god ... that's so accurate (at least they're not AOL, though). >> There are plenty of ways that the scheme could be fixed. Since key >> server enrollment can be made automatic, it would be pretty easy to >> renew the enrollment once every n months and discard keys that have >=20 > It is about mail. Mail addresses are defined by the DNS. Bind the > keys to the DNS and your are done. This needs support from the mail > providers, though. TXT records, just as was done with SPF before it was adopted as a standar= d. Though it would be nice to be able to set: IN PGPKEY "ben: 0x321E4E2373590E5D" IN PGPFPR "ben: DB47 24E6 FA42 86C9 2B4E 55C4 321E 4E23 7359 0E5D" IN PGP "Catchall: " Get around that with TXT records and prepend the response value with what you'd eventually want adopted as DNS records. > I doubt that we will be able to deploy a large, encrypted, anonymous, > and decentralized mail network unless we can build upon a transport > layer to solve the basic problems of todays Internet. For now we need > the help of some central services to get things going. Erm, there was a post to gnupg-users last month which proposes a method of doing something which is very close to that. The confidantmail.org thing (which already proposes using DNS TXT records for key ID listings). It's pseudonymous rather than anonymous, but the only pseudonym required is the key ID/fingerprint of any given key. Everything else is arbitrarily assigned (and uses freeform UIDs). Actually, Phillip, that thing is probably right up your alley given some of the other SMTP related posts around here, you should definitely go and play with it. >> Having the key servers continue to regurgitate false or stale data >> forever because there is no way to stop them does not seem like an >> acceptable plan to me. >=20 > Think of signature verification. It should work even after a mail/key > association has been disolved for example after a provider change. Right and all you need to do to prove the current key ID associated with an email address is to use the PGP Global Directory Verification Key. The stale data won't gain signatures like that. The Hushmail keyserver will provide a similar verification (and limits one key ID per UID email address, but does not limit the number of UIDs associated with a key ID). > I agree that this is onluy a problem for a smaller group but this is > something a keyserver network can be useful even after the migration > of the public key store from keyserver to more controlled service > (DNS, Web, whatever). Deleting keys from the keyservers is thus not > going to work. Besides, even if you did delete a key (and even if it was your own), there's very little preventing someone else re-uploading it. This is clearly illustrated by the signature on my key made last June by key ID 0x46406269AA2F6FBE. The exception bing the Hushmail key server, which throws a fit if you want to update to a new key (it can only be done by contacting them directly and getting it changed manually, but that's the only way to get Hush users to be able to natively encrypt to you or verify your signatures). Anyway, we've all made the error of forgetting a passphrase and being unable to revoke a key when we might want to. It's what taught us to remember the current passphrases (why do you think I got into the habit of signing by default, initially it was so I'd remember the passphrase and now it's just a good habit). As for the keys which taught me that lesson, well, I eventually did remember the passphrase =2E.. a mere fourteen and a half (14.5) years later, so they got to sign the current key before being revoked. Yes, there are some annoyances, but really those are a small price to pay to prevent having your key arbitrarily removed by a particularly determined adversary. Imagine, for a moment, if Glenn Greenwald and Laura Poitras had had their keys arbitrarily removed from all keyservers back in 2011 in response to certain WikiLeaks publications and articles ... or worse, replaced. At the very least the CitizenFour documentary wouldn't've happened and at worst, well, we'd all still be making oblique references to ECHELON instead of PRISM. It'd be like living in a world where NCIS dictated reality and while Mark Harmon portrays droll, dry humour well enough; that is nowhere near enough to justify an existence like *that*. Not to mention accepting NIST recommendations at face value ... See, there's a scary side to everything. You're welcome. ;) Regards, Ben --KJ7KIgAsQixVf5loa2PG3OkcU9elfk6SQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVLivAAAoJEH/y03E1x1U8ZLAMANpXIytBeAyFiHoNlqXbSM+x btPf9z30YRkEugUfGLdOQl3HkbX7nDDITRWzRNoHVU6mH3nRKkboPMOlhoPov5RM Vd4ISINw67Ct2eEDcAhDNQQ2iqCm9F0gBliK+mXpAsrNsRzWkaR0iNaQMFYkYHsu 6yd2EktlbRGKxjaCA6WbJN8zJZLvOzE4uG2OKMsN3T/FwGGZXlOgriqlLy9Yzhei 0HdndF2aLsEXYq5Gh+omQPGJRb2GC/U0WoIVaS9U9oW8VI442qnJ5S5cWkeHol9E 8uCoW12l/h/Gum48u5Ge9n0nKpW1xP849lWH2A7eNjyCpyUQ6AReQx4Tzascppvx iiuVG+vm1++Fh5q2D+3oKOpN+3t2dW32Q4zSEMnt/Cg/EZdQiQLKETBoR2CcOmFf IAW0c0v/ZZIOJGviCxSM6Ka5UDbKCk58atMu8suFssr5ZpIUw3eWhKelinit6dGA jyDtLbZuLc3X1MPSZNhXLCrICxyHnKrI6MbSFmQlvg== =5d19 -----END PGP SIGNATURE----- --KJ7KIgAsQixVf5loa2PG3OkcU9elfk6SQ-- From nobody Wed Apr 15 06:38: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 109F21B34DC for ; Wed, 15 Apr 2015 06:38:30 -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 wJuRkCx81DSA for ; Wed, 15 Apr 2015 06:38:28 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id C91641B34DE for ; Wed, 15 Apr 2015 06:38:20 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 00DCEF2127; Wed, 15 Apr 2015 13:38:19 +0000 (UTC) Date: Wed, 15 Apr 2015 08:38:18 -0500 From: Stephen Paul Weber To: Stephen Farrell Message-ID: <20150415133818.GH3106@singpolyma-liberty> References: <5527B621.3040104@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QRj9sO5tAVLaXnSD" Content-Disposition: inline In-Reply-To: <5527B621.3040104@cs.tcd.ie> 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] details of 4880bis work 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, 15 Apr 2015 13:38:30 -0000 --QRj9sO5tAVLaXnSD Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >g) remove compression entirely Is the idea that compression can be handled by another format (xz, probably= )=20 and from the OpenPGP perspective it's just "binary"? I guess there's not= =20 much downside here when the content was going to be binary anyway, but for= =20 text content it means you need something beyond just an OpenPGP=20 implementation to extract the text (if it is going to be compressed). --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --QRj9sO5tAVLaXnSD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVLmnKAAoJENEcKRHOUZzeoMEP/2UosjBp0Rr/RFIm7PWJ3ycY lfuFBEkkny0adUFCEYzmGIcZCZrns1mZDa5cLZ77HH7MJG6WtS7r6BBz6cg3vNU/ FnLjgptpfOrZTmt873X8N0trOb8TYd01JW41+KkzpkFsf5TWfww9XgRumQzLZa+h +j8YSSF+agfxS2pEkX7ePR3TwxPDysYTjF1MmZY+vbMku27GDioZbc3B4nxRqVUf MbCjnowHlaVb7t2kdn/gwj7119G/0CjGaRS0lXoZ+XId1WIMXIT8mXCs1kdqd6iF E4l71rEUldkNOurY/L8LABt5rwXcyeNjGvcUzz0YNIr4fthSM8QFvpfcbJlphpGf a2Cqq32J8YuG0UK76ErOxzejq4bgWEWwFWc0qZ2K78JAeoL/VPToCgCZzTHblksY n0Vnel4znpSnogIIfk2/peD1oP8zN0Jm9lXbGAb89820mEY/cK3zZ93se7XdO8qG +2dg/lbxpH5+yNk+yE8K+KArnRyfPFY/V3G/U6DUtZgeK1qme2ngpDS9rE1m/dih 2sk5sClU8OjA1cjZu+wAtY4L/SB6nUfBBRobDIZIZiApp99OPFIGYv+JUg4Z3XKs oo8fXo+NhNVXUDiIGBkIdtKXseIcKy0bl5xoTO8rfkI7ZNbHWhfFbxv3/35gz5nK q40hJ8EN+hB/Gicd7vrq =mM8H -----END PGP SIGNATURE----- --QRj9sO5tAVLaXnSD-- From nobody Wed Apr 15 06:51: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 41F1C1A923E for ; Wed, 15 Apr 2015 06:51:09 -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 XIZY7V9P-oUg for ; Wed, 15 Apr 2015 06:51:07 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id C81F61B3495 for ; Wed, 15 Apr 2015 06:51:07 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 5C700F2127; Wed, 15 Apr 2015 13:51:07 +0000 (UTC) Date: Wed, 15 Apr 2015 08:51:05 -0500 From: Stephen Paul Weber To: Phillip Hallam-Baker , Stephen Farrell , "openpgp@ietf.org" Message-ID: <20150415135105.GJ3106@singpolyma-liberty> References: <87y4m0ozlt.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wULyF7TL5taEdwHz" Content-Disposition: inline In-Reply-To: <87y4m0ozlt.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: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 13:51:09 -0000 --wULyF7TL5taEdwHz Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Somebody claiming to be Werner Koch wrote: >On Fri, 10 Apr 2015 15:23, phill@hallambaker.com said: > >> There is no need to have an algorithm field, a version field is >> sufficient because we should only be using one algorithm at a given > >Right. However an algorithm field is as good as a version field because >they have the same purpose in this context. An algorithm field saves us >a mapping to the actual algorithm. Recall that OpenPGP uses an >one-octet indentifier and not an OID. And it could save specifying versions somewhere seperately from the=20 algorithm identifiers that already exist. --wULyF7TL5taEdwHz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVLmzJAAoJENEcKRHOUZze97kP/ApptRzOnrzgigWoHDXckfTW tRjYl1mgi3fW4vZ8o33L/1gsQeMiSeiRLQg8tREWSEuNlMaP3mM2OaYcos8AhOJW WMxo5QEJB9MIbdVn1pjkRUkIzZnvm4huAK3mVq4TSIwOXZnmvkyLcKHeXEqBt7EY eFcLBywcgwddv/Y3WvpXXL6EgehMpbY45OFkNbXZ1NP+a9QCNrMAp8SM5HN5iok5 8qCU2e4EWQieSEwT/+NE+XjQmNzg5IXmdIDAFxyE67bhkYu5MSKEWMAh+3iHoqVy LsOJ2xLRJgkJ/LoEkJWuU8CS9rydLclyCL4VOyNNW6v5zKz71M7hwiXnrzDKGwnn pMGxnAuwjkVpqFgZosHkmTB0m7DdWdcKl4fFC9icbrtdyW1hDQZ7tPdoKt+ed5jJ bGK2HVebjN7jL883G/uPCDhIV66NBgsdBNeEhc49b6RyZExDDUlkjaW5d0wZU5oa kt6HOuEgnYnIdpJOggWS0iaQ+iwgavmzTvENzDdwxm0yjM1wEm2DuLED4oqHMTMS LdAyHoWH0NrMpn9RQR+f4rcmbMwB0AvlYKrchekIdmiDJSsjLZnAFeViRTe1wgpR aei7/WrL0a9puRGROv4TX58FbTHHO8onKN62zq/xbi9M9DIKzfo3mcD6J8zC//KV G93dOdtZXeLUYjef4KH8 =WGR4 -----END PGP SIGNATURE----- --wULyF7TL5taEdwHz-- From nobody Wed Apr 15 09: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 55D3A1B3620 for ; Wed, 15 Apr 2015 09:40:10 -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 qGiEf7dre6V8 for ; Wed, 15 Apr 2015 09:40:06 -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 91E581B361B for ; Wed, 15 Apr 2015 09:40:05 -0700 (PDT) Received: by labbd9 with SMTP id bd9so37164302lab.2 for ; Wed, 15 Apr 2015 09:40: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=r7ES6Hl/hO2oxRTa8a4Jxih8YEdoCcvSx0c5Y+saZCs=; b=p/m04vXOY4/krYuTNN4aw7/3Px9qFbraedkEQ0NLRkpqOqS0bxZ78uPsZU4oNoElSn zlkkhO10OWFZTffP4mjkNwsZeDftx3EQIJIt9IdcUQy9RFI3m8k/5RoEiW8Kl5nLRZNG llz+O/+DgTM9VmKzPAo+AS7LG0F2xOKtl7B1x40CLFcPW7R1yQAYB5ji7XR9+4hxb0l+ lYwIOF7W9SEpeifqDIAz2+Rt9Ly077S8itRZudHr6+18GJRxpj2BoF4DfCTlNJVJ2UmW 5+g245COUNfvt8ZTC8z3InyypG7d7Z4NfQsNcRFO95BDR4hH4QqnA9behSBuC6koVBSD m25g== MIME-Version: 1.0 X-Received: by 10.112.42.233 with SMTP id r9mr25185726lbl.58.1429116004048; Wed, 15 Apr 2015 09:40:04 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 15 Apr 2015 09:40:03 -0700 (PDT) In-Reply-To: <20150415135105.GJ3106@singpolyma-liberty> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> Date: Wed, 15 Apr 2015 12:40:03 -0400 X-Google-Sender-Auth: Y3X7iDODi9-uTQwSB93j-f9u9k8 Message-ID: From: Phillip Hallam-Baker To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Stephen Farrell Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 16:40:10 -0000 A while back, Stephen and I and some others worked on the 'ni' scheme which is 'naming things with hashes': https://tools.ietf.org/html/rfc6920 Now I don't suggest we adopt that approach directly for PGP. But I do wonder why we assume that the only thing it makes sense to name in this way is going to be a public key. Hashes are really flexible and they are simple to implement. That is not true of any PKI, PGP included. So signing binary applications with PGP is not necessarily a substitute for having a fingerprint of that application. The same is true when we are dealing with attachments in many cases. Which got me thinking, why not leverage MIME content types and make them a part of the fingerprint scheme? fingerprint = "application/pgp-key-binary:" + fingerprint = "application/pkix-keyinfo:" + fingerprint = "application/trans-log:" + or: fingerprint = "application/java:" + fingerprint = "application/cli:" + fingerprint = "application/zip:" + One of the major advantages of this scheme is that if we were to decide on a future PKI where all the data structures were encoded in JSON or XML or whatever, we can use the same scheme without having to revise the version number at all. Verifiers need to know what they are verifying of course. But that is usually obvious from the context and is easily specified in any situation where it isn't. The impact of this approach on PGP is almost nothing. All it means is you have to push the string "application/pgp-key-binary:" or whatever through the hash before the data. We are certainly going to change the algorithm. So this is not breaking backwards compatibility. Making this a fixed string rather than a header eliminates the need for canonicalization and stops people turning this into a Christmas tree for their favorite hacks. I am also thinking that overloading the hash registry is a really bad idea. To be useful, fingerprints really need to be as consistent as possible. It is really desirable that everyone uses the same algorithm (with possibly different truncation lengths). 32 different possible values is probably enough and consumes one character in Base32. We might want to choose a memorable character (P, X, Q, whatever). I am assuming a base of 0. Using truncation rather than the 'spongeworthy' property of SHA3 means that it is obvious at a glance that the following all relate to the same thing: 95 bit strength: AFRTK-NJSMF-STOMR-WG5ST-ONZXGA 145 bit strength: AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T 195 bit strength: AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM 245 bit strength: AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM-YHE4T-SYJQM 95 bits is arguably borderline for a fingerprint but it is about the limit of what can be fitted onto a business card. Now lets imagine that I have someone's business card in front of me and I try to send them an email that I really want to be sent encrypted and the machine comes back telling me it has verified the sender key as AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM-YHE4T-SYJQM. I can look at the card and quickly see that the first five blocks are correct and lock this into my personal key store. Given timing, I suggest we define code points for BOTH the SHA-2-512 and SHA-3-512 algorithms now and decide which to make mandatory at a later date. We should have exactly one mandatory algorithm and exactly one backup for all crypto algorithms. From nobody Wed Apr 15 10:51: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 2ECD11A01F4 for ; Wed, 15 Apr 2015 10:51:40 -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 Z8LNQNbD4rkL for ; Wed, 15 Apr 2015 10:51:38 -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 4E1571A011D for ; Wed, 15 Apr 2015 10:51:38 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YiRTM-0002Fw-N3 for ; Wed, 15 Apr 2015 19:51:36 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YiRQg-00054N-Gt; Wed, 15 Apr 2015 19:48:50 +0200 From: Werner Koch To: Stephen Paul Weber References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@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 Mail-Followup-To: Stephen Paul Weber , Stephen Farrell , "openpgp\@ietf.org" Date: Wed, 15 Apr 2015 19:48:50 +0200 In-Reply-To: <20150415133818.GH3106@singpolyma-liberty> (Stephen Paul Weber's message of "Wed, 15 Apr 2015 08:38:18 -0500") Message-ID: <878udt9ta5.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" , Stephen Farrell Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 15 Apr 2015 17:51:40 -0000 On Wed, 15 Apr 2015 15:38, singpolyma@singpolyma.net said: >>g) remove compression entirely > > Is the idea that compression can be handled by another format (xz, > probably) and from the OpenPGP perspective it's just "binary"? I I guess so. However I see a problem with the removal of compression: Almost all keys have preferences for compression and most messages are using compression. Thus all implementations will need to keep on supporting de-compression which is actually the more complicated part. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 15 11:28:18 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 29B3D1A036B for ; Wed, 15 Apr 2015 11:28:17 -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 oZKkCYpCaHLM for ; Wed, 15 Apr 2015 11:28:15 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 25BAE1A0169 for ; Wed, 15 Apr 2015 11:28:15 -0700 (PDT) Received: by oift201 with SMTP id t201so35965020oif.3 for ; Wed, 15 Apr 2015 11:28:14 -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=EBli0hcyfSX5cpmyApzY/CYJu5uYMBV/Z8Rkyr285w0=; b=BtAkwNUeunFoK7JnL/LwBZ/ijn2x2nqCjgHYemyvW49VQsaDcVSpV6IuNVT0NHMsB4 f2pnHtvmAML+7wLE6yBK8oBN6HgxRZSRdr05uxjry5D5ZnS0WG1OtP5aQgouuw31+Fbw Go4JjgBnUf+ghhW4HxF8PGD+jS9bG9spdGzSoCL81JCztPV7LCvTrIie+dz3SZsX/8gH GoSBxyNt6VI4GewgJa8RH+yGfD9VmPs9gzoRZ0loBdJVpePw+xT6wDG2CAa49Vym2kla W+u4gNPk2jtO72LdT1sIlK8N/AKy11U5pIP9j4v1fs7d3qfHexh+r5yj9wS+Mr9r76ls zs9Q== X-Received: by 10.107.46.155 with SMTP id u27mr9278410iou.87.1429122494555; Wed, 15 Apr 2015 11:28:14 -0700 (PDT) MIME-Version: 1.0 References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@singpolyma-liberty> <878udt9ta5.fsf_-_@vigenere.g10code.de> In-Reply-To: <878udt9ta5.fsf_-_@vigenere.g10code.de> From: Wyllys Ingersoll Date: Wed, 15 Apr 2015 18:28:13 +0000 Message-ID: To: Stephen Paul Weber , Stephen Farrell , "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=001a113ac5b6a0ead10513c782e4 Archived-At: Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 15 Apr 2015 18:28:17 -0000 --001a113ac5b6a0ead10513c782e4 Content-Type: text/plain; charset=UTF-8 Can someone explain the reasoning behind deprecating compression ? Im neutral on the idea, just trying to understand the benefits of getting rid of it beyond simplifying the processing of the packets. On Wed, Apr 15, 2015 at 1:51 PM Werner Koch wrote: > On Wed, 15 Apr 2015 15:38, singpolyma@singpolyma.net said: > >>g) remove compression entirely > > > > Is the idea that compression can be handled by another format (xz, > > probably) and from the OpenPGP perspective it's just "binary"? I > > I guess so. > > However I see a problem with the removal of compression: Almost all keys > have preferences for compression and most messages are using > compression. Thus all implementations will need to keep on supporting > de-compression which is actually the more complicated part. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a113ac5b6a0ead10513c782e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Can someone explain the reasoning behind deprecating c= ompression ?=C2=A0 Im neutral on the idea, just trying to understand the be= nefits of getting rid of it beyond simplifying the processing of the packet= s.




On Wed, Apr 15, 2015 at 1:51 PM Werner Koch <wk@gnupg.org> wrote:
On Wed, 15 Apr 2015 15:38, singpolyma@singpolyma.net said:
>>g) remove compression entirely
>
> Is the idea that compression can be handled by another format (xz,
> probably) and from the OpenPGP perspective it's just "binary&= quot;?=C2=A0 I

I guess so.

However I see a problem with the removal of compression: Almost all keys have preferences for compression and most messages are using
compression.=C2=A0 Thus all implementations will need to keep on supporting=
de-compression which is actually the more complicated part.


Shalom-Salam,

=C2=A0 =C2=A0Werner

--
Die Gedanken sind frei.=C2=A0 Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a113ac5b6a0ead10513c782e4-- From nobody Wed Apr 15 11:43: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 EEF671A1A68 for ; Wed, 15 Apr 2015 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 85R0S_QYF-VO for ; Wed, 15 Apr 2015 11:43:22 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 273FB1A1A4D for ; Wed, 15 Apr 2015 11:43:22 -0700 (PDT) Received: by qku63 with SMTP id 63so98127095qku.3 for ; Wed, 15 Apr 2015 11:43:21 -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=sves6xrMR4QuWfa0pJJ4w2BLWmq5kNkfKbTtsPztJjA=; b=ooCEKJP42RNOjIxy9uEus8P3+mYklSqjCITWfvVuY7myHzjGzxhe5G7wNzlVxJPAvF vbrruUuP2cBj2sMRmmOVXkGkw7+4NRRwjICUte+yOkE3hlAobhaG5hhzy+/wUnaEV0jY p49H7iwUZPuBxaaF3mhVPNJ4829borbnaAGNbehs4H42x1MAtqs7xRUbHNtuN2rSCWY6 SBcweZvVIUFqgfyNfcVqYujyyUOuv6ecyrX6Q+/qr39x5bI+/5p6c1OTHQaT0ic4PIxR JyEPJt1pnAT7LHetcs7KCipjv9VLz1dm/2NJJSULMesTb/BU6nCA4mkdP7Ui0aOywP0F jsDg== X-Received: by 10.140.18.238 with SMTP id 101mr31955414qgf.101.1429123376727; Wed, 15 Apr 2015 11:42:56 -0700 (PDT) Received: from [10.238.41.140] (mobile-107-107-57-29.mycingular.net. [107.107.57.29]) by mx.google.com with ESMTPSA id 97sm3742372qkp.39.2015.04.15.11.42.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Apr 2015 11:42:55 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B5901A90-D142-45BF-987A-95AF4B892FCD Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPhone Mail (12B436) In-Reply-To: Date: Wed, 15 Apr 2015 14:42:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7D0F07E5-729B-41BF-82B1-99C443B90C27@gmail.com> References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@singpolyma-liberty> <878udt9ta5.fsf_-_@vigenere.g10code.de> To: Wyllys Ingersoll Archived-At: Cc: Stephen Paul Weber , "openpgp@ietf.org" , Stephen Farrell Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 15 Apr 2015 18:43:25 -0000 --Apple-Mail-B5901A90-D142-45BF-987A-95AF4B892FCD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Compression provides an oracle for the plaintext Sent from my difference engine > On Apr 15, 2015, at 14:28, Wyllys Ingersoll wrote: >=20 >=20 > Can someone explain the reasoning behind deprecating compression ? Im neu= tral on the idea, just trying to understand the benefits of getting rid of i= t beyond simplifying the processing of the packets. >=20 >=20 >=20 >=20 >> On Wed, Apr 15, 2015 at 1:51 PM Werner Koch wrote: >> On Wed, 15 Apr 2015 15:38, singpolyma@singpolyma.net said: >> >>g) remove compression entirely >> > >> > Is the idea that compression can be handled by another format (xz, >> > probably) and from the OpenPGP perspective it's just "binary"? I >>=20 >> I guess so. >>=20 >> However I see a problem with the removal of compression: Almost all keys >> have preferences for compression and most messages are using >> compression. Thus all implementations will need to keep on supporting >> de-compression which is actually the more complicated part. >>=20 >>=20 >> Shalom-Salam, >>=20 >> Werner >>=20 >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >>=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 --Apple-Mail-B5901A90-D142-45BF-987A-95AF4B892FCD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Compression provides an oracle for the= plaintext



Sent from my difference engine

On Apr 15, 2015, at 14:28, Wyllys Ingersoll <= wyllys@gmail.com> wrote:

<= /div>

Can someone explain= the reasoning behind deprecating compression ?  Im neutral on the idea= , just trying to understand the benefits of getting rid of it beyond simplif= ying the processing of the packets.




On Wed, Apr 15, 2015 at 1:51 PM Wer= ner Koch <wk@gnupg.org> wrote:
=
On Wed, 15 Apr 2015 15:38, singpolyma@singpolyma.net sa= id:
>>g) remove compression entirely
>
> Is the idea that compression can be handled by another format (xz,
> probably) and from the OpenPGP perspective it's just "binary"?  I<= br>
I guess so.

However I see a problem with the removal of compression: Almost all keys
= have preferences for compression and most messages are using
compression.  Thus all implementations will need to keep on supporting<= br> de-compression which is actually the more complicated part.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
openpgp mailing list
openpgp@ietf.org = https://www.ietf.org/mailman/listinfo/openpgp
____________________= ___________________________
openpgp mailing list
<= span>openpgp@ietf.org
https://www.ietf= .org/mailman/listinfo/openpgp
= --Apple-Mail-B5901A90-D142-45BF-987A-95AF4B892FCD-- From nobody Wed Apr 15 12:11: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 E38711A6FF7 for ; Wed, 15 Apr 2015 12:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 EMxRnmVrWzvW for ; Wed, 15 Apr 2015 12:11:16 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id D6E801A8851 for ; Wed, 15 Apr 2015 12:11:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 4DA9F700DFFE for ; Wed, 15 Apr 2015 12:11:15 -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 d-771s-J8buo for ; Wed, 15 Apr 2015 12:11:14 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 29CAB700DFE1 for ; Wed, 15 Apr 2015 12:11:14 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 15 Apr 2015 12:11:14 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 15 Apr 2015 12:11:14 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <20150415135105.GJ3106@singpolyma-liberty> Date: Wed, 15 Apr 2015 12:11:13 -0700 Message-Id: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> To: "openpgp@ietf.org" X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 19:11:19 -0000 There was a proposal that floated around that defined an extended = fingerprint to be an algorithm number followed by the actual bits. For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary = representation. There's an obvious way to truncate that as well -- just = decide if you truncate little-endian or big. (Personally, despite being = a little-endian bigot, this is a place where network byte order is even = to me the obvious win.) The major advantage of this is that you can define it and then you never = have to change it again. We don't have to have any arguments over what = hash function is proper to use, etc. An implementation can decide to = support or not support whatever. Jon From nobody Wed Apr 15 13:04: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 890E41A1A24 for ; Wed, 15 Apr 2015 13:04:29 -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_05=-0.5, 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 sxWJxs951ZJI for ; Wed, 15 Apr 2015 13:04:27 -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 60F2F1A1A22 for ; Wed, 15 Apr 2015 13:04: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 mailgw02.dd24.net (Postfix) with ESMTP id 633E95FB70 for ; Wed, 15 Apr 2015 20:04:25 +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 13ZapjRKQWvb for ; Wed, 15 Apr 2015 20:04:23 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 15 Apr 2015 20:04:23 +0000 (UTC) Message-ID: <1429128262.1702.41.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Wed, 15 Apr 2015 22:04:22 +0200 In-Reply-To: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-RgT/b3kjLPu5Wxc1g+V5" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 20:04:29 -0000 --=-RgT/b3kjLPu5Wxc1g+V5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-15 at 12:11 -0700, Jon Callas wrote: > There was a proposal that floated around that defined an extended > fingerprint to be an algorithm number followed by the actual bits. > For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary > representation. There's an obvious way to truncate that as well -- > just decide if you truncate little-endian or big. (Personally, despite > being a little-endian bigot, this is a place where network byte order > is even to me the obvious win.) > The major advantage of this is that you can define it and then you > never have to change it again. We don't have to have any arguments > over what hash function is proper to use, etc. An implementation can > decide to support or not support whatever. +1 But shouldn't one define better the number to be either a string? Sure a one byte number with 255 possible future algorithms seem plenty enough, but people also once thought that about 32bit IPv4 addresses, two digit year numbers and so on. :-) Cheers, Chris. --=-RgT/b3kjLPu5Wxc1g+V5 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNTIwMDQy MlowTwYJKoZIhvcNAQkEMUIEQCEF+HXSrrK5tUOtavaIAWAvjmTfRUpFheU2LnxzKOuBTL8pesqL 8NkRR05oEUtn8CJ6Iw2FvJW++189g+bUqdcwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCX3npvcBUFH3R7W7pi+9Lbm187FR1O 26S+aGtaXZE4vqmsfps0u/7VoDQu7H+EQlHnvCsUVkZuME5MG4Yzz9D/dnB8qfia4vST2A6lkMhC 1h42B/y+E9kA8RcXscpQx1BGPFx6D9BQmMnQRnDekl7QuxLeOZTm1Si/6MIuNBPTSy+d/cgXTGBm gxzJb550fmXI/R45bxCMBflcpOiLmRYYmzDLTmBIUtuILm/YFt4qW6MLLREOYsuv+4SRp64KwTHs mLt+fKIcjReD99EPrjri5az8QviSlv2qUd1Gc1QzKXd/QEB9ernnRBFD1GMLPXFSJlwBDPJsXpt3 f5hf2/ZMAAAAAAAA --=-RgT/b3kjLPu5Wxc1g+V5-- From nobody Wed Apr 15 13:21: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 84B7F1A874E for ; Wed, 15 Apr 2015 13:21:20 -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 Ltzg49dVJq2i for ; Wed, 15 Apr 2015 13:21:19 -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 ECFE91A8726 for ; Wed, 15 Apr 2015 13:21:18 -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 t3FJra1s027383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Apr 2015 15:53:36 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: David Shaw In-Reply-To: <1429128262.1702.41.camel@scientia.net> Date: Wed, 15 Apr 2015 16:21:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> To: "openpgp@ietf.org" X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 20:21:20 -0000 On Apr 15, 2015, at 4:04 PM, Christoph Anton Mitterer = wrote: >=20 > On Wed, 2015-04-15 at 12:11 -0700, Jon Callas wrote: >> There was a proposal that floated around that defined an extended >> fingerprint to be an algorithm number followed by the actual bits. >> For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary >> representation. There's an obvious way to truncate that as well -- >> just decide if you truncate little-endian or big. (Personally, = despite >> being a little-endian bigot, this is a place where network byte order >> is even to me the obvious win.) >> The major advantage of this is that you can define it and then you >> never have to change it again. We don't have to have any arguments >> over what hash function is proper to use, etc. An implementation can >> decide to support or not support whatever. > +1 >=20 > But shouldn't one define better the number to be either a string? > Sure a one byte number with 255 possible future algorithms seem plenty > enough, but people also once thought that about 32bit IPv4 addresses, > two digit year numbers and so on. Using a string is fine, but even with numbers, there is no rule that the = number has to be a single byte. After enough years and algorithms = added, it could be "100000:ABCDEF0123..." Whether it's a string or number, there has to be a list for what = number/string means what algorithm. Once you have a list, it doesn't = really matter if it's a string or a number. David From nobody Wed Apr 15 13:46: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 6BF071A8AA0 for ; Wed, 15 Apr 2015 13:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nYaXwUBNZ2QO for ; Wed, 15 Apr 2015 13:46:34 -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 7D92A1A8A9E for ; Wed, 15 Apr 2015 13:46:25 -0700 (PDT) Received: by lagv1 with SMTP id v1so42009116lag.3 for ; Wed, 15 Apr 2015 13:46:23 -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=lJMJi9UhbK/cBQ6XyXW6wGyOL4Y3KUc4ttZYcl0ovnc=; b=ZvNw2AHWUxu6MPiLEbrBYIwHMsqAg5jI1kDNhiKxFsP6fu4RnA1XpKdkTfQujeBaqI JueY1FwHMg3WxLZLqQq1m6TsglYeOdlFSjEG5sqThw70DXFUcEoiiM8dSa6MnSHwJMcf Mh0r85qMTlBIznIuLHbV8tFFS2PCEqG16kknvjyIoWhaORzKbJBFtKu3y1cfCvfwWAvm rQ3qpuuLDaMLR/E14ISQ2qv95uh9p8tCdIyYX5iR8FFOjR6MBbiM0TW+BmZb5lvQxnqG rGvFDO6fZRgpnRo1DpMT79qvdwFXC0anZWPfk545ryjsw7F5vPIKaMqaYXay7tafZF0E IXCQ== MIME-Version: 1.0 X-Received: by 10.112.151.226 with SMTP id ut2mr7921693lbb.55.1429130783866; Wed, 15 Apr 2015 13:46:23 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 15 Apr 2015 13:46:22 -0700 (PDT) In-Reply-To: <1429128262.1702.41.camel@scientia.net> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> Date: Wed, 15 Apr 2015 16:46:22 -0400 X-Google-Sender-Auth: vwkQqVOxoyFVNpzbMqCq012kQrM Message-ID: From: Phillip Hallam-Baker To: Christoph Anton Mitterer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 20:46:35 -0000 On Wed, Apr 15, 2015 at 4:04 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-04-15 at 12:11 -0700, Jon Callas wrote: >> There was a proposal that floated around that defined an extended >> fingerprint to be an algorithm number followed by the actual bits. >> For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary >> representation. There's an obvious way to truncate that as well -- >> just decide if you truncate little-endian or big. (Personally, despite >> being a little-endian bigot, this is a place where network byte order >> is even to me the obvious win.) The ni scheme I linked to does essentially that. What we are discussing here is essentially the same thing only with a slightly different syntax. It is not necessary to separate the algorithm ID from the fingerprint. >> The major advantage of this is that you can define it and then you >> never have to change it again. We don't have to have any arguments >> over what hash function is proper to use, etc. An implementation can >> decide to support or not support whatever. > +1 > > But shouldn't one define better the number to be either a string? > Sure a one byte number with 255 possible future algorithms seem plenty > enough, but people also once thought that about 32bit IPv4 addresses, > two digit year numbers and so on. It isn't necessary. We just use the same trick Ken Thompson used to create UTF8. Let us say we choose the first 5 bits to be the algorithm identifier giving us a maximum of 32 code points Now let us say that we have allocated 16 code points. This means that any fingerprint which begins with the byte 00000xxx - 01111xxx has to use one of those algorithms. So when we get to code point number 17, we need to expand the registry. instead of using just the first Base32 character we might use the whole of the first byte which would give us 128 extra code points. Or we might go to the first 10 bits which gives us 512 code points. I do not think it is at all likely we will exhaust the registry in our lifetime. Since Rivest proposed MD4 in 1990 we have had four hash algorithms that have been widely used, MD4, MD5, SHA-1 and SHA-2. If we continue at the same pace it will take a century before we get up to 16. And that is actually a pretty conservative estimate. Since 1995 we have only had two algorithms. If we start a registry now with SHA-2 and SHA-3 defined, I see no reason to expect any need to assign a new code point for another 20 years. It is now 14 years since AES was published and nobody expects it to be replaced any time soon. Some people, including myself, think we should have a competition for a second, stronger algorithm for use as a backup but that is an entirely different matter. If we consume one code point every 20 years it will be 1600 years before we need to worry about going beyond the first byte. And even if we were trying to burn code points as quickly as possible I can't see the gaps between the RFCs being less than 2 years. So thats still 160. As with every other key size debate, people can always say we might need more but there is a tradeoff. At present fingerprints need to be short to fit in with our legacy paper based systems. While it is unlikely that issue will disappear in the next ten years, I don't expect it to be relevant in 30. And yes, Bill Gates did suggest 640Kb as the limit for RAM in the IBM PC. But that was not a mistake as some folk imagine. The chip had a hard limit of 1024Kb of memory (it did not have paging) and that had to include the RAM, the ROM and the video memory. Allowing more memory for programs would have prevented the use of bitmapped graphics cards. It was an engineering tradeoff. So is this. From nobody Wed Apr 15 13: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 D96091A8B84 for ; Wed, 15 Apr 2015 13:57:43 -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 HT9XAW4r0SUl for ; Wed, 15 Apr 2015 13:57: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 105481A8AFA for ; Wed, 15 Apr 2015 13:57:42 -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 998635FB45 for ; Wed, 15 Apr 2015 20:57:40 +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 apuMT91l3PpD for ; Wed, 15 Apr 2015 20:57:38 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 15 Apr 2015 20:57:38 +0000 (UTC) Message-ID: <1429131456.1702.51.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Wed, 15 Apr 2015 22:57:36 +0200 In-Reply-To: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-8m9uxb/W0dn1VHAEEowH" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 20:57:44 -0000 --=-8m9uxb/W0dn1VHAEEowH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-15 at 16:46 -0400, Phillip Hallam-Baker wrote:=20 > The ni scheme I linked to does essentially that. What we are > discussing here is essentially the same thing only with a slightly > different syntax. It is not necessary to separate the algorithm ID > from the fingerprint. So in that ni scheme, is the algorithm id then hashed along with the data? > It isn't necessary. We just use the same trick Ken Thompson used to > create UTF8. Sure that's possible as well, but I think they only did this do be compatible with ASCII... and it makes probably parsing a bit more complex. > I do not think it is at all likely we will exhaust the registry in our > lifetime. Since Rivest proposed MD4 in 1990 we have had four hash > algorithms that have been widely used, MD4, MD5, SHA-1 and SHA-2. If > we continue at the same pace it will take a century before we get up > to 16. And that is actually a pretty conservative estimate. Since 1995 > we have only had two algorithms. Well... it's always difficult to predict the future... probably you're right, but why making it not generic enough to be one the safe side if we can. As I've said, we've had that already plenty of times, that people expected something to be never exhausted and then things came completely different. So one should perhaps learn from the past =3D) Cheers, Chris --=-8m9uxb/W0dn1VHAEEowH 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNTIwNTcz NlowTwYJKoZIhvcNAQkEMUIEQFvYo6+TCFlMA7eJN1NTgPIqJKOgmopxK7S0PF44G6/RemgXcNnQ 1scPG7g901raLtdJFL3Tb23+DH4A+/h60X4wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBRHB/POTwdZcy/J+3ZNYG8tUKSKVQh yfu4CCfwGw+K/pPMPi1PUfbQdXSmq+sBahnCggN3B/GskSa88IpIw/iKdVc53B6ybeSA5tJebi0w yaK3Zdk3otNJhewOkEiB77i12mtOuz7sxzIILL0CVDekT56ijsg9+lVkZAorlMbJSiO9/2BAFZtR wHQuRmOi9E4+VkSblsc2qUR73kKun5eOuLgtim1dTyeKdxBBvsjBiMQIoADcSacLOz2A2hi3cll5 HjgSirkdbWeL2k0XTjFueMWnNYKHFIlpnBN4Kjo7+FOxr6Xml1dqiAOk5sXtyKXacwyAqtKXJLXu zA9sFRgDAAAAAAAA --=-8m9uxb/W0dn1VHAEEowH-- From nobody Wed Apr 15 13:57: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 0CC6A1A8BB5 for ; Wed, 15 Apr 2015 13:57: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 WFCcLDLi15-c for ; Wed, 15 Apr 2015 13:57:46 -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 A27DE1A8BB1 for ; Wed, 15 Apr 2015 13:57: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 mailgw02.dd24.net (Postfix) with ESMTP id 8219A5FB59 for ; Wed, 15 Apr 2015 20:57: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 tkCkM0wJIcfc for ; Wed, 15 Apr 2015 20:57:42 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 15 Apr 2015 20:57:42 +0000 (UTC) Message-ID: <1429131461.1702.52.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Wed, 15 Apr 2015 22:57:41 +0200 In-Reply-To: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-RsimBgbR83q0CNqQ88Gd" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 20:57:47 -0000 --=-RsimBgbR83q0CNqQ88Gd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-15 at 16:21 -0400, David Shaw wrote: > Using a string is fine, but even with numbers, there is no rule that > the number has to be a single byte. After enough years and algorithms > added, it could be "100000:ABCDEF0123..." But numbers would make problems if we're using the binary representation of the fingerprint (i.e. not the ASCII/UTF8 version of it). How should one know where the algo type ends, 0x0 can't be used since it may be part of the number. So it can only be done if the algo type is defined to be a (null terminated) string. Cheers, Chris. --=-RsimBgbR83q0CNqQ88Gd 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNTIwNTc0 MVowTwYJKoZIhvcNAQkEMUIEQEpoJH1iau68bFaKe5MuNdABKLdN/fBJ1xD9G+8LJ4jxBnIqfzBL PsQoA+cw+Q1SQwsukRtAZM+2NFmYCWkdVMswagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBGAsREeYY+Yo58UaNiK4A3hYiK+ZEU 4anDPH9f01s8m+4Eo8eDVproXrryefUL0EqlNDxJQb0e3mzN9Vl/UCbiHCH6IiRk8LBZf5mq78Wt Oumxa9KF5mKP0+cmiFcR7W92jA94NOQcImjbnIcTGN7TwX2dnyZVeINhuwYaLdyUwvtivlAUe095 T959rYrOZY9lhuP2ihl04xew9yMLGD91rnBG3Td4yiyMV2Hvhgrn1dUKjgJe6lwTcGgHdx7PdDGB omc+eT9+0ZQbqgaQEsM+GRw2MHRa21D2tTL1RmILcTngIqZ6o1OYzm4EhZAMwqux4d2tGy9X/dwr vOVnP3vOAAAAAAAA --=-RsimBgbR83q0CNqQ88Gd-- From nobody Wed Apr 15 14:01: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 33A371A8F42 for ; Wed, 15 Apr 2015 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Se7R87NFrmMx for ; Wed, 15 Apr 2015 14:01:21 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id C54F31A8F39 for ; Wed, 15 Apr 2015 14:01:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 51206701116A; Wed, 15 Apr 2015 14:01:21 -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 N70XuT8xleZZ; Wed, 15 Apr 2015 14:01:19 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id C1ED57011156; Wed, 15 Apr 2015 14:01:18 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 15 Apr 2015 14:01:19 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 15 Apr 2015 14:01:19 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <5527B621.3040104@cs.tcd.ie> Date: Wed, 15 Apr 2015 14:01:18 -0700 Message-Id: <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> References: <5527B621.3040104@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] details of 4880bis work 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, 15 Apr 2015 21:01:24 -0000 My comments inline: >=20 > a) update the fingerprint format (avoid inclusion of creation date, = use > stronger digest algorithm; i'm dubious about embedding algorithm > agility in the fingerprint itself, but explicit version info in the > fingerprint might be reasonable so we don't have to keep guessing by > fpr structure for future versions) There's a separate thread on the structure -- I replied to it myself. There was also a mention somewhere of removing the timestamp from the = fingerprint, and that's what I really want to comment on. When 2440 started, removing the timestamp was one of the things I wanted = to do. However, it's not such a bad thing. If you make a fingerprint = merely be a function of the key (it has no variable data), then you lose = the ability to alias the key, which is actually useful. Presently, Alice can use the same key material for "alice@example.com" = and "info@example.com" and it's not obvious that it's the same key from = the fingerprint. If the fingerprint algorithm forces them to be the same = fingerprint, there's an unnecessary information leak. An attacker learns = they can attack Alice by attacking Info. The fingerprint is an analogue of the serial number in X.509. It's = desirable to be able to reuse keys in whatever PKI you use. It gives = some people heartburn, but it's done all the time for practical reasons. If we get rid of the timestamp, there ought to be something like salt = put in in its place. "Randomized Hashing" is not a bad thing. >=20 > b) get rid of keyids entirely -- when referring to a key, use the > fingerprint where a compact hint is needed (e.g. in a replacement of > the issuer subpacket) or the full primary key where it is more > sensitive (e.g. in designated revoker). With EC keys, we could > consider using the full key (not the full cert) even in the issuer > subpacket case, which could make things cleaner. There's no *need* to do that. An implementation must (not MUST, but an actual must) consider that = there will be a collision and handle it appropriately. Remarkably few of = them do, but this is a bug. >=20 > c) deprecate MD5, SHA1, and RIPEMD160 No argument there. I will observe along with Shamir's observation that = there are no first or second-preimage collisions in SHA1. Some SHA1 uses = (like fingerprint calculation) are still secure. MD5 was deprecated in 2440; it is *only* there for = backwards-compatibility with RFC 1991, and that grudgingly. 4880 = actively spits on MD5. Deprecating SHA1 is something that can be an actual deprecation -- = saying "please don't do that" rather than banning it. Nonetheless, as I said in the fingerprint discussion, there are places = where you can design the expression of it that mean it never has to be = redesigned again. Why should we go through this all over again for = SHA-4, instead of just letting people put in a new algorithm ID? >=20 > d) clarify that cleartext signatures should all use charset/encoding > UTF-8. That's basically there now. There's some weasel-wording because of = people who still wanted to use Shift JIS and other character sets, but = that's there now. Section 3.4. (By the way, in PGP, we started off with a dictatorial view that = everything was UTF-8, and ended up having to deal with the edge = condition of Shift JIS etc.)=20 The WG can sweep this under the rug, but implementers will still have a = problem. I suggest in the name of practicality, keep it mostly the way = it is. You really need to have a shallow bow to Japan and the rest of us = will all use Unicode, just like another shallow bow is needed in the = form of Camellia. >=20 > e) update S2K with something more modern (PBKDF2, HKDF, scrypt?), > deprecate all the other mechnanisms explicitly Agree completely on just using PBKDF2. You could put other more modern password grinders in, or even leave it = open for new technologies to be introduced easily. >=20 > f) standardize the two new curves coming out of the CFRG: 25519 and > curve448 ("goldilocks") for both signatures and encryption (Werner > has already started this process for 25519 signatures) I have no problem putting in parameters for those, but similarly to the = hash issue, the EC Curve issue is not settled. There's a NIST conference = in June, and personally I expect my favorite curve, 41417, to get widely = used because it's both really fast and secure as well as not overly = large (I think 521 is overly large). >=20 > g) remove compression entirely That would be a huge relief. Or at the very least just say SHOULD NOT on = it.=20 >=20 > h) clean up the language: clearly distinguish between "public key" and > "certificate", and ensure that the use of the terms "trust" and > "validity", if still present, are used unambiguously. This would be good, but it touches upon a political third rail here. = That problem really needs to be cleaned up. When 2440 started, there was an agreement with the Security Area that = OpenPGP would not be a "PKI" (whatever the heck that means), because = there was already a PKI, namely PKIX. That means that OpenPGP has these language issues. It has to be a public = key infrastructure without being a PKI. That's the reason why there's no = trust model, while having the atomic components needed to have = infrastructure, should one want to do that. There are a number of things that really need to have documents, either = on their own or sections in some document. They include: * Trust model(s) * Key/certificate servers * Key/certificate transport (yes, they're different) But that deserves its own topic. The bottom line is that you can't talk about trust/validity issue = without admitting that it's a public key instrstructure. I believe that = you can personally solve this problem merely by saying, "yeah, whatever" = but that's the underlying unspoken issue that the previous working group = was *forbidden* from solving that problem. On the key/certificate language issue, the term "Key" as we use it comes = from Whit Diffie. It's a brilliant bit of wordsmithing because everyone = knows what a key is, but no one knows what a certificate is, let alone = the difference between a certificate and a certification. The problem = with an "OpenPGP Key" is that it contains at least one key, and almost = always at least two keys. So one is stuck having to know the difference = between a Key and a key -- or an OpenPGP Key and a public key. = Capitalization is not the answer.=20 There were a few places where it really, really made sense to use the = word "certificate." That word occurs only in eight places in 4880. The = important one is section 5.5.1.1 that says (in toto): A Public-Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate). That sentence contains in it much of the No PKI issue. We couldn't go = the other way around -- we couldn't say that an OpenPGP certificate was = sometimes called an OpenPGP key because if we had certificates, that = meant we were a PKI. Also, the OpenPGP community really likes the term = "Key" because it's a great word, and no one actually wanted to retire = "key" for certificate anyway. Nonetheless, we couldn't say up front early in the document that there's = going to be a couple of places where your head will hurt less if we just = say "certificate" so we're going to do that. We had to bury it in = 5.5.1.1. if you take that line as a definition -- "OpenPGP key" and = "certificate" are synonyms, then there's no problem. If the new WG wants to get rid of "certificate" there's only eight = places.=20 >=20 > i) declare a literal data packet type "m" that means "MIME content" so > that we can punt on the rest of the message > structure/format/encoding/type craziness to MIME. Better yet -- just say it's binary only. Get rid of all that FTP and = other pre-ASCII baggage for good. Making an "m" data type is really only a bandaid, and long-term makes = the underlying problem (that we're making semantic choices in the wrong = layer) worse. I think it's far more important to toss out all that crap with = canonicalization and what it means and all than to make it worse with a = new data type. Bits. It's all just bits, collected into bytes. Excuse = me, octets. >=20 > j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can > get away with. No problem. >=20 > k) provide a modern streamable/chunkable AEAD replacement for > Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets >=20 > l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD > mechanism should be the baseline. Well, obviously some of has to be done, since the MTI is 3DES, SHA1. However, making ECC be MTI is something that ought to have discussion. = (I'm in favor of it, but I know otherwise-sane people who have = reasonable objections.) Jon From nobody Wed Apr 15 14:04: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 3FC5D1A9004 for ; Wed, 15 Apr 2015 14:04:37 -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 lsQ64xYyjAIk for ; Wed, 15 Apr 2015 14:04:36 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3D1A8F4B for ; Wed, 15 Apr 2015 14:04:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 3AB357011254; Wed, 15 Apr 2015 14:04:36 -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 PsWX-pBQg7jV; Wed, 15 Apr 2015 14:04:35 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 998B5701123E; Wed, 15 Apr 2015 14:04:35 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 15 Apr 2015 14:04:35 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 15 Apr 2015 14:04:35 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <1429128262.1702.41.camel@scientia.net> Date: Wed, 15 Apr 2015 14:04:34 -0700 Message-Id: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> To: Christoph Anton Mitterer X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 21:04:37 -0000 > But shouldn't one define better the number to be either a string? > Sure a one byte number with 255 possible future algorithms seem plenty > enough, but people also once thought that about 32bit IPv4 addresses, > two digit year numbers and so on. Congratulations, you've just invented OIDs. ;-) Jon From nobody Wed Apr 15 14:07: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 C9E741A8FD7 for ; Wed, 15 Apr 2015 14:07:28 -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 3ltSj3hOkhkH for ; Wed, 15 Apr 2015 14:07:27 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id DA3B91A1A88 for ; Wed, 15 Apr 2015 14:07:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 9553D7011301; Wed, 15 Apr 2015 14:07:27 -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 uLgKDliFHur2; Wed, 15 Apr 2015 14:07:26 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id E462670112EF; Wed, 15 Apr 2015 14:07:25 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 15 Apr 2015 14:07:26 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 15 Apr 2015 14:07:26 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <878udt9ta5.fsf_-_@vigenere.g10code.de> Date: Wed, 15 Apr 2015 14:07:25 -0700 Message-Id: References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@singpolyma-liberty> <878udt9ta5.fsf_-_@vigenere.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 15 Apr 2015 21:07:28 -0000 > However I see a problem with the removal of compression: Almost all = keys > have preferences for compression and most messages are using > compression. Thus all implementations will need to keep on supporting > de-compression which is actually the more complicated part. Here's what I would do (and have done): Whenever someone makes a key, you throw in the preference that says no = compression. You then either get hissy when someone ignores the = preference (and thus breaks protocol) or implement the decompress side. =46rom an engineering aspect, you then don't do compression and declare = it to be an error if someone breaks protocol, knowing that six months = later, you'll have time to throw in the decompress bits. Jon From nobody Wed Apr 15 14:08: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 087501A901C for ; Wed, 15 Apr 2015 14:08:49 -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 PCSlOYisP33h for ; Wed, 15 Apr 2015 14:08:48 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB31A8F49 for ; Wed, 15 Apr 2015 14:08:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id BBC3B70113AA; Wed, 15 Apr 2015 14:08:47 -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 V8LTuVtlQyUd; Wed, 15 Apr 2015 14:08:46 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 04BB47011398; Wed, 15 Apr 2015 14:08:46 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 15 Apr 2015 14:08:46 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 15 Apr 2015 14:08:46 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: Date: Wed, 15 Apr 2015 14:08:45 -0700 Message-Id: <111DA039-7AEA-4C68-8B44-5252C714C01C@callas.org> References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@singpolyma-liberty> <878udt9ta5.fsf_-_@vigenere.g10code.de> To: Wyllys Ingersoll X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Stephen Paul Weber , "openpgp@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 15 Apr 2015 21:08:49 -0000 > On Apr 15, 2015, at 11:28 AM, Wyllys Ingersoll = wrote: >=20 >=20 > Can someone explain the reasoning behind deprecating compression ? Im = neutral on the idea, just trying to understand the benefits of getting = rid of it beyond simplifying the processing of the packets. Yes. That is the reason. Someone could wave their hand at you and give a security reason, but = it's just a handwave. The reality is that it is *better* to have a = simpler processing path than smaller messages. Jon From nobody Wed Apr 15 14:33: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 102291A90AB for ; Wed, 15 Apr 2015 14:33: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 WrRWCmKA1wjA for ; Wed, 15 Apr 2015 14:33:13 -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 9788E1A90AA for ; Wed, 15 Apr 2015 14:33:13 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 39A586D741; Wed, 15 Apr 2015 17:33:12 -0400 (EDT) Message-ID: <552ED916.6010309@iang.org> Date: Wed, 15 Apr 2015 22:33:10 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131456.1702.51.camel@scientia.net> In-Reply-To: <1429131456.1702.51.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 21:33:15 -0000 On 15/04/2015 21:57 pm, Christoph Anton Mitterer wrote: > So one should perhaps learn from the past =) IP#s are one per person, approx. We're trying to get away from one algorithm per person, not encourage it ;) iang From nobody Wed Apr 15 14:41: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 BDF951A90B1 for ; Wed, 15 Apr 2015 14:41:26 -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 yKiZp9zeX29R for ; Wed, 15 Apr 2015 14:41:26 -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 37F1F1A90DA for ; Wed, 15 Apr 2015 14:41:20 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 77C716D744; Wed, 15 Apr 2015 17:41:19 -0400 (EDT) Message-ID: <552EDAFD.60900@iang.org> Date: Wed, 15 Apr 2015 22:41:17 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> In-Reply-To: <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 15 Apr 2015 21:41:26 -0000 On 15/04/2015 22:01 pm, Jon Callas wrote: > My comments inline: >> h) clean up the language: clearly distinguish between "public key" and >> "certificate", and ensure that the use of the terms "trust" and >> "validity", if still present, are used unambiguously. > > This would be good, but it touches upon a political third rail here. That problem really needs to be cleaned up. > > When 2440 started, there was an agreement with the Security Area that OpenPGP would not be a "PKI" (whatever the heck that means), because there was already a PKI, namely PKIX. :-o I don't suppose it would have made much difference to us in OpenPGP, but it's nice to know how deep the rot ran at IETF. iang From nobody Wed Apr 15 15:09: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 662F31A9154 for ; Wed, 15 Apr 2015 15:09:42 -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 CMIE7CWUKrrs for ; Wed, 15 Apr 2015 15:09:41 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id E5F621A916B for ; Wed, 15 Apr 2015 15:09:40 -0700 (PDT) Received: from [173.75.83.181] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YiVV5-0000Q9-RH; Wed, 15 Apr 2015 18:09:39 -0400 Date: Wed, 15 Apr 2015 15:09:39 -0700 From: Bill Frantz To: Jon Callas X-Priority: 3 In-Reply-To: <111DA039-7AEA-4C68-8B44-5252C714C01C@callas.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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec790d64be65690be17ee2af37598f31bd42350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.181 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 15 Apr 2015 22:09:42 -0000 On 4/15/15 at 2:08 PM, jon@callas.org (Jon Callas) wrote: >Someone could wave their hand at you and give a security=20 >reason, but it's just a handwave. The reality is that it is=20 >*better* to have a simpler processing path than smaller messages. Phil said, "Compression provides an oracle for the plaintext".=20 This attack works on TLS when used by web pages. AFAIK, it=20 requires that the attacker be able to control some data being=20 compressed which is compressed before the data he is trying to=20 steal. I think it also requires multiple attacks. While I don't know any PGP use cases that match these=20 requirements, I don't think any of us know all the use cases,=20 present and future. If the application/user wants to compress,=20 it is straight forward to implement outside PGP, and not having=20 compression simplifies the code (in the long term), and avoids=20 what is at least a theoretical attack. CHeers - Bill ----------------------------------------------------------------------- Bill Frantz | Privacy is dead, get over | Periwinkle (408)356-8506 | it. | 16345=20 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos,=20 CA 95032 From nobody Wed Apr 15 15:10: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 A30A61A9233 for ; Wed, 15 Apr 2015 15:10: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 0W09bTFhc8Zq for ; Wed, 15 Apr 2015 15:10:55 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 D04FD1A916B for ; Wed, 15 Apr 2015 15:10:52 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so44914715lbb.2 for ; Wed, 15 Apr 2015 15:10:51 -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=q+DgS7qfCL+B95Rxy93uGqB1LMIMDvlUdSlEtcWLkLM=; b=ApDYXgZLkq0cXIKMLvGJAhnw2PV1YQuFsilw6wu/ExQ2HqWpnPqAdyS0qhkTDLtuNr AFuwT5MJPaVXg8FioXbx4dWdJPB50srXMmDMYZlC4HH4RlbYWPtdkvR+fa/iSZwAoDJ8 hVmgCK7minlA6nTohr33e2BQzebDNxDJlMsNTmc0S1sPtGfvc4UuNB7g1+Mox6wuWDJp 3cROGIHSNfP7+VfMPf+h8o/3NWu1bG7M8B2OFuVmKBOl63qd1/chRwx90MyzN0jx4Nr3 slYrHCW60YvRFmG9Mv5DaVfN8clHYqjgKjXY9l4iSrb08TpVB6Lk2R0AzD9jQ08XJvmW AoSQ== MIME-Version: 1.0 X-Received: by 10.152.18.225 with SMTP id z1mr26210639lad.124.1429135851417; Wed, 15 Apr 2015 15:10:51 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 15 Apr 2015 15:10:51 -0700 (PDT) In-Reply-To: <1429131456.1702.51.camel@scientia.net> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131456.1702.51.camel@scientia.net> Date: Wed, 15 Apr 2015 18:10:51 -0400 X-Google-Sender-Auth: 2RQvMHzLe2llvziC-fianbR-leA Message-ID: From: Phillip Hallam-Baker To: Christoph Anton Mitterer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 22:10:56 -0000 On Wed, Apr 15, 2015 at 4:57 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-04-15 at 16:46 -0400, Phillip Hallam-Baker wrote: >> The ni scheme I linked to does essentially that. What we are >> discussing here is essentially the same thing only with a slightly >> different syntax. It is not necessary to separate the algorithm ID >> from the fingerprint. > So in that ni scheme, is the algorithm id then hashed along with the > data? ni is a URI scheme designed to be used under the covers. It is not really what I would want for a fingerprint. > Well... it's always difficult to predict the future... probably you're > right, but why making it not generic enough to be one the safe side if > we can. Because introducing syntactic crud makes the identifier much less convenient and the whole point of a fingerprint is convenience. As I demonstrated, the proposed scheme has more than enough generality for our purposes which are thoroughly understood. > As I've said, we've had that already plenty of times, that people > expected something to be never exhausted and then things came completely > different. > So one should perhaps learn from the past =) That has happened when people who did not bother to try to understand the issue refused to listen to the informed opinions of those who did. While I am prepared to engage in a discussion over whether the basis of my estimates is reasonable or not, 'other people got it wrong, therefore you will' is not an argument. Unlike the people you are citing, I have actually played a significant role in the deployment of two global scale infrastructures. While I can't claim to be infallible, I can claim to know something of what I am doing. If the need ever arises, we can always cut a completely new set of fingerprint identifiers by just slapping a URI prefix on the front. Or use ni. All we are talking about here is the human readable form of the identifier. PGP is going to be using the binary data, JSON and XML apps using the same fingerprint format should use URIs. From nobody Wed Apr 15 15:46: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 2AB5F1A874B for ; Wed, 15 Apr 2015 15:46:57 -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 GH4GO0vHG0y4 for ; Wed, 15 Apr 2015 15:46:55 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2F1A873C for ; Wed, 15 Apr 2015 15:46:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 40C0F7013D03; Wed, 15 Apr 2015 15:46:54 -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 g-cnpqiwV1If; Wed, 15 Apr 2015 15:46:52 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 009EF7013CF1; Wed, 15 Apr 2015 15:46:51 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 15 Apr 2015 15:46:52 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 15 Apr 2015 15:46:52 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <552EDAFD.60900@iang.org> Date: Wed, 15 Apr 2015 15:46:51 -0700 Message-Id: <51DB391E-667B-42BA-8A1F-1AAD9025918A@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <552EDAFD.60900@iang.org> To: ianG X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] details of 4880bis work 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, 15 Apr 2015 22:46:57 -0000 >>=20 >> When 2440 started, there was an agreement with the Security Area that = OpenPGP would not be a "PKI" (whatever the heck that means), because = there was already a PKI, namely PKIX. >=20 >=20 > :-o >=20 >=20 > I don't suppose it would have made much difference to us in OpenPGP, = but it's nice to know how deep the rot ran at IETF. To be fair to the other side, it's just another axis of the choices are = good vs. choices are bad debate. It wasn't the only one -- the IPsec people thought that SSL should not = exist. SSL thought SSH should not exist (telnet over ssl as an = alternative). IPsec hated the port forwarding in SSL. POP hated IMAP. I = can go on. And those are the ones that survived. And everyone hated = SPKI. :-) But, for example, the "there can only be one" effect made it so that SSH = was limited in what they do, and so on and so forth. Schiller did us *huge* favors in letting us do what we did. He just had = to walk a tightrope. Jon From nobody Wed Apr 15 15:49: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 1EFD11A913E for ; Wed, 15 Apr 2015 15:49:13 -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 5UYtSyBVxSX8 for ; Wed, 15 Apr 2015 15:49:12 -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 B60BC1A912B for ; Wed, 15 Apr 2015 15:49:11 -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 955C95FB71 for ; Wed, 15 Apr 2015 22:49:10 +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 Yo0HpfSHhPd2 for ; Wed, 15 Apr 2015 22:49:08 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 15 Apr 2015 22:49:08 +0000 (UTC) Message-ID: <1429138147.1702.56.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Thu, 16 Apr 2015 00:49:07 +0200 In-Reply-To: <7D0F07E5-729B-41BF-82B1-99C443B90C27@gmail.com> References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@singpolyma-liberty> <878udt9ta5.fsf_-_@vigenere.g10code.de> <7D0F07E5-729B-41BF-82B1-99C443B90C27@gmail.com> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-heoZuLklruFdVKqdSafs" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 15 Apr 2015 22:49:13 -0000 --=-heoZuLklruFdVKqdSafs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-15 at 14:42 -0400, Phillip Hallam-Baker wrote:=20 > Compression provides an oracle for the plaintext Only when the attacker can do chosen plain text... and basically we can't really prevent the user from manually doing compression (thereby introducing the same oracle). Nevertheless, unless there are real crypto advantages of using compression (which I guess there are not), I agree that it's really time to remove it from OpenPGP,... we're a crypto message standard - not a compression standard. Cheers, Chris.=20 --=-heoZuLklruFdVKqdSafs 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNTIyNDkw N1owTwYJKoZIhvcNAQkEMUIEQAmM6BspEshkbANQWwGl8VlgzyuCA9twXkYc1W3BsCanCJPzOR6P 4LtDZxKx987tHw3ee9kZirdzBad0qphxjR8wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAGt1KjM9lW/59dS07AmBSfCOc7Y3hZ O4mRHlZFnC0IEHY6ip7ShyzHWG+lVibYS0bmguYWic3Z19GCIVf91Sx7Qyp8zqMh4+faxhYlqlvf qO3aMIrTmCCJKX5kYIMOGPAHls4sZiw83F51hUqJs+NYMF4O+DAZo4zcWF0Xwaw6AEppHa307vuZ aw2HzZH8isA7Bq+fvwmD5bzlQAvA/o2z58Ydy3TM0eDA5vSIjt7WJj0kTxU5nO99i1Indebf28+U WFmMjFPmcFOBALqt3Bf3yoPMLWXLFLoIRIgwS3JeNW0aC9f8I63l0l2fM8Tge6lrLtq54yQ97xwH TZyb4CIoAAAAAAAA --=-heoZuLklruFdVKqdSafs-- From nobody Wed Apr 15 15:51: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 6C59F1A92FB for ; Wed, 15 Apr 2015 15:51:40 -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_21=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 lCDszqFpMC9K for ; Wed, 15 Apr 2015 15:51:39 -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 BDB071A92F8 for ; Wed, 15 Apr 2015 15:51:36 -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 9B4035FB19 for ; Wed, 15 Apr 2015 22:51:35 +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 qdtcZSM_At9O for ; Wed, 15 Apr 2015 22:51:33 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 15 Apr 2015 22:51:33 +0000 (UTC) Message-ID: <1429138292.1702.58.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 16 Apr 2015 00:51:32 +0200 In-Reply-To: <552ED916.6010309@iang.org> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131456.1702.51.camel@scientia.net> <552ED916.6010309@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-4IXPBoT2dHzbD54HlNc4" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 22:51:40 -0000 --=-4IXPBoT2dHzbD54HlNc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-15 at 22:33 +0100, ianG wrote:=20 > IP#s are one per person, approx. Well, looking at v6, it's actually gazillions of IPs per person ;-) > We're trying to get away from one=20 > algorithm per person, not encourage it ;) Okay than take another example... e.g. registered port numbers. Cheers, Chris. --=-4IXPBoT2dHzbD54HlNc4 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNTIyNTEz MlowTwYJKoZIhvcNAQkEMUIEQG22rmkfB9f1r9z2hIHnPYoDNk3ZzAeMW49WhQJCdlGm5r0nGWAL LrvmKKdBDqfg9FXYbsVlM1N1+hpXOfapIsowagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB3JVkkNjDE6YFvJGRTXmWEeXY0sn40 sCw067l3WobH9BCmeyt8dsutXyeJIWJcZDqExlVl2DhShQKlLDRmbgY0czBFlCF4vmbT86T9BiOq gZFTwqlRoQfSE1UF+5cUkHI7JGwUteLFl2BxclRGOR1asDrV1/ak7wp//fhsIfAGAMcZHiNVKlym aaVDH621cvLuI449A/XvGgIjJJ38YOynx4btADY41YAGSzhsmgGI6AaxkEOFFi1Jkwt80rv9lPFH CXCt0BgfJfUSpGR6HjHCl8apyL9W9yooW4u6ymE633YiEj0ZLCL7EvJB/xop8Xe9XBmKwTspIXpX wW3pjIhFAAAAAAAA --=-4IXPBoT2dHzbD54HlNc4-- From nobody Wed Apr 15 15:58: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 6982C1AC3D2 for ; Wed, 15 Apr 2015 15:58:30 -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_21=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 luQbb_OdVjhj for ; Wed, 15 Apr 2015 15:58:29 -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 4AF0F1AC3D1 for ; Wed, 15 Apr 2015 15:58:29 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 37BFE6D750; Wed, 15 Apr 2015 18:58:28 -0400 (EDT) Message-ID: <552EED12.7060100@iang.org> Date: Wed, 15 Apr 2015 23:58:26 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131456.1702.51.camel@scientia.net> <552ED916.6010309@iang.org> <1429138292.1702.58.camel@scientia.net> In-Reply-To: <1429138292.1702.58.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 22:58:30 -0000 On 15/04/2015 23:51 pm, Christoph Anton Mitterer wrote: > On Wed, 2015-04-15 at 22:33 +0100, ianG wrote: >> IP#s are one per person, approx. > Well, looking at v6, it's actually gazillions of IPs per person ;-) > >> We're trying to get away from one >> algorithm per person, not encourage it ;) > Okay than take another example... e.g. registered port numbers. We can take multiple train engines if you like, or multiple mars rovers ... all of these have reasons for being multiples, we need many of them, as many as we can afford. We only ever need one fingerprint hash. The reason we're forced to have more than one is because they wear out at a rate of one per decade. So, as per PHB, 10 is like the maximum we'll ever see. Even the one we've got isn't broken. Hence, the smallest byte possible is all that is needed, and we still have plenty of room for expansion to two bytes. Now, some might say computers don't care, and they'd be right if callous. Fingerprints are for humans tho, and humans do care, and humans get all twisted up over the extra bytes. For my humanity, even one byte of algorithm identification is one too many. I'm quite happy to define the new fingerprint with unusual lengths. iang From nobody Wed Apr 15 16:03: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 0ED4B1AC3ED for ; Wed, 15 Apr 2015 16:03: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 prrr8ypL4x1i for ; Wed, 15 Apr 2015 16:03:08 -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 0BF581AC3EC for ; Wed, 15 Apr 2015 16:03:08 -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 DE91A5FB4B for ; Wed, 15 Apr 2015 23:03: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 nqLpCOyBJTp1 for ; Wed, 15 Apr 2015 23:03:05 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 15 Apr 2015 23:03:05 +0000 (UTC) Message-ID: <1429138983.1702.62.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 16 Apr 2015 01:03:03 +0200 In-Reply-To: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <87sic4jwzx.fsf@vigenere.g10code.de> <1428939645.12460.1.camel@scientia.net> <552C03CF.3020001@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-qZA0N+n4UqElZCmNsUKB" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 15 Apr 2015 23:03:10 -0000 --=-qZA0N+n4UqElZCmNsUKB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-04-14 at 20:36 -0400, Phillip Hallam-Baker wrote:=20 > It makes no difference to the security Are sure with that? I thought to have once stumbled across some paper which seemed to imply that a truncation leads to issues. Can't find it right now, though,... so maybe my mind just betrays me. Cheers. --=-qZA0N+n4UqElZCmNsUKB 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNTIzMDMw M1owTwYJKoZIhvcNAQkEMUIEQGDzXEYXdCBbpIVEvrnws2woZZK8NWM0ajZzih8Jfq3Ufk1MXl+L IxDvRDd7YaZZK5Z5JnSlsoolSZHYSZyvbzQwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDciEhkbZERsivm94nmmZ4U12dH1sZM 9dzOWArrlYZ2HbkG9or0HcAJuPrA2tgRBlOmAPQm00pGmWCzLzr5km5rmEfo+rax4dZjJelg0VSR bVFIkfpalA7ANckcwl6RUWHROCTDAwDFZHPt45JZhvDeKHBDMaQpDRCnBKCjjqO2qHJwkHCEHS2X /LOsOAtJCO0CM42xOJqm4lGZ8mJIqNBaHfQi5zMQfrisYVqpce9toaFgQTS7j/Jx7Ix2AatH/7tj 4I1VwuMbp422YeZqxEggT5X9J9UX5Q2JKKAD21wBTNwe3+6big2xe+FhWfYYQoPd+/uLZxqCNdTt jY/H/bW1AAAAAAAA --=-qZA0N+n4UqElZCmNsUKB-- From nobody Wed Apr 15 17:39: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 537301ACEE8 for ; Wed, 15 Apr 2015 17:39:43 -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 iVJ5evPUy3Fm for ; Wed, 15 Apr 2015 17:39:41 -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 DD91C1ACEE6 for ; Wed, 15 Apr 2015 17:39:40 -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 90B7C5FB1C for ; Thu, 16 Apr 2015 00:39:39 +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 UUwSxb07e2c1 for ; Thu, 16 Apr 2015 00:39:37 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-93-104-124-136.dynamic.mnet-online.de [93.104.124.136]) (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, 16 Apr 2015 00:39:37 +0000 (UTC) Message-ID: <1429144776.1702.75.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 16 Apr 2015 02:39:36 +0200 In-Reply-To: <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-XF+KYi7J/vpwAom7BElQ" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 00:39:43 -0000 --=-XF+KYi7J/vpwAom7BElQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-15 at 14:01 -0700, Jon Callas wrote: > There was also a mention somewhere of removing the timestamp from the > fingerprint, and that's what I really want to comment on. > When 2440 started, removing the timestamp was one of the things I > wanted to do. However, it's not such a bad thing. If you make a > fingerprint merely be a function of the key (it has no variable data), > then you lose the ability to alias the key, which is actually useful. I think the main problem with the valid from/through dates not being a part of the fingerprint is the following: A user may intentionally want to limit his key for security reasons, e.g. he makes a 1024 bit and wants to make sure that no one is using/trusting it after two years anymore. AFAIU, if the dates are not part of the fingerprint this would also mean that they could be changed any time with a new self sig (including at a time when the key owner may deem the 1024 bit RSA already no longer secure enough to be trusted). Of course one can make a revocation cert, but an attacker could always try a blocking attack at the keyserver level. That's why I think, that creation and expiration times should be immutable once the key has been created; at least not without invalidating all signatures (i.e. those from other users). And analogous example to the above can easily be made for the starting time. If an attacker could re-sign a broken key to an earlier date (without invalidating other signatures) he could also forge signatures for the time before. Does that sound reasonable? Cheers, Chris. --=-XF+KYi7J/vpwAom7BElQ 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNjAwMzkz NlowTwYJKoZIhvcNAQkEMUIEQKKjEKRcdQp5LMvRzwaBxonXFMq/jHQVIzDexokRCByBYSoe++sB f0RGKYVPlqtln0yg9bXgaHt6snWMNvhfjz0wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQA4iPGpY1Y/x4n1mj1RxOEIrU+e0hrN SSKP/r6T3sXxQgcC0nlPpfr5VVfGqVFLESpbMNddDwsgglliwBt6Cmy3J2UlgB+VGALfFFN/igoM 6r3KGIEvyWQ8NYorZAy/Ew6Fm3dqvDNjeWxr0Zcy5TvGaP9MrCf7/VZKvmG1G3WcrSxqN5vhFuC1 N/6D7g0V7xYUQSgOoHenQvEgP0wE48WR9B0e+YGBbFgs0AjtONFt7GfuC8Umz7VUHmNlS7db2SLD byPkmeCDN1a+FUiClG4/oc4qHp0y8sHyqbDpGx3NBaYcEhUxAzgQ9kmOPsxamWOXsqk0ckGvuruf Yv5MRYymAAAAAAAA --=-XF+KYi7J/vpwAom7BElQ-- From nobody Wed Apr 15 19: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 88A631B2C16 for ; Wed, 15 Apr 2015 19:37:00 -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 0CfMHLDZI-KY for ; Wed, 15 Apr 2015 19:36:58 -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 097971B2BFC for ; Wed, 15 Apr 2015 19:36:57 -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=1429151819; x=1460687819; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2cwZZv48IXCJwWsHx4/mLw+Tu429l7PUBbb5bQ0sGp8=; b=MSj6A0KmU0Rc6XHYQrQ9G03cF174fnkf1vnXLoJNzuIJASRb75F9odAf NeENokxGCo8sbnb1n1GpIIVRId9kDDK4o12R5W0Ap7+39Yr1GYL1FffBN ND/b4y+i1y4ck7bK+7fzDh8CqTR/1q+SCJG0cADYUt+dmlaridLRN6BKA Y=; X-IronPort-AV: E=Sophos;i="5.11,585,1422874800"; d="scan'208";a="320875511" 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; 16 Apr 2015 14:36:55 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Thu, 16 Apr 2015 14:36:53 +1200 From: Peter Gutmann To: ianG , "openpgp@ietf.org" Thread-Topic: [openpgp] details of 4880bis work Thread-Index: AQHQd79RdGiVcyQxmUKWTeP0YrBm+J1N0SWAgAEbk1E= Date: Thu, 16 Apr 2015 02:36:53 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFFB195@uxcn10-tdc05.UoA.auckland.ac.nz> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org>,<552EDAFD.60900@iang.org> In-Reply-To: <552EDAFD.60900@iang.org> 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] details of 4880bis work 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, 16 Apr 2015 02:37:00 -0000 ianG writes:=0A= >On 15/04/2015 22:01 pm, Jon Callas wrote:=0A= >>When 2440 started, there was an agreement with the Security Area that =0A= >>OpenPGP would not be a "PKI" (whatever the heck that means), because =0A= >>there was already a PKI, namely PKIX.=0A= >=0A= >I don't suppose it would have made much difference to us in OpenPGP, but = =0A= >it's nice to know how deep the rot ran at IETF.=0A= =0A= It went the other way as well. When I proposed in PKIX allowing users to= =0A= manage their own certificates rather than having to go to a CA to get them= =0A= issued and replaced:=0A= =0A= https://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt=0A= =0A= the response from the PKIX chair was "we're not going to turn X.509 into = =0A= PGP", and that was the end of it.=0A= =0A= The response to a proposal to replace the totally nonfunctional CRL blackli= st=0A= approach used by X.509 with a whitelist mechanism was even worse, amounting= =0A= to near-hysteria in some cases when I tried to push the issue (I've got som= e=0A= of the emails saved somewhere, some of them came just short of saying "burn= =0A= the heretic!").=0A= =0A= Peter.= From nobody Wed Apr 15 21:26: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 9BAB01A90C7 for ; Wed, 15 Apr 2015 21:25:59 -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 AzzNTfm0qFZp for ; Wed, 15 Apr 2015 21:25:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2C61A9095 for ; Wed, 15 Apr 2015 21:25:57 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 07E01F984; Thu, 16 Apr 2015 00:25:54 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7346420042; Wed, 15 Apr 2015 23:25:53 -0500 (CDT) From: Daniel Kahn Gillmor To: Jon Callas , Wyllys Ingersoll In-Reply-To: <111DA039-7AEA-4C68-8B44-5252C714C01C@callas.org> References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@singpolyma-liberty> <878udt9ta5.fsf_-_@vigenere.g10code.de> <111DA039-7AEA-4C68-8B44-5252C714C01C@callas.org> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 16 Apr 2015 00:25:53 -0400 Message-ID: <87a8y8pulq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Stephen Paul Weber , "openpgp@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [openpgp] 4880bis: Compression (was: details of 4880bis work) 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, 16 Apr 2015 04:25:59 -0000 On Wed 2015-04-15 17:08:45 -0400, Jon Callas wrote: > On Apr 15, 2015, at 11:28 AM, Wyllys Ingersoll wrote: > >> Can someone explain the reasoning behind deprecating compression ? >> Im neutral on the idea, just trying to understand the benefits of >> getting rid of it beyond simplifying the processing of the packets. > > Yes. That is the reason. > > Someone could wave their hand at you and give a security reason, but > it's just a handwave. The reality is that it is *better* to have a > simpler processing path than smaller messages. Simplicity is key, for sure, because bugs can hide more easily in complexity. And some of those bugs are security issues. The additional expressivity itself (complexity aside) can also present a security concern, because the data structures can take on new and surprising forms: http://mumble.net/~campbell/misc/pgp-quine/ --dkg From nobody Thu Apr 16 00:11: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 423A21B2AFF for ; Thu, 16 Apr 2015 00:11:40 -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 Oea1FXiZ-qX9 for ; Thu, 16 Apr 2015 00:11:38 -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 68F331B2A1F for ; Thu, 16 Apr 2015 00:11:38 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YidxY-0002LK-JP for ; Thu, 16 Apr 2015 09:11:36 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yidvq-0007SL-6t; Thu, 16 Apr 2015 09:09:50 +0200 From: Werner Koch To: Christoph Anton Mitterer References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.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 Mail-Followup-To: Christoph Anton Mitterer , "openpgp\@ietf.org" Date: Thu, 16 Apr 2015 09:09:49 +0200 In-Reply-To: <1429128262.1702.41.camel@scientia.net> (Christoph Anton Mitterer's message of "Wed, 15 Apr 2015 22:04:22 +0200") Message-ID: <87egnk8s76.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] Fingerprints 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, 16 Apr 2015 07:11:40 -0000 On Wed, 15 Apr 2015 22:04, calestyo@scientia.net said: > But shouldn't one define better the number to be either a string? > Sure a one byte number with 255 possible future algorithms seem plenty All algorithm identifiers have by spec values below 128. If in any future time this number space is not sufficient, we can resort to the TLV or UTF-8 tricks of using the high bit to encode larger numbers. It keeps our fingerprints as short as possible but give theoretical space to extend it. Short fingerprints are important; if they are getting too long they won't serve a purpose because the public key could be used directly. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Apr 16 01:06: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 E27BE1B2BC7 for ; Thu, 16 Apr 2015 01:06:39 -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 4SCeFxQOEaME for ; Thu, 16 Apr 2015 01:06:39 -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 E47141B2BC6 for ; Thu, 16 Apr 2015 01:06:38 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yieon-0002ue-6F for ; Thu, 16 Apr 2015 10:06:37 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yiekq-0007as-SL; Thu, 16 Apr 2015 10:02:32 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <5527B621.3040104@cs.tcd.ie> <20150415133818.GH3106@singpolyma-liberty> <878udt9ta5.fsf_-_@vigenere.g10code.de> <111DA039-7AEA-4C68-8B44-5252C714C01C@callas.org> <87a8y8pulq.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Daniel Kahn Gillmor , Jon Callas , Wyllys Ingersoll , Stephen Paul Weber , "openpgp\@ietf.org" , Stephen Farrell Date: Thu, 16 Apr 2015 10:02:32 +0200 In-Reply-To: <87a8y8pulq.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 16 Apr 2015 00:25:53 -0400") Message-ID: <87a8y88prb.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 , Stephen Farrell , Wyllys Ingersoll , Jon Callas , "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Compression 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, 16 Apr 2015 08:06:40 -0000 On Thu, 16 Apr 2015 06:25, dkg@fifthhorseman.net said: > The additional expressivity itself (complexity aside) can also present a > security concern, because the data structures can take on new and But that is not different from cat plaintext | gzip | rfc4880bis-encrypt because the resulting data structures are similar. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Apr 16 01:19: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 36A841B2BEE for ; Thu, 16 Apr 2015 01:19:11 -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 NspX7genTs7X for ; Thu, 16 Apr 2015 01:19:05 -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 721F31B2BE8 for ; Thu, 16 Apr 2015 01:19:05 -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=1429172345; x=1460708345; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HKaaQVSDQK2kdK/ytvOE7NqeEDb7759JEmxLiO4DY0w=; b=CmT++ueiYVgi63rdYhW9WpE+d2fAUz2RvVsShyoKfh1DFE3Uuz3IIh8H fHS4phjdaQm5VbNW2KDTMLe4V6TO2VJAEPDOtqFhTKn2ZaDHiya1x1utw uQ97bL4Xk2uooA/FQODKdCjAvSZXbrFkSbWX4qf6CpB4zKCos5fDAAuCH 8=; X-IronPort-AV: E=Sophos;i="5.11,586,1422874800"; d="scan'208";a="320929532" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Apr 2015 20:19:03 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 16 Apr 2015 20:19:03 +1200 From: Peter Gutmann To: "openpgp@ietf.org" Thread-Topic: [openpgp] details of 4880bis work Thread-Index: AdB4Hf7/jqVMCxDpRzeqEYm9IhQHgg== Date: Thu, 16 Apr 2015 08:19:02 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFFB50E@uxcn10-tdc05.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] details of 4880bis work 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, 16 Apr 2015 08:19:11 -0000 Jon Callas writes:=0A= =0A= >> e) update S2K with something more modern (PBKDF2, HKDF, scrypt?),=0A= >> deprecate all the other mechnanisms explicitly=0A= >=0A= >Agree completely on just using PBKDF2.=0A= >=0A= >You could put other more modern password grinders in, or even leave it ope= n=0A= >for new technologies to be introduced easily.=0A= =0A= With any luck the PHC will be done by the time any new PGP RFC is published= ,=0A= so there'd be a well-designed, attack-resistant password-processing functio= n=0A= ready to use.=0A= =0A= Peter.= From look@my.amazin.horse Thu Apr 16 01:56: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 A57C61B2C74 for ; Thu, 16 Apr 2015 01:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hviBdw2lBbYz for ; Thu, 16 Apr 2015 01:56:23 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B671B2C65 for ; Thu, 16 Apr 2015 01:56:22 -0700 (PDT) Received: from localhost (p5798E5B4.dip0.t-ipconnect.de [87.152.229.180]) by mail.mugenguild.com (Postfix) with ESMTPSA id 536255FB02; Thu, 16 Apr 2015 10:53:56 +0200 (CEST) References: <5527B621.3040104@cs.tcd.ie> From: Vincent Breitmoser To: Stephen Farrell Date: Thu, 16 Apr 2015 10:32:18 +0200 In-reply-to: <5527B621.3040104@cs.tcd.ie> Message-ID: <87pp74e9js.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 08:57:43 -0000 I'd like to address two points: Can someone explain why key usage and preference flags for the primary were made part of user id signatures instead of a direct key signature or something of the sort? I felt like this added a lot of complexity and non-determinism to those parts of the implementation which dealt with that. Secondly, (this came up somewhere else), I'm not convinced at all that designated revokers (5.2.3.15) are a good idea. Is there a significant advantage over just handing the person a revocation certificate of your key? I remember deciding against implementing this feature at some point in OpenKeychain because the complexity/benefit tradeoff just wasn't there. - V From nobody Thu Apr 16 02:53: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 B84571B30BA for ; Thu, 16 Apr 2015 02:53: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, 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 LZDlUDqAQsb4 for ; Thu, 16 Apr 2015 02:53:24 -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 52BBD1B30B8 for ; Thu, 16 Apr 2015 02:53:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EEC51BED2; Thu, 16 Apr 2015 10:53:22 +0100 (IST) 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 5oxG8ddj3-XC; Thu, 16 Apr 2015 10:53:21 +0100 (IST) Received: from [10.87.48.73] (unknown [86.41.51.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 12E66BF14; Thu, 16 Apr 2015 10:53:21 +0100 (IST) Message-ID: <552F8690.3000109@cs.tcd.ie> Date: Thu, 16 Apr 2015 10:53:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Peter Gutmann , ianG , "openpgp@ietf.org" References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org>, <552EDAFD.60900@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AAFFB195@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFFB195@uxcn10-tdc05.UoA.auckland.ac.nz> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 09:53:25 -0000 Peter, On 16/04/15 03:36, Peter Gutmann wrote: > It went the other way as well. When I proposed in PKIX allowing users to > manage their own certificates rather than having to go to a CA to get them > issued and replaced: > > https://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt > > the response from the PKIX chair was "we're not going to turn X.509 into > PGP", and that was the end of it. > > The response to a proposal to replace the totally nonfunctional CRL blacklist > approach used by X.509 with a whitelist mechanism was even worse, amounting > to near-hysteria in some cases when I tried to push the issue (I've got some > of the emails saved somewhere, some of them came just short of saying "burn > the heretic!"). I don't see how that's really relevant or constructive for the discussion here. Re-visiting [x509|pgp|whatever]-bashing that may have been done in the past isn't interesting for me anyway unless there's some lesson to be learned and I don't see anything like that above. There are other lists where we can all vent and that are better venues for such. S. From nobody Thu Apr 16 03:16: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 20AEA1B30F0 for ; Thu, 16 Apr 2015 03:16:40 -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 1szM1VdfThAM for ; Thu, 16 Apr 2015 03:16:38 -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 2861C1B30EE for ; Thu, 16 Apr 2015 03:16:38 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yigqa-0004Wv-L6 for ; Thu, 16 Apr 2015 12:16:36 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YignF-00083A-OB; Thu, 16 Apr 2015 12:13:09 +0200 From: Werner Koch To: Vincent Breitmoser References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> 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: Vincent Breitmoser , Stephen Farrell , "openpgp\@ietf.org" Date: Thu, 16 Apr 2015 12:13:09 +0200 In-Reply-To: <87pp74e9js.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Thu, 16 Apr 2015 10:32:18 +0200") Message-ID: <87618w7556.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" , Stephen Farrell Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 10:16:40 -0000 On Thu, 16 Apr 2015 10:32, look@my.amazin.horse said: > Can someone explain why key usage and preference flags for the primary > were made part of user id signatures instead of a direct key signature Note that you may put them into a direct key signature. Assume you use the same key for home and work. You have two user ids but at home you use an implementation and preferences you like while at work you have to comply with company policies and thus different preferences. Right, that is a bit artifical and for example gpg uses a direct key signature or the latest user id to get the key flags and preferences. > or something of the sort? I felt like this added a lot of complexity > and non-determinism to those parts of the implementation which dealt > with that. Remember that you anyway need to implement a policy on how to work with multipe self-signatures on the same user id, or with multiple direct key signatures. > Secondly, (this came up somewhere else), I'm not convinced at all that > designated revokers (5.2.3.15) are a good idea. Is there a significant > advantage over just handing the person a revocation certificate of your > key? I remember deciding against implementing this feature at some point That requires that you still have access to a pre-generated revocation certificate and that that you are able to use it. A dedicated revoker certificate also allows to create a revocation certificate with a valid reason code and not just a catch-all reason code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Apr 16 05: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 546551A701C for ; Thu, 16 Apr 2015 05:02:59 -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 k0cwjR3pi5DK for ; Thu, 16 Apr 2015 05:02:58 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 E82BF1A7007 for ; Thu, 16 Apr 2015 05:02:57 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so56728878lbb.2 for ; Thu, 16 Apr 2015 05:02:56 -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=/zbnzsa4i4aB8i4Bklf0nrmXKzaqBkrVZBHM7kweBd0=; b=UsSnAN6Am3hevYmCbMokJqvCf4XReoOyQp3r3UBK3IFpoDn+fThXEXXE4dk482tVld Yqolpw0kLdqPaXHstR/M7nAjdujHXLLpFOvagr4CtJ0FU5pBAWGltvHg8zrJC+5FC+qv hHFePluh66KbX+IVV+N3wkCBpFLFTQy9e8M5qvcpOpVIejI/RMOAUlSqouT/WiIiWvAv ujVyQS2B/UJsG2ZYxmHOEsQ1ptjExpsfz+94aVZYrji1vfm4xNR6G9zPOQGc/kAfDIo1 gStdoF+WKxxPvZGmGDDa40GgNAH0A6V+Nvw0GNIaIvaj33R15XCrBO5CjAxlBh6RvUaU Attg== MIME-Version: 1.0 X-Received: by 10.152.87.162 with SMTP id az2mr28896725lab.58.1429185776356; Thu, 16 Apr 2015 05:02:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 16 Apr 2015 05:02:56 -0700 (PDT) In-Reply-To: <1429144776.1702.75.camel@scientia.net> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> Date: Thu, 16 Apr 2015 08:02:56 -0400 X-Google-Sender-Auth: jeE-gu944MCrMaN3y1SM9FIY53E 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] details of 4880bis work 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, 16 Apr 2015 12:02:59 -0000 On Wed, Apr 15, 2015 at 8:39 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-04-15 at 14:01 -0700, Jon Callas wrote: >> There was also a mention somewhere of removing the timestamp from the >> fingerprint, and that's what I really want to comment on. >> When 2440 started, removing the timestamp was one of the things I >> wanted to do. However, it's not such a bad thing. If you make a >> fingerprint merely be a function of the key (it has no variable data), >> then you lose the ability to alias the key, which is actually useful. > > I think the main problem with the valid from/through dates not being a > part of the fingerprint is the following: > > A user may intentionally want to limit his key for security reasons, > e.g. he makes a 1024 bit and wants to make sure that no one is > using/trusting it after two years anymore. That is an important requirement but putting the time info into the fingerprint is not the only way to address it. Operating PKIX, the lifetime of root keys and root certs is very different. Rolling over a root with the same key is common. The principal application of fingerprints is analogous to a root. That said, if we hash + rather than just , there is no need to commit to a single approach now. > That's why I think, that creation and expiration times should be > immutable once the key has been created; at least not without > invalidating all signatures (i.e. those from other users). At that point we are authenticating a self signed cert, not just the key and the dynamics are different. From nobody Thu Apr 16 05:03:18 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 E96351A89E0 for ; Thu, 16 Apr 2015 05:03:16 -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 JD6Yiz_sKwqy for ; Thu, 16 Apr 2015 05:03:14 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27331A7007 for ; Thu, 16 Apr 2015 05:03:14 -0700 (PDT) Received: from localhost (dhcp183-160.wlan.rz.tu-bs.de [134.169.183.160]) by mail.mugenguild.com (Postfix) with ESMTPSA id BC02C5FCD3; Thu, 16 Apr 2015 14:00:48 +0200 (CEST) References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> From: Vincent Breitmoser To: Werner Koch Date: Thu, 16 Apr 2015 13:19:09 +0200 In-reply-to: <87618w7556.fsf@vigenere.g10code.de> Message-ID: <87mw28e0w1.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 12:03:17 -0000 On 16 Apr 2015, Werner Koch wrote: > Assume you use the same key for home and work. You have two user > ids but at home you use an implementation and preferences you like > while at work you have to comply with company policies and thus > different preferences. The solution to this problem should be two keyrings. Different encryption settings per user id like this are completely out of scope for everyone who isn't familiar with the inner workings of RFC4880. Even assuming this was a useful feature, it is underspecified to a point where trying to figure out what an other implementation meant by some constellation of preferences in user ids or direct key signatures is little more than guesswork. > Remember that you anyway need to implement a policy on how to work > with multipe self-signatures on the same user id, or with multiple > direct key signatures. Just like gpg, we use the latest signature. Is there a reason this isn't specified? While I agree that the trust model should not be specified, leaving this kind of thing open just leads to confusion, unintended behavior which isn't even really a bug but just different interpretations by different developers, and complexity in an attempt to be compatible with de facto standards. I remember several discussions about this kind of thing between me and Dominik which went like "how's it specified?" - "it isn't." - "well, just look at gpg's source and do what they do". > A dedicated revoker certificate also allows to create a revocation > certificate with a valid reason code and not just a catch-all reason > code. That's a valid reason. It still means my import routine can't decide by the data of a keyring whether it's revoked or not, but may need another key lookup (and verification, ...) for it, reducing reliability of this kind of recovation. - V From nobody Thu Apr 16 05:58: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 676091A88A4 for ; Thu, 16 Apr 2015 05:58:23 -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 ayVVTmhh4t01 for ; Thu, 16 Apr 2015 05:58:21 -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 1737D1A889D for ; Thu, 16 Apr 2015 05:58:21 -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 E3ECA5FAED for ; Thu, 16 Apr 2015 12:58:19 +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 jmv8jYlaZORM for ; Thu, 16 Apr 2015 12:58:17 +0000 (UTC) Received: from [138.246.16.147] (unknown [138.246.16.147]) (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, 16 Apr 2015 12:58:17 +0000 (UTC) Message-ID: <1429189097.1702.85.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 16 Apr 2015 14:58:17 +0200 In-Reply-To: <87618w7556.fsf@vigenere.g10code.de> References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-HLobOvuHDe7G/C0cv8BO" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 12:58:23 -0000 --=-HLobOvuHDe7G/C0cv8BO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-04-16 at 12:13 +0200, Werner Koch wrote:=20 > On Thu, 16 Apr 2015 10:32, look@my.amazin.horse said: >=20 > > Can someone explain why key usage and preference flags for the primary > > were made part of user id signatures instead of a direct key signature >=20 > Note that you may put them into a direct key signature. >=20 > Assume you use the same key for home and work. You have two user ids > but at home you use an implementation and preferences you like while at > work you have to comply with company policies and thus different > preferences. This has however some problems, which I've mentioned already in my initial wishlist. - Nothing of this is really specified. One *may* interpret the standard that it is as you say above. - There is nothing specified that would resolve ambiguities (what if there's both, direct-key signature and user id sig, setting the same subpackets but with different properties)? > Right, that is a bit artifical and for example gpg uses a direct key > signature or the latest user id to get the key flags and preferences. =46rom the standards PoV, the same problem as above... nothing really specified what it means if e.g. flags are on a user sig or on a direct key sig. IMHO flags should anyway be immutable. > Remember that you anyway need to implement a policy on how to work with > multipe self-signatures on the same user id, or with multiple direct key > signatures. The standard didn't even specify that newer sigs would replaces older ones, right? IMO all quite fuzzy and vague... :( Cheers, Chris. --=-HLobOvuHDe7G/C0cv8BO 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNjEyNTgx N1owTwYJKoZIhvcNAQkEMUIEQF6fwOR2dcPMpyki1LyqE8b01rh5gT4vim7rKCCV1dx/qKaWNRzz R3yguRJ8i20GxhI/kxx5P0jVmU78Q5pjGycwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBawXr8yXHHG2+YAMhmzChNRqDI3tmE uWm85CkXhPrgF3lBSxaQFs1UFaPc9EYcsWUT/DrboSX8MoV56FkPa4RxriYnd+74cMI9rXT/3VEd uV/HSlGV0LjRxeec6cK036P9MsCO87E1HuNqDWjT3cDzHUpa8lSa8l8Cl13QhXcmqVcT08EqUfA5 FHg4HZsPvjdAJCy9bB1iXW5YrkK0DTAmAykXqvbSyM6ZgIqJCoghkRoI3+hJGDfu/wdlsYF2/R6S 0SES9OyTrehh6SUTrIi5+rBgvbNKYJwSNO3N4qgSzFoksIWTdX3b6zTFrauuabIb1+h4C+KkTrMy TGVBkns+AAAAAAAA --=-HLobOvuHDe7G/C0cv8BO-- From nobody Thu Apr 16 06: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 19A311B3170 for ; Thu, 16 Apr 2015 06:04:20 -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 SR15dNiIxGg6 for ; Thu, 16 Apr 2015 06:04:14 -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 B75E81B3171 for ; Thu, 16 Apr 2015 06:04:13 -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 90AD15FAFD for ; Thu, 16 Apr 2015 13:04:12 +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 JvTwaKJsk3QN for ; Thu, 16 Apr 2015 13:04:07 +0000 (UTC) Received: from [138.246.16.147] (unknown [138.246.16.147]) (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, 16 Apr 2015 13:04:07 +0000 (UTC) Message-ID: <1429189446.1702.90.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Thu, 16 Apr 2015 15:04:06 +0200 In-Reply-To: <87mw28e0w1.fsf@littlepip.fritz.box> References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-OhV0wuxyFwAzQsrMNha+" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 13:04:20 -0000 --=-OhV0wuxyFwAzQsrMNha+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-04-16 at 13:19 +0200, Vincent Breitmoser wrote:=20 > The solution to this problem should be two keyrings. You probably mean two keys? > Different > encryption settings per user id like this are completely out of scope > for everyone who isn't familiar with the inner workings of RFC4880. I don't agree at all. Actually we should make it finally usable that a person has only one primary (and certifying/certified) key,... and many subkeys which are usable for different use cases, which is right now practically impossible. And I think once it would be reasonably possible, it makes absolutely sense to have e.g. different key prefs depending on the UID and/or (role) subkey. > it is underspecified to a point > where trying to figure out what an other implementation meant by some > constellation of preferences in user ids or direct key signatures is > little more than guesswork. Yes. > Just like gpg, we use the latest signature. Is there a reason this > isn't specified? While I agree that the trust model should not be > specified, leaving this kind of thing open just leads to confusion Yes. IMO this vagueness may be even a security issue. Cheers. --=-OhV0wuxyFwAzQsrMNha+ 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNjEzMDQw N1owTwYJKoZIhvcNAQkEMUIEQK1Mb8ZZ7xoI20v+BZP29D+TXZ5FSBUpN9vnUlNc9APYwN1DCyyT qvsGzYVpGrU9CD2OTsaq2AswKmoiSkVa1sgwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBRO7+ufrTkmhrNpITbrsVitPzPywwy q3jXpgOQSPXAYmFHuMAElpquYz2ODtCfmvgNcYCmBcwLjEevyt6XQzRDsOcRllOQPLF2yDXvRbDB BKcNgJjN44rP8B4pY76dvxYxeNUb2QzDbJX7fyQ4idZEo0IcYFAQxn2BvNunDiCgLO0HPAN4EzQR 4OsQzLDQo+tqdPMzo52sH0egcVdsKoidueHImalNQMsOK2b7YZKbpLsC9K2TNCDJUp287pHuXbDY 9dcmYmxGc3CGbU18wJUBdlhJqjxoDhDBB+zIB7E5t6N/zWId/zETZyG0F9z188lEQMDE/wuknLYI u/rT8wC9AAAAAAAA --=-OhV0wuxyFwAzQsrMNha+-- From nobody Thu Apr 16 06:08:18 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 CC1DE1A8A5A for ; Thu, 16 Apr 2015 06:08:16 -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 5hFalwRJAxCz for ; Thu, 16 Apr 2015 06:08:15 -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 30D7C1A8A51 for ; Thu, 16 Apr 2015 06:08:15 -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 104AF5FAE0 for ; Thu, 16 Apr 2015 13:08:14 +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 cWW74uk1fMKs for ; Thu, 16 Apr 2015 13:08:08 +0000 (UTC) Received: from [138.246.16.147] (unknown [138.246.16.147]) (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, 16 Apr 2015 13:08:08 +0000 (UTC) Message-ID: <1429189688.1702.93.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Thu, 16 Apr 2015 15:08:08 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-n3zqwL9oFchWSECz0IBA" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 13:08:17 -0000 --=-n3zqwL9oFchWSECz0IBA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-04-16 at 08:02 -0400, Phillip Hallam-Baker wrote:=20 > That is an important requirement but putting the time info into the > fingerprint is not the only way to address it. How else would you want to do it? If you don't also put it in the fingerprint, than we could e.g. meet at a signing party, exchange our FPs,... I forget to sign yours, but remember a year later. I still have the fingerprint, but if that would stay the same, even though other dates have been set, I wouldn't notice this. > Operating PKIX, the lifetime of root keys and root certs is very > different. Rolling over a root with the same key is common. Which I think is a questionable practise... > > That's why I think, that creation and expiration times should be > > immutable once the key has been created; at least not without > > invalidating all signatures (i.e. those from other users). > At that point we are authenticating a self signed cert, not just the > key and the dynamics are different. ? Cheers. --=-n3zqwL9oFchWSECz0IBA 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxNjEzMDgw OFowTwYJKoZIhvcNAQkEMUIEQHZ6s7qwugOdikgAoT2wtbWPop0qmndzPvsTXxxR7W2nICuLzx5a PN1XKloT4cnf80LHz3l/oHh+AMF+AOzuk1AwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBbIM2ltB6ZpoFwvqnb47ejWsKxIcnO JK6Ti6YZTLLxjmiDmJMzeYKFZfwSmkLaCTk+nnhPutz6R7bbojY+Iwp+pYKgWXdQsZD0VXYULt7Q Xks434NYL5vCmNyDVtNrsoLP6kmvUS4MTyNJ/IwbZ4Z8noK2cg/vhdzM9ZTAVgAW02bqASfjryqd 8uaw9lTgQ9U2WbSNnc4vboBHwnaeecEFm7Z+0QkpbVbrVe/iolEcno7dz2FokjpXyCXzDb5U3CuM /6ZzdLJe9uT3q5AAcZdDz8VARWrAkTQoRzKN1Yz/hOZK0QBdh+gYOjJpgMiV+dlEBR8s/0+/6YGg THVxO2vNAAAAAAAA --=-n3zqwL9oFchWSECz0IBA-- From nobody Thu Apr 16 06:31: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 3BDB91AD1A6 for ; Thu, 16 Apr 2015 06:31:51 -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 HhjSoCg-3IyY for ; Thu, 16 Apr 2015 06:31:49 -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 DEBA21ACE4B for ; Thu, 16 Apr 2015 06:31:42 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id CEB9A6D7E9; Thu, 16 Apr 2015 09:31:40 -0400 (EDT) Message-ID: <552FB9B9.9080002@iang.org> Date: Thu, 16 Apr 2015 14:31:37 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> In-Reply-To: <1429189097.1702.85.camel@scientia.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 16 Apr 2015 13:31:51 -0000 So, the OpenPGP world has always separated policy from tech. It has in effect kicked policy upstairs to the people. Hence the key signing parties and the discordance between signing meaning "I saw a passport" versus "I saw a person". This we all agreed was the smart thing to do. However, Jon's revelation of yesterday really changed everything for me at least: > When 2440 started, there was an agreement with the Security > Area that OpenPGP would not be a "PKI" (whatever the heck > that means), because there was already a PKI, namely PKIX. This thread (below) is about PGP as "a PKI" in a world where we are used to (up against) "the PKI" or incumbent x.509/CA. Now that we're watching the slow burning sunset of "the PKI," and, now that we're looking at a whole new generation of usage for PGP (*), it may become more clear that we might have to revisit this. Context: I'm not saying I want to open up the debate. My context is that I'm already doing it. In effect I abandoned OpenPGP 2 years back so that I could build my own PKI to suit my today's requirements . To add further flesh to that, PHB is doing the same. Jon will also have something to say on this, and others... In short, the reality is that PKIs are evolving around us, so the question is not whether to do it, it's already happening. The question is whether to bring it back in house? iang (*) to explain "new generation" a bit. OpenPGP is a legacy product that deals with some niche use cases. In order to make it move forward, and in order to justify putting the rather huge shared resources into a new update, it would be nice to kick it forward to the current level of understanding ... so that if finds a whole new user base in the 2020s world (aiming ahead). I'm not saying what that is, just making a comment about market development. On 16/04/2015 13:58 pm, Christoph Anton Mitterer wrote: > On Thu, 2015-04-16 at 12:13 +0200, Werner Koch wrote: >> On Thu, 16 Apr 2015 10:32, look@my.amazin.horse said: >> >>> Can someone explain why key usage and preference flags for the primary >>> were made part of user id signatures instead of a direct key signature >> >> Note that you may put them into a direct key signature. >> >> Assume you use the same key for home and work. You have two user ids >> but at home you use an implementation and preferences you like while at >> work you have to comply with company policies and thus different >> preferences. > This has however some problems, which I've mentioned already in my > initial wishlist. > > - Nothing of this is really specified. One *may* interpret the standard > that it is as you say above. > - There is nothing specified that would resolve ambiguities (what if > there's both, direct-key signature and user id sig, setting the same > subpackets but with different properties)? > > >> Right, that is a bit artifical and for example gpg uses a direct key >> signature or the latest user id to get the key flags and preferences. > From the standards PoV, the same problem as above... nothing really > specified what it means if e.g. flags are on a user sig or on a direct > key sig. > IMHO flags should anyway be immutable. > > > >> Remember that you anyway need to implement a policy on how to work with >> multipe self-signatures on the same user id, or with multiple direct key >> signatures. > The standard didn't even specify that newer sigs would replaces older > ones, right? > > IMO all quite fuzzy and vague... :( > > Cheers, > Chris. > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Thu Apr 16 06:32: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 C36551B29AC for ; Thu, 16 Apr 2015 06:32:54 -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 hAe-W5o3zu86 for ; Thu, 16 Apr 2015 06:32:53 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B621AD362 for ; Thu, 16 Apr 2015 06:32:53 -0700 (PDT) Received: from localhost (dhcp183-160.wlan.rz.tu-bs.de [134.169.183.160]) by mail.mugenguild.com (Postfix) with ESMTPSA id 42C3B5FB9A; Thu, 16 Apr 2015 15:30:27 +0200 (CEST) References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> From: Vincent Breitmoser To: Christoph Anton Mitterer Date: Thu, 16 Apr 2015 15:26:24 +0200 In-reply-to: <1429189446.1702.90.camel@scientia.net> Message-ID: <87lhhsdwqn.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 13:32:54 -0000 > You probably mean two keys? I meant keyrings, as in primary keys + subkeys. > And I think once it would be reasonably possible, it makes absolutely > sense to have e.g. different key prefs depending on the UID and/or > (role) subkey. I agree. The phrase "out of scope" was probably misleading, I meant that it is right now completely intransparent to users that key settings may differ per user id, and that something might be differently encrypted to one user id than to another in the same keyring. I also suspect that this is simply not true for many implementations - in the API we designed for OpenKeychain, the user id to encrypt to is not even part of the parameters. - V From nobody Thu Apr 16 08:00: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 0364E1A00BE for ; Thu, 16 Apr 2015 08:00:01 -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 cn2kLlnxE75J for ; Thu, 16 Apr 2015 07:59:59 -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 418331A1BA2 for ; Thu, 16 Apr 2015 07:58:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 1BCCFE2035; Thu, 16 Apr 2015 10:58:58 -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 09028-09; Thu, 16 Apr 2015 10:58:56 -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 A7D1FE2034; Thu, 16 Apr 2015 10:58:56 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3GEwuw9016679; Thu, 16 Apr 2015 10:58:56 -0400 From: Derek Atkins To: ianG References: <5527B621.3040104@cs.tcd.ie> <5527E9F9.7010505@iang.org> Date: Thu, 16 Apr 2015 10:58:55 -0400 In-Reply-To: <5527E9F9.7010505@iang.org> (iang@iang.org's message of "Fri, 10 Apr 2015 16:19:21 +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: openpgp@ietf.org Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 15:00:01 -0000 ianG writes: >> f) standardize the two new curves coming out of the CFRG: 25519 and >> curve448 ("goldilocks") for both signatures and encryption (Werner >> has already started this process for 25519 signatures) > > > Why two curves? Is this just the algorithm agility discussion or is > there an actual difference between them? Why not just use the > stronger one and be done with it? > > (Not wishing to start the algorithm agility debate, I'm sure > everyone's familiar with the basics there, just wondering if there is > any other motivation.) Speed/Security tradeoff. The two curves appear to be Curve25519 and then Goldilocks-448. The former is significantly faster than the latter, so there is a desire for two curves to allow the speed/security tradeoff. >> l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD >> mechanism should be the baseline. > > > No RSA? Is there consensus amongst devs that enough of us aren't > going to implement RSA anyway? We're ready to make a clean break, and > actually mitigate against it? Just because RSA isn't MTI algorithm doesn't mean that it WONT get implemented. AES isn't MTI and most implementations seem to support it today. There's is a relatively small difference between MUST and SHOULD, a larger difference between SHOULD and MAY, and a large canyon between MAY and *NOT. I believe the suggestions here are MUST v SHOULD. > (I'm happy to join the witch-burning party, but it's had such long > legs, it saw off the DSA challenger even tho many tried to kill it.) > > > > iang -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 16 08:06: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 CACAF1A0084 for ; Thu, 16 Apr 2015 08:06:04 -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 Z1gLhTyNH02L for ; Thu, 16 Apr 2015 08:06:02 -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 0E7BF1A00CD for ; Thu, 16 Apr 2015 08:06:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC2EEBF02; Thu, 16 Apr 2015 16:05:59 +0100 (IST) 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 HiZ8qi8aiks0; Thu, 16 Apr 2015 16:05:59 +0100 (IST) 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 A7FF8BF08; Thu, 16 Apr 2015 16:05:57 +0100 (IST) Message-ID: <552FCFD6.9040806@cs.tcd.ie> Date: Thu, 16 Apr 2015 16:05:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ianG , openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> In-Reply-To: <552FB9B9.9080002@iang.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 16 Apr 2015 15:06:04 -0000 To the extent that this is not openpgp specific, we have an occasionally active list (therightkey@ietf.org) for topics like that. So far though, I don't think anyone's gotten much traction for anything on that, with the exception of CT that turned into RFC6692 and now the trans WG. But if you want a generic discussion of "whither now PKI" that is probably the most appropriate IETF list. (Non-IETF lists might also be appropriate too, depending on what you want.) If you want an openpgp-specific discussion, that it'd be this list, even if it's not so likely that a new WG would work on that, or at least anytime very soon. (That's based on the responses we got for doing "option 2" etc.) I'm not clear if you wanted an openpgp specific discussion or not though. (And the subject line combined with your mail saying "I'm not saying I want to open up the debate" also puzzled me mightily;-) S. On 16/04/15 14:31, ianG wrote: > So, the OpenPGP world has always separated policy from tech. It has in > effect kicked policy upstairs to the people. Hence the key signing > parties and the discordance between signing meaning "I saw a passport" > versus "I saw a person". This we all agreed was the smart thing to do. > > However, Jon's revelation of yesterday really changed everything for me > at least: > > > > When 2440 started, there was an agreement with the Security > > Area that OpenPGP would not be a "PKI" (whatever the heck > > that means), because there was already a PKI, namely PKIX. > > > This thread (below) is about PGP as "a PKI" in a world where we are used > to (up against) "the PKI" or incumbent x.509/CA. Now that we're > watching the slow burning sunset of "the PKI," and, now that we're > looking at a whole new generation of usage for PGP (*), it may become > more clear that we might have to revisit this. > > > > Context: I'm not saying I want to open up the debate. My context is > that I'm already doing it. In effect I abandoned OpenPGP 2 > years back so that I could build my own PKI to suit my today's > requirements . To add further flesh to that, PHB is doing the > same. Jon will also have something to say on this, and others... > > In short, the reality is that PKIs are evolving around us, so the > question is not whether to do it, it's already happening. > > The question is whether to bring it back in house? > > > iang > > > > (*) to explain "new generation" a bit. OpenPGP is a legacy product that > deals with some niche use cases. In order to make it move forward, and > in order to justify putting the rather huge shared resources into a new > update, it would be nice to kick it forward to the current level of > understanding ... so that if finds a whole new user base in the 2020s > world (aiming ahead). I'm not saying what that is, just making a > comment about market development. > > > On 16/04/2015 13:58 pm, Christoph Anton Mitterer wrote: >> On Thu, 2015-04-16 at 12:13 +0200, Werner Koch wrote: >>> On Thu, 16 Apr 2015 10:32, look@my.amazin.horse said: >>> >>>> Can someone explain why key usage and preference flags for the primary >>>> were made part of user id signatures instead of a direct key signature >>> >>> Note that you may put them into a direct key signature. >>> >>> Assume you use the same key for home and work. You have two user ids >>> but at home you use an implementation and preferences you like while at >>> work you have to comply with company policies and thus different >>> preferences. >> This has however some problems, which I've mentioned already in my >> initial wishlist. >> >> - Nothing of this is really specified. One *may* interpret the standard >> that it is as you say above. >> - There is nothing specified that would resolve ambiguities (what if >> there's both, direct-key signature and user id sig, setting the same >> subpackets but with different properties)? >> >> >>> Right, that is a bit artifical and for example gpg uses a direct key >>> signature or the latest user id to get the key flags and preferences. >> From the standards PoV, the same problem as above... nothing really >> specified what it means if e.g. flags are on a user sig or on a direct >> key sig. >> IMHO flags should anyway be immutable. >> >> >> >>> Remember that you anyway need to implement a policy on how to work with >>> multipe self-signatures on the same user id, or with multiple direct key >>> signatures. >> The standard didn't even specify that newer sigs would replaces older >> ones, right? >> >> IMO all quite fuzzy and vague... :( >> >> Cheers, >> Chris. >> >> >> >> _______________________________________________ >> 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 > > From nobody Thu Apr 16 08:20: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 AAECF1A87DB for ; Thu, 16 Apr 2015 08:20:02 -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 NihHMv-sN94z for ; Thu, 16 Apr 2015 08:19:57 -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 A32481A87BD for ; Thu, 16 Apr 2015 08:19:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 88F47E2036; Thu, 16 Apr 2015 11:19:56 -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 09324-05; Thu, 16 Apr 2015 11:19:54 -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 B08C0E2034; Thu, 16 Apr 2015 11:19:54 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3GFJr8h017646; Thu, 16 Apr 2015 11:19:53 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> Date: Thu, 16 Apr 2015 11:19:52 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 16 Apr 2015 08:02:56 -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: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 15:20:02 -0000 Phillip Hallam-Baker writes: > On Wed, Apr 15, 2015 at 8:39 PM, Christoph Anton Mitterer > wrote: >> On Wed, 2015-04-15 at 14:01 -0700, Jon Callas wrote: >>> There was also a mention somewhere of removing the timestamp from the >>> fingerprint, and that's what I really want to comment on. >>> When 2440 started, removing the timestamp was one of the things I >>> wanted to do. However, it's not such a bad thing. If you make a >>> fingerprint merely be a function of the key (it has no variable data), >>> then you lose the ability to alias the key, which is actually useful. >> >> I think the main problem with the valid from/through dates not being a >> part of the fingerprint is the following: >> >> A user may intentionally want to limit his key for security reasons, >> e.g. he makes a 1024 bit and wants to make sure that no one is >> using/trusting it after two years anymore. > > That is an important requirement but putting the time info into the > fingerprint is not the only way to address it. True, but it's IMHO the best way in OpenPGP terms. > Operating PKIX, the lifetime of root keys and root certs is very > different. Rolling over a root with the same key is common. The > principal application of fingerprints is analogous to a root. Yes, but in PKIX you have the serial number. We don't have that in OpenPGP, and frankly I don't think we do need it or want it. > That said, if we hash + rather than just , > there is no need to commit to a single approach now. > >> That's why I think, that creation and expiration times should be >> immutable once the key has been created; at least not without >> invalidating all signatures (i.e. those from other users). > > At that point we are authenticating a self signed cert, not just the > key and the dynamics are different. Not really. The creation and expiration times in the "key" are (IIRC) included not just in the self-singatures but also in all the additional certification signatures, too. I agree that if the Key has a creation date and expiration date then those items should be immutable. If the user wants to generate a new "key" using the same key material (generally a bad idea, IMHO) then it should be considered a different key (and as a result have a different fingerprint). If the user believes that they might, down the road, want to re-certfiy their key then the way to do that, IMHO, is to leave out the expiration date in the key packet and just use the expiration date in the self-signature to "time out" the key. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 16 08:25: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 5DD8F1A88D2 for ; Thu, 16 Apr 2015 08:25:18 -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 48smOqDeOMhE for ; Thu, 16 Apr 2015 08:25:17 -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 235AA1A88C2 for ; Thu, 16 Apr 2015 08:25:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 09BBEE2036; Thu, 16 Apr 2015 11:25:16 -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 09324-06; Thu, 16 Apr 2015 11:25:09 -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 04433E2034; Thu, 16 Apr 2015 11:25:08 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3GFP7l2017863; Thu, 16 Apr 2015 11:25:07 -0400 From: Derek Atkins To: Vincent Breitmoser References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> Date: Thu, 16 Apr 2015 11:25:07 -0400 In-Reply-To: <87lhhsdwqn.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Thu, 16 Apr 2015 15:26:24 +0200") 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] details of 4880bis work 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, 16 Apr 2015 15:25:18 -0000 Vincent Breitmoser writes: >> You probably mean two keys? > > I meant keyrings, as in primary keys + subkeys. I must admit that given my 23-year history with PGP/OpenPGP, that is *NOT* my personal definition of "keyring". At least it's not where my brain goes first when I see that word (it goes to the data file that contains my local cache of all users' keys). Ah, English -- so many ways to say the same thing.. or too few.. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 16 08:29: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 CCBB51A890F for ; Thu, 16 Apr 2015 08:29:12 -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 f69MibbWHc0i for ; Thu, 16 Apr 2015 08:29:11 -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 9D59E1A87C2 for ; Thu, 16 Apr 2015 08:29:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 67E77E2038; Thu, 16 Apr 2015 11:29:10 -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 09484-02; Thu, 16 Apr 2015 11:29:09 -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 CF059E2034; Thu, 16 Apr 2015 11:29:08 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3GFT7uJ018017; Thu, 16 Apr 2015 11:29:07 -0400 From: Derek Atkins To: ianG References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> Date: Thu, 16 Apr 2015 11:29:07 -0400 In-Reply-To: <552FB9B9.9080002@iang.org> (iang@iang.org's message of "Thu, 16 Apr 2015 14:31:37 +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: openpgp@ietf.org Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 16 Apr 2015 15:29:13 -0000 Ian, ianG writes: > Context: I'm not saying I want to open up the debate. My context is > that I'm already doing it. In effect I abandoned OpenPGP 2 > years back so that I could build my own PKI to suit my today's > requirements . To add further flesh to that, PHB is doing > the same. Jon will also have something to say on this, and others... > > In short, the reality is that PKIs are evolving around us, so the > question is not whether to do it, it's already happening. > > The question is whether to bring it back in house? I'm not sure why you need to abandon OpenPGP to do this. Me, I'm building a PKI *using* OpenPGP. It's actually working quite well, although I wish there were more standard ways to do the things I need/want to do. But there's definitely enough flexibility in 4880 to do everything I want/need. Perhaps what we need is (as already suggested by Jon) a document or set of documents that define how to do different types of PKI using OpenPGP data structures. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 16 08:39: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 182DA1A8AD6 for ; Thu, 16 Apr 2015 08:39:42 -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 oVYa3544y69z for ; Thu, 16 Apr 2015 08:39:41 -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 483DF1A8AA7 for ; Thu, 16 Apr 2015 08:39:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 365ADE2035; Thu, 16 Apr 2015 11:39:40 -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 09484-07; Thu, 16 Apr 2015 11:39:38 -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 BC03BE2034; Thu, 16 Apr 2015 11:39:38 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3GFdb96018492; Thu, 16 Apr 2015 11:39:37 -0400 From: Derek Atkins To: Christoph Anton Mitterer References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131461.1702.52.camel@scientia.net> Date: Thu, 16 Apr 2015 11:39:37 -0400 In-Reply-To: <1429131461.1702.52.camel@scientia.net> (Christoph Anton Mitterer's message of "Wed, 15 Apr 2015 22:57:41 +0200") 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] Fingerprints 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, 16 Apr 2015 15:39:42 -0000 Christoph Anton Mitterer writes: > On Wed, 2015-04-15 at 16:21 -0400, David Shaw wrote: >> Using a string is fine, but even with numbers, there is no rule that >> the number has to be a single byte. After enough years and algorithms >> added, it could be "100000:ABCDEF0123..." > But numbers would make problems if we're using the binary representation > of the fingerprint (i.e. not the ASCII/UTF8 version of it). > How should one know where the algo type ends, 0x0 can't be used since it > may be part of the number. > So it can only be done if the algo type is defined to be a (null > terminated) string. It's easy -- all algorithms are currently defined to be <= 127. If we need more than that we can use base-128 encoding. I.e., the number is self-length-encoded in a way that you always know when the number ends. The benefit of using a number instead of a string is that in the vast majority (probably 99.999%) of use cases we'll be within the 127-value limitation so we can encode it in exactly one byte. A string will always require at least two bytes, and that only gives you ~52 options. > Cheers, > Chris. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 16 08:40:44 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41091A8A94 for ; Thu, 16 Apr 2015 08:40:42 -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 iWnEHnmUxZ19 for ; Thu, 16 Apr 2015 08:40:35 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480DE1A8AEC for ; Thu, 16 Apr 2015 08:40:35 -0700 (PDT) Received: from localhost (dhcp183-160.wlan.rz.tu-bs.de [134.169.183.160]) by mail.mugenguild.com (Postfix) with ESMTPSA id 167BA5FB9A; Thu, 16 Apr 2015 17:38:09 +0200 (CEST) References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> From: Vincent Breitmoser To: Derek Atkins Date: Thu, 16 Apr 2015 17:28:14 +0200 In-reply-to: Message-ID: <87k2xcdqtt.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 15:40:43 -0000 > I must admit that given my 23-year history with PGP/OpenPGP, that is > *NOT* my personal definition of "keyring". At least it's not where > my brain goes first when I see that word (it goes to the data file > that contains my local cache of all users' keys). My use of the term was misleading I must admit, going by 4880. I just always found it confusing that a "public key" in OpenPGP lingo means "a collection of one primary key and some subkeys", where each of those is a 'public key' in itself in a cryptographical sense. - V From nobody Thu Apr 16 10:46: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 1FA4F1B33A1 for ; Thu, 16 Apr 2015 10:46:31 -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 EMU6uG3nPpoZ for ; Thu, 16 Apr 2015 10:46:29 -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 6C5891B33A2 for ; Thu, 16 Apr 2015 10:46:28 -0700 (PDT) Received: by labbd9 with SMTP id bd9so62538997lab.2 for ; Thu, 16 Apr 2015 10:46: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=dGxHYrJ9zChSjIF0+GMFKqasUgQOXk1OI2xLwxC1nok=; b=NwvQ3OnAONuFrAibuTmpgcp+gzQ1q3TN+mFKlbEd7A3YGcQ6JVh2oNhQtZMSTiOo15 4RU+xHnhVQjj/26J2GYRT05AMWYF6k8KfZ7PSxYSC1XpGvYegoMpNuYIdzOUzu7uHrnA 4eEj2C07RVrt6Do59EQqMRvkIulAbnDVryodfroCzP8jv1U9oqvZIquQcMamkeCjCyMy KbFLJrIChrstVt6VV92rvMmXn6SFT3dYkkj0Ir1lqPVDqjuiVQoWeeJwyPgBqlirxkGb Qdt/OqEuTuE9pSf24+KeZgLUNCmRa46t680bA6ViQ6/fHIWCHhJflbhsFUoCrAkgKZFN vXNQ== MIME-Version: 1.0 X-Received: by 10.152.4.136 with SMTP id k8mr29654769lak.103.1429206386908; Thu, 16 Apr 2015 10:46:26 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Thu, 16 Apr 2015 10:46:26 -0700 (PDT) In-Reply-To: References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131461.1702.52.camel@scientia.net> Date: Thu, 16 Apr 2015 13:46:26 -0400 X-Google-Sender-Auth: oJI_TfoR_8RTW5h6WORwZIk8qEI Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 16 Apr 2015 17:46:31 -0000 Responding to multiple threads, trying to inject some precision... If people are happy with what I propose here, I can get a draft started. Just to be clear here, there are two separate places where an identifier might occur: Fingerprint = + Hash ( , ) Registering a new code should be rare. We don't yet have consensus on whether is needed but it certainly does not hurt and adding it solves many of the problems that would otherwise require us to cut a new . In this scheme there is no need to cut a new ID for the PKIX KeyInfo blobs I want for vanity crypto or for a SAML assertion or a JOSE key blob. Which means that we also have complete flexibility to introduce a completely different PGP key format at a later date. [Detail] To be precise, the option is Fingerprint = + H( , ) Where H (c, d) might be Hash (c +d) or Hash (c + Hash (d)). Using the second form allows existing hashes to be converted to data fingerprints. And that can come in handy in a lot of situations. And for completeness, and to get everything straight, let me add: DisplayedFingerprint = Base32-ify (Fingerprint , n) TruncatedFingerprint = Trunc (Fingerprint, n) URIEncoding = + ":" + DisplayedFingerprint Note that there is no need for a length on the Displayed fingerprint. The precise definition of Base32-ify (x, n) and Trunc (x, n) are not yet specified. Since Base32 encodes 5 bytes at a time and this is not a multiple of 8, there is a possibility that the fingerprint does not 'round trip' between ASCII and binary forms. We can discuss that in detail later and the question of whether we want to include some sort of checksum on each block. If we are working in blocks of 5 characters, we might want to use one bit for a running parity which has the pleasing effect that each 5 character block represents 3 binary bytes. At the moment the consensus proposal seems to be that Fingerprint-ID is a numeric code that has exactly two entries. I suggest: 96: SHA-2-512 144: SHA-3-512 These numbers are not completely random. While the codes themselves don't matter, using 0x60 and 0x90 has the pleasing and convenient effect that SHA-2-512 fingerprints will always start with the letter M (for Merkle-Damgard) and SHA-3-512 fingerprints will always start with the letter S (for Spongeworthy). I suggest that we use a choice of either + ":" This does not need to be a closed registry. The only requirement is that the identifiers be unique and unambiguous. In normal circumstances the content type for a key in PGP format is simply 'application/pgp-key'. Allowing any entry in the URN repository means we get OIDs for free: Lets say you want to use Ed2555 and this does not (yet) have a PGP number assigned: http://www.ietf.org/mail-archive/web/openpgp/current/msg07321.html The text representation of the OID is 1.3.6.1.4.1.11591.15.1. So the content type identifier is "urn:oid:1.3.6.1.4.1.11591.15.1" This approach is preferred over using the byte encoding of the OID because it does not require an encoder. People can use any crypto they like including experimental and vanity crypto without any impact on the IETF or IANA. The group has not discussed a URI form of the fingerprint but allocating a URI for any identifier should be routine. Given the key role fingerprints play, it is obvious someone will want a URI somewhere. Just defining the URI is probably enough to use the key with SAML for example. If specified, there should be exactly one prefix and it is probably best if we define something that is neutral. Something like 'Uniform Data Fingerprint' (UDF). Security considerations: Fingerprints are brittle. While it is very difficult to cause a collision even with a short fingerprint, unintended variations in the calculation of a fingerprint can occur unless great care is taken. From nobody Thu Apr 16 12:26: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 F2D3C1A88D5 for ; Thu, 16 Apr 2015 12:26:41 -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 rCx2rE8-Kerv for ; Thu, 16 Apr 2015 12:26:40 -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 E5EE61A1A3D for ; Thu, 16 Apr 2015 12:26:39 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YipQs-0000cE-2f for ; Thu, 16 Apr 2015 21:26:38 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YipLr-00019C-MY; Thu, 16 Apr 2015 21:21:27 +0200 From: Werner Koch To: Vincent Breitmoser References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> 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: Vincent Breitmoser , Christoph Anton Mitterer , openpgp@ietf.org Date: Thu, 16 Apr 2015 21:21:27 +0200 In-Reply-To: <87lhhsdwqn.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Thu, 16 Apr 2015 15:26:24 +0200") Message-ID: <87pp736frc.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: Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] details of 4880bis work 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, 16 Apr 2015 19:26:42 -0000 On Thu, 16 Apr 2015 15:26, look@my.amazin.horse said: > I meant keyrings, as in primary keys + subkeys. We use the term keyblock for this. See 6.2. Forming ASCII Armor. A keyring is a collection of keyblocks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Apr 17 06:38: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 2AE0F1B2C3D for ; Fri, 17 Apr 2015 06:38:29 -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 7jTjcRjBcUPT for ; Fri, 17 Apr 2015 06:38: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 7E15D1B2C89 for ; Fri, 17 Apr 2015 06:38:25 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id B02BD6D7A1; Fri, 17 Apr 2015 09:38:23 -0400 (EDT) Message-ID: <55310CCE.8050003@iang.org> Date: Fri, 17 Apr 2015 14:38:22 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 17 Apr 2015 13:38:29 -0000 On 16/04/2015 16:29 pm, Derek Atkins wrote: > Ian, > > ianG writes: > >> Context: I'm not saying I want to open up the debate. My context is >> that I'm already doing it. In effect I abandoned OpenPGP 2 >> years back so that I could build my own PKI to suit my today's >> requirements . To add further flesh to that, PHB is doing >> the same. Jon will also have something to say on this, and others... >> >> In short, the reality is that PKIs are evolving around us, so the >> question is not whether to do it, it's already happening. >> >> The question is whether to bring it back in house? > > I'm not sure why you need to abandon OpenPGP to do this. Me, I'm > building a PKI *using* OpenPGP. It's actually working quite well, > although I wish there were more standard ways to do the things I > need/want to do. But there's definitely enough flexibility in 4880 to > do everything I want/need. Right, that was what I was doing until recently. Hence my historical interest in OpenPGP. What caused the shift was a combination of bugs & failures, and outright cost. I was working to get old software up and going, and had to get three different implementations of OpenPGP to behave. I failed on all three, for different reasons. So in the end I bit the bullet and wrote the stuff I needed directly [0] [1] [2]. > Perhaps what we need is (as already suggested by Jon) a document or set > of documents that define how to do different types of PKI using OpenPGP > data structures. I would say: let's ground it to experience. I'm uninterested in the pontifications of a group of cafe academics. If you have real cases that are working for you, I'm interested in seeing that document. iang [0] It took 1 month to write and another month to roll out through the rest of the code. Since then it's been golden, a lot smaller, all totally aligned. The older code bases probably cost me from 1-2 months of delay just in failing to get them going. The first one that failed was Perl OpenPGP which relied on some maths library that just refused to install. So this caused me to write the entire Perl application into Java - at a cost of 1-2m, but I always wanted to eliminate Perl ;) The second failure was a combination of ye olde Cryptix and BouncyCastle OpenPGP implementations. Part of the factor was that I drowned in the lower layer packets and APIs that just weren't documented enough, and the code was huge and opaque and comment shy. Another part was dependency on JCE. I hit something that was impossible on Android, too many dependencies, and decided enough was enough. [1] Topic drift: The approach I employ is also highly distinct to the older ways of doing things. In the past, good design was based on packets and APIs. We heavily standardised the packets & algs, then composed up from there, providing an API to build from individual bricks and knobs. In a newer emerging method, if I may call it that, we standardise on high level interfaces and instead build vertical silo mini-protocols. I now have a series of these heavy weight objects that do entire higher-level protocol things, that in some cases compose on other such objects. However the internals of how they do it aren't the standard. DJB's cryptobox is an example of this approach in the wild. In contrast, the anti-pattern is Java's JCA. There, you pass in strings like "AES/CBC/HMACSHA1" and have the Java Control Engine compose the things you're allowed to do. Just to make the point, this is bad. [2] It's also worth mentioning that back in the old days I had a team of people doing this stuff. These days, it's just me. So cost of development is a real killer issue. I'm always looking for ways to build big powerful crypto stuff efficiently... From nobody Fri Apr 17 06:44: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 38B6C1B2CE8 for ; Fri, 17 Apr 2015 06:44:10 -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 m9ldXlpZMJom for ; Fri, 17 Apr 2015 06:44: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 E9A4D1B2CE7 for ; Fri, 17 Apr 2015 06:44:08 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 07B8C6D7A1; Fri, 17 Apr 2015 09:44:05 -0400 (EDT) Message-ID: <55310E24.10403@iang.org> Date: Fri, 17 Apr 2015 14:44:04 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> <552FCFD6.9040806@cs.tcd.ie> In-Reply-To: <552FCFD6.9040806@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 17 Apr 2015 13:44:10 -0000 On 16/04/2015 16:05 pm, Stephen Farrell wrote: > > To the extent that this is not openpgp specific, we have an > occasionally active list (therightkey@ietf.org) for topics > like that. So far though, I don't think anyone's gotten much > traction for anything on that, with the exception of CT that > turned into RFC6692 and now the trans WG. But if you want a > generic discussion of "whither now PKI" that is probably the > most appropriate IETF list. (Non-IETF lists might also be > appropriate too, depending on what you want.) (Just on that point alone, I think the better approach is to just do it. Build it, show it works, and then worry about dox later on. The solution on the table will drive the standardisation process.) > If you want an openpgp-specific discussion, that it'd be this > list, even if it's not so likely that a new WG would work on > that, or at least anytime very soon. (That's based on the > responses we got for doing "option 2" etc.) > > I'm not clear if you wanted an openpgp specific discussion > or not though. Yes, I was specifically speaking to openpgp, and more specifically speaking to the straw poll you raised a few weeks ago over whether to investigate the 't' in the 4 variants. > (And the subject line combined with your > mail saying "I'm not saying I want to open up the debate" > also puzzled me mightily;-) Indeed ;) The point is, I think a lot of people might have not realised that there was a "higher force" pushing OpenPGP in the direction of not building a PKI. It will take time for people to think about that, so I don't expect any change. But next time this opportunity arises, there is now more data on the table. I suspect in slow time this debate will open up now. iang From nobody Fri Apr 17 07:24: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 831211B2D5F for ; Fri, 17 Apr 2015 07:24:52 -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 QmVhY4OS0aCm for ; Fri, 17 Apr 2015 07:24:51 -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 8BD7E1B2D62 for ; Fri, 17 Apr 2015 07:24:49 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 5AA476D7A9; Fri, 17 Apr 2015 10:24:48 -0400 (EDT) Message-ID: <553117AF.9070205@iang.org> Date: Fri, 17 Apr 2015 15:24:47 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131461.1702.52.camel@scientia.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 17 Apr 2015 14:24:52 -0000 On 16/04/2015 18:46 pm, Phillip Hallam-Baker wrote: > > > At the moment the consensus proposal seems to be that Fingerprint-ID > is a numeric code that has exactly two entries. I don't know why we'd do both. I suppose it's because hashes are like mountains and seeing them, we have to walk up them. If there are two, we have to walk up and down twice... > I suggest: > > 96: SHA-2-512 > 144: SHA-3-512 In the unfortunate event that we allocate multiple hashes + numbers, then I suggest we also allocate an X that is to be used for closed, internal trials. This way, people are less likely to homestead spots and then come to us with arguments about how they're using ABC and they don't want people to change and bla bla. > These numbers are not completely random. While the codes themselves > don't matter, using 0x60 and 0x90 has the pleasing and convenient > effect that SHA-2-512 fingerprints will always start with the letter M > (for Merkle-Damgard) and SHA-3-512 fingerprints will always start with > the letter S (for Spongeworthy). OK, cautious nod to the letters - although it would be pleasing if you could point to a web calculator that could lay out the conversions for those of us who've forgotten how do to hex-b32-ascii-dec in our head ;) What is the extension strategy for when we've exhausted the 256 possibilities in a byte? (Yes I realise you didn't specify a byte, but I guess that's part of the question.) We ourselves don't want more than a handful. But if we open up the fingerprint standard to a wider audience, then austerity will be out the window. What's our approach of the TLS group decides they want to add a few hundred? iang From nobody Fri Apr 17 10:00: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 3F1B91A8868 for ; Fri, 17 Apr 2015 09:59:56 -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 xaB6w6XL3QoD for ; Fri, 17 Apr 2015 09:59:48 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 9FB631A8854 for ; Fri, 17 Apr 2015 09:59:45 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so87905884lbb.0 for ; Fri, 17 Apr 2015 09:59:44 -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=rftR7lZ9GiFwbdINmtKkk1k7UDaySJGv7UdJlDXCgWM=; b=J4cgcTar9Q8XtSwn1yggbO5vktpZt/ftgtCkbGokp4Bprp3XOIx0CuZDQoCBTUhANn DTJiQzw7Nsyl9GvyzMAxGFosVs7KZs8oYMPGd8VloadRO8qv6DMN/lvp1bCwrom79KBg eyci5Gu4EHpe4ax+0cfGsXAFjYrCu5WXo5paiZ9Pc7XtNZTrOtPvXuYn04+zWk8gOEIv owt56lAihVcbi+3PODM5AUF74M8NERdSsUwZ8puBNFAZNz3vmJmnYO5bfHMHaPicYouF zk/2h3a4Og3HPkRw2wWOEvyPrdVrRVySyjhprNL4H0DB3nJibQandgApKGuvqZPpDGWl VAng== MIME-Version: 1.0 X-Received: by 10.112.198.225 with SMTP id jf1mr5022099lbc.91.1429289983990; Fri, 17 Apr 2015 09:59:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Fri, 17 Apr 2015 09:59:43 -0700 (PDT) In-Reply-To: <553117AF.9070205@iang.org> References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131461.1702.52.camel@scientia.net> <553117AF.9070205@iang.org> Date: Fri, 17 Apr 2015 12:59:43 -0400 X-Google-Sender-Auth: htm7lL6BuT3t2Qz49logWcF1gDA Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprints 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, 17 Apr 2015 16:59:56 -0000 On Fri, Apr 17, 2015 at 10:24 AM, ianG wrote: > On 16/04/2015 18:46 pm, Phillip Hallam-Baker wrote: > >> >> >> At the moment the consensus proposal seems to be that Fingerprint-ID >> is a numeric code that has exactly two entries. > > I don't know why we'd do both. I suppose it's because hashes are like > mountains and seeing them, we have to walk up them. If there are two, we > have to walk up and down twice... It is very much the settled consensus now that proliferating crypto algorithms is a bad thing. The security of a system is determined by its weakest algorithm, not the strongest. So we need the number of algorithms to be as small as possible. The number of algorithms has to be greater than zero. Systems that have a single algorithm that cannot be changed have also resulted in real problems. People tend to hard code code paths in the expectation that they will never change. So for all those reasons, the approach that seems to work best as the general rule is exactly one mandatory to implement and exactly one recommended alternative as a backup. Given that we only have two hash algorithms that are likely candidates, the only real discussion is which of the two should be mandatory to implement for use in OpenPGP. Which is a discussion we can and should defer to later. Right now I can make a fairly good argument that SHA-2 is the better pick based on the facts as they stand today. I do not expect those facts to be the same in 18 months time. But right now I don't have SHA-3 implementations on my platform and nor do many others. And I really don't want to spend time writing a library or using code from other sources when I know that I am certain to have a BSD/MIT licensed alternative from a well resourced vendor in a short space of time. >> I suggest: >> >> 96: SHA-2-512 >> 144: SHA-3-512 > > In the unfortunate event that we allocate multiple hashes + numbers, then I > suggest we also allocate an X that is to be used for closed, internal > trials. This way, people are less likely to homestead spots and then come > to us with arguments about how they're using ABC and they don't want people > to change and bla bla. I don't think this is a problem. I very much doubt anyone will want to argue for an algorithm that is not SHA-2 or SHA-3 and one of the main reasons to choose the 512 bit versions and truncate is that it removes the incentive to argue for one of the shorter versions. The reason to pre-allocate the two spots now is precisely to remove the incentive for homesteading. Right now I don't have SHA-3 but I need something to test. We are definitely going to see homesteading if we don't declare a spot for SHA-2. >> These numbers are not completely random. While the codes themselves >> don't matter, using 0x60 and 0x90 has the pleasing and convenient >> effect that SHA-2-512 fingerprints will always start with the letter M >> (for Merkle-Damgard) and SHA-3-512 fingerprints will always start with >> the letter S (for Spongeworthy). > > OK, cautious nod to the letters - although it would be pleasing if you could > point to a web calculator that could lay out the conversions for those of us > who've forgotten how do to hex-b32-ascii-dec in our head ;) OK, using the Windows calculator in programmer mode: 96 decimal = 0x60 = 0110,0000 144 Decimal = 0x90 = 1001,0000 Base32 requires us to start with the most significant bits. So the first characters are 01100 = 12 = 'M' 10010 = 18 = 'S' The base32 encoding table is taken from: https://tools.ietf.org/html/rfc3548 This is not just the IETF encoding, it is I believe the same one that Phil Z. proposed. And likely for the same reason - take the latin-1 alphabet first, then discard the numbers 0, 1, 2 which are easily confused with O, I and Z. I verified the analysis using these tools: http://www.binaryhexconverter.com/decimal-to-binary-converter http://tomeko.net/online_tools/hex_to_base32.php?lang=en Note that I am not certain yet that we want to use Base32 encoding without modification. We might well want to use a parity scheme so that the fingerprint can be verified as it is typed. Lets say we are using a fingerprint with six character blocks: aaaaa-bbbbb-ccccc-ddddd-eeeee-fffff We could make the least significant bit of block A a parity check on the other bits of block A, the least significant of block B a parity check on AB, the lsb of C a check on ABC, etc. This adds quite a bit of robustness and allows the value to be checked as it is typed. It is not a perfect check of course. But it is something. And it might just be that six character blocks with parity checking has higher user acceptability than five blocks without. So this might well strengthen the system net. > What is the extension strategy for when we've exhausted the 256 > possibilities in a byte? > > (Yes I realise you didn't specify a byte, but I guess that's part of the > question.) The general answer is 'reserve half the code points in the initial registry to extension schemes'. So I see two options: 1) Prepend the identifier to the hash value, this obviously requires the identifiers be issued in byte aligned increments. Fingerprint = ID + Hash If Fingerprint [0] < 128, the first byte is the algorithm identifier If Fingerprint [1] < 196, the lower 14 bits of the first two bytes are the algorithm identifier. This gives 128 possible single byte identifiers and 16384 two byte values. I do not feel the need to specify additional expansion capability since we never came close to exhausting a 16 bit algorithm registry for a single algorithm when we encouraged multiple algorithms (suites are a different issue) 2) Make the topmost 5 bits the identifier. This is actually simpler to implement on many platforms as it is easier to overwrite the first byte of a buffer than prepending another buffer This discards data from the hash value of course but that is inevitable when a fingerprint is used. > We ourselves don't want more than a handful. But if we open up the > fingerprint standard to a wider audience, then austerity will be out the > window. What's our approach of the TLS group decides they want to add a few > hundred? The TLS group have run into problems because suites are a bad idea. Choosing the strongest versions of the best of class Merkle-Damgard and Spongeworthy algorithms should remove the incentive to proliferate. I have never been in a situation where someone has been saying 'we need a weaker algorithms'. The COAP folk might want to use a rubbish algorithm 'for speed' of course. But the only algorithm they are likely to agree on is SHA1 and that isn't a lot faster and there are all sorts of reasons why they are going to be unable to make it their only algorithm. From nobody Fri Apr 17 10:14: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 B3FDF1A8979 for ; Fri, 17 Apr 2015 10:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOH7HKwHvq58 for ; Fri, 17 Apr 2015 10:14:55 -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 BADBE1A8980 for ; Fri, 17 Apr 2015 10:14:54 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 625EF6D78A; Fri, 17 Apr 2015 13:14:53 -0400 (EDT) Message-ID: <55313F8C.6070400@iang.org> Date: Fri, 17 Apr 2015 18:14:52 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87y4m0ozlt.fsf@vigenere.g10code.de> <20150415135105.GJ3106@singpolyma-liberty> <1429128262.1702.41.camel@scientia.net> <1429131461.1702.52.camel@scientia.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 17 Apr 2015 17:14:56 -0000 On 16/04/2015 16:39 pm, Derek Atkins wrote: > Christoph Anton Mitterer writes: > >> On Wed, 2015-04-15 at 16:21 -0400, David Shaw wrote: >>> Using a string is fine, but even with numbers, there is no rule that >>> the number has to be a single byte. After enough years and algorithms >>> added, it could be "100000:ABCDEF0123..." >> But numbers would make problems if we're using the binary representation >> of the fingerprint (i.e. not the ASCII/UTF8 version of it). >> How should one know where the algo type ends, 0x0 can't be used since it >> may be part of the number. >> So it can only be done if the algo type is defined to be a (null >> terminated) string. > > It's easy -- all algorithms are currently defined to be <= 127. If we > need more than that we can use base-128 encoding. I.e., the number is > self-length-encoded in a way that you always know when the number ends. > > The benefit of using a number instead of a string is that in the vast > majority (probably 99.999%) of use cases we'll be within the 127-value > limitation so we can encode it in exactly one byte. A string will > always require at least two bytes, and that only gives you ~52 options. I rather use numbers than strings because a number is typically far more controlled, which is important in a security context. With strings, there's always room for manouvre. Leaving that room in means people will abuse it. In a sense, it's almost a signal - a number means it has to be exact & checked. A string means it's up to the application to display and some higher layer to figure out and interpret. All waste, all opportunity for trouble. iang From nobody Fri Apr 17 14:05: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 873351B2DA8 for ; Fri, 17 Apr 2015 14:05:54 -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 IQGn3nbtyrq6 for ; Fri, 17 Apr 2015 14:05:53 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 F0FC11B2CF7 for ; Fri, 17 Apr 2015 14:05:32 -0700 (PDT) Received: by labbd9 with SMTP id bd9so89571299lab.2 for ; Fri, 17 Apr 2015 14:05:31 -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=yaWD1V/8PbJtUKwUT2dqLFBH3bCvWMc2rS1wYzmZi1o=; b=W6Knkcnd7RJuxeUcifm+U3tpkjaZC+oOI6yA0HQG2Ku52WFc7ubghJV4vC00YcvQ6w 49GZ1V2BPjk7LrMVDFN7n11Tcm0tCbJb/mw99/dk/OB8o6WXa0DZX5N9V9YJQGuPVick R7wutCDoxDqzMa+wlKWYRhm+vshcztWfrHPap8Q3vPSQznSMRConjuOQLKDUItTBaNBR BjmYYyPN95fKmrJWdkmfGNCSTVFDWZwm9rcouuZCk8MjXbTWJAc1j4mJbWObuCw7TSce FZ42mOh/Irtq/5rEiVcxhhvRXbuN8qtA51GQk2srHUZMkOTNUDZ+h4GMvQUf0AdHtCNQ hSdQ== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr5964521lab.79.1429304731531; Fri, 17 Apr 2015 14:05:31 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Fri, 17 Apr 2015 14:05:31 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> Date: Fri, 17 Apr 2015 17:05:31 -0400 X-Google-Sender-Auth: 6mLUb8a6D3vp6n_BF2IUCFQ8yQM Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 17 Apr 2015 21:05:54 -0000 On Thu, Apr 16, 2015 at 11:29 AM, Derek Atkins wrote: > Ian, > > ianG writes: > >> Context: I'm not saying I want to open up the debate. My context is >> that I'm already doing it. In effect I abandoned OpenPGP 2 >> years back so that I could build my own PKI to suit my today's >> requirements . To add further flesh to that, PHB is doing >> the same. Jon will also have something to say on this, and others... >> >> In short, the reality is that PKIs are evolving around us, so the >> question is not whether to do it, it's already happening. >> >> The question is whether to bring it back in house? > > I'm not sure why you need to abandon OpenPGP to do this. Me, I'm > building a PKI *using* OpenPGP. It's actually working quite well, > although I wish there were more standard ways to do the things I > need/want to do. But there's definitely enough flexibility in 4880 to > do everything I want/need. > > Perhaps what we need is (as already suggested by Jon) a document or set > of documents that define how to do different types of PKI using OpenPGP > data structures. I think that Stephen's proposal to use the right key for this is the right approach. What I want to do at this point is play. I want to strip the system down and look at every part and decide what an ideal system might look like and then look at how that maps to the legacy resources, including OpenPGP and PKIX. Looking forward, I want to eventually get to one PKI which combines Web of Trust and Hierarchical concepts. I think I can demonstrate mathematically that it is possible to achieve a higher work factor that way than with either approach on its own. There are use cases that I cannot satisfy with one or the other. There are some features of a new PKI that I think are fairly obvious. It is clear for example that the energy will come from the OpenPGP world. It is also clear that ASN.1 is as popular as a dose of ebola and there must be no new ASN.1. But if we do have to do a lot of new stuff, I want to go to JSON rather than trying to muck about trying to extend the 1990s style structures. From nobody Fri Apr 17 22:10: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 858F21A911B for ; Fri, 17 Apr 2015 22:10:52 -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 17F2ucLwc0lu for ; Fri, 17 Apr 2015 22:10:50 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD7B1A047A for ; Fri, 17 Apr 2015 22:10:50 -0700 (PDT) Received: from fifthhorseman.net (x55b4dbcd.dyn.telefonica.de [85.180.219.205]) by che.mayfirst.org (Postfix) with ESMTPSA id AB12DF986 for ; Sat, 18 Apr 2015 01:10:45 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BAA412070B; Fri, 17 Apr 2015 13:46:21 -0400 (EDT) From: Daniel Kahn Gillmor To: IETF OpenPGP In-Reply-To: References: User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 17 Apr 2015 13:46:21 -0400 Message-ID: <87d232lkb6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Fingerprints 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, 18 Apr 2015 05:10:52 -0000 On Fri 2015-04-10 09:23:18 -0400, Phillip Hallam-Baker wrote: > On Fri, Apr 10, 2015 at 7:38 AM, Stephen Farrell wrote: >> >> Hiya, here's the 2nd thread, starting from DKG's list. >> >> a) update the fingerprint format (avoid inclusion of creation date, use >> stronger digest algorithm; i'm dubious about embedding algorithm >> agility in the fingerprint itself, but explicit version info in the >> fingerprint might be reasonable so we don't have to keep guessing by >> fpr structure for future versions) > > I would like to get started on this bit ASAP as it is the one that has > the most long term consequences. I've been chewing over this discussion for a while, and i find myself coming out fairly conservative on this. I think i'm leaning toward something like a 200- or 250-bit truncation of a strong digest (sha-512 is fine with me) over a common representation of just the key material (SubjectPublicKeyInfo is fine with me, though i understand the ASN.1 concerns). I am ok with inferring fingerprint version by structure. I don't much care about the difference between hex (base16) and base32 -- base32 reduces the length by 20% and it introduces some extra confusion when communicating the fingerprint by voice. Here's my attempt at clarification for why i find myself in this position: As an exercise, i tried to write down all the places that i expect fingerprints to be useful. Perhaps surprisingly, i think there are not that many good use cases for fingerprints. I came up with: 0) keyserver lookup -- Finding or retrieving a key on the basis of a fingerprint. If you have hte fingerprint, you should be able to get a copy of the key. 1) key verification -- I have a copy of a key that i think might be yours, and i want to confirm that it's yours without a mechanized byte-for-byte comparison of the entire key. This covers the "put it on a slip of paper for out-of-band confirmation" use case. Are there actually any other use cases for the fingerprint? Truncated fingerprints (which we call keyids) are also used in some workflows, for example, by some tools to provide a human-accessible handle for the key. I don't think this is appropriate, as i've argued elsewhere: https://www.debian-administration.org/users/dkg/weblog/105 I should also be clear: i *don't* think we want a many different fingerprint variants. I actually don't think we want more than one for OpenPGPv5. And i don't think we should choose a design that will encourage people to pick their favorite fingerprint algorithm. Fingerprints are useful because everyone uses the same one. I don't want to put have to two v5 fingerprints on my business card for the same key to satisfy two different fingerprint camps. the transition period where i need a v4 fingerprint and a v5 fingerprint is going to be bad enough, let's not make that persistent. If i put one form of a v5 fingerprint on mine, and you put another, then any implementation that copes with them (keyservers; manual verifiers) will have to understand and work with them both. The fingerprint decisions i made came from these factors: * version detection: how do we know that this is fingerprint format X? * truncation: how long is the fingerprint? Is it acceptable to truncate further? If so, by how much? Werner's note is also relevant here as we move to ECC keys: > Short fingerprints are important; if they are getting too long > they won't serve a purpose because the public key could be used > directly. If we use a 256-bit fingerprint for a 255-bit curve25519 key, what's the point? * digest algorithm; we need preimage resistance; we do not need collision resistance. * what material gets digested; at a minmum, this is: - the algorithm for the key (incl. any parameters) - public key values (mpi's, bitstrings) it's not clear to me that there is any advantage to adding anything else here. * what structure is used to frame the material before digest; v4 uses an approximation of the public key packet format as a framing device, but this ends up including the creation date. we could use the ASN.1 SubjectPublicKeyInfo format (as phb suggests), though some people are (probably understandably) allergic to ASN.1. Or we could make up our own structure, yuck! * human-representable form of the digest: e.g. hex, base32, common hyphenation patterns, etc. there are legibility/usability factors here that i don't know enough to comment on. Did i miss any factors? --dkg From nobody Mon Apr 20 08:17: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 3914F1B2EC8 for ; Mon, 20 Apr 2015 08:17:32 -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 4T_J4bRcD1fr for ; Mon, 20 Apr 2015 08:17:28 -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 A0D6A1B2EC7 for ; Mon, 20 Apr 2015 08:17:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 14003E2038; Mon, 20 Apr 2015 11:17: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 06068-06; Mon, 20 Apr 2015 11:17: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 D8CD8E2035; Mon, 20 Apr 2015 11:17:24 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3KFHN84020704; Mon, 20 Apr 2015 11:17:23 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87d232lkb6.fsf@alice.fifthhorseman.net> Date: Mon, 20 Apr 2015 11:17:22 -0400 In-Reply-To: <87d232lkb6.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 17 Apr 2015 13:46: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: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprints 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, 20 Apr 2015 15:17:32 -0000 Daniel Kahn Gillmor writes: > Here's my attempt at clarification for why i find myself in this > position: > > As an exercise, i tried to write down all the places that i expect > fingerprints to be useful. Perhaps surprisingly, i think there are not > that many good use cases for fingerprints. I came up with: > > 0) keyserver lookup -- Finding or retrieving a key on the basis of a > fingerprint. If you have hte fingerprint, you should be able to get > a copy of the key. > > 1) key verification -- I have a copy of a key that i think might be > yours, and i want to confirm that it's yours without a mechanized > byte-for-byte comparison of the entire key. This covers the "put it > on a slip of paper for out-of-band confirmation" use case. > > Are there actually any other use cases for the fingerprint? Specified Revokers use the (binary) full fingerprint, not the (truncated) keyID. > Truncated fingerprints (which we call keyids) are also used in some > workflows, for example, by some tools to provide a human-accessible > handle for the key. I don't think this is appropriate, as i've argued > elsewhere: > > https://www.debian-administration.org/users/dkg/weblog/105 It's important to have a keyserver API to lookup a key based on the keyID in a signature. > I should also be clear: i *don't* think we want a many different > fingerprint variants. I actually don't think we want more than one for > OpenPGPv5. And i don't think we should choose a design that will > encourage people to pick their favorite fingerprint algorithm. > > Fingerprints are useful because everyone uses the same one. I don't > want to put have to two v5 fingerprints on my business card for the same > key to satisfy two different fingerprint camps. the transition period > where i need a v4 fingerprint and a v5 fingerprint is going to be bad > enough, let's not make that persistent. If i put one form of a v5 > fingerprint on mine, and you put another, then any implementation that > copes with them (keyservers; manual verifiers) will have to understand > and work with them both. > > > The fingerprint decisions i made came from these factors: > > * version detection: how do we know that this is fingerprint format X? Leading byte with the FPVNo. (FingerPrint Version Number) > * truncation: how long is the fingerprint? Is it acceptable to > truncate further? If so, by how much? Werner's note is also > relevant here as we move to ECC keys: > > > Short fingerprints are important; if they are getting too long > > they won't serve a purpose because the public key could be used > > directly. > > If we use a 256-bit fingerprint for a 255-bit curve25519 key, what's > the point? > > * digest algorithm; we need preimage resistance; we do not need > collision resistance. So you're saying we can stick with SHA1? ;) > * what material gets digested; at a minmum, this is: > - the algorithm for the key (incl. any parameters) > - public key values (mpi's, bitstrings) > it's not clear to me that there is any advantage to adding > anything else here. I still believe that the creation time (and key expiration time, if it exists) should be included. > * what structure is used to frame the material before digest; v4 uses > an approximation of the public key packet format as a framing device, > but this ends up including the creation date. we could use the ASN.1 > SubjectPublicKeyInfo format (as phb suggests), though some people are > (probably understandably) allergic to ASN.1. Or we could make up our > own structure, yuck! Personally I like the current framing (because I do believe the creation date should be included). > * human-representable form of the digest: e.g. hex, base32, common > hyphenation patterns, etc. there are legibility/usability factors > here that i don't know enough to comment on. I prefer either hex or base32. > Did i miss any factors? > > --dkg -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 20 08:22: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 F38911B2EDC for ; Mon, 20 Apr 2015 08:22: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 wzGutHzBk-lc for ; Mon, 20 Apr 2015 08:22: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 9AE261B2ED7 for ; Mon, 20 Apr 2015 08:22:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 337F7E203A; Mon, 20 Apr 2015 11:22: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 06064-09; Mon, 20 Apr 2015 11:22: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 9B981E2039; Mon, 20 Apr 2015 11:22:35 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3KFMYkc020991; Mon, 20 Apr 2015 11:22:34 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> Date: Mon, 20 Apr 2015 11:22:33 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 17 Apr 2015 17:05:31 -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: IETF OpenPGP , Derek Atkins , ianG Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 20 Apr 2015 15:22:40 -0000 Phillip Hallam-Baker writes: > Looking forward, I want to eventually get to one PKI which combines > Web of Trust and Hierarchical concepts. I think I can demonstrate > mathematically that it is possible to achieve a higher work factor > that way than with either approach on its own. There are use cases > that I cannot satisfy with one or the other. I'll note you can do that, today, with OpenPGP. You run a CA -- start signing OpenPGP keys with your CA Key. Boom. You're done. > There are some features of a new PKI that I think are fairly obvious. > It is clear for example that the energy will come from the OpenPGP > world. It is also clear that ASN.1 is as popular as a dose of ebola > and there must be no new ASN.1. > > But if we do have to do a lot of new stuff, I want to go to JSON > rather than trying to muck about trying to extend the 1990s style > structures. I don't see what "new stuff" really needs to be done. Seriously, please tell me what (other than Name Constraints) OpenPGP is missing in order to support your concept of a PKI? (And I'll note that even NC can be done in OpenPGP via notations) -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 20 08:25: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 A8D6B1B2E4F for ; Mon, 20 Apr 2015 08:25:41 -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 jpXm9RCZU3ac for ; Mon, 20 Apr 2015 08:25:39 -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 7A33D1B2EBB for ; Mon, 20 Apr 2015 08:25:39 -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 F0A815FAD3 for ; Mon, 20 Apr 2015 15:25:37 +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 UTy1dC4ImTMu for ; Mon, 20 Apr 2015 15:25:35 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 20 Apr 2015 15:25:35 +0000 (UTC) Message-ID: <1429543533.24823.73.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 20 Apr 2015 17:25:33 +0200 In-Reply-To: References: <87d232lkb6.fsf@alice.fifthhorseman.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-Y2YysAxhWkBNzVGb4aGc" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 20 Apr 2015 15:25:41 -0000 --=-Y2YysAxhWkBNzVGb4aGc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-20 at 11:17 -0400, Derek Atkins wrote:=20 > > * what material gets digested; at a minmum, this is: > > - the algorithm for the key (incl. any parameters) > > - public key values (mpi's, bitstrings) > > it's not clear to me that there is any advantage to adding > > anything else here. >=20 > I still believe that the creation time (and key expiration time, if it > exists) should be included. I think the same accounts for the key usage flags. Or actually, we should perhaps make primary keys to be generally certifying-only keys. And specifying a expiration time (even if it's 0) should be mandatory. Cheers. --=-Y2YysAxhWkBNzVGb4aGc 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyMDE1MjUz M1owTwYJKoZIhvcNAQkEMUIEQMwaSnO6BlEpARIuEfs3cd3eRhWG/DmYK0t2aB1h94VNx/r59avN DOZOpxmBQsK8nQdPFaNGgIudoHKjySugdDQwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBqiJTEcRf5H08dE7nqxSn1627OfKXd 7AVEcVxKU/mBm129YXHJTQCwkrpI8y7WKocdabR2K1dfGgxDiEw+rTb8IFJ2zTv03L3kyWwHcMBc nZ0zzAquP/6Slo2ok55d7SFg0B9MVVKZV5VhAQg0Vlr3orS3u0IYymM6gfgC1y8bL27ujjYVcWjy 13GFRUbWnQS3w+OE1it+y+UfWvEPnSi3SvmschX1sXlN3q5zShp64zRutHAHG5vQ8Wu6ls7zkAoY PBVjzwqHO3mnVbENEc1a5fJ0ejfBWxxXgZ4hjRAD5OqaWgMKvR7ILAR2GmYFi9ddMEwkXx8pj0vA nS5OSuCIAAAAAAAA --=-Y2YysAxhWkBNzVGb4aGc-- From nobody Mon Apr 20 08:33: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 6F30D1B2EF9 for ; Mon, 20 Apr 2015 08:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 paJ7hQfiD0Ed for ; Mon, 20 Apr 2015 08:33:47 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 001351B2EF5 for ; Mon, 20 Apr 2015 08:33:46 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 3A38311C1ABB for ; Tue, 21 Apr 2015 01:33:45 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2oUeuZoYsUWg for ; Tue, 21 Apr 2015 01:33:40 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id B866F11C1AB9 for ; Tue, 21 Apr 2015 01:33:39 +1000 (EST) Message-ID: <55351C52.4040008@adversary.org> Date: Tue, 21 Apr 2015 01:33:38 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> In-Reply-To: <1429144776.1702.75.camel@scientia.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bcFWf9sKA1tvbFettDHsdbPa4Ok4CH7Hr" Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 20 Apr 2015 15:33:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bcFWf9sKA1tvbFettDHsdbPa4Ok4CH7Hr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/04/2015 10:39 am, Christoph Anton Mitterer wrote: > On Wed, 2015-04-15 at 14:01 -0700, Jon Callas wrote: >> There was also a mention somewhere of removing the timestamp from the >> fingerprint, and that's what I really want to comment on. >> When 2440 started, removing the timestamp was one of the things I >> wanted to do. However, it's not such a bad thing. If you make a >> fingerprint merely be a function of the key (it has no variable data),= >> then you lose the ability to alias the key, which is actually useful. >=20 > I think the main problem with the valid from/through dates not being a > part of the fingerprint is the following: >=20 > A user may intentionally want to limit his key for security reasons, > e.g. he makes a 1024 bit and wants to make sure that no one is > using/trusting it after two years anymore. >=20 > AFAIU, if the dates are not part of the fingerprint this would also mea= n > that they could be changed any time with a new self sig (including at a= > time when the key owner may deem the 1024 bit RSA already no longer > secure enough to be trusted). > Of course one can make a revocation cert, but an attacker could always > try a blocking attack at the keyserver level. >=20 > That's why I think, that creation and expiration times should be > immutable once the key has been created; at least not without > invalidating all signatures (i.e. those from other users). While I can certainly see where you're coming from with this proposal, the problem is that it is completely the opposite of the current function of all key and subkey types. There are quite a lot of existing users out there who set expiration dates on their keys and then keep changing them as the expiration date approaches. So this would be a nasty shock at the very least and may break some other things, depending on what they're doing with all those keys. To put it another way; that's a *lot* of old dogs we'd need to teach new tricks to (and it's so often hard enough to teach the current tricks to puppies already). Regards, Ben --bcFWf9sKA1tvbFettDHsdbPa4Ok4CH7Hr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVNRxTAAoJEH/y03E1x1U8Bx0L/R8h+R+L4xT2i8GBAdfktqJV 9j2x0o4QIMC8kU6tmPtH4u9murjrV0paqyMNu9ElJgEDsQXBpvNfjqT6orXcMMQl dw8tkcaDZFcouYP3Gjm0EiX2oi+E7wlYe0+zBGT7yScxunbLJM1uB+Rr8G/PtkUB UzAOVf39dUC6lSkQ6/biQBjcVCaaotx9hh2+byQAJxFxC5tkkBZyFFwnozNEdkcR 2Bw+SvbQdLWC+M+3UdDzZkA88LZ5Gxox9BJdgd2LXVrTcPtztRftrslYKH1Vd+g+ vPXkivFCUTTHBW1hrSAziaWWYyiULcCq4mH1vjTFs5Kap6kH2AbRGVf3G8C33QUS oJPTkYv8eBe1EGrXY0Lx/4+ZjnV/FIQJV+Zvdl7Y81oNHHx+ubLm5KUCQwZVAssW SkAvGksIDHYEe+Dr/w/0khTyIOKvTP4+dYwxwp8+UV/yJyssNtfMjiliv0lZbY3M aLO74oY5wa5lc7foYX60oNDXEhklroln8RRqLlqqyw== =P4po -----END PGP SIGNATURE----- --bcFWf9sKA1tvbFettDHsdbPa4Ok4CH7Hr-- From nobody Mon Apr 20 08:35: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 811951B2F08 for ; Mon, 20 Apr 2015 08:35:16 -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 ly_L1JkiNMUQ for ; Mon, 20 Apr 2015 08:35:15 -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 643AF1B2F07 for ; Mon, 20 Apr 2015 08:35:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6C726E203A; Mon, 20 Apr 2015 11:35:14 -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 06223-02; Mon, 20 Apr 2015 11:35:08 -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 EF6CEE2038; Mon, 20 Apr 2015 11:35:07 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3KFZ6pp021649; Mon, 20 Apr 2015 11:35:06 -0400 From: Derek Atkins To: Christoph Anton Mitterer References: <87d232lkb6.fsf@alice.fifthhorseman.net> <1429543533.24823.73.camel@scientia.net> Date: Mon, 20 Apr 2015 11:35:06 -0400 In-Reply-To: <1429543533.24823.73.camel@scientia.net> (Christoph Anton Mitterer's message of "Mon, 20 Apr 2015 17:25:33 +0200") 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] Fingerprints 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, 20 Apr 2015 15:35:16 -0000 Christoph Anton Mitterer writes: > On Mon, 2015-04-20 at 11:17 -0400, Derek Atkins wrote: >> > * what material gets digested; at a minmum, this is: >> > - the algorithm for the key (incl. any parameters) >> > - public key values (mpi's, bitstrings) >> > it's not clear to me that there is any advantage to adding >> > anything else here. >> >> I still believe that the creation time (and key expiration time, if it >> exists) should be included. > > I think the same accounts for the key usage flags. Or actually, we > should perhaps make primary keys to be generally certifying-only keys. I generally agree with this, modulo what I have written in draft-atkins-openpgp-device-certificates that allows encryption-only primary keys. > And specifying a expiration time (even if it's 0) should be mandatory. > > Cheers. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 20 09:17: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 733DE1B2F93 for ; Mon, 20 Apr 2015 09:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 dV3auDYf1PV6 for ; Mon, 20 Apr 2015 09:17:17 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7352D1B2F97 for ; Mon, 20 Apr 2015 09:17:09 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 4868B11C1AC9 for ; Tue, 21 Apr 2015 02:17:08 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C2lNH1IS-hPJ for ; Tue, 21 Apr 2015 02:16:57 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 591C011C1AC8 for ; Tue, 21 Apr 2015 02:16:57 +1000 (EST) Message-ID: <55352678.20605@adversary.org> Date: Tue, 21 Apr 2015 02:16:56 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> In-Reply-To: <552FB9B9.9080002@iang.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Nu4xhvpqUlV81nFOSt3T4ikx8lVxNgqP8" Archived-At: Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 20 Apr 2015 16:17:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Nu4xhvpqUlV81nFOSt3T4ikx8lVxNgqP8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/04/2015 11:31 pm, ianG wrote: > So, the OpenPGP world has always separated policy from tech. It has in= > effect kicked policy upstairs to the people. Hence the key signing > parties and the discordance between signing meaning "I saw a passport" > versus "I saw a person". This we all agreed was the smart thing to do.= >=20 > However, Jon's revelation of yesterday really changed everything for me= > at least: >=20 >=20 > > When 2440 started, there was an agreement with the Security > > Area that OpenPGP would not be a "PKI" (whatever the heck > > that means), because there was already a PKI, namely PKIX. >=20 >=20 > This thread (below) is about PGP as "a PKI" in a world where we are use= d > to (up against) "the PKI" or incumbent x.509/CA. Now that we're > watching the slow burning sunset of "the PKI," and, now that we're > looking at a whole new generation of usage for PGP (*), it may become > more clear that we might have to revisit this. I think part of the reason this keeps coming back to whether or not trust definitions, signing policies and security policies keep coming back is because of the lack of clarity, even amongst geeks. I agree with the previous stance taken by most; we should not dictate policy to end users, they're the ones in the best position to determine how they use whichever implementation of the protocol they'll use. We should stick to specifying the tech involved. The problem, however, is that current key management functions don't really seem to address all the relevant components of different policy types. For example, I can sign a key locally, normally at certain levels or assign a trust signature to indicate I trust the owner so much they can make trust metric decisions for me (kind of). Okay, but why can't I include a specific notation value with my signature to tie back to a published key policy on my site. Then people could see there's a signature and check a reference which indicates something like "I met this guy, seemed honest, saw a license, but they can be forged in this country, I'd readily encrypt to him, I'm pretty sure he's legit, but I wouldn't bet my childrens' lives on that." The real world is more complicated than the few options presently available and if utilisation of trust metrics and relevant security policies are to be effectively maintained then the end users need the tools to put the scenarios they encounter into effect. Some additional functionality in that respect now would be good. The same goes for the totally arbitrary trust settings. Presently I disable the thing entirely because I have too many keys to locally sign everyone I might encrypt to (everyone if I had my way). Why can't I say, "always trust when encrypting, but use the trustdb in relation to signatures and determining authenticity of signed data." There's also a lack of any way to indicate trust in the consistency of a perceived entity being the same person, even without having identities confirmed. This could be useful for those establishing a long term, consistent pseudonymous identity for whatever reason. These are all functional, practical aspects of a trust system which the specification should consider as a technical response to a lack in the current standard. Deciding on key usage policies would still be entirely in the hands of end users as, indeed, it should be. But those users should have the resources to be more specific about how their policies affect the usage of every component and application of their keys within the context of their communications. I am, of course, also aware that there is very often a fundamental lack of understanding on where the lines are on things like that out there, but as with cryptography itself, that is simply a matter of education and familiarity. There is, I will admit, a significant lack of documentation in how to formulate a security or signing policy in relation to OpenPGP, at least by comparison to sites with guides to making keys and checking email. That's another little beast entirely and probably well beyond the scope of this WG. It shouldn't be lost on anyone here, though, that the only crypto users with specific key policies are those with a professional requirement to do so or are interested in those aspects of information security which make it relevant to them. Everyone else coming to the party tends toplay it by ear or ignore the entire thing. This sort of thing, however, deals with a great many things which go far beyond just OpenPGP and it's definitely not something for the WG to handle. Presumably someone will write something to help everyone else along with it eventually ... by which I mean, once I've finished the outline I've got in another buffer, I'll actually have to flesh it out. ;) Regards, Ben --Nu4xhvpqUlV81nFOSt3T4ikx8lVxNgqP8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVNSZ4AAoJEH/y03E1x1U8HgsL/09e0XT3QYmSzOsPhuqgF7UG YkaH66nSzAf+vLHIwDN9L/CGaWm0sWn0Py4pR8HtqWgbTQdbK54Psd7JiUxR25ph IYFSrPxpMjGDoThTsm+Ob3NtaKK65Xf1xHB9Pr+tUuSuTfsYgDXeACamgyuTfAfE wqNNEsNyKubrsS7J1fjWaHzWDykwRS/Ceg9f1Ayh6oD/cxdXsQbeJPdE15WNibsA FO2VzXGmQBEdZm8XFumSLUWsxfv1oFmy/aIiHhU5Qtf1QXeIg8VGPUtk/B+Q29Ge 2kPo5qJ3M7pfjfCPMBlrcu7DPP6FHAVHgguOD8lVStUV9hbmIZbmAYR0ZhfdnFfb oN7OUnNljPN8e4Tg+NzTO4an88x6qO/gIumyfGw1TZw+VVsyTgzYFFFz6IKDfABK Aqo6j41xq+gHKyh45yfeFETJUgLyBrayjCINifjkhm5or4tQ5Od+p86OdsRHIxmi WM2RmTJbgxT80nUIw5YPV1OHJl7P2tHqGJNllWi7Dg== =Gl1i -----END PGP SIGNATURE----- --Nu4xhvpqUlV81nFOSt3T4ikx8lVxNgqP8-- From nobody Mon Apr 20 09:18: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 49C5E1B2F97 for ; Mon, 20 Apr 2015 09:18:34 -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 3HDEyMd3AxDW for ; Mon, 20 Apr 2015 09:18:32 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE5C1B2F94 for ; Mon, 20 Apr 2015 09:18:31 -0700 (PDT) Received: from localhost (dhcp176-197.wlan.rz.tu-bs.de [134.169.176.197]) by mail.mugenguild.com (Postfix) with ESMTPSA id 758095FCEF for ; Mon, 20 Apr 2015 18:16:02 +0200 (CEST) References: <87d232lkb6.fsf@alice.fifthhorseman.net> From: Vincent Breitmoser To: IETF OpenPGP Cc: Date: Mon, 20 Apr 2015 17:54:11 +0200 Message-ID: <87iocqepta.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Designated Revokers 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, 20 Apr 2015 16:18:34 -0000 On 20 Apr 2015, Derek Atkins wrote: > Specified Revokers use the (binary) full fingerprint, not the > (truncated) keyID. I would motion for designated revokers to use (or include) the full public key. This allows verification of a revocation signature in combination with a designated revoker certificate *without* the requirement to retrieve, parse, and verify an entire other key, allows supporting designated revokers without requiring the possibility to retrieve keys during import. There are two downsides to consider: - increased packet size. not by an order of magnitude though, and if this is a concern the designated revoker certificate can be published together with the revocation only - incomplete verification of the designated revoker's key. if we fetch a key by fingerprint, it might have been revoked before the revocation was issued, invalidating the revocation signature. this still leaves the key in question in a very fishy state and it probably makes more sense than not to consider it revoked. Another alternative would be adding the public key to the revocation certificate as a subpacket. Both options have the same downsides, and none of them stands out as the natural choice to me. - V From nobody Mon Apr 20 09:24: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 875811B2FC7 for ; Mon, 20 Apr 2015 09:24:22 -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 uls8jo_3hCsK for ; Mon, 20 Apr 2015 09:24:21 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825C01B2FC0 for ; Mon, 20 Apr 2015 09:24:21 -0700 (PDT) Received: from localhost (dhcp176-197.wlan.rz.tu-bs.de [134.169.176.197]) by mail.mugenguild.com (Postfix) with ESMTPSA id 245945FCEF; Mon, 20 Apr 2015 18:21:52 +0200 (CEST) References: <87d232lkb6.fsf@alice.fifthhorseman.net> <1429543533.24823.73.camel@scientia.net> From: Vincent Breitmoser To: Christoph Anton Mitterer Date: Mon, 20 Apr 2015 18:18:55 +0200 In-reply-to: <1429543533.24823.73.camel@scientia.net> Message-ID: <87h9saepjh.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints 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, 20 Apr 2015 16:24:22 -0000 On 20 Apr 2015, Christoph Anton Mitterer wrote: > On Mon, 2015-04-20 at 11:17 -0400, Derek Atkins wrote: >> I still believe that the creation time (and key expiration time, if >> it exists) should be included. > I think the same accounts for the key usage flags. Definitely in favor of including key usage flags. I can't think of a reason these should ever be mutable over the lifetime of a key, at least in the incarnation of the key material identified by one fingerprint. > Or actually, we should perhaps make primary keys to be generally > certifying-only keys. Not sure about that, primary keys with more than C capability can have legitimate use cases. - V From nobody Mon Apr 20 09:35: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 D04711A017A for ; Mon, 20 Apr 2015 09: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 5ZE7gFWAXaXk for ; Mon, 20 Apr 2015 09:34:53 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2591A0222 for ; Mon, 20 Apr 2015 09:34:29 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 419D811C1AD3; Tue, 21 Apr 2015 02:34:28 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WAmpYbq4s3us; Tue, 21 Apr 2015 02:34:23 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id D14D511C1AD2; Tue, 21 Apr 2015 02:34:22 +1000 (EST) Message-ID: <55352A8D.40204@adversary.org> Date: Tue, 21 Apr 2015 02:34:21 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christoph Anton Mitterer , openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> In-Reply-To: <1429189446.1702.90.camel@scientia.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SlqoEfM4NeovddO9kkw7PHXl4j3sgQPQq" Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 20 Apr 2015 16:34:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SlqoEfM4NeovddO9kkw7PHXl4j3sgQPQq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/04/2015 11:04 pm, Christoph Anton Mitterer wrote: > On Thu, 2015-04-16 at 13:19 +0200, Vincent Breitmoser wrote:=20 >> The solution to this problem should be two keyrings. > You probably mean two keys? >=20 >> Different >> encryption settings per user id like this are completely out of scope >> for everyone who isn't familiar with the inner workings of RFC4880. > I don't agree at all. > Actually we should make it finally usable that a person has only one > primary (and certifying/certified) key,... and many subkeys which are > usable for different use cases, which is right now practically > impossible. Hmm ... if you think I'm taking the master/cert key for any of my personal keys and leaving it on hardware controlled by an employer then you'll be waiting a long time. > And I think once it would be reasonably possible, it makes absolutely > sense to have e.g. different key prefs depending on the UID and/or > (role) subkey. This bit is true and certainly the functionality of the first part would be useful, but you can be sure that some people will still separate keys to some extent. Although in my case, the first thing I always did with creating a new work key was to make sure I'd exported the secret key and took a copy home. It's not that I didn't trust a company and thought it might screw me over one day, it's just that ... oh, wait, that was exactly it. >> Just like gpg, we use the latest signature. Is there a reason this >> isn't specified? While I agree that the trust model should not be >> specified, leaving this kind of thing open just leads to confusion > Yes. > IMO this vagueness may be even a security issue. Yeah, my previous email responding to Ian deals with some of this. There's still a separation of tech and policy or intent, but there are identifiable functions which should be supported in order to provide end users what they need to utilise a trust system and a security policy effectively. Regards, Ben --SlqoEfM4NeovddO9kkw7PHXl4j3sgQPQq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVNSqOAAoJEH/y03E1x1U8e+gMANNFyvSkVfwVAOKG6Naug71o XF6cPteymHoYhWuHnrqebmqlGLtQq6txeHF7j7VpSbmbglivo1qubQbDbMKFSiYY FBCtSMopUMQC1yryY3eg54EQuXBCJVpHW4yIGDri48OPH3DsbHEk4d6xZBCGY1Yd +B1zKoYYnzYiDUMJuyG1RmyT/ycHnpLFpvws6KT77P9oTjQz1WBYCtRTJmTd4wPe mgJLIrIdIzcH/TKXqJpiW5uja6krATHFlxH565pdyzY/W6SY4q+yvGUM8OdHlgwQ R+/4VKaL8MXb6l5d1MKkL0qPku8hqpEQU+kN+BeUO1Q1w15oreuDNsBJdGwfgaA/ zZb3o8dfBpemSOR7argeXWVoRaoNZ/luYsK7kZ/sQYgOkDJ4gY6ql6CMHhEsByrQ ZCyQwm7+Jm+FWg4v3WMJ9QWeiwkkKD/qVNpLKulS8RaoaXt+O0yaX4ctqXh8FSnH an73PISxdGHVXwaBLcvd4Ux54hJCTp8eFfJ/mlsbKg== =Wt8v -----END PGP SIGNATURE----- --SlqoEfM4NeovddO9kkw7PHXl4j3sgQPQq-- From nobody Mon Apr 20 09: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 BAD441A873D for ; Mon, 20 Apr 2015 09:49:23 -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 LhUYVX0yj3NU for ; Mon, 20 Apr 2015 09:49:22 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC831A8728 for ; Mon, 20 Apr 2015 09:49:16 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 5076311C1AD7 for ; Tue, 21 Apr 2015 02:49:15 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QGthD1F-7BL5 for ; Tue, 21 Apr 2015 02:49:06 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id A144811C1AD6 for ; Tue, 21 Apr 2015 02:49:05 +1000 (EST) Message-ID: <55352DFF.8080801@adversary.org> Date: Tue, 21 Apr 2015 02:49:03 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> <87pp736frc.fsf@vigenere.g10code.de> In-Reply-To: <87pp736frc.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="comGu5lpj4njg0MSwTItjCLhG21cXhJVe" Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 20 Apr 2015 16:49:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --comGu5lpj4njg0MSwTItjCLhG21cXhJVe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/04/2015 5:21 am, Werner Koch wrote: > On Thu, 16 Apr 2015 15:26, look@my.amazin.horse said: >=20 >> I meant keyrings, as in primary keys + subkeys. >=20 > We use the term keyblock for this. See 6.2. Forming ASCII Armor. >=20 > A keyring is a collection of keyblocks. While we're on this part, can we finally get some consensus on keyblock formats? Specifically that newly generated keys should *NOT* consist solely of a primary with SCE or SCEA. Though as near as I can tell, this will mainly only affect the Kmail + Kleopatra Kontingent (out of the box) and, maybe, the Bouncy Castle Java devs who continue to insist on that kind of poor design choice and then inflict them on unsuspecting end users to the detriment of those users and everyone communicating with them. Regards, Ben --comGu5lpj4njg0MSwTItjCLhG21cXhJVe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVNS3/AAoJEH/y03E1x1U8fg0L/0q30XiOIPp3z8TU2v2MBi6a FT1DvtZmPP5QcFEIuzOcG9MME0rpEQEz1DNmnSBQu+7+ZWtbuMjZWM7N6MAHtFTu fo+FHCj2T+YaJjGpcGPnCHQYtzZL1tatD2i/GQePFP1oNIw4ZXARAdNLXvbtO+Vw u6xSCOer7JbKVS7JNybuqN0a/HkIQa4RENT1UfH+PyO9R8AiGi5puXRN+DCyHyZD PzG6NnYNlwTC5qCy6swc3Qy01Td2uTUk87E+jwrPVxrBpMeRkbz8w1hKlhHpJ0Yx +Q9kPNpbT1aKm+Ioow224/OPKaYZI6BvfHlUkuP0BqfdSiezEFWXgtAOSlCUvvYp b9xg7rkOFv0vXXwOP7w46C73ys6X88dBA+yU3o0QmUFTzSPnIsdiVzptKHi0c+rE kcF4u1JrrIILxtkp4vePncDsnmqf3QHKHra7/D+t0YB4V9axvbRgLwaLznDWhmyc dRVzlsD3EMSUxr4JvxYIVgpbihxSBnhnpkspb7jaQg== =N5j0 -----END PGP SIGNATURE----- --comGu5lpj4njg0MSwTItjCLhG21cXhJVe-- From nobody Mon Apr 20 09:53: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 2994C1A7D85 for ; Mon, 20 Apr 2015 09:53:17 -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 kehjBC3rKsvf for ; Mon, 20 Apr 2015 09:53:16 -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 C31281A802D for ; Mon, 20 Apr 2015 09:53:15 -0700 (PDT) Received: by layy10 with SMTP id y10so131590197lay.0 for ; Mon, 20 Apr 2015 09:53: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=lxpjz/s8p+SgPTmm4oaKU1A5kIH+1xLM4QmUPY5S3N8=; b=l+kaTUnq/Ok4HjRZ4DojtSsyG+2z4mcQCLkfNleTeBsCdnDQ/KqYP9js4D4LzmXVg3 NK0cOghubRQuTJVih9IJrTwIrn8cEf7W0ULsN2fLeeAs9pkL1dPqlHj9U5d5jq7qxCOH dUHjUrcU5nskxQyOgtoJAHvcFGI9fhfTLshwRNLF4smqbs2PQRRtTQs10zEFgDCD5ErM ct0tzS0gtK0Gi2Vvl7qhkiEfo7QeLBilR3ftmjZH51cgmm4glgqv98d+m9gLhZkddEOB eEAAJHv19YGmLVZ1SGCkatdaShRQAe6VRtIHkhhaJsWOzcrwMONBXfDl+yYn9stgu9tF wdzA== MIME-Version: 1.0 X-Received: by 10.152.18.225 with SMTP id z1mr16683288lad.124.1429548794281; Mon, 20 Apr 2015 09:53:14 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 20 Apr 2015 09:53:14 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> Date: Mon, 20 Apr 2015 12:53:14 -0400 X-Google-Sender-Auth: gr7gs9M5o9dOF5kOFgSREuY7hQU Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP , ianG Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 20 Apr 2015 16:53:17 -0000 On Mon, Apr 20, 2015 at 11:22 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > >> Looking forward, I want to eventually get to one PKI which combines >> Web of Trust and Hierarchical concepts. I think I can demonstrate >> mathematically that it is possible to achieve a higher work factor >> that way than with either approach on its own. There are use cases >> that I cannot satisfy with one or the other. > > I'll note you can do that, today, with OpenPGP. You run a CA -- start > signing OpenPGP keys with your CA Key. Boom. You're done. > >> There are some features of a new PKI that I think are fairly obvious. >> It is clear for example that the energy will come from the OpenPGP >> world. It is also clear that ASN.1 is as popular as a dose of ebola >> and there must be no new ASN.1. >> >> But if we do have to do a lot of new stuff, I want to go to JSON >> rather than trying to muck about trying to extend the 1990s style >> structures. > > I don't see what "new stuff" really needs to be done. > > Seriously, please tell me what (other than Name Constraints) OpenPGP is > missing in order to support your concept of a PKI? (And I'll note that > even NC can be done in OpenPGP via notations) It is not necessarily a question of capabilities as much as the effect of rails. PKIX has a set of rules that are very useful and clarifying for cases where the trust provider is an authority on the assertion being made. If I have a CA that is bound to example.com then it can make authoritative statements about *.example.com and *@*.example.com. If I have an offline key it can create an intermediate that is almost the same as it. Such rules have value in the situations where they work. But they don't work everywhere. What we need is the PKI equivalent of structured programming. PKIX is Pascal. PGP is BASIC. Yes, you can do anything with IF-THEN-GOTO. But you probably should not try. I don't think that it is going to be sustainable to have a PKI for email and a PKI for non-email in the long term. There has to be merger at some point. That was the origin of the assertion infrastructure that became SAML when we were doing angle brackets. Now its curly braces... From nobody Mon Apr 20 11:01: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 12D8E1B2C9E for ; Mon, 20 Apr 2015 11:01:43 -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 Hl3Ik1E927aR for ; Mon, 20 Apr 2015 11:01:41 -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 777DC1B2C8B for ; Mon, 20 Apr 2015 11:01:40 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YkG0o-0004Ok-NR for ; Mon, 20 Apr 2015 20:01:38 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YkFy5-0008Fq-ON; Mon, 20 Apr 2015 19:58:49 +0200 From: Werner Koch To: Ben McGinnes References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> <87pp736frc.fsf@vigenere.g10code.de> <55352DFF.8080801@adversary.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Ben McGinnes , openpgp@ietf.org Date: Mon, 20 Apr 2015 19:58:49 +0200 In-Reply-To: <55352DFF.8080801@adversary.org> (Ben McGinnes's message of "Tue, 21 Apr 2015 02:49:03 +1000") Message-ID: <87egneznom.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] details of 4880bis work 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, 20 Apr 2015 18:01:43 -0000 On Mon, 20 Apr 2015 18:49, ben@adversary.org said: > keyblock formats? Specifically that newly generated keys should *NOT* > consist solely of a primary with SCE or SCEA. Though as near as I can > tell, this will mainly only affect the Kmail + Kleopatra Kontingent Sorry, I do not understand this. I can imagine reasons why you want a signing and encryption capable key and no subkeys. What has this to do with Kmail + Kleopatra ? They use standard GnuPG and I am pretty sure that they create RSA+RSA keys; after all this is what gpg4win does which is the standard installer for GnuPG. > (out of the box) and, maybe, the Bouncy Castle Java devs who continue > to insist on that kind of poor design choice and then inflict them on > unsuspecting end users to the detriment of those users and everyone In case you refer to a bug report where some Bouncy Castle based implementation ignored the keyflags [1]: This is clearly a bug in that implementation. I actually heard stories at the weekend about implementations which didn't implement even very basic requirements. It is not a problem of Bouncy Castle, though. Shalom-Salam, Werner [1] Which ignored the key flags and encrypted to the primary key which happened to be on a smartcard which enforces PKCS#1 for the key so that the reporter was not able to decrypt. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 20 11:06: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 559A61B2C9C for ; Mon, 20 Apr 2015 11:06:41 -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 CcqQ8mpiob9i for ; Mon, 20 Apr 2015 11:06:40 -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 3F48C1A8AC8 for ; Mon, 20 Apr 2015 11:06:40 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YkG5e-0004R1-PN for ; Mon, 20 Apr 2015 20:06:38 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YkG41-0008Gz-E0; Mon, 20 Apr 2015 20:04:57 +0200 From: Werner Koch To: Christoph Anton Mitterer References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.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 Mail-Followup-To: Christoph Anton Mitterer , openpgp@ietf.org Date: Mon, 20 Apr 2015 20:04:57 +0200 In-Reply-To: <1429144776.1702.75.camel@scientia.net> (Christoph Anton Mitterer's message of "Thu, 16 Apr 2015 02:39:36 +0200") Message-ID: <87a8y2znee.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: [openpgp] rfc3880bis - hard expiration time (was: details of 4880bis work) 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, 20 Apr 2015 18:06:41 -0000 On Thu, 16 Apr 2015 02:39, calestyo@scientia.net said: > That's why I think, that creation and expiration times should be > immutable once the key has been created; at least not without > invalidating all signatures (i.e. those from other users). A hard expiration time vor a v5 key format was proposed by Florian Weimer many years ago. IIRC, we even had consent that this should be done by putting it into a v5 key packet. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 20 11:41: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 811401B2CA2 for ; Mon, 20 Apr 2015 11:41:41 -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 TIe0bJzL0fFC for ; Mon, 20 Apr 2015 11:41:40 -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 1C5EA1B2C9F for ; Mon, 20 Apr 2015 11:41:40 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YkGdW-0004iO-Hb for ; Mon, 20 Apr 2015 20:41:38 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YkGZc-0008MY-1M; Mon, 20 Apr 2015 20:37:36 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <87d232lkb6.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Daniel Kahn Gillmor , IETF OpenPGP Date: Mon, 20 Apr 2015 20:37:35 +0200 In-Reply-To: <87d232lkb6.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 17 Apr 2015 13:46:21 -0400") Message-ID: <87618qzlw0.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprints 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, 20 Apr 2015 18:41:41 -0000 On Fri, 17 Apr 2015 19:46, dkg@fifthhorseman.net said: > key to satisfy two different fingerprint camps. the transition period > where i need a v4 fingerprint and a v5 fingerprint is going to be bad > enough, let's not make that persistent. If i put one form of a v5 I do not think that this is major problem. For many years we had to cope with the v3 and v4 fingerprints. It was easy to explain that they are similar but that 4-hex-nibble fingerprint are used with modern keys and most folks like to be modern or own modern keys. > fingerprint on mine, and you put another, then any implementation that > copes with them (keyservers; manual verifiers) will have to understand Right, that is not going to work. It is worse enough that there is no fingerprint standard for X.509 and we need to avoid it. I understood the proposal as to define a common fingerprint format which can be re-used for a v6 key format. The number of different ways to render a string of hex digits is limited. > * truncation: how long is the fingerprint? Is it acceptable to > truncate further? If so, by how much? Werner's note is also [...] > If we use a 256-bit fingerprint for a 255-bit curve25519 key, what's > the point? BTW, there is another option: We could demand a specific subkey (e.g. 256 bit ECDSA) which directly acts as the fingerprint. This fingerprint-key could then also be used for forthcoming distributed naming systems. > * digest algorithm; we need preimage resistance; we do not need > collision resistance. Thus SHA-256 should be sufficient. > * what material gets digested; at a minmum, this is: > - the algorithm for the key (incl. any parameters) > - public key values (mpi's, bitstrings) > it's not clear to me that there is any advantage to adding > anything else here. It has been discussed that a hard expiration date would be useful. Having a creation date as part of the key allows to create a key from the same key material but still be identified as a different key. This is for example useful if the key material is on a smartcard and you want (e.g. due to company policy) two independent looking keys. > * human-representable form of the digest: e.g. hex, base32, common > hyphenation patterns, etc. there are legibility/usability factors > here that i don't know enough to comment on. For a long time I pondered with the idea to suggest base32 for a v5 key but meanwhile I think that hex digits are easier to read and spell over noisy channels. 08-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcdef0 would fit into one line and is still not too hard to read. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 20 12:49: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 F17751A8BBF for ; Mon, 20 Apr 2015 12:49:48 -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 zhFIVSZqGs5I for ; Mon, 20 Apr 2015 12:49:45 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id B07CE1A8AE3 for ; Mon, 20 Apr 2015 12:49:44 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 8735811C1B02 for ; Tue, 21 Apr 2015 05:49:43 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hZiGoDVSxIIv for ; Tue, 21 Apr 2015 05:49:31 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 2E8DA11C1AEA for ; Tue, 21 Apr 2015 05:49:30 +1000 (EST) Message-ID: <55355841.4060101@adversary.org> Date: Tue, 21 Apr 2015 05:49:21 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> <87pp736frc.fsf@vigenere.g10code.de> <55352DFF.8080801@adversary.org> <87egneznom.fsf@vigenere.g10code.de> In-Reply-To: <87egneznom.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1WdumltVcMmQDhHe3nL2FNQGjBgHbFvg0" Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 20 Apr 2015 19:49:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1WdumltVcMmQDhHe3nL2FNQGjBgHbFvg0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/04/2015 3:58 am, Werner Koch wrote: > On Mon, 20 Apr 2015 18:49, ben@adversary.org said: >=20 >> keyblock formats? Specifically that newly generated keys should *NOT*= >> consist solely of a primary with SCE or SCEA. Though as near as I can= >> tell, this will mainly only affect the Kmail + Kleopatra Kontingent >=20 > Sorry, I do not understand this. I can imagine reasons why you want a > signing and encryption capable key and no subkeys. Really? Alright then at least make it so that in each implementation that's not the default. > What has this to do with Kmail + Kleopatra ? They use standard GnuPG > and I am pretty sure that they create RSA+RSA keys; after all this is > what gpg4win does which is the standard installer for GnuPG. No, Kleopatra's default config in gpg4win is to create RSA as SCE with no subkeys. Like this: pub rsa4096/0xD3..REDACTED..47 created: 2014-12-29 expires: never usage: SCE [ unknown] (1). S**** L***** BTW, this is a real key belonging to a prominent Australian political figure, who has been somewhat vocal on privacy issues (hence using his personal address and not his other one). Fortunately for him we'll be at the same event next week and I can help him fix it, but that's pure chance and something all the other gpg4win users don't get. It wouldn't be so bad if GPA was the default GUI, but it isn't, Kleopatra is the default install with GPA requirong manual selection when the installer launches. Instead users get whatever defaults are set by the Kleopatra team in that product (which seems to be to try to turn OpenPGP into SMIME). If there's some function that Kleopatra performs and GPA doesn't then that sounds like a good reason to draft some volunteer help in expanding GPA. Even the little Qt thing the GPG4USB team came up with would be better than Kleopatra if it could work with 2.0. Plus there are numerous reports of a higher frequency of bad signatures and other errors from people using KMail clients, very likely linked to other aspects of poor implementation. The only way for gpg4win users to get a key with subkeys is to either manually add one after key generation, use GPA instead, use the command line instead or do ignore those frontends entirely and generate within Enigmail. The only thing in gpg4win's favour at this point is that someone in a country that won't lock them up for exporting crypto (so that rules me out ... at least once ECC is involved) can build a version which removes Kleopatra from it entirely. At least that process looks pretty simple (a little line removal in packages/packages.current should do it). >> (out of the box) and, maybe, the Bouncy Castle Java devs who continue >> to insist on that kind of poor design choice and then inflict them on >> unsuspecting end users to the detriment of those users and everyone >=20 > In case you refer to a bug report where some Bouncy Castle based > implementation ignored the keyflags [1]: This is clearly a bug in that > implementation. I actually heard stories at the weekend about > implementations which didn't implement even very basic requirements. I= t > is not a problem of Bouncy Castle, though. I can't off the top of my head right now, but given BC is just the java libs it might have been one of the other projects which leaned so heavily on it. Maybe Portable PGP, but I thought it was more recent than that particular travesty. Ah well, maybe it'll come back to me later, still I guess if people are Hell-bent on breaking something we can only advise them not to (and then get out of the line of fire). > [1] Which ignored the key flags and encrypted to the primary key which > happened to be on a smartcard which enforces PKCS#1 for the key so > that the reporter was not able to decrypt. Wow, that's just hilariously bad. I shouldn't laugh at that, but I just can't help it. :) Regards, Ben --1WdumltVcMmQDhHe3nL2FNQGjBgHbFvg0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVNVhCAAoJEH/y03E1x1U8ORgMANMSV8FilC1F+TcqBmVTb69x lKH3uOUYdmxJqJBnUR0pRRA7+uZqxG+IMMvpd4S8apyq9wZjvgaOvfDRJFLN8d8P g9TBa8qsz8SBPhNWnf/gLsckjpKBWUracZKb5kQ+WsIrfclAN6sKdwRN22eNgpLq 2u0CkSGRX1o0w0g1vaKY91JAzmwsHndZwwDYtoYH6c7x8Utj8lnJU/gsXoyVN4u2 92QUUbuUu1SVL7xwh5p90A/l+oJhNjSZeqsn9BU2c2Lpt1Eblg7S/Go4RDEy6bzy 7z5QEGSIF2kelq1tLkeIFEYnOkPUTZ2oXkK6FCiNyUl/1WacW05LO3Bao+0PQf0h it9AIVXlYbXjEhHadQrx6OmEGCXbymGMQw628HaBPWt3k7F6U8W6U50Mqd+uxkMc l/FjQquZ7+gJqVSb2eJosBKhApC23WfNnaja5Ai0BhUKKFy4AvnUdvZLToCbhkCZ xkuSk4DMO28h4j+hodvwJNLw+FetoZvy5PC8i5ngmg== =ZYyJ -----END PGP SIGNATURE----- --1WdumltVcMmQDhHe3nL2FNQGjBgHbFvg0-- From nobody Mon Apr 20 15:04: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 333971B32CB for ; Mon, 20 Apr 2015 15:04:16 -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 juHLRuNqgJ0N for ; Mon, 20 Apr 2015 15:04:14 -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 EC81C1B32C3 for ; Mon, 20 Apr 2015 15:04:13 -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 CB8A65FB40 for ; Mon, 20 Apr 2015 22:04:12 +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 P1UHsBzzqIPm for ; Mon, 20 Apr 2015 22:04:10 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 20 Apr 2015 22:04:10 +0000 (UTC) Message-ID: <1429567448.11806.45.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 21 Apr 2015 00:04:08 +0200 In-Reply-To: <55352A8D.40204@adversary.org> References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <55352A8D.40204@adversary.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-tDlEE9Gtt8kEJWzFRdAZ" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 20 Apr 2015 22:04:16 -0000 --=-tDlEE9Gtt8kEJWzFRdAZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-04-21 at 02:34 +1000, Ben McGinnes wrote:=20 > > I don't agree at all. > > Actually we should make it finally usable that a person has only one > > primary (and certifying/certified) key,... and many subkeys which are > > usable for different use cases, which is right now practically > > impossible. > Hmm ... if you think I'm taking the master/cert key for any of my > personal keys and leaving it on hardware controlled by an employer > then you'll be waiting a long time. Actually the opposite: You should be able to place your *secondary* key(s) onto your employer's hardware.. but for that to be practically usable, we need some kind of "UID or role attributes" or anything that like which can be connected with certain subkeys. > This bit is true and certainly the functionality of the first part > would be useful, but you can be sure that some people will still > separate keys to some extent. Sure... but that's a completely unrelated thing. > It's not that I didn't trust a company and thought it might screw me > over one day, it's just that ... oh, wait, that was exactly it. Sure... but that's one of the reason why it might make sense to have e.g. different key flags depending on the combination of UID *and* subkey (of course right now, there is no connection between UID/subkey, at least not in the sense mentioned above). Cheers, Chris.- --=-tDlEE9Gtt8kEJWzFRdAZ 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyMDIyMDQw OFowTwYJKoZIhvcNAQkEMUIEQAbjJddfjc6aLvxKDhCEzzeJwCDJINVF+bT4uQN2M7o4ISQ8hsm8 zYKq1JzriwZRQ0uP6iMNy3uZg1nxU+Qs9ikwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB0yt8/sQ4Icy2JAHAOoQy01eYhMb3M tLaz8MAfLCM5m9cGfI6v8DkYUCvH/lDizlJ+PTlxOk1aMwznNMQDdJmd6ygpxN7e4EWN/pWDGOnI pRnrjEM0uxKHUvQog20RJvI7xqKQ1I9y1+GNbMfxKFs4PaxLzwvCR4dHEtStTzwTA/3eOMe4BDqm Ocv3JZ/wWUEhSN8S+y3IQLBg23RI3CPK4dMdHNuVDegbJF0dPYHasQcsNwAXX9efYzpAGTRIm6VN r3LjL1r9uar5YKybsoTm6jXNQUzs9jFFsWKPhj981taR4zkbqkZvE2zU+aR11nrGKE5/WkMfbQyQ SKvB5yiUAAAAAAAA --=-tDlEE9Gtt8kEJWzFRdAZ-- From nobody Mon Apr 20 23:41: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 D48C11ACDEB for ; Mon, 20 Apr 2015 23:41:42 -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 uNZEvDUzgM4G for ; Mon, 20 Apr 2015 23:41:41 -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 1E2551ACDE5 for ; Mon, 20 Apr 2015 23:41:41 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YkRsJ-0002qH-8w for ; Tue, 21 Apr 2015 08:41:39 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YkRoz-0001yQ-6C; Tue, 21 Apr 2015 08:38:13 +0200 From: Werner Koch To: Ben McGinnes References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> <87pp736frc.fsf@vigenere.g10code.de> <55352DFF.8080801@adversary.org> <87egneznom.fsf@vigenere.g10code.de> <55355841.4060101@adversary.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Ben McGinnes , openpgp@ietf.org Date: Tue, 21 Apr 2015 08:38:13 +0200 In-Reply-To: <55355841.4060101@adversary.org> (Ben McGinnes's message of "Tue, 21 Apr 2015 05:49:21 +1000") Message-ID: <87sibux9yi.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] details of 4880bis work 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, 21 Apr 2015 06:41:43 -0000 On Mon, 20 Apr 2015 21:49, ben@adversary.org said: > Really? Alright then at least make it so that in each implementation > that's not the default. Sure. Everything else is a bug. > No, Kleopatra's default config in gpg4win is to create RSA as SCE > with no subkeys. Like this: Oops. That should not have happened. Let's take this to gpg4win-devel@. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 20 23:51: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 17BC41ACE18 for ; Mon, 20 Apr 2015 23:51:11 -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 V-fmB6J1GSP0 for ; Mon, 20 Apr 2015 23:51:09 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id B3F241ACDE9 for ; Mon, 20 Apr 2015 23:51:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 20E5F70C6A92; Mon, 20 Apr 2015 23:51:08 -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 3HBy7rdqW72F; Mon, 20 Apr 2015 23:51:05 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 03EA370C6A70; Mon, 20 Apr 2015 23:51:04 -0700 (PDT) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 20 Apr 2015 23:51:05 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 20 Apr 2015 23:51:05 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <87a8y2znee.fsf_-_@vigenere.g10code.de> Date: Mon, 20 Apr 2015 23:50:59 -0700 Message-Id: <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christoph Anton Mitterer , openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time (was: details of 4880bis work) 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, 21 Apr 2015 06:51:11 -0000 > On Apr 20, 2015, at 11:04 AM, Werner Koch wrote: >=20 > On Thu, 16 Apr 2015 02:39, calestyo@scientia.net said: >=20 >> That's why I think, that creation and expiration times should be >> immutable once the key has been created; at least not without >> invalidating all signatures (i.e. those from other users). >=20 > A hard expiration time vor a v5 key format was proposed by Florian > Weimer many years ago. IIRC, we even had consent that this should be > done by putting it into a v5 key packet. I wouldn't go quite that far as "consent" if by that you mean = "consensus." There are many things that got punted into the future = rather than argue now. Personally, I think that the present way things are done is = syntactically fine. Semantically, there are many bogosities. You can = time-limit your signature on a key, but no one ever does. There are lots = of reasons for that, I think, none of them technical. They all are = social. Jon From nobody Tue Apr 21 00:14: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 006E71B36AB for ; Tue, 21 Apr 2015 00:14:52 -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 rNUHorg5gsHu for ; Tue, 21 Apr 2015 00:14:50 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCEB1B36A9 for ; Tue, 21 Apr 2015 00:14:48 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id E5E2511C16C3 for ; Tue, 21 Apr 2015 17:14:46 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2JuvkAeUOh7f for ; Tue, 21 Apr 2015 17:14:42 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 1581111C16C2 for ; Tue, 21 Apr 2015 17:14:41 +1000 (EST) Message-ID: <5535F8E1.9050005@adversary.org> Date: Tue, 21 Apr 2015 17:14:41 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> <87pp736frc.fsf@vigenere.g10code.de> <55352DFF.8080801@adversary.org> <87egneznom.fsf@vigenere.g10code.de> <55355841.4060101@adversary.org> <87sibux9yi.fsf@vigenere.g10code.de> In-Reply-To: <87sibux9yi.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2ALjr45ju8xuq4m7DWMDpi9riVnqjHdFr" Archived-At: Subject: Re: [openpgp] details of 4880bis work 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, 21 Apr 2015 07:14:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2ALjr45ju8xuq4m7DWMDpi9riVnqjHdFr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/04/2015 4:38 pm, Werner Koch wrote: > On Mon, 20 Apr 2015 21:49, ben@adversary.org said: >=20 >> Really? Alright then at least make it so that in each implementation >> that's not the default. >=20 > Sure. Everything else is a bug. Excellent. >> No, Kleopatra's default config in gpg4win is to create RSA as SCE >> with no subkeys. Like this: >=20 > Oops. That should not have happened. Let's take this to > gpg4win-devel@. I'll be on that list just as soon as the subscription messages work their way past the grey-listing. ;) Regards, Ben --2ALjr45ju8xuq4m7DWMDpi9riVnqjHdFr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVNfjhAAoJEH/y03E1x1U8Ze4MAPVyYKT95pdPzeunpBpv9jL8 xq+WQpCQ4H+oSBagOK3RKDX32kCt8BJywChIMrS6xMLGay48g8AnR26w9efRXagG 8bpzBRazk+VrKLk9qIEt8SFVeTe8XYF+SjyqPiK8M+BuqzttS3iYB1VAUFholQoZ Uud7MIlA9OvjfcNt57yBXqAnKPjR1ZbzaEUNQjt7Dbxj5JLmU4BSOhqlNNBa0gJm x+qSw1fTcp75yQjwcFWK1bNa2eKQOjGIFMuOdMm849a+GfAnETms/sqpW+UX/ROe Ggs2Am827hXYOddWcWh51Qe7Hgu3QwyzLQXt34cuCUIxQxuff5OEY9JRllsC0mOe vA+JPzK8CvrQxpsiyCTgREgVdkqkt7d44Svuq4pznBu7+nBawv4bjISp5Bv9S26O n+EL+42F5fZ/euYmJDAMdxoCTmEJW52PT1XIDRI8uLskpFdfFBG5NG6AZzAm+2sb eKgVsev0+Iz6j+udYW/LTeA0sKZKlWRWBpPSCw9QnA== =Frl8 -----END PGP SIGNATURE----- --2ALjr45ju8xuq4m7DWMDpi9riVnqjHdFr-- From nobody Tue Apr 21 02:51: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 6DD291A895B for ; Tue, 21 Apr 2015 02:51:46 -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 uFbHAD4XBzCh for ; Tue, 21 Apr 2015 02:51:44 -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 00A521A8772 for ; Tue, 21 Apr 2015 02:51:42 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YkUqC-000520-7C for ; Tue, 21 Apr 2015 11:51:40 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YkUk6-0002cb-6W; Tue, 21 Apr 2015 11:45:22 +0200 From: Werner Koch To: Jon Callas References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Jon Callas , Christoph Anton Mitterer , openpgp@ietf.org Date: Tue, 21 Apr 2015 11:45:22 +0200 In-Reply-To: <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> (Jon Callas's message of "Mon, 20 Apr 2015 23:50:59 -0700") Message-ID: <87zj61x1al.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: Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 21 Apr 2015 09:51:46 -0000 On Tue, 21 Apr 2015 08:50, jon@callas.org said: > I wouldn't go quite that far as "consent" if by that you mean > "consensus." There are many things that got punted into the future Yeah, the latter of course. In the context of a v5 key format we should discuss whether it really makes sense. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 21 04:50: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 8F0561AC3B8 for ; Tue, 21 Apr 2015 04:50:33 -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 mRSvRvS7DL7T for ; Tue, 21 Apr 2015 04:50:30 -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 824651AC3B9 for ; Tue, 21 Apr 2015 04:50:29 -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 0A3945FB63; Tue, 21 Apr 2015 11:50:28 +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 1Rt4aXDdAyr3; Tue, 21 Apr 2015 11:50:25 +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; Tue, 21 Apr 2015 11:50:25 +0000 (UTC) Message-ID: <1429617025.11806.88.camel@scientia.net> From: Christoph Anton Mitterer To: Jon Callas Date: Tue, 21 Apr 2015 13:50:25 +0200 In-Reply-To: <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-HNo2O21+tAIbNJyO5p02" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time (was: details of 4880bis work) 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, 21 Apr 2015 11:50:33 -0000 --=-HNo2O21+tAIbNJyO5p02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-20 at 23:50 -0700, Jon Callas wrote: > Personally, I think that the present way things are done is > syntactically fine. Semantically, there are many bogosities. You can > time-limit your signature on a key, but no one ever does. As I've explained before, I don't think that this is the same as hardcoding it into the key, as it wouldn't change the fingerprint, would it?! --=-HNo2O21+tAIbNJyO5p02 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyMTExNTAy NVowTwYJKoZIhvcNAQkEMUIEQCI/wm/xjxsaGBVmH4K+2ZHWPRj89Y5EQ2wN5cuyzRcZHSZogH98 UQofAq+xC1qKcsCf7WGihz16yxRthbQjjhMwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDhCb1LmN2XxyWjhY7qoyPEkKSz8UL0 EkwErkxAiWXFQd7SlgxQdO07w5xBQSUNyzkvdxuC3VzoAt875rQ4vFb4MwE2EhO1ppgn2zmFEPqL IWkXzqCKoeO8C4kMYfux4RGZuUT1w5sVffJG7MV/UFCRC9BccuBJzEFtGswhnWOaCJtQKWMOC4Y/ 0TW9r9Z+Yk3tnh+Z2GPXkiR0PKzt32VkQjkO04MucDR4H+6K8WBF6WGrsHsiQJJuZFccbuzyEWtv czbOhiicED+J+jDnLQvp/WdutFVgOwBCM77vbEffPel0nv9S6Z5NqXq6Ajgm2IpKm8f79IOxTWgk WG9o9lbwAAAAAAAA --=-HNo2O21+tAIbNJyO5p02-- From nobody Wed Apr 22 17:46: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 A019B1B2C56 for ; Wed, 22 Apr 2015 17:46: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 fQfVQ2Cm-1WJ for ; Wed, 22 Apr 2015 17:46:09 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001: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 D1EFA1B2C53 for ; Wed, 22 Apr 2015 17:46:07 -0700 (PDT) Received: by iejt8 with SMTP id t8so50343817iej.2 for ; Wed, 22 Apr 2015 17:46:07 -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=FJOfvN2tH5J1r4yVK1Q3xQUYUf2W4cNxC1UHUy7+uNg=; b=eFfbwVLHwGbB8AeiEbq8bNQA4Phw3fIZxt72uc9AOSdf5opvrErRZ85E8CdvCtldjZ r6kDLFlLPPewFd5hFFIKHGeA/vkUi1rSoHCwhMgx8CCeUgbt7vrLNxeEbT/+GG3AKzW2 2fx/fmIaeeZZRr0Yx1OTsBTen39CYZqb5JDz25hUlHXKNBH8d0wnXuJlgDk866EMmP66 UwFHGEnOyFfoiZvLEFk9+edS9vsNsgqD+BMAIZlWN+08wQWt5JQqjddnTasQlYB3I4Tv kqudyahMCGYmToKvNHeQKElBtikK41FIPSdnuXoCgugpdPDVogHcjf0qfClR1aVZW3pt Q84Q== X-Received: by 10.107.153.8 with SMTP id b8mr344394ioe.3.1429749967325; Wed, 22 Apr 2015 17:46:07 -0700 (PDT) MIME-Version: 1.0 References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> In-Reply-To: From: David Leon Gil Date: Thu, 23 Apr 2015 00:46:06 +0000 Message-ID: To: Benjamin Kaduk , Werner Koch Content-Type: multipart/alternative; boundary=001a1140d720eb926a0514599ab3 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 00:46:10 -0000 --001a1140d720eb926a0514599ab3 Content-Type: text/plain; charset=UTF-8 S2K with MD hashes is a horrible KDF. It is very very much worse than PBKDF2. The main reason that there are no papers comparing them is that S2K is so obviously bad that no-one thinks it is worth the effort of publishing about it. Scrypt is okay as a password hash. Lyra2 would be better. On Fri, Apr 10, 2015 at 12:57 PM Benjamin Kaduk wrote: > On Fri, 10 Apr 2015, Werner Koch wrote: > > > b) Symmetric-Key Encrypted Session Key Packets. I don't know how often > > this is used. I assume that in most use cases the passphrase is > > taken from external key management system and thus we can expect > > that it has full entropy and the KDF does not add to the security. > > I have used gpg -c to password-encrypt data with a human-generated (i.e., > not-great) password fairly recently, as a single anecdote. > > -Ben > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1140d720eb926a0514599ab3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable S2K with MD hashes is a horrible KDF. It is very very much worse than PBKDF= 2.

The main reason that there are no papers comparing them is that S= 2K is so obviously bad that no-one thinks it is worth the effort of publish= ing about it.

Scrypt is okay as a password hash. Lyra2 would be bet= ter.
On Fri, Apr 10, 2015 at 12:57 PM Benjami= n Kaduk <kaduk@mit.edu> wrote:
On Fri, 10 Apr 2015, Werner Koch wrote:
>=C2=A0 b) Symmetric-Key Encrypted Session Key Packets.=C2=A0 I don'= t know how often
>=C2=A0 =C2=A0 =C2=A0this is used.=C2=A0 I assume that in most use cases= the passphrase is
>=C2=A0 =C2=A0 =C2=A0taken from external key management system and thus = we can expect
>=C2=A0 =C2=A0 =C2=A0that it has full entropy and the KDF does not add t= o the security.

I have used gpg -c to password-encrypt data with a human-generated (i.e., not-great) password fairly recently, as a single anecdote.

-Ben

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a1140d720eb926a0514599ab3-- From nobody Thu Apr 23 00:16: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 364E11B2EF6 for ; Thu, 23 Apr 2015 00:16:48 -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 XoK-AVfVmeUo for ; Thu, 23 Apr 2015 00:16:46 -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 1B5EF1B2EF9 for ; Thu, 23 Apr 2015 00:16:42 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YlBNI-0006mf-E8 for ; Thu, 23 Apr 2015 09:16:40 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YlBJy-0001vG-N9; Thu, 23 Apr 2015 09:13:14 +0200 From: Werner Koch To: David Leon Gil References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.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 , Benjamin Kaduk , "openpgp\@ietf.org" Date: Thu, 23 Apr 2015 09:13:14 +0200 In-Reply-To: (David Leon Gil's message of "Thu, 23 Apr 2015 00:46:06 +0000") Message-ID: <87egnbs4fp.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" , Benjamin Kaduk Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 07:16:48 -0000 On Thu, 23 Apr 2015 02:46, coruus@gmail.com said: > S2K with MD hashes is a horrible KDF. It is very very much worse than > PBKDF2. Care to explain? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Apr 23 00:55: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 4C8921B2F61 for ; Thu, 23 Apr 2015 00:55:41 -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 ioYnTd6dvf_1 for ; Thu, 23 Apr 2015 00:55:40 -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 15F181B2F6A for ; Thu, 23 Apr 2015 00:55:18 -0700 (PDT) Received: by wizk4 with SMTP id k4so205847700wiz.1 for ; Thu, 23 Apr 2015 00:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zYPfVWPHqw9XJYJ//azrrL02YQCwV2LKNa03t/kGnBE=; b=f3qxKO6PKY6N4QVWnYh0ferMx2/82GAJm/nWizdvzGbLiTyT0Umo5i6kcwpO8qZbt8 RxcYreE2qbgoavC6MFK+c1MVjPMJH5X38evngZTDab3j3N9XOKuzsGSuoGJXa0IcuImr 8Ru0GR8KkxVuVIz1y2imqMmC5kDPXw23ZChqMRpI2dMZ0WSSihnN6cijTrj2IQGo+w6L eTWnAxqrt9ZSa9avSWSNWGrx8BUgZED+81b3URF/XiKbNYxsPRWbCC6zTkpYHs6NfniX LLnhvskUFqwEYnQYB0v3GtZBzkra1VFuMgH4FrfC+O6JvSik0HDM78pwmCeyLLvadhe/ 9qXg== X-Received: by 10.180.83.6 with SMTP id m6mr13087444wiy.72.1429775716913; Thu, 23 Apr 2015 00:55:16 -0700 (PDT) Received: from [131.175.121.117] (pc121-117.elet.polimi.it. [131.175.121.117]) by mx.google.com with ESMTPSA id dg8sm10843766wjc.9.2015.04.23.00.55.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 00:55:16 -0700 (PDT) From: Alessandro Barenghi X-Google-Original-From: Alessandro Barenghi Message-ID: <5538A568.2070809@polimi.it> Date: Thu, 23 Apr 2015 07:55:20 +0000 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: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> In-Reply-To: <87egnbs4fp.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 07:55:41 -0000 On 04/23/2015 07:13 AM, Werner Koch wrote: > On Thu, 23 Apr 2015 02:46, coruus@gmail.com said: >> S2K with MD hashes is a horrible KDF. It is very very much worse than >> PBKDF2. > > Care to explain? > S2K is somehow lagging behind in considerations to prevent efficient bruteforce : -- Mode 0 allows to exploit time-to-memory tradeoffs (e.g. rainbow tables) to break large amounts of passwords -- Mode 1 adds salt, but still employs a single run of a hash function, which is designed to be efficient, to derive the password. This allows efficient bruteforce with just computational resources -- Mode 3 has a maximum working factor of 255 (one octet to specify iterations), which is both growing thin (current hash working factor are around 1k-3k to cope with increased computational power and parallelism) PBKDF2 is salted, and has a tunable working factor, although only exploits computational and not memory needs to prevent efficient bruteforce. Scrypt adds to a tunable working factor, the requirement for a tunable amount of memory to compute the KDF. Tuning the memory to be high enough you can hinder the bruteforce on highly parallel architectures, as it is harder to obtain fast and large memories than a large amount of parallel processors. Cheers Alessandro From nobody Thu Apr 23 00:56: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 BABA31B2F5F for ; Thu, 23 Apr 2015 00:56:24 -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 RDbp99ZAxKTd for ; Thu, 23 Apr 2015 00:56:23 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 50DA91B2F5E for ; Thu, 23 Apr 2015 00:56:23 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so6485074wic.1 for ; Thu, 23 Apr 2015 00:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pIP7f1NzMN1UzND0fRd9OvXUatnLl2/5fRMqwjSn5II=; b=s362E3hOaro0RYn/es8v22zYADHv1efciK9HRfHA9UNL9LcyrUoa+ZkLk7YxI+363A KPRJKPNyamRk30sfyFBPk5OAQlICo0Q19CC20AD2xYVJ9uM9vpeT5BGkLvDpYYsCodvQ YJesh9EwBoafhDo1uC+g7BPSFZ9PVgSuwzpcHoAVA5HeToNlKIBkKnkSrhHGqmWCFHtI HrDZV48L5A8NHKNFZhP0juHqSXZcMXRuNESsFTBQTn340JO5+bUDRVn3McOVOtkhhguo ow8Ht8r5OiNoGCi1aa2BcFgTqbiY1OJcUdW9qHz5edfooUQWm+kpBJlONVhe6K4cqsFN 6W8g== X-Received: by 10.180.105.74 with SMTP id gk10mr13030650wib.29.1429775782084; Thu, 23 Apr 2015 00:56:22 -0700 (PDT) Received: from [131.175.121.117] (pc121-117.elet.polimi.it. [131.175.121.117]) by mx.google.com with ESMTPSA id fs9sm10843032wjc.34.2015.04.23.00.56.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 00:56:21 -0700 (PDT) From: Alessandro Barenghi X-Google-Original-From: Alessandro Barenghi Message-ID: <5538A5A9.2020703@polimi.it> Date: Thu, 23 Apr 2015 07:56:25 +0000 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: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> In-Reply-To: <87egnbs4fp.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alessandro.barenghi@polimi.it List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 07:56:24 -0000 On 04/23/2015 07:13 AM, Werner Koch wrote:> On Thu, 23 Apr 2015 02:46, coruus@gmail.com said: >> S2K with MD hashes is a horrible KDF. It is very very much worse than >> PBKDF2. > > Care to explain? > S2K is somehow lagging behind in considerations to prevent efficient bruteforce : -- Mode 0 allows to exploit time-to-memory tradeoffs (e.g. rainbow tables) to break large amounts of passwords -- Mode 1 adds salt, but still employs a single run of a hash function, which is designed to be efficient, to derive the password. This allows efficient bruteforce with just computational resources -- Mode 3 has a maximum working factor of 255 (one octet to specify iterations), which is both growing thin (current hash working factor are around 1k-3k to cope with increased computational power and parallelism) PBKDF2 is salted, and has a tunable working factor, although only exploits computational and not memory needs to prevent efficient bruteforce. Scrypt adds to a tunable working factor, the requirement for a tunable amount of memory to compute the KDF. Tuning the memory to be high enough you can hinder the bruteforce on highly parallel architectures, as it is harder to obtain fast and large memories than a large amount of parallel processors. Cheers Alessandro From nobody Thu Apr 23 02:38: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 E5C531A9060 for ; Thu, 23 Apr 2015 02:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, 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 QkPlhoI11dbb for ; Thu, 23 Apr 2015 02:38:27 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d: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 E622A1A905A for ; Thu, 23 Apr 2015 02:38:10 -0700 (PDT) Received: by qcpm10 with SMTP id m10so6036367qcp.3 for ; Thu, 23 Apr 2015 02:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BbdSiB6Y0N0Xg+7dmT1QYMfhOPJ6oXQJ0iwAa86VoHo=; b=F/d1PiAHBqs39noWYV+dDCo5edI9TSiRzV4TowIDCsWqH9vguFW4FY7eKQK3xVL3P/ KmfyHh7+lB9HSEhpFdD4HcpFelkHGBfHN+9OYB4emt5ep/49aK6NAP52HNj9/1Ory2Zm 3LsOCC3au8j6fuPqWOuVLUfhP6frp+dRtuw1ypmFChz+YUND2Awt4BfsStRxXEZsIFIZ KhnCk206Tumj1EutOmYtceJCuJxeJyuva3lQnVgC+FcwDiuxWxDrDT1DOo0terpHRXu6 LwIwfqpxj1xMv0SZxrkHSvG15egLyPvnOqx9f0bQA+hvV4lg6RDApwfHIrRXXmbfEuAh 0brA== MIME-Version: 1.0 X-Received: by 10.55.41.93 with SMTP id p90mr3204846qkh.98.1429781890045; Thu, 23 Apr 2015 02:38:10 -0700 (PDT) Received: by 10.229.56.132 with HTTP; Thu, 23 Apr 2015 02:38:09 -0700 (PDT) In-Reply-To: <5538A5A9.2020703@polimi.it> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> Date: Thu, 23 Apr 2015 11:38:09 +0200 Message-ID: From: Nils Durner To: alessandro.barenghi@polimi.it Content-Type: multipart/alternative; boundary=001a11496780a99ab00514610954 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 09:38:28 -0000 --001a11496780a99ab00514610954 Content-Type: text/plain; charset=UTF-8 Hi, > -- Mode 3 has a maximum working factor of 255 (one octet to specify > iterations), The one octet encodes much larger values, see RFC 4880 section 3.7.1.3. for the formula applied to it. A literal value of 255 in this octet would compute to an iteration count of 65 millions. Regards, Nils --001a11496780a99ab00514610954 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
-- Mode 3 has a max= imum working factor of 255 (one octet to specify
iterations),

The one octet encodes m= uch larger values, see RFC 4880 section=C2=A03.7.1.3. for the formula appli= ed to it. A literal value of 255 in this octet would compute to an iteratio= n count of 65 millions.
=C2=A0

Regards,<= /div>

Nils
--001a11496780a99ab00514610954-- From nobody Thu Apr 23 02:40: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 6F6C71A905C for ; Thu, 23 Apr 2015 02:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, 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 t3UHfLpYYquI for ; Thu, 23 Apr 2015 02:40:19 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 560881A9069 for ; Thu, 23 Apr 2015 02:40:12 -0700 (PDT) Received: by qgej70 with SMTP id j70so5458203qge.2 for ; Thu, 23 Apr 2015 02:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Uc14rzglG1Ask1fiLOsWVIjaMR9kBpi8+bo4u09RzdY=; b=KdrerUs+QDFibR92nad3flVerOCe16d/Z5qfaTUAoBqxgk4DtFIP3gV1Rabl1YgtuI QzYbTExMjCbB5rViTRgin6oAUScq7q9sRDeV8/YHCIwyk7gHK8bn1w3YG7XOyrAfPCd/ WcxQp/V1t3iUJG2Nb6x4jfX6dJ6zJT9dJH/YD525Puhjsy3mbhoAbfo4ke6fnFt8z92H RnukEFKQhj+HSp6WEMxEsDJ5HM1o78X2gWE4STO4d/bFoqXAwyAQ3JgVoBvtIuez1U43 SbgSNnv4nYVmXfM8WGIvBjJ90BNnSfj4GSPqMhWn/kaSM0Sr/GM9VmN+Pzu5+cdpN9L4 l7qQ== MIME-Version: 1.0 X-Received: by 10.55.23.143 with SMTP id 15mr3164596qkx.17.1429782011623; Thu, 23 Apr 2015 02:40:11 -0700 (PDT) Received: by 10.229.56.132 with HTTP; Thu, 23 Apr 2015 02:40:11 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> Date: Thu, 23 Apr 2015 11:40:11 +0200 Message-ID: From: Nils Durner To: alessandro.barenghi@polimi.it Content-Type: multipart/alternative; boundary=001a1147b220e8bd9d051461108c Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 09:40:20 -0000 --001a1147b220e8bd9d051461108c Content-Type: text/plain; charset=UTF-8 Wrong. It's not the iteration count - it's the octet count of how many octets will be hashed. 2015-04-23 11:38 GMT+02:00 Nils Durner : > Hi, > > >> -- Mode 3 has a maximum working factor of 255 (one octet to specify >> iterations), > > > The one octet encodes much larger values, see RFC 4880 section 3.7.1.3. > for the formula applied to it. A literal value of 255 in this octet would > compute to an iteration count of 65 millions. > > > Regards, > > Nils > --001a1147b220e8bd9d051461108c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wrong. It's not the iteration count - it's the=C2= =A0octet count of how many o= ctets will be hashed.

2015-04-23 11:38 GMT+02:00 Nils Durner <ndurner@googlemail= .com>:
Hi,
=C2=A0
-- Mode 3 has a maximum working factor of 255 (on= e octet to specify
iterations),

The one octet en= codes much larger values, see RFC 4880 section=C2=A03.7.1.3. for the formul= a applied to it. A literal value of 255 in this octet would compute to an i= teration count of 65 millions.
=C2=A0

Re= gards,

Nils

--001a1147b220e8bd9d051461108c-- From nobody Thu Apr 23 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 6C8401ACD90 for ; Thu, 23 Apr 2015 03:38: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 OU97VQkFXlq6 for ; Thu, 23 Apr 2015 03:37:59 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 510211ACDA4 for ; Thu, 23 Apr 2015 03:37:52 -0700 (PDT) Received: by wizk4 with SMTP id k4so210664926wiz.1 for ; Thu, 23 Apr 2015 03:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hjjuBUwqItfg+Wy226c022LYVCnQtL9eaP0rfP8DPPI=; b=w/Dk4/USATsXdF0hsgjZXHHIyP/YxfQTN9PO7whZpDNvf3ksG7nMj1eOsxCJCxMixv EUOTe4IiQcdfiN9v2xxLqcqTKOj8UToXOmzc1pKNefCaknz9sLuOUaF7LsJ7+vfT95gU zdp7KqLfsHvUPNhWNGGt56oxShx4leUkorguJVEjxsnY6ZDMPvENXAzYIFYr7nD+5p0T YnqIXzTw26As7l+qYg+ttC5vwd7Sh4LnQjxcGSEXKMd95KyfgutVmS76I93e91iWK3AX Q2LzPqRLCKUNUnP8csIXHVTxoBlQnwcQOHr4NSirDXWuggIr1G4OR/SELYdIyeev6njC 1R6g== X-Received: by 10.180.74.144 with SMTP id t16mr4556200wiv.33.1429785471099; Thu, 23 Apr 2015 03:37:51 -0700 (PDT) Received: from [131.175.121.117] (pc121-117.elet.polimi.it. [131.175.121.117]) by mx.google.com with ESMTPSA id z13sm11492599wjr.44.2015.04.23.03.37.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 03:37:50 -0700 (PDT) From: Alessandro Barenghi X-Google-Original-From: Alessandro Barenghi Message-ID: <5538CB82.7000102@polimi.it> Date: Thu, 23 Apr 2015 10:37:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Nils Durner References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Update S2K X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: alessandro.barenghi@polimi.it List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 10:38:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/23/2015 09:38 AM, Nils Durner wrote: > Hi, > > > -- Mode 3 has a maximum working factor of 255 (one octet to > specify iterations), > > > The one octet encodes much larger values, see RFC 4880 section > 3.7.1.3. for the formula applied to it. A literal value of 255 in > this octet would compute to an iteration count of 65 millions. Yep, sorry, my mistake. It is possible to tune the work factor to match common ones for PBKDF2 in S2K. The point on fixed memory requirements, on the other hand, still holds in favor of scrypt Cheers Alessandro -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlU4y4IACgkQE+mB79BmI3FR1AEAmiJ25uiY3cGP8HC2Kb66ZoO4 S7cD++B76xa598iBzqoBAJhFY2/bQb35Fw15NeLlay6gqY/TNi/LEwNaooyVGHBz =6tlE -----END PGP SIGNATURE----- From nobody Thu Apr 23 08:49: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 AE6341ACCFC for ; Thu, 23 Apr 2015 08:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 e2ntbgBGk4cY for ; Thu, 23 Apr 2015 08:49:00 -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 C230C1B2E98 for ; Thu, 23 Apr 2015 08:49:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 93EB7E2036; Thu, 23 Apr 2015 11:48:59 -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 30089-10; Thu, 23 Apr 2015 11:48:52 -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 8E90BE2035; Thu, 23 Apr 2015 11:48:52 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3NFmpNM031924; Thu, 23 Apr 2015 11:48:51 -0400 From: Derek Atkins To: Christoph Anton Mitterer References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> Date: Thu, 23 Apr 2015 11:48:51 -0400 In-Reply-To: <1429617025.11806.88.camel@scientia.net> (Christoph Anton Mitterer's message of "Tue, 21 Apr 2015 13:50:25 +0200") 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: Werner Koch , openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 23 Apr 2015 15:49:01 -0000 Christoph Anton Mitterer writes: > On Mon, 2015-04-20 at 23:50 -0700, Jon Callas wrote: >> Personally, I think that the present way things are done is >> syntactically fine. Semantically, there are many bogosities. You can >> time-limit your signature on a key, but no one ever does. > As I've explained before, I don't think that this is the same as > hardcoding it into the key, as it wouldn't change the fingerprint, would > it?! No, it would not, which is IMHO the right thing. I.e., IMNSHO I feel you should expire your key by expiring your self-signature on the key. If you want to extend your key then you re-sign it with a new self-signature. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Apr 23 09:11: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 E36F71A1B95 for ; Thu, 23 Apr 2015 09:11:56 -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_05=-0.5, 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 CvH7DN_x-j-d for ; Thu, 23 Apr 2015 09:11:55 -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 2BFE01A1A80 for ; Thu, 23 Apr 2015 09:11: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 B2EA05FB67; Thu, 23 Apr 2015 16:11: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 hwyjbs1cJwNq; Thu, 23 Apr 2015 16:11:50 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA; Thu, 23 Apr 2015 16:11:50 +0000 (UTC) Message-ID: <1429805507.27711.15.camel@scientia.net> From: Christoph Anton Mitterer To: Derek Atkins Date: Thu, 23 Apr 2015 18:11:47 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-T6E6gQRvVCg0oob7xTDQ" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 23 Apr 2015 16:11:57 -0000 --=-T6E6gQRvVCg0oob7xTDQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-04-23 at 11:48 -0400, Derek Atkins wrote:=20 > No, it would not, which is IMHO the right thing. >=20 > I.e., IMNSHO I feel you should expire your key by expiring your > self-signature on the key. If you want to extend your key then you > re-sign it with a new self-signature. Well but than it's useless to make the key as a whole expirable. And as I outlaid before, this destroys the use case that a user wants to limit the usability of his key, regardless of whether e.g. old signature algos would be broken or his key compromised. If that's only in the selfsig *without* invalidating the other signatures, then an attacker could try a downgrade attack and e.g. forge the selfsig with weaker algos... or more likely... simply create a new selfsig when the key was compromised. If the fingerprint and other users' signatures wouldn't invalidate them, all the attacker needs to do is block the revocation (if any). Therefore, it should be mandatory that both, the valid from and valid to times are encoded in such a way, that changing them would render all other signatures invalid and would change the FP. (Of course it should be possible to specify and infinite expiration time). Cheers, Chri --=-T6E6gQRvVCg0oob7xTDQ 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyMzE2MTE0 N1owTwYJKoZIhvcNAQkEMUIEQIIf/kuonavWGfnBN4pd6RU8WTCp2qWxxf9ZCzLtgkMBQlbpvQye o6haN5NSyeTPMNiSAuOK6LkjSuBwToesNkkwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBL1+Oe+tXqcFKGjh/ww8NQnrBBiTFH QWzehmO7zXzl+kAywe9Y2PFt6Ic5gtGzNDs1hsxa6HZl1BwhgMTplk9viYVtXJQ5PAAPTbgZRlN1 YaC+NUepGGWPQ2MzFJ5OwUILxIjNrNyHX2XUI7AI4GUmOfHHeFJMoYEXtFIhYqYjkANiSFEtHsif QTwnmQQppLeHbqbE/EyzDZNtZo0aEHL0wU/l8Jk5UM85Q3ODr33kxMwXlOrMGRRvDzEsC3OmlVlj pr4lMnFZNfRMhhZZFQJMWU/8cPtSMe1EDCif0Dod4fuUjfa/1ENVxcA1Ijjlb17XKdVk4giFc+dQ 92pTdw3FAAAAAAAA --=-T6E6gQRvVCg0oob7xTDQ-- From nobody Thu Apr 23 10:19: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 81ED91ACDD8 for ; Thu, 23 Apr 2015 10:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 C_guXHcXPHh6 for ; Thu, 23 Apr 2015 10:19:05 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DDCD1ACDD1 for ; Thu, 23 Apr 2015 10:18:51 -0700 (PDT) Received: by qku63 with SMTP id 63so14747971qku.3 for ; Thu, 23 Apr 2015 10:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elowe.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/YAcB7a76z7cHC6qwGWkqSuWbPuF9q69kjIfMnCdTpo=; b=KvJB4tguWCOjVhMHUtzWd+KDmRCbMLPS3QKX393eQay4iiOeETh77cFZE6eTkUt42F JoKZArsf1v9EXUFbmypk7ayQVb+GwK8flK9ynidfgVpcmmGFfJ3T9bG0tpKe5rai1k2W Xb3ROv0s8OHkkeRXhzasZvke+P/8TnVRcL+74= 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:content-type; bh=/YAcB7a76z7cHC6qwGWkqSuWbPuF9q69kjIfMnCdTpo=; b=ept0lcE5bcpvQX6y06v+b3r2o46F3da+Y8LCmUfpaP8rU4qtjMgjHTp37FzgmEL04t 4bV1wMmJzPJy6/rlhAufV6Rc1DdEBrWqHkVbzzkp0N/8MsKZutMkOHyvSk6LaRmrs1pa rm0gd8/u/xjO8/SwkUvx61qRYPQ5DMj/I5JFCxjQybiegUR9k2b5TugDdmSqCwPu3moi wr6tivTwDETxINdySC5HBqTTfI23kFyZbPfOZXs0LS3rW8retMzYHz7iV58pGsPAlwPa Ar3bJFGteFBk6oUvICzBUbSp5BYKt6Zxw4DFYX6M/0pYEe/fer4QHVf5m2Pc/T4cpnjT qiGQ== X-Gm-Message-State: ALoCoQklDZTwawIT/RXzOZqswaEXCGoZ4/1xSGP++Ehf+Cm9WTznz9dqlL+IaqR4wL2S/NjEQGUI MIME-Version: 1.0 X-Received: by 10.140.104.129 with SMTP id a1mr4381840qgf.89.1429809530964; Thu, 23 Apr 2015 10:18:50 -0700 (PDT) Received: by 10.140.73.116 with HTTP; Thu, 23 Apr 2015 10:18:50 -0700 (PDT) In-Reply-To: <5538CB82.7000102@polimi.it> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <5538CB82.7000102@polimi.it> Date: Thu, 23 Apr 2015 10:18:50 -0700 Message-ID: From: Earle Lowe To: "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=001a11354dae30a5670514677967 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 17:19:07 -0000 --001a11354dae30a5670514677967 Content-Type: text/plain; charset=UTF-8 The maximum work factor for RFC4800 S2K is lower than the maximum for (eg) PBKDF2 As the maximum for RFC4800 is specified in bytes, the iteration count (number of hash invocations) goes down as the size of the hash increases. The max iteration count for SHA1 ~= 2^22; SHA256 ~= 2^21; SHA512 ~= 2^20, etc, etc (65011712 / sizeof hash) So in this case, you can have a much higher work factor for the other algorithms. Although I'm not sure it really matters that much when off-the-shelf and cheap GPUs can do billions of these a second. I'd like to see PBKDF2 simply from an "certification" point of view (it's well known to various certification agencies - common criteria, cesg, nist) (although for others that same reason might be a detractor) -Earle On Thu, Apr 23, 2015 at 3:37 AM, Alessandro Barenghi < alessandro.barenghi.polimi@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 04/23/2015 09:38 AM, Nils Durner wrote: > > Hi, > > > > > > -- Mode 3 has a maximum working factor of 255 (one octet to > > specify iterations), > > > > > > The one octet encodes much larger values, see RFC 4880 section > > 3.7.1.3. for the formula applied to it. A literal value of 255 in > > this octet would compute to an iteration count of 65 millions. > > Yep, sorry, my mistake. It is possible to tune the work factor to > match common ones for PBKDF2 in S2K. > The point on fixed memory requirements, on the other hand, still holds > in favor of scrypt > > Cheers > > Alessandro > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlU4y4IACgkQE+mB79BmI3FR1AEAmiJ25uiY3cGP8HC2Kb66ZoO4 > S7cD++B76xa598iBzqoBAJhFY2/bQb35Fw15NeLlay6gqY/TNi/LEwNaooyVGHBz > =6tlE > -----END PGP SIGNATURE----- > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a11354dae30a5670514677967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The maximum work factor for RFC4800 S2K is lower than the = maximum for (eg) PBKDF2

As the maximum for RFC4800 is sp= ecified in bytes, the iteration count (number of hash invocations) goes dow= n as the size of the hash increases.

The max itera= tion count for SHA1 ~=3D 2^22; SHA256 ~=3D 2^21; SHA512 ~=3D 2^20, etc, etc=

(65011712 / sizeof hash)

So in this case, you can have a much higher work factor for the other algo= rithms.

Although I'm not sure it really matter= s that much when off-the-shelf and cheap GPUs can do billions of these a se= cond.

I'd like to see PBKDF2 simply from an &q= uot;certification" point of view (it's well known to various certi= fication agencies - common criteria, cesg, nist)=C2=A0

=
(although for others that same reason might be a detractor)
=
-Earle

On Thu, Apr 23, 2015 at 3:37 AM, Alessandro Barenghi <alessandro.barenghi.polimi@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/23/2015 09:38 AM, Nils Durner wrote:
> Hi,
>
>
> -- Mode 3 has a maximum working factor of 255 (one octet to
> specify iterations),
>
>
> The one octet encodes much larger values, see RFC 4880 section
> 3.7.1.3. for the formula applied to it. A literal value of 255 in
> this octet would compute to an iteration count of 65 millions.

Yep, sorry, my mistake. It is possible to tune the work factor = to
match common ones for PBKDF2 in S2K.
The point on fixed memory requirements, on the other hand, still holds
in favor of scrypt

Cheers

Alessandro

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlU4y4IACgkQE+mB79BmI3FR1AEAmiJ25uiY3cGP8HC2Kb66ZoO4
S7cD++B76xa598iBzqoBAJhFY2/bQb35Fw15NeLlay6gqY/TNi/LEwNaooyVGHBz
=3D6tlE
-----END PGP SIGNATURE-----

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

--001a11354dae30a5670514677967-- From nobody Thu Apr 23 11:19: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 15C001ACE9E for ; Thu, 23 Apr 2015 11:19:43 -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 Y4pbuzY1xWDc for ; Thu, 23 Apr 2015 11:19:41 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 9C1551B316B for ; Thu, 23 Apr 2015 11:19:28 -0700 (PDT) Received: by wizk4 with SMTP id k4so226115980wiz.1 for ; Thu, 23 Apr 2015 11:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bzY5CMVJoUkqh0wJ5LBvME4k9BLbrrS0iJeT0Q3gvGU=; b=b9zShI6dZns/ZLk559KdzFubJw43ZjqnJex4iH5kVFq5ZXrE88H8Mj5ZYshQVRbdgU fUq17lQs0EtK+JW9RkCBA/6wnMKfDxrb7CeTYq+e3bhTaRr6KdIECZW1tLn0tPYWxuBp RcsaOUDTsoNRLDsqQQCzJjlvNbagfbGjZeCsYn8Kh2QMxUF2GICUUNFZFkf3XyEZa2hr j0JyqgNhjwlyrGTYmDVvvvh3xjWN0eBfCcOpZ0ZpxOXd2ZwdAOFw8/AnTFl/1IHoCJEP m5bdS8i1LjwgP/FK55o62mL+rdg2qexwUYq40JfWdAsVNFkWtOBT2tZkNq3AmLMb3uts V4AA== X-Received: by 10.194.23.66 with SMTP id k2mr7801919wjf.18.1429813167436; Thu, 23 Apr 2015 11:19:27 -0700 (PDT) Received: from [131.175.121.117] (pc121-117.elet.polimi.it. [131.175.121.117]) by mx.google.com with ESMTPSA id df1sm30362773wib.12.2015.04.23.11.19.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 11:19:26 -0700 (PDT) From: Alessandro Barenghi X-Google-Original-From: Alessandro Barenghi Message-ID: <553937B3.20702@polimi.it> Date: Thu, 23 Apr 2015 18:19:31 +0000 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: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <5538CB82.7000102@polimi.it> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 18:19:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/23/2015 05:18 PM, Earle Lowe wrote: > The maximum work factor for RFC4800 S2K is lower than the maximum > for (eg) PBKDF2 Yes, although it is possible to match ones commonly used now (1k-3k) and have a reasonable margin for raising the value (hitting around 100k is not a problem, which keeps the now-dying Moore law at bay for another 10 yrs at worst). > As the maximum for RFC4800 is specified in bytes, the iteration > count (number of hash invocations) goes down as the size of the > hash increases. > > The max iteration count for SHA1 ~= 2^22; SHA256 ~= 2^21; SHA512 > ~= 2^20, etc, etc > > (65011712 / sizeof hash) > > So in this case, you can have a much higher work factor for the > other algorithms. Looking at section 3.7.1.3, the formula for the work count is defined as: #define EXPBIAS 6 count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); where c is the octet-sized value stored. I could not find the dependence of the work factor from the hash size: could you possibly point me to it? > Although I'm not sure it really matters that much when > off-the-shelf and cheap GPUs can do billions of these a second. With respect to this, picking a memory hard KDF such as scrypt nullifies the benefits of massively parallel hardware, as there's no way of getting both fast and large memories for [G|C]PUs, and a sizeable amount of SRAM takes up a lot of space in a dedicated ASIC breaker. Cheers Alessandro -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlU5N7MACgkQE+mB79BmI3GURAD8D6g/znTgj2uZ7IwFwf7hoqiR CP7jmeOwXvm4LHlCQ3QA/jpoVvSn+UJ0v89+RWex0HigMkqSVd3lVFe+7as7FkBG =WJoE -----END PGP SIGNATURE----- From nobody Thu Apr 23 11:53: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 5420E1A0377 for ; Thu, 23 Apr 2015 11:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 AQkqpUF12k-J for ; Thu, 23 Apr 2015 11:53:01 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 3C0361A0056 for ; Thu, 23 Apr 2015 11:52:39 -0700 (PDT) Received: by qkx62 with SMTP id 62so16524301qkx.0 for ; Thu, 23 Apr 2015 11:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=elowe.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4Vr4dD2yVxOCUx9G2u5LAtp3BzuhSz+KYVE7Xo2gNYE=; b=Ox7whE194Db4w6jcUgz4R3j9nHX+of9rKG6nfyI+CIEXJ5rhN5UD5CqLDWUTxIJhdT u+E3Od7ShWA1KqLd12/xlGRvLzqS4edk2d/KAXl3fPx+sVmDW4oHwdea3r2q6Mg1esx2 EF+Edrpe4ONo4gnYCXlZ2IXHjOFR278H+VUsQ= 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:content-type; bh=4Vr4dD2yVxOCUx9G2u5LAtp3BzuhSz+KYVE7Xo2gNYE=; b=kp7pxfnICWzk36L8bBlr0xleKpbTERseq2WzXW7FX7pYOBxodQBnQZVzTiOHN6LFz0 gx+yazc00Yf0Wm96te2R69ElSSOebHeiqGQ6AL0SciAe9CaxjF03bkVAZhIqmpbfpTk1 LLaBS24/cpMGsrirfeJV7j9kmkkBPP9He9ZFRkjojYS/L0zrQZuITjcMWyEQQmIpMeeK EWXelN53j0+3hrwpeSmyPqMIq3Oee+852yMQ2UgaKLMFrgr5yLE46Lzz24QwUVNok4s7 iW/uxzIr2u6k9wXhQ1uj3pTp84AHNnz9lsVcbg9UgvTiCttlSbM9uuTwaonRhUzwh/DS 4yjQ== X-Gm-Message-State: ALoCoQk1JI37SZf5BHYH1G92Webxh2gIXkPPFnUgVXucI09FkE7wPEXAd78VasE8D2+IS5YPCwDm MIME-Version: 1.0 X-Received: by 10.141.28.142 with SMTP id f136mr3221969qhe.67.1429815158515; Thu, 23 Apr 2015 11:52:38 -0700 (PDT) Received: by 10.140.73.116 with HTTP; Thu, 23 Apr 2015 11:52:38 -0700 (PDT) In-Reply-To: <553937B3.20702@polimi.it> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <5538CB82.7000102@polimi.it> <553937B3.20702@polimi.it> Date: Thu, 23 Apr 2015 11:52:38 -0700 Message-ID: From: Earle Lowe To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=001a11423d2a9e4003051468c841 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 18:53:05 -0000 --001a11423d2a9e4003051468c841 Content-Type: text/plain; charset=UTF-8 Assume iteration count to mean "the number of times I call the hash function - eg the number of times I call Sha256()" (this is my understanding of the typical work factor eg for PBKDF2) The OpenPGP work factor is a count of bytes to hash. If the hash function hashes 32 bytes, then I would call that hash function "count / 32" - as each invocation gives me 32 bytes. (this may be overly simplistic a view - please correct me if I'm overly simple ) -Earle On Thu, Apr 23, 2015 at 11:19 AM, Alessandro Barenghi < alessandro.barenghi.polimi@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 04/23/2015 05:18 PM, Earle Lowe wrote: > > The maximum work factor for RFC4800 S2K is lower than the maximum > > for (eg) PBKDF2 > > Yes, although it is possible to match ones commonly used now (1k-3k) > and have a reasonable margin for raising the value (hitting around > 100k is not a problem, which keeps the now-dying Moore law at bay for > another 10 yrs at worst). > > > As the maximum for RFC4800 is specified in bytes, the iteration > > count (number of hash invocations) goes down as the size of the > > hash increases. > > > > The max iteration count for SHA1 ~= 2^22; SHA256 ~= 2^21; SHA512 > > ~= 2^20, etc, etc > > > > (65011712 / sizeof hash) > > > > So in this case, you can have a much higher work factor for the > > other algorithms. > > Looking at section 3.7.1.3, the formula for the work count is defined as: > #define EXPBIAS 6 > count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); > > where c is the octet-sized value stored. I could not find the > dependence of the work factor from the hash size: could you possibly > point me to it? > > > > Although I'm not sure it really matters that much when > > off-the-shelf and cheap GPUs can do billions of these a second. > > With respect to this, picking a memory hard KDF such as scrypt > nullifies the benefits of massively parallel hardware, as there's no > way of getting both fast and large memories for [G|C]PUs, and a > sizeable amount of SRAM takes up a lot of space in a dedicated ASIC > breaker. > > Cheers > > Alessandro > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAlU5N7MACgkQE+mB79BmI3GURAD8D6g/znTgj2uZ7IwFwf7hoqiR > CP7jmeOwXvm4LHlCQ3QA/jpoVvSn+UJ0v89+RWex0HigMkqSVd3lVFe+7as7FkBG > =WJoE > -----END PGP SIGNATURE----- > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a11423d2a9e4003051468c841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Assume iteration count to mean "the number of times I= call the hash function - eg the number of times I call Sha256()" (thi= s is my understanding of the typical work factor eg for PBKDF2)

The OpenPGP work factor is a count of bytes to hash. If the hash fu= nction hashes 32 bytes, then I would call that hash function "count / = 32" - as each invocation gives me 32 bytes.

(= this may be overly simplistic a view - please correct me if I'm overly = simple )

-Earle


On Thu, Apr 23, 2015 at 11:19 A= M, Alessandro Barenghi <alessandro.barenghi.polimi@gmai= l.com> wrote:
-----BE= GIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/23/2015 05:18 PM, Earle Lowe wrote:
> The maximum work factor for RFC4800 S2K is lower than the maximum
> for (eg) PBKDF2

Yes, although it is possible to match ones commonly used now (1k-3k)=
and have a reasonable margin for raising the value (hitting around
100k is not a problem, which keeps the now-dying Moore law at bay for
another 10 yrs at worst).

> As the maximum for RFC4800 is specified in bytes, the iteration
> count (number of hash invocations) goes down as the size of the
> hash increases.
>
> The max iteration count for SHA1 ~=3D 2^22; SHA256 ~=3D 2^21; SHA512 > ~=3D 2^20, etc, etc
>
> (65011712 / sizeof hash)
>
> So in this case, you can have a much higher work factor for the
> other algorithms.

Looking at section 3.7.1.3, the formula for the work count is define= d as:
#define EXPBIAS 6
=C2=A0 =C2=A0 count =3D ((Int32)16 + (c & 15)) << ((c >> 4)= + EXPBIAS);

where c is the octet-sized value stored. I could not find the
dependence of the work factor from the hash size: could you possibly
point me to it?


> Although I'm not sure it really matters that much when
> off-the-shelf and cheap GPUs can do billions of these a second.

With respect to this, picking a memory hard KDF such as scrypt
nullifies the benefits of massively parallel hardware, as there's no way of getting both fast and large memories for [G|C]PUs, and a
sizeable amount of SRAM takes up a lot of space in a dedicated ASIC
breaker.

Cheers

Alessandro


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlU5N7MACgkQE+mB79BmI3GURAD8D6g/znTgj2uZ7IwFwf7hoqiR
CP7jmeOwXvm4LHlCQ3QA/jpoVvSn+UJ0v89+RWex0HigMkqSVd3lVFe+7as7FkBG
=3DWJoE
-----END PGP SIGNATURE-----

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

--001a11423d2a9e4003051468c841-- From nobody Thu Apr 23 12:04: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 8C4341A8768 for ; Thu, 23 Apr 2015 12:04:35 -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 wc0LO5epW5li for ; Thu, 23 Apr 2015 12:04:34 -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 C951B1AD0A0 for ; Thu, 23 Apr 2015 12:03:18 -0700 (PDT) Received: by lagv1 with SMTP id v1so19657748lag.3 for ; Thu, 23 Apr 2015 12:03:17 -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=PEckp5BSATunMJ1OO0zmEWlG+wm5q0QCrwpPaeOpe8Q=; b=yUsb9GUqCl9/Gzkrklc5MzqTflRl/d1I90O7g3plBd28GjQCkKAhBdzi2a6ke+aWVh dEdxbn8X9HK99V5dZcrNTxKZd+keUaSgQK4gZ28luSn7AqywBDJQhfC/UoiUGMvNd7ve 2wYhGAAS0+kC3pvo0NrqArARlngJetcVuJDpb2c4xueIkQwDtEwjaw3gk9yQXUxDxjlU J9J8MlEWUSYqMH0zhaiXIkfVz4Ybb/L5BmIi50gN3Q0YpB79TfDNleNKb/HJKb3qEgux nCMNXTNcoC5H95qMKRKP5iyoMuPLhAuonYruCM9cp/vbKXsb7JRvcXbjd3kLbmDuiQWb FS2w== MIME-Version: 1.0 X-Received: by 10.112.40.9 with SMTP id t9mr3835828lbk.55.1429815797300; Thu, 23 Apr 2015 12:03:17 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 23 Apr 2015 12:03:17 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> Date: Thu, 23 Apr 2015 15:03:17 -0400 X-Google-Sender-Auth: hyvavJU1m8FITyy3EqwyWLM94t4 Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , IETF OpenPGP , Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 23 Apr 2015 19:04:35 -0000 On Thu, Apr 23, 2015 at 11:48 AM, Derek Atkins wrote: > Christoph Anton Mitterer writes: > >> On Mon, 2015-04-20 at 23:50 -0700, Jon Callas wrote: >>> Personally, I think that the present way things are done is >>> syntactically fine. Semantically, there are many bogosities. You can >>> time-limit your signature on a key, but no one ever does. >> As I've explained before, I don't think that this is the same as >> hardcoding it into the key, as it wouldn't change the fingerprint, would >> it?! > > No, it would not, which is IMHO the right thing. > > I.e., IMNSHO I feel you should expire your key by expiring your > self-signature on the key. If you want to extend your key then you > re-sign it with a new self-signature. You are not expiring a key. That is impossible in any PKI and almost certainly undesirable. What you are doing is expiring an assertion binding between the key to a set of attributes. Similarly you are not revoking a key, you are making an irrevocable and permanent assertion that the key is not valid. Being precise about these things is going to be important if we are going to actually clean up OpenPGP and not add more confusion. It is quite possible to set a key fingerprint for expiry however. We simply take a fingerprint of an assertion that includes an expiry time. From nobody Thu Apr 23 12:36: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 BA4581B29EE for ; Thu, 23 Apr 2015 12:36:02 -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_84=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 v3JAXZGr0nKg for ; Thu, 23 Apr 2015 12:36:02 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 701991B29E3 for ; Thu, 23 Apr 2015 12:35:55 -0700 (PDT) Received: by wgso17 with SMTP id o17so29290113wgs.1 for ; Thu, 23 Apr 2015 12:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1hB2wpcz3gYDaRXst17GGe9DuL6ytPpVgYE8pDOinpg=; b=Tk/YT9eIxtzzrdBwE/JDl+7x3mPhkvW6itzCxIL1VGl/rQnZA63Hh81DWuw8O93DJ+ hdySUoFaT9mgVTp3FBKGnWLswaPKFRRRm5P5I2cSu7FJUvFYVEUfRoFwfSsxXPbxz1C7 kjOFaHjTYb1UBbJ1iRU5j6ogm3YyWskD3JfihnbrWUTE9YhoKC+mmpGrlyIfO2O0fhWd WRyKI+8m3vF8LGAxN6I8sRMBwaXCDYb8loKhomaHhiCndQey7lApLXRYU/15K0FMGscp gL0TPdPvAy949KlI9zkzPW1LrfpofzqiqYtygTqrh7cU79MKukWk2s2zEspW6E1FduiP DrkA== X-Received: by 10.194.90.172 with SMTP id bx12mr8435915wjb.93.1429817754246; Thu, 23 Apr 2015 12:35:54 -0700 (PDT) Received: from [131.175.121.117] (pc121-117.elet.polimi.it. [131.175.121.117]) by mx.google.com with ESMTPSA id go4sm292863wib.1.2015.04.23.12.35.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 12:35:53 -0700 (PDT) From: Alessandro Barenghi X-Google-Original-From: Alessandro Barenghi Message-ID: <5539499E.4010305@polimi.it> Date: Thu, 23 Apr 2015 19:35:58 +0000 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: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <5538CB82.7000102@polimi.it> <553937B3.20702@polimi.it> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 19:36:02 -0000 On 04/23/2015 06:52 PM, Earle Lowe wrote: > Assume iteration count to mean "the number of times I call the hash > function - eg the number of times I call Sha256()" (this is my > understanding of the typical work factor eg for PBKDF2) Ok, I'm on the same boat > The OpenPGP work factor is a count of bytes to hash. Ok, now I got the point, thanks :) > If the hash > function hashes 32 bytes, then I would call that hash function "count / > 32" - as each invocation gives me 32 bytes. As far as I know, the input to a hash function has a very large limit on its maximum size (2^64 for SHA-2-... functions), so, if I get that correctly, this means that given a count value C , the hash function gets called: (C- (size of passwd+salt)) / output_hash_size correct? (which, on a curious side note means "the longer the password+salt, the lesser the amount of calls to the hash function", although the computation effort is substantially the same) Cheers Alessandro From nobody Thu Apr 23 12:45:18 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 EC2E61B31D2 for ; Thu, 23 Apr 2015 12:45:16 -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 pjq4UJaxN02c for ; Thu, 23 Apr 2015 12:45:15 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::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 22F9D1B31E2 for ; Thu, 23 Apr 2015 12:44:51 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so68974436ieb.3 for ; Thu, 23 Apr 2015 12:44:50 -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=HQjhac4tAl1Zl2b4EcjmapeWC/7nY65Eo98pGNn10AM=; b=KR3VKiYYP9+sGLELcOuCtqUOf6qhdjCJrTVBTzfwN04aPidU6XBdMRBzlq5sGV6t6y kBtrE6GnDDiQBQaAgDBdy3nkN9kBOxJ6SX0cdJAqFadaAniFvrrAP9FPrivXz4HN20pu lSdDQVCisMDHH/tY9Pv4NMSFQoAcgHT9OBYFDBDg3cBoFxFL+fFpz4qGTdQKgtOWnHsR P8pIMraNNksXc4BWFItfZLioCYQJbnyTZjdOuyERE32i1fRVzXUoicgzYWY1JtjCFPpU a/7JYL81ZIW6BXp/TpC3kVSnFZQf17lHF4PML5DUiiC/YFNqZDdU5vE8hd/nvjdnOBSB pLig== X-Received: by 10.50.77.13 with SMTP id o13mr14436000igw.39.1429818290665; Thu, 23 Apr 2015 12:44:50 -0700 (PDT) MIME-Version: 1.0 References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> In-Reply-To: <87egnbs4fp.fsf@vigenere.g10code.de> From: David Leon Gil Date: Thu, 23 Apr 2015 19:44:49 +0000 Message-ID: To: Benjamin Kaduk , "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc110a4efbe40514698337 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 23 Apr 2015 19:45:17 -0000 --047d7bdc110a4efbe40514698337 Content-Type: text/plain; charset=UTF-8 The input to the hash function is predictable. You can thus (depending on how the hash function is constructed) precalculate some portion of the S2K function. For example: For SHA-1 and SHA-2, message expansion is independent of the chaining value. So for, e.g., an 8 byte password, you only need to expand the message schedule *once*. See https://github.com/google/end-to-end/issues/150 On Thu, Apr 23, 2015 at 12:16 AM Werner Koch wrote: > On Thu, 23 Apr 2015 02:46, coruus@gmail.com said: > > S2K with MD hashes is a horrible KDF. It is very very much worse than > > PBKDF2. > > Care to explain? > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > --047d7bdc110a4efbe40514698337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The input to the hash function is predictable. You can thus (depending on h= ow the hash function is constructed) precalculate some portion of the S2K f= unction.

For example: For SHA-1 and SHA-2, message expansion is ind= ependent of the chaining value. So for, e.g., an 8 byte password, you only = need to expand the message schedule *once*.

See https://github.com/google/end-to-en= d/issues/150
On Thu, Apr 23, 2015 at 12:1= 6 AM Werner Koch <wk@gnupg.org> w= rote:
On Thu, 23 Apr 2015 02:46, coruus@gmail.com said: > S2K with MD hashes is a horrible KDF. It is very very much worse than<= br> > PBKDF2.

Care to explain?


Salam-Shalom,

=C2=A0 =C2=A0Werner

--
Die Gedanken sind frei.=C2=A0 Ausnahmen regelt ein Bundesgesetz.

--047d7bdc110a4efbe40514698337-- From nobody Fri Apr 24 00:19: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 1A7F91B2ED3 for ; Fri, 24 Apr 2015 00:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 hZyB93GiFj9q for ; Fri, 24 Apr 2015 00:19:21 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA621B3507 for ; Fri, 24 Apr 2015 00:19:04 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-07v.sys.comcast.net with comcast id KjK31q0015Clt1L01jK3rZ; Fri, 24 Apr 2015 07:19:03 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-17v.sys.comcast.net with comcast id KjK21q0054uhcbK01jK2CG; Fri, 24 Apr 2015 07:19:03 +0000 Message-ID: <5539EE66.2060002@brainhub.org> Date: Fri, 24 Apr 2015 00:19:02 -0700 From: Andrey Jivsov 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: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> In-Reply-To: <877ftkqhr4.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429859943; bh=9ulmfbmwY+LgtUUbuTzHVcUGLEA5F6eifqYESxXv7Hg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a5X4z9x+E1DEHHcbntU8kV7kl+rvJMGd6y54LqQR0GAiseoc+P33iRlASW4J6SMgE XMMKeP6cl43ovHW+BCK/T5pPzfQtc68AsX7WLbk5PSqNZRWGq6QwTVylfd6k0bwkjA gVT55C7uMcig7Z4q7A058F5FUNHlrKOtkfqIusMwFwbEIGQNKbTX4bZqYWv2CJwB3w mekJycLi5JE5XQBOLtvEZel+h/U9Fgssv6/hJmJzGMatYOv2x9bOrnOU1yqVH/wozy R4MEy9jhbvI+rqE83qFfsAQqEyC95gGGx3jJV7TF+/CMMfEFBqpV+10EUVPlTJrHnr 6OdXAIGvW/sKg== Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 24 Apr 2015 07:19:23 -0000 In summary, I would be more concerned with users getting wrong impression that somehow their low-entropy password will get "upgraded" by a new S2K scheme. There is a cost of change, and I think if the OpenPGP does change the S2K, the choice should bring concrete additional benefits. Here is why: 1. One should keep in mind what value the iterative methods like S2K or PDKDF actually provide. Assuming that the number of iterations is c and the password space has 2^n entries, the work factor for legitimate users is c*2^n, as opposed to 2^n without iterated calculations. Doubling the c slows the computation time in half for the attacker as well as for the the password holder; this is equivalent to adding 1 bit of extra entropy to password space. This offers one of the worst cost-benefits to legitimate users. Just compare this with any other computational security schemes, such as public key crypto (exponential v.s. polynomial complexity). 2. The Iterated S2K is essentially a M = M1 || M2 || M2 || M2 || ... || M2, where M1 includes the salt. S2K = Hash( M ) (assuming that hash output is no smaller than the number of bits required for the key). In many respects, this construction is easier to analyze. There is no attempt to "fix" the hash function as in some other schemes. Imagine a sponge construction like SHA3 Keccak or many other hash functions with sufficient internal state (probably including SHA-256), which should be fine to handle the above task. 3. The max number of iterations that the S2K counter encodes is c = 16+15^(15) + 6 > 2^58 For SHA1 S2K this is over 2^53 invocations and about the same for SHA-256. SHA-256 can only hash 2^64 bytes. Likewise, AES-256, as any 16-byte block cipher, is considered insecure after about the same number of invocations due to the birthday bounds limitation. This is plenty of iterations for the foreseeable future. 4. One can argue that the S2K construction is one of the strongest in active use today. If we assume that it's possible to recover M given the S2K as defined the above, i.e. to invert a hash function (even assuming somehow that S2K value is known, which it is not) then many existing schemes will be broken. For example, an attacker that is able to get M from S2K can use the same method to recover the authentication key K from an HMAC MAC value, leading to the forgery of MAC. The proof is easy: use the "oracle" that returns M from S2K = Hash( M ) to recover the HMAC key as follows: get M' = K ^ opad | H( K ^ ipad | m ), which reveals the K as M' ^ opad with appropriate truncation. The other problem one might try to solve with S2K construction is how the scheme behaves with non-uniform hash functions. ( Imagine that a hypotherical Hash() often returns all-zero output for random M). However, we don't intend to use these hash functions, will quickly replace them if we discover that we do. It's hard to see that S2K and PBKDF are materially different. ( In less formal language: PBKDF2 should have the same resulting weakness, but long before this the collision resistance will likely be broken ). Both schemes have the same problems. For example, both have an unfortunate property that if the two invocations of PBKDF (or S2K) use the same salt and password but different counters c1, c2, the S2K or PBKDF can be calculated from the previous values with just |c2-c1| iterations. I.e. it seems like an oversight that c was not hashed. As was noted by others, it may be desirable to increase memory footprint requirements. HKDF is not designed to handle S2K. (It's main target are things like derivation of an AES key from a DH shared secret). At least it needs the stretching step defined. From nobody Fri Apr 24 04: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 144941A9008 for ; Fri, 24 Apr 2015 04: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 2YntJR-Y2yzi for ; Fri, 24 Apr 2015 04: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 F319B1A8AF8 for ; Fri, 24 Apr 2015 04:51:42 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Ylc8z-0000lJ-7U for ; Fri, 24 Apr 2015 13:51:41 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Ylc2y-0006ko-BZ; Fri, 24 Apr 2015 13:45:28 +0200 From: Werner Koch To: Andrey Jivsov References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <5539EE66.2060002@brainhub.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Andrey Jivsov , openpgp@ietf.org Date: Fri, 24 Apr 2015 13:45:27 +0200 In-Reply-To: <5539EE66.2060002@brainhub.org> (Andrey Jivsov's message of "Fri, 24 Apr 2015 00:19:02 -0700") Message-ID: <87iocloilk.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] 4880bis: Update S2K 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, 24 Apr 2015 11:51:45 -0000 On Fri, 24 Apr 2015 09:19, openpgp@brainhub.org said: > 2. The Iterated S2K is essentially a > > M = M1 || M2 || M2 || M2 || ... || M2, where M1 includes the salt. > S2K = Hash( M ) Actually M2 also includes the salt: | Then the salt, followed by the passphrase data, is repeatedly hashed | until the number of octets specified by the octet count has been | hashed. [...] Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Apr 24 10:11: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 321471B37BD for ; Fri, 24 Apr 2015 10:11:26 -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 WNMaBCzWBWkm for ; Fri, 24 Apr 2015 10:11:25 -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 BC0EA1B37B9 for ; Fri, 24 Apr 2015 10:11:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B1BC0E2039; Fri, 24 Apr 2015 13:11:23 -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 07691-06; Fri, 24 Apr 2015 13:11: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 361FAE2035; Fri, 24 Apr 2015 13:11:21 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3OHBKBZ000461; Fri, 24 Apr 2015 13:11:20 -0400 From: Derek Atkins To: Christoph Anton Mitterer References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <1429805507.27711.15.camel@scientia.net> Date: Fri, 24 Apr 2015 13:11:20 -0400 In-Reply-To: <1429805507.27711.15.camel@scientia.net> (Christoph Anton Mitterer's message of "Thu, 23 Apr 2015 18:11:47 +0200") 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, Derek Atkins Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 24 Apr 2015 17:11:26 -0000 Christoph Anton Mitterer writes: > On Thu, 2015-04-23 at 11:48 -0400, Derek Atkins wrote: >> No, it would not, which is IMHO the right thing. >> >> I.e., IMNSHO I feel you should expire your key by expiring your >> self-signature on the key. If you want to extend your key then you >> re-sign it with a new self-signature. > Well but than it's useless to make the key as a whole expirable. No, it's not useless. If you know that when you generate the key you absolutely never want it to be usable past a certain date, then you put the expiry into the Public Key packet. Once that date passes, the key has expired. The date should be immutable. However if you're not sure, or you want to prove user liveness on the key, you can perform similar functions (note that it's not exactly the same function) by using expiring self signatures. > And as I outlaid before, this destroys the use case that a user wants to > limit the usability of his key, regardless of whether e.g. old signature > algos would be broken or his key compromised. It doesn't destroy the use case; you can still use the Key Expiry. It's just an IMMUTABLE setting. If you change it then it should make it a "new" key, which means a different fingerprint (and invalidating all signatures). > If that's only in the selfsig *without* invalidating the other > signatures, then an attacker could try a downgrade attack and e.g. forge > the selfsig with weaker algos... or more likely... simply create a new > selfsig when the key was compromised. Yes, this is a risk of not using the expiry field in the key packet. > If the fingerprint and other users' signatures wouldn't invalidate them, > all the attacker needs to do is block the revocation (if any). I'm not sure I understand this statement. > Therefore, it should be mandatory that both, the valid from and valid to > times are encoded in such a way, that changing them would render all > other signatures invalid and would change the FP. > (Of course it should be possible to specify and infinite expiration > time). Yes, that's why the key expiry should be immutable. Changing it would invalidate all signatures on the key, as well as changing the key fingerprint. I.e., it's a "different key". However the key expiry should not be mandatory (i.e. it can be 0, meaning "never expired"). There are use cases where you might not necessarily want the key to expire, or you might not know when it should expire. > Cheers, > Chri -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 24 10:38: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 668861B3828 for ; Fri, 24 Apr 2015 10:38:34 -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 LpmEHfxfyYSb for ; Fri, 24 Apr 2015 10:38:33 -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 D02E61B3827 for ; Fri, 24 Apr 2015 10:38:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 862D3E2036; Fri, 24 Apr 2015 13:38: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 08034-01; Fri, 24 Apr 2015 13:38:29 -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 3372DE2035; Fri, 24 Apr 2015 13:38:29 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3OHcROa001698; Fri, 24 Apr 2015 13:38:27 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> Date: Fri, 24 Apr 2015 13:38:27 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 23 Apr 2015 15:03:17 -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: Werner Koch , Christoph Anton Mitterer , IETF OpenPGP , Derek Atkins , Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 24 Apr 2015 17:38:34 -0000 Phillip Hallam-Baker writes: > On Thu, Apr 23, 2015 at 11:48 AM, Derek Atkins wrote: >> Christoph Anton Mitterer writes: >> >>> On Mon, 2015-04-20 at 23:50 -0700, Jon Callas wrote: >>>> Personally, I think that the present way things are done is >>>> syntactically fine. Semantically, there are many bogosities. You can >>>> time-limit your signature on a key, but no one ever does. >>> As I've explained before, I don't think that this is the same as >>> hardcoding it into the key, as it wouldn't change the fingerprint, would >>> it?! >> >> No, it would not, which is IMHO the right thing. >> >> I.e., IMNSHO I feel you should expire your key by expiring your >> self-signature on the key. If you want to extend your key then you >> re-sign it with a new self-signature. > > You are not expiring a key. That is impossible in any PKI and almost > certainly undesirable. Well, it depends. In OpenPGP you *can* expire the key (by setting the Key Expiration in the Public Key Packet by setting it to a non-zero value). My argument is that that setting should be immutable. I.e., if you change the value in the key packet, it's IMHO effectively a new key, with a new fingerprint, and would require new signatures. Whether or not it's desireable is an open question (and one I don't think you or I can make for the users). > What you are doing is expiring an assertion binding between the key to > a set of attributes. Similarly you are not revoking a key, you are > making an irrevocable and permanent assertion that the key is not > valid. > > Being precise about these things is going to be important if we are > going to actually clean up OpenPGP and not add more confusion. I agree it's important to be precise. And yes, the proposal I made earlier to use the self-sig is indeed expiring the assertion binding the key to a UserID. I.e., the signature itself has an expiry (which is independent of the expiry field in the Public Key Packet). When the signature expires then the assertion expires. But of course you can refresh the signature; it doesn't change the key. Of course, as pointed out, you're only as strong as your weakest algorithm, so there is a risk of someone being able to create a false signature using a (supported) broken hash algorithm. I consider this a LOW risk, but it is still a risk. > It is quite possible to set a key fingerprint for expiry however. We > simply take a fingerprint of an assertion that includes an expiry > time. This is... different. OpenPGP allows you to specify a fingerprint as a dedicated revoker. I.e., I assert (via a self-sig IIRC) that the key with fingerprint X is allowed to revoke this key. I'm not sure that you would use your own fingerprint for anything like this. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Apr 24 12:03: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 0391C1B3687 for ; Fri, 24 Apr 2015 12:03:12 -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 psqZ0pQDsqrq for ; Fri, 24 Apr 2015 12:03:10 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id B28861B31B5 for ; Fri, 24 Apr 2015 12:03:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 60B3E7131FA1; Fri, 24 Apr 2015 12:03: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 DsRl06Q3BF4I; Fri, 24 Apr 2015 12:03:08 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 12D467131F85; Fri, 24 Apr 2015 12:03:02 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 24 Apr 2015 12:03:08 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 24 Apr 2015 12:03:08 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: Date: Fri, 24 Apr 2015 12:03:00 -0700 Message-Id: References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 24 Apr 2015 19:03:12 -0000 > On Apr 20, 2015, at 9:53 AM, Phillip Hallam-Baker = wrote: >=20 >=20 > What we need is the PKI equivalent of structured programming. PKIX is > Pascal. PGP is BASIC. Yes, you can do anything with IF-THEN-GOTO. But > you probably should not try. If only there were a way to do that. Let's consider a machine that has a set of simple operations that it can = do, like IF-GOTO and another language that did more complex things like = IF-THEN-ELSE. If we could make something that could take the complex = language and translate it into a set of the simpler statements reliably, = then perhaps we could solve that problem. Jon From nobody Fri Apr 24 12:09: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 373091B384B for ; Fri, 24 Apr 2015 12:09: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 aEUeY1fFGh7u for ; Fri, 24 Apr 2015 12:09:05 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEB61B3730 for ; Fri, 24 Apr 2015 12:09:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id E7C1D7132320; Fri, 24 Apr 2015 12:09: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 Js4d3Mwzep-5; Fri, 24 Apr 2015 12:09:03 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id DF7A67132310; Fri, 24 Apr 2015 12:09:03 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 24 Apr 2015 12:09:03 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 24 Apr 2015 12:09:03 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: Date: Fri, 24 Apr 2015 12:09:01 -0700 Message-Id: References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 24 Apr 2015 19:09:06 -0000 Okay, turning off my smartass mode for a moment. PGP does this. By the way, PGP is registered trademark owned by = Symantec. They presently call that software "Symantec Endpoint = Encryption" and "Symantec Encryption Management Server" but that's PGP. OpenPGP is an IETF standard for describing crypto syntax and protocols. X.509 and OpenPGP are isomorphic to each other. You can do anything in = one of them that you can do in the other. If you take an OpenPGP key, = you can express the same thing with a set of X.509 certificates. It = works. We did it. PGP does OpenPGP, X.509, CMS and S/MIME. You can do it. You just have to want to. Jon From nobody Fri Apr 24 12:11: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 102441A0102 for ; Fri, 24 Apr 2015 12:11:20 -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 Tm7yeRZfF_ry for ; Fri, 24 Apr 2015 12:11:19 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBDC1A1BBC for ; Fri, 24 Apr 2015 12:11:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id BDF75713244D; Fri, 24 Apr 2015 12:11:17 -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 2toJPtaMOP4x; Fri, 24 Apr 2015 12:11:08 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 287CA7132419; Fri, 24 Apr 2015 12:11:08 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 24 Apr 2015 12:11:08 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 24 Apr 2015 12:11:08 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <1429543533.24823.73.camel@scientia.net> Date: Fri, 24 Apr 2015 12:11:04 -0700 Message-Id: <2142458E-1636-4E3B-8CCE-36078AFC02C9@callas.org> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <1429543533.24823.73.camel@scientia.net> To: Christoph Anton Mitterer X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Fingerprints 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, 24 Apr 2015 19:11:20 -0000 > On Apr 20, 2015, at 8:25 AM, Christoph Anton Mitterer = wrote: >=20 > * PGP - S/MIME Signed: 04/20/2015 at 08:25:33 AM >=20 > And specifying a expiration time (even if it's 0) should be mandatory. >=20 That's there now. When Derek says "if it's there" he means that it could = be there. Syntactically, a zero means no expiration. >=20 > * Christoph Anton Mitterer > * Issuer: CAcert Inc. Jon From nobody Fri Apr 24 12:43: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 49FD71B388F for ; Fri, 24 Apr 2015 12:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 T2jA9CJ-vYga for ; Fri, 24 Apr 2015 12:43:13 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id AA9C21B29EE for ; Fri, 24 Apr 2015 12:43:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 73CA0713366F; Fri, 24 Apr 2015 12:43:11 -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 caeVeRr9bskU; Fri, 24 Apr 2015 12:43:01 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 8A6DC713363D; Fri, 24 Apr 2015 12:42:58 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 24 Apr 2015 12:43:01 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 24 Apr 2015 12:43:01 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <87pp74e9js.fsf@littlepip.fritz.box> Date: Fri, 24 Apr 2015 12:42:57 -0700 Message-Id: <33FA9189-595F-459D-9695-B941787FCB1A@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> To: Vincent Breitmoser X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "openpgp@ietf.org" Subject: [openpgp] Key Usage, Designated Revocation 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, 24 Apr 2015 19:43:15 -0000 (Pulled into a new subject.) > Can someone explain why key usage and preference flags for the primary > were made part of user id signatures instead of a direct key signature > or something of the sort? I felt like this added a lot of complexity > and non-determinism to those parts of the implementation which dealt > with that. Because you want the key owner to issue a signed statement that says = "this is how I want you to use my key" and you want that to be part of = the self-signature that says "I own this key." You don't want a separate = signature, because you don't want them to be torn apart. > Secondly, (this came up somewhere else), I'm not convinced at all that > designated revokers (5.2.3.15) are a good idea. Is there a significant > advantage over just handing the person a revocation certificate of = your > key? I remember deciding against implementing this feature at some = point > in OpenKeychain because the complexity/benefit tradeoff just wasn't > there. Let's face it. Revocation is not as good as people think it is. In the = general case it cannot work. There are specific cases where it can work, = but you must always account for the case that there is revocation = information, you're just not getting it. It's true in OpenPGP, where a = revocation signature can be stripped from the key, and true in CRLs = where there are all sorts of spoofing things that can be done that block = you from the information. You can in some cases *know* you've been = blocked. (Suppose the connection to the CRLDP (etc.) fails outright, or = it hands you an old CRL.) Sadly, the correct thing to do is almost never to pull the emergency = brake and stop whatever process you're doing. The reason is that the = likelihood of a completely reasonable reason for the failure (your = network sucks) is several orders of magnitude higher than a real needed = revocation. (There are many, many unneeded revocations. For example, I know a = code-signing system where the code-signing cert includes a bunch of = developer information. Every time the developer changes anything in = their web profile, a new cert gets issued, the old cert gets put on a = CRL, and the old cert is also thrown away. It's rigorous and tidy, but = utterly unneeded.) Anyway, I advise not going too far to fix revocation because there are = edge conditions on the edge conditions. It works when it works and how = it works, and just accept it. But I didn't answer your question. Sorry. You can do that now -- Alice = can give Bob a pre-revoked key and ask him to release it when she asks. But you don't want to do that for a number of reasons. One is that you = can't a priori know *why* you're going to revoke. You also can't a = priori know *when* you want to revoke. If Alice loses her laptop on = April 24, you want signatures she made on April 23 to still be valid. = You really don't want to undo everything that key ever did. That makes = revocation worse than useless. Presently revocation is kinda sorta often = useful.=20 On top of that, the thing that Bob has is dangerous data. It has to be = stored somewhere with all the seriousness of a private key, if not more = because it's trust issue. (Not this weird thing we call trust in public = key infrastructure, but actual real trust.) It makes a whole huge OPSEC = issue that's harder to solve than it is to implement the designated = revoker. Yeah, having it makes it hard on a developer, but not having it = pushes the problem to people who are incapable of doing it right. Jon From nobody Fri Apr 24 12:46: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 B6BAB1B389E for ; Fri, 24 Apr 2015 12:45:58 -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 wAv7dluCt-fD for ; Fri, 24 Apr 2015 12:45:57 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id CDFD11B389D for ; Fri, 24 Apr 2015 12:45:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 6D44971338EF; Fri, 24 Apr 2015 12:45:56 -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 5ZzhOBqyrB5a; Fri, 24 Apr 2015 12:45:55 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id A6F7671338DB; Fri, 24 Apr 2015 12:45:54 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 24 Apr 2015 12:45:55 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 24 Apr 2015 12:45:55 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <87k2xcdqtt.fsf@littlepip.fritz.box> Date: Fri, 24 Apr 2015 12:45:51 -0700 Message-Id: References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <87mw28e0w1.fsf@littlepip.fritz.box> <1429189446.1702.90.camel@scientia.net> <87lhhsdwqn.fsf@littlepip.fritz.box> <87k2xcdqtt.fsf@littlepip.fritz.box> To: Vincent Breitmoser X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] details of 4880bis work 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, 24 Apr 2015 19:45:58 -0000 > On Apr 16, 2015, at 8:28 AM, Vincent Breitmoser = wrote: >=20 > My use of the term was misleading I must admit, going by 4880. I just > always found it confusing that a "public key" in OpenPGP lingo means = "a > collection of one primary key and some subkeys", where each of those = is > a 'public key' in itself in a cryptographical sense. And that's why sometimes you should just use the word "Certificate." Jon= From nobody Fri Apr 24 12:51: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 F28661A0387 for ; Fri, 24 Apr 2015 12:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 8BwVfU_elCTn for ; Fri, 24 Apr 2015 12:51:25 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 69CD81A037D for ; Fri, 24 Apr 2015 12:51:25 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so44190498lbb.2 for ; Fri, 24 Apr 2015 12:51:24 -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:content-transfer-encoding; bh=+/ufppMinC1qaQ8wKAL3mEZF3wB10EdplVAy7RNMQ4Q=; b=iIkVU8m5WuKW/SvRNOtzmytFxrjHATA3VbVtjefxPzTc80H3IGENrFaVK/zULXFtbA 8D1x/gVDgqnqTe4bv1z2Htn0CbGfJf4T/MEeyFXf/iDkiB6QhY6seA09XGFwofBB7QiY N2qVWdFlzL1kd1yKU5qBqt7aG9GkbHdF8RPGO/XfvjQXavxEWBoG21Hp514bJzNocs1E Muj5+mf4d4/Ic72wpXZ1UwjxIV+7RzCddEayCl/vnsH6r+gBT7vcF/OpsxUf+LS7jTO2 87PtAbvzQBKl4OeM8nOC8GlGt/Fgtma+Ctq6fZPFbq8QCTNaccxMoLmGyLXRGkb7nAWX Ikvg== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr22719lbc.79.1429905083959; Fri, 24 Apr 2015 12:51:23 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 24 Apr 2015 12:51:23 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> Date: Fri, 24 Apr 2015 15:51:23 -0400 X-Google-Sender-Auth: BdD9OnLg7aXjbeTd1iWONQoL1eg Message-ID: From: Phillip Hallam-Baker To: Jon Callas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 24 Apr 2015 19:51:27 -0000 What I would like to see is a clear semantic and syntactic separation between first and third party assertions. I am aware that Symantec bought PGP, but it is still the name of Phil Z.'s model. PKIX and OpenPGP both conflate the two. But there is a big difference between them when it comes to trust issues. A first party assertion such as a PKIX root signing an intermediate is a direct assertion and can be modeled in the same manner as a finger print. The only assumptions I am making are that the crypto isn't broken and the key holder has not lost control of their key. Third party assertions are much more complex and problematic. We get into recursion issues and fixed points on contraction mappings and all the math stuff. Neither PKIX nor OpenPGP really provide the end user with the full set of tools needed to do comprehensive key management. The PKIX model is that the user does not have a persistent key history at all, the CA is the only party managing this. OpenPGP takes the UNIX/C attitude of give the users a sharp knife and blame them when they cut themselves. On Fri, Apr 24, 2015 at 3:09 PM, Jon Callas wrote: > Okay, turning off my smartass mode for a moment. > > PGP does this. By the way, PGP is registered trademark owned by Symantec.= They presently call that software "Symantec Endpoint Encryption" and "Syma= ntec Encryption Management Server" but that's PGP. > > OpenPGP is an IETF standard for describing crypto syntax and protocols. > > X.509 and OpenPGP are isomorphic to each other. You can do anything in on= e of them that you can do in the other. If you take an OpenPGP key, you can= express the same thing with a set of X.509 certificates. It works. We did = it. PGP does OpenPGP, X.509, CMS and S/MIME. > > You can do it. You just have to want to. Yep. And I suspect that pretty much anyone that is doing a key management app will do the same. It is really easy to roll the same set of assertions in multiple syntaxes. And that is necessary to solve a lot of real world use cases. I have just bought a QNAP server, it has SSL but does not have a CA issued cert so I get browser warnings. I should be able to snap that server into my personal PKI keychain and have it 'just work' and the protocol for doing that should be no different to the protocol for setting up my email client or my Web browser. And I should be able to do that without having to wait for S/MIME or PGP to win the email format wars or TLS to support PGP certs. It is quite possible to express the full functionality of PKIX in a far more compact form. That is what I was originally commissioned to do by VeriSign in what became XKMS and SAML. TAXI was only about 30 pages long and it did everything the WebPKI does using PKIX. Just instead of OCSP and SCVP and CRLs these were all expressed as assertion validity conditions. From nobody Fri Apr 24 13:02: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 416041A1A66 for ; Fri, 24 Apr 2015 13:02:53 -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 61-opmYVpII8 for ; Fri, 24 Apr 2015 13:02:52 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1C1A1B07 for ; Fri, 24 Apr 2015 13:02:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 449C7713439D; Fri, 24 Apr 2015 13:02:35 -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 DK86JAQLEQYj; Fri, 24 Apr 2015 13:02:32 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 3101C713437E; Fri, 24 Apr 2015 13:02:32 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 24 Apr 2015 13:02:32 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 24 Apr 2015 13:02:32 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <1429617025.11806.88.camel@scientia.net> Date: Fri, 24 Apr 2015 13:02:28 -0700 Message-Id: <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> To: Christoph Anton Mitterer X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Werner Koch , openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time (was: details of 4880bis work) 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, 24 Apr 2015 20:02:53 -0000 > On Apr 21, 2015, at 4:50 AM, Christoph Anton Mitterer = wrote: >=20 > * PGP - S/MIME Signed: 04/21/2015 at 04:50:25 AM >=20 > On Mon, 2015-04-20 at 23:50 -0700, Jon Callas wrote: >> Personally, I think that the present way things are done is >> syntactically fine. Semantically, there are many bogosities. You can >> time-limit your signature on a key, but no one ever does. > As I've explained before, I don't think that this is the same as > hardcoding it into the key, as it wouldn't change the fingerprint, = would > it?! I read your explanation. I understand it. I just disagree. I think that hard-expiration is not only a bad idea, but unenforceable. It's a *good* thing for Alice to be able to update the expiration time = on her key. It encourages putting a limit on (as opposed to no limit) if = it can be changed later. It also allows advanced systems to be able to = do some really cool things with short lived keys. And you probably can't prevent it anyway. X.509 syntax people have = kittens if you reuse a key in certs. And yet a major feature of many PKI = systems is to "reissue" a cert with a new expiration time, because it = makes operations much easier for everyone. Jon From nobody Fri Apr 24 13:08: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 F193A1A1B00 for ; Fri, 24 Apr 2015 13:08:49 -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 UMLYc23OX9zC for ; Fri, 24 Apr 2015 13:08:48 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3F1A1B0E for ; Fri, 24 Apr 2015 13:08:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id A03F97134815; Fri, 24 Apr 2015 13:08:41 -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 Xnp5ssfhgrcr; Fri, 24 Apr 2015 13:08:40 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 117B771347F5; Fri, 24 Apr 2015 13:08:39 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 24 Apr 2015 13:08:39 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 24 Apr 2015 13:08:39 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: Date: Fri, 24 Apr 2015 13:08:34 -0700 Message-Id: <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> To: Nils Durner X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: alessandro.barenghi@polimi.it, "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] 4880bis: Update S2K 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, 24 Apr 2015 20:08:50 -0000 > On Apr 23, 2015, at 2:40 AM, Nils Durner = wrote: >=20 > Wrong. It's not the iteration count - it's the octet count of how many = octets will be hashed. it is isomorphic to iteration count. It's just screwy and too clever by = half. Okay, I take that back. You know how there's a fine line between = clever and stupid? It's so clever that it wraps the cleverness counter = and ends up on the stupid side. I would love to see PBKDF2 in there on the list of things acceptable. = Please do not assume my comment above means that I have *anything* nice = to say about the present iterator. It is, however, as secure as PBKDF2. = It's just too clever by half. Jon From nobody Fri Apr 24 16:15: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 5C3091A1A24 for ; Fri, 24 Apr 2015 16:15:52 -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 KRBd2NHufIWY for ; Fri, 24 Apr 2015 16:15:50 -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 D0DE21A1A20 for ; Fri, 24 Apr 2015 16:15:49 -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 328115FB7E; Fri, 24 Apr 2015 23:15:48 +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 CaC7ryyVejtk; Fri, 24 Apr 2015 23:15:45 +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; Fri, 24 Apr 2015 23:15:45 +0000 (UTC) Message-ID: <1429917345.4659.4.camel@scientia.net> From: Christoph Anton Mitterer To: Phillip Hallam-Baker Date: Sat, 25 Apr 2015 01:15:45 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-GE4xm4ez0QJ1TjpnNAT4" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: Werner Koch , IETF OpenPGP , Derek Atkins , Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 24 Apr 2015 23:15:52 -0000 --=-GE4xm4ez0QJ1TjpnNAT4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2015-04-23 at 15:03 -0400, Phillip Hallam-Baker wrote:=20 > You are not expiring a key. That is impossible in any PKI and almost > certainly undesirable. >=20 > What you are doing is expiring an assertion binding between the key to > a set of attributes. Similarly you are not revoking a key, you are > making an irrevocable and permanent assertion that the key is not > valid. And the important point here to add is, that there is basically no guarantee, that this irrevocable and permanent assertion of revocation ever reaches the user. The contrary, it is likely extremely easy to selectively filter out revocations for each (receiving) user. So when e.g. Wener's key for signing gnupg is compromised, he notices and revokes it, what keeps the ISPs, NSA, cyber criminals & Co. from blocking the revocation? Sure, when they'd do it, it *migh* be noticed, sooner or later,... but when they do it really smart it may be never ever noticed and even if, it may be too late for many people. > It is quite possible to set a key fingerprint for expiry however. We > simply take a fingerprint of an assertion that includes an expiry > time. Yep,... plus the same is needed for any other signtaures which are calculated over the key material + UID data itself. Cheers, Chris. --=-GE4xm4ez0QJ1TjpnNAT4 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNDIzMTU0 NVowTwYJKoZIhvcNAQkEMUIEQGMjggf509L8axX9yKKX1z0cwCyBnKZosfcCUs3nfvlL4FqY2tlE IN1+WpKbppXnR2QUcKezVd9Bfg/If40o5PowagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBgkxqRv+cyiRBrz6SQgYmqc7OJR/uk kojkJ2sTDMlrZyQ6sOfpyS2QjHGd9aBr2vAr/GyUauJptSoqqIFVwGNVy7RyDhOabvXuM/gBsMGz LNJyq4h7VWMzsaalnnwkF5VBl3q7CYEe78U5sP7Qw7P+4CQCFUXyNfElQFEwiSUqQaKEP04yxiMM 4C3/Igj6ri0nkZ4iiGE88MUHhFZ6iQR0/TpqwPru99qIO2f2xPd5/CqUvLT0qMI8lhGZKwePgyyC DJTkO7fcx1BILtmB5GJ0qAg7v9PCcbL4YjIYH8YqvOhVf4pX/zsmpWpVXuGfFLDFYeItgMewb9ru 8BB+ZYwwAAAAAAAA --=-GE4xm4ez0QJ1TjpnNAT4-- From nobody Fri Apr 24 16:39: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 4286E1A8A67 for ; Fri, 24 Apr 2015 16:39:18 -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 b0JUzK1p1uWA for ; Fri, 24 Apr 2015 16:39:16 -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 C0D211A8A9A for ; Fri, 24 Apr 2015 16:39:15 -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 56FCA5FB41; Fri, 24 Apr 2015 23:39:14 +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 rJZBv9Pd1ORx; Fri, 24 Apr 2015 23:39:12 +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 mailgw02.dd24.net (Postfix) with ESMTPSA; Fri, 24 Apr 2015 23:39:12 +0000 (UTC) Message-ID: <1429918751.4659.22.camel@scientia.net> From: Christoph Anton Mitterer To: Derek Atkins Date: Sat, 25 Apr 2015 01:39:11 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <1429805507.27711.15.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-6ORhv7aVcenoOykPRoDS" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 24 Apr 2015 23:39:18 -0000 --=-6ORhv7aVcenoOykPRoDS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-04-24 at 13:11 -0400, Derek Atkins wrote:=20 > >> I.e., IMNSHO I feel you should expire your key by expiring your > >> self-signature on the key. If you want to extend your key then you > >> re-sign it with a new self-signature. > > Well but than it's useless to make the key as a whole expirable. > No, it's not useless. If the expiration time is *not* hard-coded into the FP and other signatures... what does it give you that can't be done with revocation signatures? > If you know that when you generate the key you > absolutely never want it to be usable past a certain date, then you put > the expiry into the Public Key packet. Once that date passes, the key > has expired. The date should be immutable. Maybe I'm wrong, but I don't think there is a field for that. Section 5.5.2 lists only the creation time as part of the public key packet for v4 keys. So to my understanding, with v4 keys (and IIRC v3 is deprecated?) any expiration times are always stored in the signature subpackets. But since these are not part over which the FP or other user's sigs are calculated, they forgeries I've mentioned earlier are possible. > However if you're not sure As I've mentioned before, I don't think we should made an expiration time mandatory - it should be hardcoded, but users should still be able to set it to infinity or 1000 years if they want. > , or you want to prove user liveness on the > key Proving "user liveness" is a) anyway questionable (if the user is dead, who guarantees that noone else has his private key?) and b) much better done by simply resigning the key+UID with a selfsig - but that doesn't mean one cannot hardcode the expiration time. > It doesn't destroy the use case; you can still use the Key Expiry. It's > just an IMMUTABLE setting. Well than please explain this more detailed. AFAIU, when you now change the expiration time on a v4 key+UID, it neither invalidates 3rd user sigs, nor it changes the FP. Have a look at 5.2.4, where it's described how cert sigs are made and AFAIU, these are only done over the UID+key, but not the selfsigs and thus not the key expiration times. > > If that's only in the selfsig *without* invalidating the other > > signatures, then an attacker could try a downgrade attack and e.g. forg= e > > the selfsig with weaker algos... or more likely... simply create a new > > selfsig when the key was compromised. >=20 > Yes, this is a risk of not using the expiry field in the key packet. I guess you mixed up v3 with v4 keys, the former were still secure with respect to meta attacks on the expiration time. > > If the fingerprint and other users' signatures wouldn't invalidate them= , > > all the attacker needs to do is block the revocation (if any). >=20 > I'm not sure I understand this statement. Well I referred to the basic attack vector in this scenario: - If I could create a key/UID with immutable expiration times, then I could e.g. say, all my high security keys are only valid for one year. If the key is compromised after that time, then an attacker could no longer "re-sign" they key with a new expiration time (thereby tricking my peers into trusting it), because it would change the FP and invalidate their sigs. - Right now (with v4 keys) they expiration is to my understanding only set in the self-sigs and changing it doesn't invalidate other user's signatures nor result in another FP. So if my key is compromised now, than even if I set the expiration to one month, the attacker could simply make another selfsig. Further, he could probably block any revocation signatures from the keyservers... and even any "older" self-sigs that contain the expiration (which may otherwise look suspicious to the careful lookin user) > Yes, that's why the key expiry should be immutable. Changing it would > invalidate all signatures on the key, as well as changing the key > fingerprint. I.e., it's a "different key". Well that's what I always say, isn't it? It's just not doable with current key versions. > However the key expiry should not be mandatory (i.e. it can be 0, > meaning "never expired"). Sure, but I never said that we should force the user to actually set a time. Cheers, Chris. --=-6ORhv7aVcenoOykPRoDS 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNDIzMzkx MVowTwYJKoZIhvcNAQkEMUIEQDm750+h5tLFidVujHlSLGxbr4DeCK/3ulLWogenURUiQQ/+t0oy AWj41VPH2N9J/qYMXsJu15bKQ2LDzHZD0kUwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAUVKVv5IoEkmm0NucKWj9z+r3DZPDh MezXgchMw8JVojOsKZJvvFISLG6S6TzE8AAHhX/PRMatdSeOCXdk4+yiRTZlo0IGwWH8i4foJg/L NH35aeH0Hp+3Y1L6JEDgdZUtdm5SFmIkRzf0xvSsWtrIujhLjqPz8fgxtyQ5DI8tA8LQS0ASPOCK bEwfBaQVeLbBn41asGSFn3jUYuX9qY9fTC2du2BHc6toxWBcdXOmbKhMq2yey1lELx72lB6r71ef Ha0AZZ5zIRkGwy+ZjGOrWRXDcyQuQ1XPzg++isIx+c5zVrasY2t85wigxQmYC3sZ2Fe/gCLmBg4u tUgFWh0BAAAAAAAA --=-6ORhv7aVcenoOykPRoDS-- From nobody Fri Apr 24 16:43:18 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 8EAC91ACDD5 for ; Fri, 24 Apr 2015 16:43:16 -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 Sf3Z2QdR-3no for ; Fri, 24 Apr 2015 16:43:15 -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 DC57D1ACD14 for ; Fri, 24 Apr 2015 16:43:14 -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 BBE765FAD3 for ; Fri, 24 Apr 2015 23:43:13 +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 LPlhzNvccsIA for ; Fri, 24 Apr 2015 23:43:12 +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 mailgw02.dd24.net (Postfix) with ESMTPSA for ; Fri, 24 Apr 2015 23:43:11 +0000 (UTC) Message-ID: <1429918991.4659.25.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Sat, 25 Apr 2015 01:43:11 +0200 In-Reply-To: <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-QhkW9dfntDufbniFw47E" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 24 Apr 2015 23:43:16 -0000 --=-QhkW9dfntDufbniFw47E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Perhaps a side note on the key derivation function discussion: I think it would be beneficial, the algorithm for that would be variable (i.e. having an algorithm field like the other alogs). Secret keys typically don't move so much, so this is really a place where distros/implementations may to choose what they prefer. And as usual, it would also allow us to move on much easier, when new/"better" functions hit the market. Cheers, Chris. --=-QhkW9dfntDufbniFw47E 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNDIzNDMx MVowTwYJKoZIhvcNAQkEMUIEQNuXXTx824tbKgfYGc0LMj99FkBSMsI7zZ8r7QQsT4AyuslXTIDv 4IVP9CHRpfANqrgUjoxMmpGU6GmitOYxMmMwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBmm1skhHnZcNzlX+kIe+XY2oy1iBDR l0HmdG5mRQCovSlF+GWR0kn3lDHahciFOVr0jhjnPWZyn7CF39z0fLMon8PjRMQ7Yl2GvWaUpfdq W4w+bUuW0GsIOKaslMAPn/G+8lztr54ub4Bd8P5FOftlb5IcGvXRxcI5+Fi0gxNP1GlAG2XgIe6g tnudWHhxlVnaXA5EJscILTaFrKK3NFe/8MJkpWDlp1qChfIlHxGcnX1xjCg/XNNsLCUTZseW1RKN ubFdIqNvqO1r2w456oPlI2vR0gRQGyaJY357BKTts6elRvhJgKjMhbACimhH0MyogAvHLVQmIeI5 ZVOMtm7eAAAAAAAA --=-QhkW9dfntDufbniFw47E-- From nobody Fri Apr 24 16:55: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 14D1D1ACEFF for ; Fri, 24 Apr 2015 16:55:42 -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 m2Dm9t6B9005 for ; Fri, 24 Apr 2015 16:55:40 -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 442681ACEFD for ; Fri, 24 Apr 2015 16:55:40 -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 D79455FB7A; Fri, 24 Apr 2015 23:55:38 +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 CgqPc7_kBS68; Fri, 24 Apr 2015 23:55:36 +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; Fri, 24 Apr 2015 23:55:36 +0000 (UTC) Message-ID: <1429919736.4659.37.camel@scientia.net> From: Christoph Anton Mitterer To: Jon Callas Date: Sat, 25 Apr 2015 01:55:36 +0200 In-Reply-To: <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-B/3qfIZOMXRagbfQf2f6" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: Werner Koch , openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time (was: details of 4880bis work) 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, 24 Apr 2015 23:55:42 -0000 --=-B/3qfIZOMXRagbfQf2f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-04-24 at 13:02 -0700, Jon Callas wrote:=20 > I read your explanation. I understand it. I just disagree. > I think that hard-expiration is not only a bad idea, but unenforceable. Then please elaborate why, cause I gave some clear usage scenarios where hard expiration times would be beneficial, and your points below don't really seem to be good against. > It's a *good* thing for Alice to be able to update the expiration time > on her key. It encourages putting a limit on (as opposed to no limit) > if it can be changed later. It also allows advanced systems to be able > to do some really cool things with short lived keys. But for all that I don't think we'd need to have a mutable expiration time. Just make they non-expiring at first, and release a revocation certificate once the point has been reached, when it should really be stopped from using. Theoretically one could even make the revocation signatures themselves expiring again, so that the revocation would only last for so and so long (which is however really just hypothetically, and nothing that should ever be done ;) ). Further, my proposal of allowing for an immutable expiration time doesn't mean that we have to drop the mutable on. Just define it like this: - if the expiration time in the key block itself is set to non-zero, than this time is the expiation time and any other key expirations on self signature MUST be ignored - if the expiration time in the key block itself is set to zero, then the key doesn't expire, but selfsigs may. So you still could revoke single selfsigs and you could also resign your key with new selfsigs, thereby getting the same behaviour as of now - a mutable "key expiration time". But the key expiration time signature subpacket should really go away, it doesn't do what it's name promises, and it's effect could/should rather be done with the expiration time of the selfsigs. > And you probably can't prevent it anyway. X.509 syntax people have > kittens if you reuse a key in certs. And yet a major feature of many > PKI systems is to "reissue" a cert with a new expiration time, because > it makes operations much easier for everyone. I don't see why it shouldn't be possible. Just put it back into the key block, then the FP will include it and the cert sigs from other users as well. Of course you can still use the raw key material and create a new key with another expiration time and the same UIDs of it,... but that will be a new and totally different key. Cheers, Chris. --=-B/3qfIZOMXRagbfQf2f6 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNDIzNTUz NlowTwYJKoZIhvcNAQkEMUIEQMG9i4dUoLcGI17vgSyq0fQoV8Zz43y8SFjpoF9k3FUbXc5Zm6mJ 6ds840Lr7lisr5fuRcwcdU6vKOxJpMjQzMYwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQC8s1mNN3T+hgtRtFE7C3CpMUS0yB2/ oMkYFYwGToQew/rIjMHJk0P7blvNYTzgcdVyOUhndTaFzrckRalBRlLJnat3QT+fvd/INv4AF9Yd 7e90SnzbbS9NN9gagd0oF4r8qffgCNwCNqQ9u3qwpZiNR0Pe0+7U2blW0pP9YRpj6rWVjaKHbQ+i WMWVU1txMOGVwWz4K/zuWdifvQDHaSN82pYvyo2vPvLOohWUz2bVs0UvPiEv7b5ygyBdrH8T8pWY w6VBKl2m5jPJcR11HJu3gEovkVvK4WRuPJnYu51bNBrIjSrQmfNuLN+UdZFR0stzAk7P/x2JuU4m NB28Alx7AAAAAAAA --=-B/3qfIZOMXRagbfQf2f6-- From nobody Fri Apr 24 16:58: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 543721B30F7 for ; Fri, 24 Apr 2015 16:58:35 -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 kaX9Zz3JslRF for ; Fri, 24 Apr 2015 16:58:34 -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 CC5B91B30FE for ; Fri, 24 Apr 2015 16:58:33 -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 A8EFA5FAF5; Fri, 24 Apr 2015 23:58:32 +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 LBj57X9jOe9t; Fri, 24 Apr 2015 23:58:30 +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 mailgw02.dd24.net (Postfix) with ESMTPSA; Fri, 24 Apr 2015 23:58:30 +0000 (UTC) Message-ID: <1429919909.4659.39.camel@scientia.net> From: Christoph Anton Mitterer To: Phillip Hallam-Baker Date: Sat, 25 Apr 2015 01:58:29 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-p6G8MG3KtFfIdGebX/5E" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: IETF OpenPGP , Jon Callas Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 24 Apr 2015 23:58:35 -0000 --=-p6G8MG3KtFfIdGebX/5E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-04-24 at 15:51 -0400, Phillip Hallam-Baker wrote:=20 > Neither PKIX nor OpenPGP really provide the end user with the full set > of tools needed to do comprehensive key management. The PKIX model is > that the user does not have a persistent key history at all, the CA is > the only party managing this. OpenPGP takes the UNIX/C attitude of > give the users a sharp knife and blame them when they cut themselves. You can have a CA model in OpenPGP as well, actually it's very simple by using trust signatures. Just found some "CA keys", sign them with an unlimited trust-sig, any you'll believe whatever they sell you. Cheers, Chris. --=-p6G8MG3KtFfIdGebX/5E 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNDIzNTgy OVowTwYJKoZIhvcNAQkEMUIEQEgGgEHSjLXyUwkUOs/EVl++ua0Yg8qOtJ6+DxVBWaovDU7V+awy IOwJYGHrCZ//572DWSHC14B3W10MNRjgegUwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDb7/4IW39J5J0s2DYWwbgCRydIKgY5 ns11gDaVcP9Doxh3CYxocT/oJTK+zOcqZIxfLI/FmZV27XH16z9E+o8i1vsurpfDBT779cKi92v0 N59FUJt9qXAhh36vLVKMwPO1WUCmaTvjbYko6ce0/2dIpxZkSM0TWI0WosGtHQnE1udY0j5s90UZ 1arYIfdGAoq2D5Vf5tNZc3PclbiE+bElpk1vlRSCBRdfZYaoic2CA4acB3fCEjd3PxMJOJaf4nVG QIb+aadsrIXH8bOANzxMuc0m+sVepL2KGt/c7Y3COD2E48fV5p2ltGmA3tX/lD+dErgvs1iyJyNe cGwtEcmBAAAAAAAA --=-p6G8MG3KtFfIdGebX/5E-- From nobody Fri Apr 24 17:36: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 85E8D1B31D2 for ; Fri, 24 Apr 2015 17:36:03 -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 x6ERqCdD0JCh for ; Fri, 24 Apr 2015 17:36: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 09E951AD08F for ; Fri, 24 Apr 2015 17:36:02 -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 AFE205FAE6; Sat, 25 Apr 2015 00:36:00 +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 kqXahigEUjdh; Sat, 25 Apr 2015 00:35:58 +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 mailgw02.dd24.net (Postfix) with ESMTPSA; Sat, 25 Apr 2015 00:35:58 +0000 (UTC) Message-ID: <1429922158.4659.43.camel@scientia.net> From: Christoph Anton Mitterer To: Jon Callas Date: Sat, 25 Apr 2015 02:35:58 +0200 In-Reply-To: <2142458E-1636-4E3B-8CCE-36078AFC02C9@callas.org> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <1429543533.24823.73.camel@scientia.net> <2142458E-1636-4E3B-8CCE-36078AFC02C9@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-KyREjQIHwLZZFRIjppsW" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints 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, 25 Apr 2015 00:36:03 -0000 --=-KyREjQIHwLZZFRIjppsW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-04-24 at 12:11 -0700, Jon Callas wrote:=20 > > And specifying a expiration time (even if it's 0) should be mandatory. > That's there now. Again, I don't see where this would be specified, except for the deprecated v3 keys. It's not part of the v4 keys, and I can't recall a section which makes the key exp sig subpacket mandatory. Anyway, the idea for making it mandatory has less to do with the immutable vs. mutable question... it's rather based on the idea that we should IMHO try to strengthen and clarify the whole message format. E.g. I think we should convert the critical-bit to be a non-critical bit. e.g. everything is considered critical unless explicitly specified not to be. Cheers, Chris. --=-KyREjQIHwLZZFRIjppsW 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNTAwMzU1 OFowTwYJKoZIhvcNAQkEMUIEQI/QUmfzEmlzHLVpZ432hGaFdK1luBKA+ltIRHwXwQQCX8RWmyZl QQj6f8EwDhB9DSZ6Xj6PRXyzwu6IKGFnD1UwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB6yD+du5GcF5lIh4y9cpGtK6MoaRXy tRHk5dvbNXkGNv12nEuH96mbbvyqwrz7XaBrvRKsGkBcKUKn/NHSJ5aA6do/Am1kZXjt5wyZ2Uue +V4SPUbgH70JhMjto0UZ9r8TkI1bu+1tuB9a00G23IKpnLu1taKRkMvB8iVVZ2yEy/QGdpLlQipd dHAkvkCNKh+6p+aqDQ4WL1GiFlDFT0ydQd3DuHfLDhb152f49vpSDX00ZvtmaxnAmbgNdGk12GfI dgRJ7HbQkEFyyrYcR/u+LBv3iZO6ojLcB4U6rbOprNVGR3UW5I6MLG+DjyeD8+zNR79r22FbJ4SD /owdTgUhAAAAAAAA --=-KyREjQIHwLZZFRIjppsW-- From nobody Fri Apr 24 17:43: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 505E81B31F8 for ; Fri, 24 Apr 2015 17:43:03 -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 sJHbYtYQXRP1 for ; Fri, 24 Apr 2015 17:43: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 C006D1B31F6 for ; Fri, 24 Apr 2015 17:43:01 -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 9F2DB5FAE6 for ; Sat, 25 Apr 2015 00:43:00 +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 UB5Tdoa-ua7B for ; Sat, 25 Apr 2015 00:42:58 +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 mailgw02.dd24.net (Postfix) with ESMTPSA for ; Sat, 25 Apr 2015 00:42:58 +0000 (UTC) Message-ID: <1429922578.4659.49.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Sat, 25 Apr 2015 02:42:58 +0200 In-Reply-To: <87618qzlw0.fsf@vigenere.g10code.de> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <87618qzlw0.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-C4LTAMbQ8ps9DFMkuqiI" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 25 Apr 2015 00:43:03 -0000 --=-C4LTAMbQ8ps9DFMkuqiI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-20 at 20:37 +0200, Werner Koch wrote:=20 > For a long time I pondered with the idea to suggest base32 In principle I'd agree, especially as it nicely solves that 0 vs. O issue. > meanwhile I think that hex digits are easier to read and spell over > noisy channels. Hmm,... well I have no strong opinion,... but I think with e.g. the ICAO alphabet it should work fairly well - I mean this was made more or less for exactly that purpose. > 08-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcde= f0 > would fit into one line and is still not too hard to read. And what if we'd already move to a 512 bit hash? E.g. SHA3-512. Also consider that people often write this to business cards and that like, were space is more limited than on a computer system's line (e.g. the 80 chars of traditional terminal). Cheers, Chris. --=-C4LTAMbQ8ps9DFMkuqiI 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNTAwNDI1 OFowTwYJKoZIhvcNAQkEMUIEQPhxUkrYnSkyvocigZfhnIVrv7rga7PrgxsAdZNXs8Ilp/trQSgI JZA9TICQcTTicYcYwURI1/34tB5B0E13qIgwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCi3ye74Ng5YrUaJKcV2PIQgjM47TWc MkAAnou49+QjODVyn4YavnHDJI9IzCr9hgkbHwLblQ3ZHzRKARNcI3sW5qz3uf3+WuVQQwkNSQhH QrK47iulq4e68p6Auts+22U/tZI7GPBNydO3txU5lyZZhXSAV77lB32G9jY5teaYXfsIiJ4QZ1j4 V6Gdywi5lJenJBOdzwBDZvwYtDn5N68coXfeLmIPaQXUq2OV2PQJWKBgaoYBo/+VE0WZHCJHaXKK PjWJBYAeIbhsE6dh7XATJDqCVl9Pby4ofqeQrzsW0RVxfSCXLiESQSbGMZgV44GcjJyRGiAJJx1n kjE9daUBAAAAAAAA --=-C4LTAMbQ8ps9DFMkuqiI-- From nobody Fri Apr 24 17:57: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 7B0EA1B321B for ; Fri, 24 Apr 2015 17:57:03 -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 P5OWG36aP4ox for ; Fri, 24 Apr 2015 17:57:02 -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 B7A641B3218 for ; Fri, 24 Apr 2015 17:57:01 -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 979385FAD2 for ; Sat, 25 Apr 2015 00:57:00 +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 wj7KT1iW9s8V for ; Sat, 25 Apr 2015 00:56:58 +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 ; Sat, 25 Apr 2015 00:56:58 +0000 (UTC) Message-ID: <1429923418.4659.58.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Sat, 25 Apr 2015 02:56:58 +0200 In-Reply-To: <87h9saepjh.fsf@littlepip.fritz.box> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <1429543533.24823.73.camel@scientia.net> <87h9saepjh.fsf@littlepip.fritz.box> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-XLmX+jKEdB+o5/6Mq7Y4" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 25 Apr 2015 00:57:03 -0000 --=-XLmX+jKEdB+o5/6Mq7Y4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-20 at 18:18 +0200, Vincent Breitmoser wrote:=20 > Definitely in favor of including key usage flags. I can't think of a > reason these should ever be mutable over the lifetime of a key, at least > in the incarnation of the key material identified by one fingerprint. >=20 > > Or actually, we should perhaps make primary keys to be generally > > certifying-only keys. >=20 > Not sure about that, primary keys with more than C capability can have > legitimate use cases. But that in case makes a valid use case where one wants to change the the usage flag. E.g. consider you have a private key where you want to add/remove enc or signing flags. IMHO, having subkeys is extremely cheap, probably even for very lowcost embedded systems (don't even the OpenPGP cards support multiple keys these days). So there should be no reason where you every really need to change the usage of an existing primary/sub key,... just create a new one (which is probably even more secure). It may be even possible to let the keyservers benefit from this: Conceptually the keyservers should never remove primary keys (and their direct signature) for security reasons (this would mean one would also loose revocations, etc.) For historical reasons, I'd also say, they should never remove signing subkeys (because another user may need it 20 years later to verify a signature). But in principle there's no strong reason to keep the enc keys after these have been revoked or expired (of course the revocation and the subkey binding sigs must be kept). Cheers, Chris. --=-XLmX+jKEdB+o5/6Mq7Y4 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNTAwNTY1 OFowTwYJKoZIhvcNAQkEMUIEQDFzmzuEZc6vz58IP3WBLDyDlXlJZsYa8d/Gvy9rUkS8OYuz9tg8 skc+57s/e+o51ktO33ASBBlBiWgNtA1anOYwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDB98qIpEm8Eb5fASYqjxZDJlL5GfMi +Ggs2Oy0U9hJEAPRuJJrMK4fdSDD4UL3p/bt4ETCftK29toZXknWB4X4YVQ7vTyssTgKT0fOPJS1 t1Pk1E1nVfG3eAu8nqOas3UgzX13C09U2C3RYy5FWenwu2UsTBs0lAyJ63tACsgENukMTRCTPwJZ VQnYktVbo8W72h4EIosaDJx49XK/fab/HI8NbEt7Ug5ywdHNYd07MAYbIPpETdBTD+zR+y82joGz /1SCcBsr2lUtU/cKjYIXcRvdfEbEJt657xuBEjXQi21gWV24jm6JJaHOcbN4uMbOxY1yuP/VfV3A UXQcPZ7vAAAAAAAA --=-XLmX+jKEdB+o5/6Mq7Y4-- From nobody Fri Apr 24 23: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 3A2FE1B2A13 for ; Fri, 24 Apr 2015 23:06:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 5VVjHih0Y3_U for ; Fri, 24 Apr 2015 23:06:21 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892B21B2A19 for ; Fri, 24 Apr 2015 23:06:19 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-12v.sys.comcast.net with comcast id L66G1q0055BUCh40166Kuc; Sat, 25 Apr 2015 06:06:19 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-16v.sys.comcast.net with comcast id L66J1q0094uhcbK0166JdJ; Sat, 25 Apr 2015 06:06:19 +0000 Message-ID: <553B2EDA.4030909@brainhub.org> Date: Fri, 24 Apr 2015 23:06:18 -0700 From: Andrey Jivsov 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: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <5539EE66.2060002@brainhub.org> <87iocloilk.fsf@vigenere.g10code.de> In-Reply-To: <87iocloilk.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429941979; bh=eQl0XWLjOAGbuXLEQgawvKUogFeK+nmZFN+SNBg3Nwo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FU8GkJIc6TcJgpEpp7Id7+V/NV+JIjbQ3ohEY88sjCQvPK9wpUKOf7K80d47dpzGh erqyVU5DGJB3yq3izXGfyO5bAHfued09as3gYdhpomkJHSSWWd+/N4YwYuMnWz/gVM PAqKc3JgOT02br3fkmLrDkEL/QLXK8ms0i0pIfvhzUKwYBWnMwgGqVJ5XJI0qSDOhJ TFa6tJoG5NfRpH9Thm3sdTXHy787zFYkBaCwCN7zfaHHJZN1iLvECnZMmBaj7jpkbN 8Xcl17pLezakE4yvEwLOM8MzLpywKQ8Syvpf0vrxohb+7XnAYCj9m35elQ+LWmAyCE u5x3V4cB5jGRg== Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 25 Apr 2015 06:06:23 -0000 On 04/24/2015 04:45 AM, Werner Koch wrote: > On Fri, 24 Apr 2015 09:19, openpgp@brainhub.org said: > >> 2. The Iterated S2K is essentially a >> >> M = M1 || M2 || M2 || M2 || ... || M2, where M1 includes the salt. >> S2K = Hash( M ) > Actually M2 also includes the salt: > > | Then the salt, followed by the passphrase data, is repeatedly hashed > | until the number of octets specified by the octet count has been > | hashed. [...] > > > I stand corrected. My argument holds with even greater simplifications with the following adjustment: M = M1 || M1 || M1 || M1 || ... || M1, where M1 includes the salt. S2K = Hash( M ) If we use the Hash() which is insecure in this setting, we should expect troubles in other application of this hash function: e.g. in digital signatures or MAC. From nobody Sat Apr 25 01:36: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 7A6031ACD96 for ; Sat, 25 Apr 2015 01:36:44 -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 p0tgbaZpu5L9 for ; Sat, 25 Apr 2015 01:36:42 -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 683CF1ACD61 for ; Sat, 25 Apr 2015 01:36:42 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YlvZo-0004B7-RJ for ; Sat, 25 Apr 2015 10:36:40 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YlvUW-0001dq-Ah; Sat, 25 Apr 2015 10:31:12 +0200 From: Werner Koch To: Christoph Anton Mitterer References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <1429918991.4659.25.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 Mail-Followup-To: Christoph Anton Mitterer , openpgp@ietf.org Date: Sat, 25 Apr 2015 10:31:11 +0200 In-Reply-To: <1429918991.4659.25.camel@scientia.net> (Christoph Anton Mitterer's message of "Sat, 25 Apr 2015 01:43:11 +0200") Message-ID: <871tj8obhs.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] 4880bis: Update S2K 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, 25 Apr 2015 08:36:44 -0000 On Sat, 25 Apr 2015 01:43, calestyo@scientia.net said: > I think it would be beneficial, the algorithm for that would be variable > (i.e. having an algorithm field like the other alogs). | 3.7.1. String-to-Key (S2K) Specifier Types | | [...] | 3 Iterated and Salted S2K | 100 to 110 Private/Experimental S2K Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat Apr 25 10:11: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 750701B2D3D for ; Sat, 25 Apr 2015 10:11:06 -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 1IE6CKseCZBD for ; Sat, 25 Apr 2015 10:11:04 -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 5B7B11B2D3A for ; Sat, 25 Apr 2015 10:11: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 0D1275FA80; Sat, 25 Apr 2015 17:10: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 QzetiZsO92Gl; Sat, 25 Apr 2015 17:10:57 +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 mailgw02.dd24.net (Postfix) with ESMTPSA; Sat, 25 Apr 2015 17:10:56 +0000 (UTC) Message-ID: <1429981856.4659.60.camel@scientia.net> From: Christoph Anton Mitterer To: Werner Koch Date: Sat, 25 Apr 2015 19:10:56 +0200 In-Reply-To: <871tj8obhs.fsf@vigenere.g10code.de> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <1429918991.4659.25.camel@scientia.net> <871tj8obhs.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-gK9z2ZPm08sLVXMRwxUl" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] 4880bis: Update S2K 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, 25 Apr 2015 17:11:06 -0000 --=-gK9z2ZPm08sLVXMRwxUl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2015-04-25 at 10:31 +0200, Werner Koch wrote:=20 > > I think it would be beneficial, the algorithm for that would be variabl= e > > (i.e. having an algorithm field like the other alogs). >=20 > | 3.7.1. String-to-Key (S2K) Specifier Types > | =20 > | [...] > | 3 Iterated and Salted S2K > | 100 to 110 Private/Experimental S2K Ah... sorry for the noise then :-) It's already some time ago that I was more closely familiar with the RFC and apparently I have forgotten some things O:-) --=-gK9z2ZPm08sLVXMRwxUl 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNTE3MTA1 NlowTwYJKoZIhvcNAQkEMUIEQP+//chIJHTKzM7JGEDjb3GacOm1T17nS7LPvAtZ+ZH1xj9DL4j4 0YXMCnNGcfPlSYNyfS7cN8Z+te5/ZsBOkf8wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQA9dvHmekxrE5YSUemnAc/qhAr6vHKK MllJ3pvMLZicxxnGf8DktFDm5UOGlSI4jzk2Icj1VPjpsy0H0Wn3MBk1BP0FawdLrLUSpJlsgSwH z4KFX57FrFwLKORBFoXJCrL14pqHg2LJcxAnuTHjqWM9BvSXvSDBMlIZkiEfuZ/hJCF+/0H5LwEv ewW8B2OSgnOiSWOmB+MFvZejwO0fX9vcr+FMZqrkaZQxX2nU0ADFa0MWLfuv2PSGKUMp7XDZXXjc zc/MTtUQpq+CBtH5sawygetH/+PF+rztQV+SxYCjB2IJLzMlSqRB14OiUwhsNtztV0iqjGwi9Mwj eqdI4NP+AAAAAAAA --=-gK9z2ZPm08sLVXMRwxUl-- From nobody Sat Apr 25 10: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 737A51B2E4E for ; Sat, 25 Apr 2015 10:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xrYEqhm5Dy1w for ; Sat, 25 Apr 2015 10:58: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 1E5251B2E4F for ; Sat, 25 Apr 2015 10:58: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=1429984693; x=1461520693; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TDarKAtwQoKKlOUIbAFTBv9yP4aW4L7YNVbCPNAI4Q8=; b=jCIpaRKYJMRiX9HBk8qaDp3pSONderzdOIoVQDZqOxHbJhU7WMUXIpMz HnRCut6ArA/I7hxjVo9BrCm0TjjvIWFedR6Rz6ijBRbmrQr1MRl0hexaK 8GtD4l8rsbJEHuddTc2M27I72thZA/76cdEoXBqNWZqQFjTtqvWY4Qy60 s=; X-IronPort-AV: E=Sophos;i="5.11,647,1422874800"; d="scan'208";a="321429995" 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; 26 Apr 2015 05:57:58 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sun, 26 Apr 2015 05:57:57 +1200 From: Peter Gutmann To: Alessandro Barenghi , "openpgp@ietf.org" Thread-Topic: [openpgp] 4880bis: Update S2K Thread-Index: AQHQfV7oztRkyamS1UKaDwa88nuOop1aMDbX//9B34CAABxtgIAAELEAgABwBQCAABD1gIAACUEAgAAMGwCAA9I4Wg== Date: Sat, 25 Apr 2015 17:57:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB0075AA@uxcn10-tdc05.UoA.auckland.ac.nz> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <5538CB82.7000102@polimi.it> <553937B3.20702@polimi.it> , <5539499E.4010305@polimi.it> In-Reply-To: <5539499E.4010305@polimi.it> 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] 4880bis: Update S2K 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, 25 Apr 2015 17:58:15 -0000 Alessandro Barenghi writes:=0A= >On 04/23/2015 06:52 PM, Earle Lowe wrote:=0A= >> The OpenPGP work factor is a count of bytes to hash. =0A= >Ok, now I got the point, thanks :)=0A= =0A= That's always been a major pain with PGP's PRF, for every other PRF in=0A= existence you're given an iteration count and just iterate the PRF that man= y=0A= times. For PGP you're given a value encoded as some bizarro fixed-point=0A= format crammed into a byte value (saving *three whole bytes* per message),= =0A= which you then have to reverse-engineer into an iteration count, which is w= hat=0A= the PRF actually works with (complicated by the fact that the byte count an= d=0A= hash sizes typically don't match, so you end up having to special-case=0A= handling around the leftover bytes at the end of the hashing process).=0A= =0A= For the next PRF, I would hope that the iteration count is just a straight= =0A= int32 telling you how many times to cycle the PRF.=0A= =0A= Peter.=0A= From nobody Sat Apr 25 11:08:18 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 CEA9D1B2E78 for ; Sat, 25 Apr 2015 11:08:16 -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 OKd1odmPhA02 for ; Sat, 25 Apr 2015 11:08:15 -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 97CFF1B2E79 for ; Sat, 25 Apr 2015 11:08:14 -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=1429985295; x=1461521295; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r/hgcZNeRQodooN6lPtkG043neLnXC6UM4aBEQrCcXs=; b=rENPshQiPRfY9x+CS3C38n1yAM38NZJpPTUzLT2MvZ9aNp9hgO/pTexr UyXeP2oQSeINHXa7J+FXTFFAtS07hFU+9f/SxPyv02f3EZuYrRnZ2HtGn JdcHqEOZHKzL7SGNAfHrdVpU3INw/6eTy6n6v7ccXc1WtoPuR6521zhj2 0=; X-IronPort-AV: E=Sophos;i="5.11,647,1422874800"; d="scan'208";a="321430043" 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; 26 Apr 2015 06:07:52 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Sun, 26 Apr 2015 06:07:51 +1200 From: Peter Gutmann To: Jon Callas , Nils Durner Thread-Topic: [openpgp] 4880bis: Update S2K Thread-Index: AQHQfV7oztRkyamS1UKaDwa88nuOop1aMDbX//9B34CAABxtgIAAAJGAgAJB5wCAAjlhug== Date: Sat, 25 Apr 2015 18:07:51 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> , <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> In-Reply-To: <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> 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: Cc: "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" Subject: Re: [openpgp] 4880bis: Update S2K 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, 25 Apr 2015 18:08:17 -0000 Jon Callas writes:=0A= =0A= >I would love to see PBKDF2 in there on the list of things acceptable.=0A= =0A= Don't go for PBKDF2, wait for the PHC to conclude (which it will have by th= e=0A= time any new PGP RFC is ready) and use that. The product of the PHC will b= e=0A= pretty much the best that we can design at the current time, and I say that= =0A= not as propaganda from someone involved in it (although please note the=0A= potential conflict of interest there) but because the designers who have=0A= submitted entries have looked at everything else that's been done and impro= ved=0A= on it, which includes cross-pollinating ideas from other submissions into= =0A= their own. The result is going to be a really, really good password-=0A= processing function that's about the best that we can currently design in= =0A= terms of working over a wide range of environments while resisting speciali= sed=0A= attacks using GPUs and ASICs. So all that a future PGP RFC needs to do is= =0A= leave a hole to slot in the PHC winner.=0A= =0A= Peter.=0A= From nobody Sat Apr 25 14:02: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 A6FCA1A1BA3 for ; Sat, 25 Apr 2015 14:02:58 -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 QOXA8mp_9TQC for ; Sat, 25 Apr 2015 14:02:57 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 00A911A0231 for ; Sat, 25 Apr 2015 14:02:57 -0700 (PDT) Received: by widdi4 with SMTP id di4so53162001wid.0 for ; Sat, 25 Apr 2015 14:02:55 -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=IQ29IU64stPdMzsAzMf96rDmQCm1b/n5eBR+w/IOAUU=; b=Nf1p1AOQZlL8Jy+dqHihqqpT72e8VxCk0HpLM2THaqPhWeqRZVuqUGSbP3kDkqiikZ jr0hrG1l490Z2gI4OKoFmmxhw1dlodRaRzx55H0OOt34oB2/VNqKYU3m1Temirankyre H35NiuYbzsmcgdSVwRg0jO4hjnSi4SrDHpLvsmwV402kAgHXhHJ1Ku1OzIxUf3dQ5edQ bDpJsHL7F0BS1ZoZ9WidoxJhhqAKFoPexCjOjKqrUvhjYKc53FBErpbk+zlbOS7RBvXw ovI4qHx5FN5W7KTjdZO2UmDP9wSJ+edYmoCx4M7onzKg/6OgcvkXNtK748wY/Lrjs2vF 7Xjw== MIME-Version: 1.0 X-Received: by 10.194.61.82 with SMTP id n18mr8519410wjr.35.1429995775757; Sat, 25 Apr 2015 14:02:55 -0700 (PDT) Received: by 10.194.162.35 with HTTP; Sat, 25 Apr 2015 14:02:55 -0700 (PDT) In-Reply-To: <87a8y2znee.fsf_-_@vigenere.g10code.de> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> Date: Sat, 25 Apr 2015 22:02:55 +0100 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time (was: details of 4880bis work) 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, 25 Apr 2015 21:02:58 -0000 On Mon, Apr 20, 2015 at 7:04 PM, Werner Koch wrote: > On Thu, 16 Apr 2015 02:39, calestyo@scientia.net said: > >> That's why I think, that creation and expiration times should be >> immutable once the key has been created; at least not without >> invalidating all signatures (i.e. those from other users). > > A hard expiration time vor a v5 key format was proposed by Florian > Weimer many years ago. IIRC, we even had consent that this should be > done by putting it into a v5 key packet. I don't see the benefit of a hard expiration time. More users should be encouraged to use expiration times, because that would help to limit the problem of losing control of keys through forgetting a passphrase (probably the most frequent AQ on the gnupg users list). It seems to me possible that so few do so because they do not realize that expiration times can be changed. Introducing a hard expiration time would introduce complexity because there would then need to be two kinds -- hard and soft. What are the use cases for a hard expiration time? 1. Perhaps an organization wishes to be sure that employee keys are not used beyond a certain date. If so, the answer already exists: refuse to renew certifications of the UIDs on that key and make sure that all certifications have an expiration date. 2. Enforcing key rotation. But if this is important to individual users, the answer is simply: set an expiration time on your key and don't extend it. 3. Preventing an attacker who has gained complete control of a private key, and who can prevent the dissemination of a revocation certificate, from extending the life-time of a key, assuming that that same attacker is not in a position to forge or coerce the creation of a replacement key. Scenario 3 is so niche (in fact, are there *any* documented cases of this?) that I don't see the benefit of adding the complexity necessary to support this. Just my $0.02 From nobody Mon Apr 27 05:08: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 7F4911B30F0 for ; Mon, 27 Apr 2015 05:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 IlJxQSg_7jAX for ; Mon, 27 Apr 2015 05:08:54 -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 65DD81B30EF for ; Mon, 27 Apr 2015 05:08: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 07F7D40080; Mon, 27 Apr 2015 14:08:52 +0200 (CEST) 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 pxydDsj-uRYL; Mon, 27 Apr 2015 14:08:51 +0200 (CEST) Message-ID: <553E26D1.4020304@dominikschuermann.de> Date: Mon, 27 Apr 2015 14:08:49 +0200 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: Nicholas Cole , "openpgp@ietf.org" References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 12:08:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/25/2015 11:02 PM, Nicholas Cole wrote: > I don't see the benefit of a hard expiration time. Full ACK. I also don't see the need for hard expiration times. For me soft expiration is a way that prevents the usage of keys after a certain amount of time, e.g. one year, when the secret key has been accidentally deleted or the passphrase has been forgotten. So - and this is important - these use cases are not really attack scenarios they only provide convenience for key distribution. > > More users should be encouraged to use expiration times, because > that would help to limit the problem of losing control of keys > through forgetting a passphrase (probably the most frequent AQ on > the gnupg users list). It seems to me possible that so few do so > because they do not realize that expiration times can be changed. > > Introducing a hard expiration time would introduce complexity > because there would then need to be two kinds -- hard and soft. > > What are the use cases for a hard expiration time? > > 1. Perhaps an organization wishes to be sure that employee keys > are not used beyond a certain date. If so, the answer already > exists: refuse to renew certifications of the UIDs on that key and > make sure that all certifications have an expiration date. ACK > > 2. Enforcing key rotation. But if this is important to individual > users, the answer is simply: set an expiration time on your key > and don't extend it. ACK > > 3. Preventing an attacker who has gained complete control of a > private key, and who can prevent the dissemination of a revocation > certificate, from extending the life-time of a key, assuming that > that same attacker is not in a position to forge or coerce the > creation of a replacement key. If one consider the average time that a key is still valid (5 years expiration on key generation in Enigmail) so 2,5 years on average valid from the time it got stolen by an attacker, the attacker has enough time to do her "thing", e.g., forge signatures. The scenario that an attacker needs to use the key after 2,5 years is totally unrealistic. Thus, hard exp solves nothing. Regards Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVPibRAAoJEHGMBwEAASKCzIcH/3vZ/YGwSLGQuavi8KT9WwZZ kW9oBp7oZaGhokCh1El/+XJuMxPIbPHy/sLhw75zF417fxh0BqsnEQ6/zdgv0yTO nT7JZ79U9O/pwpqF/e206P0PDg4dLT+Hfr2BIoqbDMXssz2osdigvjnMBeT1lAku QiKSrfj0PWN0+J7Lkst7F5KGHAnDIHMs2gdpTdTr5rAThOuDGummaNRAQr1ezyBS NFBVGSeMMsRJNRHbfiqyfndYmyBzW2babZu/rmw3e6FB1y70vZn6GiDmysXFMLpH 5lXyChP0WBsaTwVncCkCzur6QfI9os09v9jhIClu3Y16vgDWP02RzaKnhmLE4E8= =n38i -----END PGP SIGNATURE----- From nobody Mon Apr 27 07:16: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 2B3341A1A4E for ; Mon, 27 Apr 2015 07:16:05 -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 U7VOoaQXikBd for ; Mon, 27 Apr 2015 07:16:03 -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 9FF451A1A4C for ; Mon, 27 Apr 2015 07:16:02 -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 04AF25FB91 for ; Mon, 27 Apr 2015 14:16:01 +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 EnT3t6FM-HUE for ; Mon, 27 Apr 2015 14:15:59 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 14:15:59 +0000 (UTC) Message-ID: <1430144158.15361.2.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 27 Apr 2015 16:15:58 +0200 In-Reply-To: <553E26D1.4020304@dominikschuermann.de> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-Uw8v70S6XdCWfX3gEIgP" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 14:16:05 -0000 --=-Uw8v70S6XdCWfX3gEIgP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 14:08 +0200, Dominik Schuermann wrote:=20 > Full ACK. I also don't see the need for hard expiration times. I don't quite understand why people lobby against a use case, which wouldn't have an effect on any other use cases if people choose so. It's like "I only use signing - so let's remove any encryption capabilities from OpenPGP" o.O > For me soft expiration is a way that prevents the usage of keys after > a certain amount of time As I've outlaid before, it doesn't really prevent this. Chris. --=-Uw8v70S6XdCWfX3gEIgP 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzE0MTU1 OFowTwYJKoZIhvcNAQkEMUIEQGEEN8OREFK/fEEHIJeFX53037/EgGnFi2Rg5JREjlb97sjsvsQQ 0jnjWjGOHIEdlrjusqCqWVGp1qoXvSdmDXwwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCXR10/zDEMSngeHve0jP7YPieYmgQu rkHDtMdQzmgHS3MpIoMb5T4u0xyDaZi5k2ns2LXA+4e1dDXoUGCmbJY+jxfeAgFTT3i6Co0A19jn 8YsV0mgOlbrgMnocu8GzJhgEvU3q/vVvueTDfuIOtJuk++chVbeyJuLAGRS4+VIufThNqrIKIcCp +eDe+U3WKe+v2nKMirdlbKqHIIzietT/SIAOtPHIPN9OVBbfCr9ir2EmO46tPRj7TMJHTsU55JJp X1faQJmFsXCfPOKVvzQs3MLr5UWKNBStAEZW/jUVe6sLn2ucvzWGdYWF8iCwy/o7A6x3H9h1G59Q MQUe7sa/AAAAAAAA --=-Uw8v70S6XdCWfX3gEIgP-- From nobody Mon Apr 27 07:19: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 8D6E41A1A2F for ; Mon, 27 Apr 2015 07:19:02 -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 GfzGW9Cu5I1u for ; Mon, 27 Apr 2015 07:19:01 -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 633D01A1A4C for ; Mon, 27 Apr 2015 07:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 579C5E2036; Mon, 27 Apr 2015 10:19:00 -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 29713-01; Mon, 27 Apr 2015 10:18:53 -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 A3B5DE2035; Mon, 27 Apr 2015 10:18:53 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3REIqCk023400; Mon, 27 Apr 2015 10:18:52 -0400 From: Derek Atkins To: Jon Callas References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> Date: Mon, 27 Apr 2015 10:18:52 -0400 In-Reply-To: <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> (Jon Callas's message of "Fri, 24 Apr 2015 13:02:28 -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: Werner Koch , Christoph Anton Mitterer , openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 14:19:02 -0000 Jon, Jon Callas writes: >> On Apr 21, 2015, at 4:50 AM, Christoph Anton Mitterer >> wrote: >> >> * PGP - S/MIME Signed: 04/21/2015 at 04:50:25 AM >> >> On Mon, 2015-04-20 at 23:50 -0700, Jon Callas wrote: >>> Personally, I think that the present way things are done is >>> syntactically fine. Semantically, there are many bogosities. You can >>> time-limit your signature on a key, but no one ever does. >> As I've explained before, I don't think that this is the same as >> hardcoding it into the key, as it wouldn't change the fingerprint, would >> it?! > > I read your explanation. I understand it. I just disagree. > > I think that hard-expiration is not only a bad idea, but unenforceable. It was enforceable with V3 keys. It is, as Christoph pointed out, no longer enforceable with V4 keys because it was moved out of the Public Key Packet and into the SelfSig. :-( > It's a *good* thing for Alice to be able to update the expiration time > on her key. It encourages putting a limit on (as opposed to no limit) > if it can be changed later. It also allows advanced systems to be able > to do some really cool things with short lived keys. This is a reason for SelfSigs to expire. However if the key itself is stolen/compromised the attacker could then create an updated SelfSig with an updated expiration. If the key itself had an expiration (as it did in v3) then this attack wouldn't work. But then it also means Alice would *have* to generate a new key after the old key expired. (Or, worst case, Alice would have to regenerate a new Certificate using the same key parameters and then obtain all those signatures again). > And you probably can't prevent it anyway. X.509 syntax people have > kittens if you reuse a key in certs. And yet a major feature of many > PKI systems is to "reissue" a cert with a new expiration time, because > it makes operations much easier for everyone. > > Jon > > _______________________________________________ > 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 Mon Apr 27 07:23: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 71B6A1A1A7B for ; Mon, 27 Apr 2015 07:23:45 -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 iqRnNTWegwPT for ; Mon, 27 Apr 2015 07:23:43 -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 14E3A1A1A78 for ; Mon, 27 Apr 2015 07:23:43 -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 A9BAD4007F for ; Mon, 27 Apr 2015 16:23:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id TgRD6b3iWzMW for ; Mon, 27 Apr 2015 16:23:40 +0200 (CEST) Message-ID: <553E466C.9030709@dominikschuermann.de> Date: Mon, 27 Apr 2015 16:23:40 +0200 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: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> In-Reply-To: <1430144158.15361.2.camel@scientia.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 14:23:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/27/2015 04:15 PM, Christoph Anton Mitterer wrote: > On Mon, 2015-04-27 at 14:08 +0200, Dominik Schuermann wrote: >> Full ACK. I also don't see the need for hard expiration times. > I don't quite understand why people lobby against a use case, > which wouldn't have an effect on any other use cases if people > choose so. > > It's like "I only use signing - so let's remove any encryption > capabilities from OpenPGP" o.O I am not arguing from a user's perspective, I am arguing from the perspective of an implementor of the standard. More features, more complexity. I want to see a use case before we put something in the standard that everyone MUST implement. > > >> For me soft expiration is a way that prevents the usage of keys >> after a certain amount of time > As I've outlaid before, it doesn't really prevent this. Please read my email again. It does not prevent it when you consider an attacker, but we are not talking about an attack scenario here. If you think we are talking about an attack scenario, I like to here what hard exp can do for us. Regards Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVPkZsAAoJEHGMBwEAASKCDsIH/iCpIYAQQVZj5BBjH6QJw34k owf6qCBLA2vF4LVdCTciBVJqTyN2ySdxlBPadve7S0BbClAjUvGIfqJhE+iD7JCj zC8Puj/ToSI0O4zV/uYX+C35maP9+L6zcAIbc5JGpjvu7Rcyfy70+b6fnq03UJJD vrS3eEURj/fHB84tzKY+WqFyAjEhXe9cAZOixZC9Ok58vjiLbID16N3gJdxgX5EM FwT/f0OyVIO53Yam7BEKlh0LaOCNbcTJPTfJy1WxzMa+/RGHmt22OObMBhMXdb/I C87gmvMuY6isqB45+sBXEIWaz3X70Be1UwCOp8G1xR/INekHDUj4j/E7A/g2gmw= =IGfz -----END PGP SIGNATURE----- From nobody Mon Apr 27 07:24: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 A4A531A1A7E for ; Mon, 27 Apr 2015 07:24:15 -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 or73-8Mt9Hw7 for ; Mon, 27 Apr 2015 07:24:14 -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 8EAFB1A1A7C for ; Mon, 27 Apr 2015 07:24:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 71406E2036; Mon, 27 Apr 2015 10:24:13 -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 29713-03; Mon, 27 Apr 2015 10:24:11 -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 C34F6E2035; Mon, 27 Apr 2015 10:24:11 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3REOBol023695; Mon, 27 Apr 2015 10:24:11 -0400 From: Derek Atkins To: Christoph Anton Mitterer References: <87d232lkb6.fsf@alice.fifthhorseman.net> <1429543533.24823.73.camel@scientia.net> <2142458E-1636-4E3B-8CCE-36078AFC02C9@callas.org> <1429922158.4659.43.camel@scientia.net> Date: Mon, 27 Apr 2015 10:24:11 -0400 In-Reply-To: <1429922158.4659.43.camel@scientia.net> (Christoph Anton Mitterer's message of "Sat, 25 Apr 2015 02:35:58 +0200") 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 Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 14:24:15 -0000 Hi, Christoph Anton Mitterer writes: > On Fri, 2015-04-24 at 12:11 -0700, Jon Callas wrote: >> > And specifying a expiration time (even if it's 0) should be mandatory. >> That's there now. > Again, I don't see where this would be specified, except for the > deprecated v3 keys. > > It's not part of the v4 keys, and I can't recall a section which makes > the key exp sig subpacket mandatory. I read 4880 again and I'm afraid I was wrong and you are correct; the key expiration was removed in v4 keys. Having the subpacket mandatory doesn't help, because the self-sig can always be reissued. > Anyway, the idea for making it mandatory has less to do with the > immutable vs. mutable question... it's rather based on the idea that we > should IMHO try to strengthen and clarify the whole message format. > E.g. I think we should convert the critical-bit to be a non-critical > bit. e.g. everything is considered critical unless explicitly specified > not to be. With it being in the self-sig there is no way to make it immutable. I could take the top-level key packet and create a new self-sig on it with a different key-expiration subpacket. All other signatures on the key will remain valid (because they don't include the self-sig), and the key fingerprint wont change (because it doesn't include the selfsig, either). > Cheers, > Chris. > _______________________________________________ > 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 Mon Apr 27 07:28: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 0785A1A1A9C for ; Mon, 27 Apr 2015 07:28:36 -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 kObefCfb6J8J for ; Mon, 27 Apr 2015 07:28:34 -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 28D631A1A9B for ; Mon, 27 Apr 2015 07:28:34 -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 AF48B5FAC0 for ; Mon, 27 Apr 2015 14:28: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 JedONhbzbWwr for ; Mon, 27 Apr 2015 14:28:30 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 14:28:30 +0000 (UTC) Message-ID: <1430144910.15361.8.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 27 Apr 2015 16:28:30 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-3Xac9vNMokuytIxt4MR+" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 14:28:36 -0000 --=-3Xac9vNMokuytIxt4MR+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 10:18 -0400, Derek Atkins wrote:=20 > But then it also means Alice would *have* to generate a > new key after the old key expired. (Or, worst case, Alice would have to > regenerate a new Certificate using the same key parameters and then > obtain all those signatures again). Just to point that out once more: The later here is actually the feature of the whole idea. And in just in order to calm down (once more) all the opponents of a hard coded expiration time: - having a hardcoded expiration time, does NOT mean, that people have to use it One could still let people choose during key creation what they want... one could even "hide" such feature behind something like gnupg's --export - even though it's IMHO rather useless, one could still allow for "soft" expiration times, although - as mentioned previously - I'd rather do that simply via the expiration time of the self sigs So nothing of the current functionality is lost. Cheers, Chris. --=-3Xac9vNMokuytIxt4MR+ 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzE0Mjgz MFowTwYJKoZIhvcNAQkEMUIEQM+hXIRpToCkS2sqrw9Ii3rxMzw3/fSVvNzZ1bM6416DxMs9fd93 WsV9S+u91nbvfNNZoOjz4EOPVI1dKLMQ1BIwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDVP6du83mzjGzHGGu8877xZXh7Ao0e jlzGi+qeUi37bAul3wRdCoic57srGI4QyopenlNh8KFKNV5Cs28JkdoazGoBA9ZgXv0T8hT/00T8 LY3ohgXUvIMPzx+G7ks6U2znAwSKLj6PQl5uHeEMPdpRpiZZigh4c/2IWjDi431ZgmU7/BEcHJVy LFd3AwZukK/J95zVGl85bK7NZ4eEt+MiQWgze/l46gpUx/PyWZKh6IEt89zwOJMXdqwpzAbgSQSU 6umFS+pOxGNeZxJtNghnJJeuswRjY9h7OCgDwkq9oGDgbbtQFDmsj0FpMbIyiO3JOCjn4sL09pj+ X+mY0er/AAAAAAAA --=-3Xac9vNMokuytIxt4MR+-- From nobody Mon Apr 27 07:30: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 434BD1A1AD0 for ; Mon, 27 Apr 2015 07:30:44 -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] 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 AjaSb9C4Mhs9 for ; Mon, 27 Apr 2015 07:30:41 -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 3BC8A1A1ADC for ; Mon, 27 Apr 2015 07:30:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5ACD2E2035; Mon, 27 Apr 2015 10:29:58 -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 29713-05; Mon, 27 Apr 2015 10:29:56 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 20CA9E2039; Mon, 27 Apr 2015 10:29:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1430144996; bh=xTsfyiiPMjZi8ga1/AEt1xNogkRXtoxg1CYpAPzqwbw=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=CNyJD7KDWvB8Vg1ghIxfuJv52p7NSvIBFSZRiB3VbFOY67DBj5maBXIpLCXTbKoZ1 DYkglwmYGn7W54HWewrfWwriioSlBCjxnAlyHW5WiwlU+EdPaxweBhFk4JrpY7H1LN BYlz/pinOoAsCVHx0cUc05tVdY5HHTTCmRp2UsiQ= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 27 Apr 2015 10:29:56 -0400 Message-ID: <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> In-Reply-To: <553E466C.9030709@dominikschuermann.de> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> Date: Mon, 27 Apr 2015 10:29:56 -0400 From: "Derek Atkins" To: "Dominik Schuermann" 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] rfc3880bis - hard expiration time 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, 27 Apr 2015 14:30:44 -0000 HI, On Mon, April 27, 2015 10:23 am, Dominik Schuermann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I am not arguing from a user's perspective, I am arguing from the > perspective of an implementor of the standard. More features, more > complexity. I want to see a use case before we put something in the > standard that everyone MUST implement. Unless you've removed support for V3 keys from your implementation then you effectively already have this implemented. >>> For me soft expiration is a way that prevents the usage of keys >>> after a certain amount of time >> As I've outlaid before, it doesn't really prevent this. > > Please read my email again. It does not prevent it when you consider > an attacker, but we are not talking about an attack scenario here. If > you think we are talking about an attack scenario, I like to here what > hard exp can do for us. You are correct that the current v4+self-sig-sub-packet does not prevent an attack where the private key gets compromised. That's exactly why some of us want to re-introduce key expiration in the key packet (ala v3). What it allows is the ability to say "this key cannot be used after date X". Even if an attacker gets the private key there is no way for them to change that. Of course, if an attacker does obtain the private key they could still sign stuff as of "date X-1". But eventually that stops working. > Regards > Dominik ______________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Apr 27 07:51: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 5D43B1A7D80 for ; Mon, 27 Apr 2015 07:51:06 -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 RGhWiH_77aMU for ; Mon, 27 Apr 2015 07:51:04 -0700 (PDT) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (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 6F6FB1A710C for ; Mon, 27 Apr 2015 07:51:03 -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 mx1.mailbox.org (Postfix) with ESMTPS id C192941576; Mon, 27 Apr 2015 16:51:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id MLcvTPcr-WUn; Mon, 27 Apr 2015 16:51:00 +0200 (CEST) Message-ID: <553E4CD4.30200@dominikschuermann.de> Date: Mon, 27 Apr 2015 16:51:00 +0200 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: Derek Atkins References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> In-Reply-To: <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 14:51:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/27/2015 04:29 PM, Derek Atkins wrote: > Unless you've removed support for V3 keys from your implementation > then you effectively already have this implemented. We removed support for v3 keys in OpenKeychain. > You are correct that the current v4+self-sig-sub-packet does not > prevent an attack where the private key gets compromised. That's > exactly why some of us want to re-introduce key expiration in the > key packet (ala v3). What it allows is the ability to say "this key > cannot be used after date X". Even if an attacker gets the private > key there is no way for them to change that. > > Of course, if an attacker does obtain the private key they could > still sign stuff as of "date X-1". But eventually that stops > working. 2,5 years on average until a key expires, even if you would argue setting the expiry time to 6 month, it's enough time for an attacker to misuse the key, I just don't see attack scenario prevented by having expiration dates. As outlined before, I see soft expiration dates as a convenience feature, not something that prevents attacks. Thus, hard expiration makes no sense in my model. Some argue that expiration helps invalidating old crypto, I disagree. Using 512 bit RSA keys should be rejected by the client software, no need to place expiration dates inside the key. This is actually something we currently have on our TODO list for OpenKeychain. Regards Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEbBAEBAgAGBQJVPkzUAAoJEHGMBwEAASKC2L8H+I37tl8RQO6GRzkwnOZEOXhO LKq4dEIzYzJUtyek0Y7xblNyPtkxFu1poEzA6euoqB8d/5cI0z0Cxl8aP3lKxMmi 6NuWuCqczlWBR3NFTx2Cc1lgyeg376yLltNClcRIXiWGn83cEDDzUFn/bAcnwbpn 5cj5j66mySGTVT5aPC+Wbq9p21d63NhNvVX7j1EPq6fie9NVKmSjr3U+FBE940QW rx6+x92EDC1VfFwQsufFvdeiiLxIPt7xdl6CM19uAlBMiElilpBUgPF8BWq52/tR 39FwLxXskNP5YQhZDeCcn2Xun3vf+0GwF2HmDPxhq66xjr7uFDy2zNEXbaD0SA== =XyNX -----END PGP SIGNATURE----- From nobody Mon Apr 27 07:57: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 614951A8712 for ; Mon, 27 Apr 2015 07:57: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 QdB662vE9Y21 for ; Mon, 27 Apr 2015 07:57: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 673481A802E for ; Mon, 27 Apr 2015 07:57:41 -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 45BAB5FB17 for ; Mon, 27 Apr 2015 14:57:40 +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 oXLACqeZoB9w for ; Mon, 27 Apr 2015 14:57:38 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 14:57:38 +0000 (UTC) Message-ID: <1430146657.15361.13.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 27 Apr 2015 16:57:37 +0200 In-Reply-To: <553E466C.9030709@dominikschuermann.de> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-t4/HnyctQfATgHnZGkPc" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 14:57:48 -0000 --=-t4/HnyctQfATgHnZGkPc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 16:23 +0200, Dominik Schuermann wrote:=20 > I am not arguing from a user's perspective, I am arguing from the > perspective of an implementor of the standard. More features, more > complexity. Well... I don't think that this adds *that* much more complexity... it's just one more field that needs to be set and read out... > I want to see a use case before we put something in the > standard that everyone MUST implement. Please have a look at my previous posts on that matter, I already gave some possible usage scenarios respectively "attacks". > >> For me soft expiration is a way that prevents the usage of keys > >> after a certain amount of time > > As I've outlaid before, it doesn't really prevent this. > Please read my email again. It does not prevent it when you consider > an attacker, but we are not talking about an attack scenario here. Well but that's what needs to be talked about ^^ > If > you think we are talking about an attack scenario, I like to here what > hard exp can do for us. See previous mails. Cheers, Chris. --=-t4/HnyctQfATgHnZGkPc 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzE0NTcz N1owTwYJKoZIhvcNAQkEMUIEQH+vLlr5g9jD/gXSdkzz7fEdeqwfGh8GcTSlbPtEgibNUkYY4J1y rLFrs+rPjPwxtIjrTz+sCoNXV6Yzr25EZPkwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBjmVKNkPqYL3YQsHDZAquk6IP/RieI nb82e2ZAzIB+CkwGmYxZiUtkjTndOyF9eI1YeSz9cuZGbKRwzBH1M+c3NQP2f2D73awMkK7ifKNi qM4K0XwmJF65GYmnVrWTRL9RbYq2ZCLbpgiTujAInNzypnpWMs1sPcY8XNgAS7nd5Jz2AsULv/Ty WPEsm3p33F6TXFRklCqjCpPTR9Tgtm7B4tKFh9juM2LHZdgTiJTxsBKO1Yx1fh4SKhuuKk5Mrtri 6fQz3pO8AP4eScGRfHHI7sEqqp/fd5ZbI9LM+cQ9TJlYAIsw33zZLnK+kRcWs37kMxQkVW4ZRDkh hAswB56vAAAAAAAA --=-t4/HnyctQfATgHnZGkPc-- From nobody Mon Apr 27 08:03: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 D67AF1A879A for ; Mon, 27 Apr 2015 08:03: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 bP6dwTNw8Syo for ; Mon, 27 Apr 2015 08:03:45 -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 14E851A8755 for ; Mon, 27 Apr 2015 08:03: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 mailgw02.dd24.net (Postfix) with ESMTP id E7C555FAE3 for ; Mon, 27 Apr 2015 15:03:43 +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 JDRKIS-zMytO for ; Mon, 27 Apr 2015 15:03:42 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 15:03:42 +0000 (UTC) Message-ID: <1430147021.15361.16.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 27 Apr 2015 17:03:41 +0200 In-Reply-To: References: <87d232lkb6.fsf@alice.fifthhorseman.net> <1429543533.24823.73.camel@scientia.net> <2142458E-1636-4E3B-8CCE-36078AFC02C9@callas.org> <1429922158.4659.43.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-UdK1zJtv303cwoEEp6hR" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 15:03:47 -0000 --=-UdK1zJtv303cwoEEp6hR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 10:24 -0400, Derek Atkins wrote:=20 > > It's not part of the v4 keys, and I can't recall a section which makes > > the key exp sig subpacket mandatory. > I read 4880 again and I'm afraid I was wrong and you are correct; the > key expiration was removed in v4 keys. No worries :)=20 > Having the subpacket mandatory doesn't help, because the self-sig can > always be reissued. Sure,.. I meant the key packet shouldn't be designed in such a way, that "absence" of the expiration time field is interpreted as "infinite". That one zero field doesn't harm and I think it's generally better to explicitly store things. > > Anyway, the idea for making it mandatory has less to do with the > > immutable vs. mutable question... it's rather based on the idea that we > > should IMHO try to strengthen and clarify the whole message format. > > E.g. I think we should convert the critical-bit to be a non-critical > > bit. e.g. everything is considered critical unless explicitly specified > > not to be. >=20 > With it being in the self-sig there is no way to make it immutable. I > could take the top-level key packet and create a new self-sig on it with > a different key-expiration subpacket. All other signatures on the key > will remain valid (because they don't include the self-sig), and the key > fingerprint wont change (because it doesn't include the selfsig, either). Sure... that's what I'm trying to write since some days now :-) --=-UdK1zJtv303cwoEEp6hR 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzE1MDM0 MVowTwYJKoZIhvcNAQkEMUIEQJs5rfOvrWIjqLcUVPtADHy5F7rrP4WmX7/X5VT9QkiKYifKK5qQ +dvIM9g23scHWZYJQCkaoHcXgjpwQFQ4Y6QwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCnZKe2o3AgpG4bo1FUGDsD0xfH0nJJ yD83nBsLcNrs09JQTMnb/2U4/WSil2mkENPDqAk0ZqwUzxThtHhXGGfHM/IwssptAzqqngeUpifc rHq+L8CO7b0rLkklTxmQoXtXpEI0d0iG3Uwoih7qV4KeOXL6Ziw9AzqZnMq9gGoCWQ8XFLoUjtFY 3QG8+LQURwWDQp4bSoxZHjPJGDHPrLs+aXiDDHM9kdSZdZBNCk5aQe1wDQ0xevzHUwpDyoC6qLEc bWhjFxJY9JRUR4YENHkCABb/DARbYAsnPKv7vqJoLQ3y5jPJUcHdnq6ltbnM/eijP10VIDlhAKsi UbcGN6IfAAAAAAAA --=-UdK1zJtv303cwoEEp6hR-- From nobody Mon Apr 27 08:10: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 58E911A87EB for ; Mon, 27 Apr 2015 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.277 X-Spam-Level: X-Spam-Status: No, score=-16.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_WHITELIST=-15] 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 F6Xp87Rl6yOu for ; Mon, 27 Apr 2015 08:10:07 -0700 (PDT) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7202C1A87E3 for ; Mon, 27 Apr 2015 08:10:07 -0700 (PDT) Received: from omp1050.mail.ne1.yahoo.com (omp1050.mail.ne1.yahoo.com [98.138.89.192]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id t3RF9PfZ019352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Apr 2015 08:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1430147366; bh=EKVXaHLNzKGUuSDAr5gfky1v+SkK71G3uoOYpabQfqk=; h=Date:From:Subject:To:In-Reply-To; b=duV7F5Ut3GrLAWxnAO6W+lbZ+IrWdYtXcUzPX4MpY+lNgxZltDpY8OdD9Q7koxt1B Q2p0jBirWgVHtPm/MdkmUZ8cuu4/mQe/PIN6g8YZf3VQeDgz9sCLQUtEGfpNRH0s65 ch0WlONb7o3cXkaRbymEHC6d4mbZvImaefsp9+qQ= Received: (qmail 66774 invoked by uid 1000); 27 Apr 2015 15:09:24 -0000 Received: (qmail 12198 invoked by uid 60001); 27 Apr 2015 15:09:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1430147364; bh=dIdf/J0Bmp95GqezHXfAOqW7HajWzYNBdkc9Wd6tHDg=; h=Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pzh525Xo80L/SL3kFQ+H2+Tksry1qRxslQv0+yatr/rnzGshJXji8EgqFpsyTAeIQwHD/cwPXA5x/kEKqR4vhXxBFzlxXFSYvijp99ATJlJ+mCT2762qPK9pFRVVbogLTOmm8a4p8hhsmpSBZG/cIrEoHSPZUy3aNrqpEW1EXNk= X-YMail-OSG: Pa.IAGcVM1lWbAbaen6WoHDK0C6uGvh2loAy8oU8jV4odan ESt.pmPGhCQCmeUbfTipIx8Nxp_h4yiqp52LZ_li_Sl0NZ6JdEV4q2pNaoO_ .RKLh9uK5w8lWpUu5AxmpH2WSzB5g1JaIo7vP.Vt3OHZwyag1LLLxVIFQKNu 5I3vZRzggD.ywRiUTa6VnfX4qOvNVnsdJ1HeJJcQjnfy8OmUl3v0AM1sXZwL NYh5hkMK83hTOjANVYW8_NHbIiQuURC7QV28H2ghPOv_Z_SGIQQeerpkjyva TMdJ4CORihrd_rfOwDQqCbyoPOeSMcmLzSyyaNa8- Received: from [209.131.62.124] by web310005.mail.ne1.yahoo.com via HTTP; Mon, 27 Apr 2015 08:09:24 PDT X-Rocket-MIMEInfo: 002.001, QSBoYXNoIGZ1bmN0aW9uIHdoaWNoIGlzIHNlY3VyZSBvbiBzaG9ydCBpbnB1dHMgbWF5IG5vdCBiZSBzZWN1cmUgb24gbG9uZyBpbnB1dHMuIFRoaXMgaXMsIGluZGVlZCwgdGhlIGNhc2UgKGdlbmVyaWNhbGx5KSBmb3IgdGhlIE1EIGFuZCBTSEEtWzEyXSBmdW5jdGlvbnM6IFNlZSBwYXBlcnMgYnkgU2NobmVpZXIgZXQgYWwuIGludGVyIGFsaWEuQXQgQXByIDI0LCAyMDE1LCAxMTowNjo0MCBQTSwgQW5kcmV5IEppdnNvdiB3cm90ZTpPbiAwNC8yNC8yMDE1IDA0OjQ1IEFNLCBXZXJuZXIgS29jaCB3cm90ZToBMAEBAQE- X-Mailer: YahooMailIosMobile/0.0 YahooMailWebService/0.8.203.740 Message-ID: <1430147364.75064.YahooMailIosMobile@web310005.mail.ne1.yahoo.com> Date: Mon, 27 Apr 2015 08:09:24 -0700 From: David Gil To: "openpgp@brainhub.org" , "openpgp@ietf.org" In-Reply-To: <553B2EDA.4030909@brainhub.org> MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 147366002 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 27 Apr 2015 15:10:11 -0000
A hash function whic= h is secure on short inputs may not be secure on long inputs. This is, inde= ed, the case (generically) for the MD and SHA-[12] functions: See papers by= Schneier et al. inter alia.

At Apr 24, 2015, 11:06:40 PM, Andrey Jivsov<= openpgp@brainhub.org> wrote:
On 04/24/2015 04:45 AM, Werner Koch wrote:
> On Fri, 24 Apr 2015 09:19, openpgp@brainhub.org said:>
>> 2. The Iterated S2K is essentially a
>= >
>> M =3D M1 || M2 || M2 || M2 || ... || M2, where M= 1 includes the salt.
>> S2K =3D Hash( M )
> Actually M2 also includes the salt:
>
> | Then the salt, followed by the passphrase data, is repeatedl= y hashed
> | until the number of octets specified by the= octet count has been
> | hashed. [...]
>
>
>
I stand corr= ected.

My argument holds with even gre= ater simplifications with the following
adjustment:

M =3D M1 || M1 || M1 || M1 || ... || M1= , where M1 includes the salt.
S2K =3D Hash( M )

If we use the Hash() which is insecure in th= is setting, we should expect troubles in other application of this hash function: e.g. in digital signatures or MAC= .



____________________________________= ___________
openpgp mailing list
= openpgp@ietf.org
https://www.ietf.org= /mailman/listinfo/openpgp
From nobody Mon Apr 27 08:12: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 F30871A8835 for ; Mon, 27 Apr 2015 08:12:08 -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 dWv8aKcvlpdU for ; Mon, 27 Apr 2015 08:12:03 -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 4ADE41A8823 for ; Mon, 27 Apr 2015 08:12:03 -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 2AE815FAE7 for ; Mon, 27 Apr 2015 15:12:02 +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 7V_jzg0gp5fz for ; Mon, 27 Apr 2015 15:11:57 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 15:11:57 +0000 (UTC) Message-ID: <1430147516.15361.23.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 27 Apr 2015 17:11:56 +0200 In-Reply-To: <553E4CD4.30200@dominikschuermann.de> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> <553E4CD4.30200@dominikschuermann.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-+p9H1aN1b/9iSXh7gzqq" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 15:12:09 -0000 --=-+p9H1aN1b/9iSXh7gzqq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 16:51 +0200, Dominik Schuermann wrote:=20 > 2,5 years on average until a key expires, even if you would argue > setting the expiry time to 6 month, it's enough time for an attacker > to misuse the key, I just don't see attack scenario prevented by > having expiration dates. What speaks against keys that are just used e.g. for some weeks? You could have them signed by other long-term keys, which are kept on offline systems and are thus "more secure". > Thus, hard expiration > makes no sense in my model. Well as said before, just because you or I don't use a certain scenario doesn't mean that it's invalid for everyone else. > Using 512 bit RSA keys should be rejected by the client software, no > need to place expiration dates inside the key. And what has the one thing to do with the other? You could have created a 4096 bit RSA key 4 years ago, it would still be considered "safe", even though the real owner may have abandoned it and/or it may have been compromised long ago. Since revocations are per se blockable, the peers of the key owner may continue to use it forever. Cheers, Chris. --=-+p9H1aN1b/9iSXh7gzqq 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzE1MTE1 NlowTwYJKoZIhvcNAQkEMUIEQDg6THASGoO7FpBYtrBAmKkpVaJGDWG8i4xuIbXuWZ+qc0F3CM6B XggIWvLoD21ipUeQkrcvO9SzYwZ0z7bZ9J8wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAls8f1PNLLnrtcxpluXw4TNlpi2shb 0aaRuLqA9MgFgRemb0YlNT4vxzOQxpxXAUwCPktDPzV6EMTUUfKEhqrFnmYTFj+uQebjnqJBjXQC e6q1GuJ7q47GwzLP1byOotXoB+qSGOKWHrKHXgy7w+c67n7kuCqZy2H2KOFFx0YExW989T/Cqj3z c9j+YBrD8VibAJVB4nNtAmew6g1mX9ATBZkSz3TxXfytDQCcRrTN4e7UsCwKNi8IvUMfDjocQ4ga Rquwv2nCQ+3Fu3AV+V8+WT1D9PIe9w+jW6FxvPnUgHaf0dKPTSFBpmNUb/gUqkWKmR1O/LEAb1+W 2K6wNN4UAAAAAAAA --=-+p9H1aN1b/9iSXh7gzqq-- From nobody Mon Apr 27 08:31: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 A86B51A8785 for ; Mon, 27 Apr 2015 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 FK4bjeKPNVTW for ; Mon, 27 Apr 2015 08:31:45 -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 E14561A8728 for ; Mon, 27 Apr 2015 08:31:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yml0Z-0000Xn-Ao for ; Mon, 27 Apr 2015 17:31:43 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YmkyS-00040B-FD; Mon, 27 Apr 2015 17:29:32 +0200 From: Werner Koch To: "Derek Atkins" References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: "Derek Atkins" , "Dominik Schuermann" , openpgp@ietf.org Date: Mon, 27 Apr 2015 17:29:32 +0200 In-Reply-To: <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> (Derek Atkins's message of "Mon, 27 Apr 2015 10:29:56 -0400") Message-ID: <874mo1egir.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, Dominik Schuermann Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 15:31:46 -0000 On Mon, 27 Apr 2015 16:29, derek@ihtfp.com said: > Unless you've removed support for V3 keys from your implementation then > you effectively already have this implemented. He has a new implementation and I actually hope it can't handle v3. I don't view the increased complexity as a serious problem in this case. Hard expiration time is easier to implement than the v4 soft-expiration time. Thus it adds only a small bit of additional complexity. A quick local search showed that the hard expiration time must have been discussed before 2001-09-05 (Florian Weimer) and raised again by Bodo Moeller on 2003-03-06. FWIW: I have no real preference pro or contra a hard expiration time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 27 09: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 030E71A8A1C for ; Mon, 27 Apr 2015 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 KYSP2pDf03kn for ; Mon, 27 Apr 2015 09:04:03 -0700 (PDT) Received: from mail.giepa.de (ns.giepa.de [193.110.205.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F341A8957 for ; Mon, 27 Apr 2015 09:03:31 -0700 (PDT) Received: from localdomain (localhost [127.0.0.1]) by mail.giepa.de (Postfix) with SMTP id 4995A66A09 for ; Mon, 27 Apr 2015 18:03:28 +0200 (CEST) Received: from S2008SBS.intern.giepa.de (unknown [193.110.205.100]) by mail.giepa.de (Postfix) with ESMTP id D157366A11; Mon, 27 Apr 2015 18:03:23 +0200 (CEST) Received: from S2008SBS.intern.giepa.de ([fe80::c527:809d:89e1:2fc3]) by S2008SBS.intern.giepa.de ([fe80::c527:809d:89e1:2fc3%12]) with mapi; Mon, 27 Apr 2015 18:03:25 +0200 From: Daniel Ranft To: Christoph Anton Mitterer Date: Mon, 27 Apr 2015 18:03:23 +0200 Thread-Topic: [openpgp] Fingerprints Thread-Index: AdB+8N8RsJrzlN3sSfu9VhSKVJwqBQCEaFFA Message-ID: <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.de> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <87618qzlw0.fsf@vigenere.g10code.de> <1429922578.4659.49.camel@scientia.net> In-Reply-To: <1429922578.4659.49.camel@scientia.net> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 16:04:05 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQovLyBkb2lu ZyBteSBwcmVtaWVyZSBoZXJlIG9uIHRoZSBtYWlsaW5nIGxpc3QgOikNCg0KPj4gIDA4LTEyMzQ1 Njc4LTlhYmNkZWYwLTEyMzQ1Njc4LTlhYmNkZWYwLTEyMzQ1Njc4LTlhYmNkZWYwLTEyMzQ1Njc4 LTlhYmNkZWYwDQo+PiB3b3VsZCBmaXQgaW50byBvbmUgbGluZSBhbmQgaXMgc3RpbGwgbm90IHRv byBoYXJkIHRvIHJlYWQuDQo+IEFuZCB3aGF0IGlmIHdlJ2QgYWxyZWFkeSBtb3ZlIHRvIGEgNTEy IGJpdCBoYXNoPyBFLmcuIFNIQTMtNTEyLg0KDQo+IEFsc28gY29uc2lkZXIgdGhhdCBwZW9wbGUg b2Z0ZW4gd3JpdGUgdGhpcyB0byBidXNpbmVzcyBjYXJkcyBhbmQgdGhhdA0KPiBsaWtlLCB3ZXJl IHNwYWNlIGlzIG1vcmUgbGltaXRlZCB0aGFuIG9uIGEgY29tcHV0ZXIgc3lzdGVtJ3MgbGluZSAo ZS5nLg0KPiB0aGUgODAgY2hhcnMgb2YgdHJhZGl0aW9uYWwgdGVybWluYWwpLg0KDQpZb3UgY291 bGQgdXNlIGEgUVIgY29kZSBmb3IgYXQgbGVhc3QgdGhlIGJ1c2luZXNzIGNhcmRzPyBXZSBkaXNj dXNzZWQgc29tZXRoaW5nIGxpa2UgdGhhdCBvbiB0aGUgT3BlblBHUCBzdW1taXQgYSBjb3VwbGUg b2YgZGF5cyBhZ28uDQpUaGUgcmVsYXRlZCBkb2N1bWVudGF0aW9uIGRyYWZ0cyBjYW4gYmUgZm91 bmQgaGVyZTogaHR0cHM6Ly9naXRodWIuY29tL01vZGVyblBHUC9RUg0KDQoNCi0gLS0NClZlcnNj aGzDvHNzZWxuIFNpZSBJaHJlIEUtTWFpbHMgbWl0IGdwZzRvIGbDvHIgT3V0bG9vayB8IEVuY3J5 cHQgeW91ciBlbWFpbCB3aXRoIGdwZzRvDQpNZWluZW4gUEdQLVNjaGzDvHNzZWwgZmluZGVuIFNp ZSBhdWYgaGtwOi8vcGdwLm1pdC5lZHUuIEtleS1JRDogQTJCNEIzRUYNCi0gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGFuaWVsIFJh bmZ0DQpTb2Z0d2FyZWVudHdpY2tsZXINCg0KR2llZ2VyaWNoICYgUGFydG5lciBHbWJIICANClJv YmVydC1Cb3NjaC1TdHJhw59lIDE4IHwgRC02MzMwMyBEcmVpZWljaA0KVGVsLiArNDkgNjEwMyA1 ODgxLTUwIHwgRmF4ICs0OSA2MTAzIDU4ODEtNDkNCmRhbmllbC5yYW5mdEBnaWVwYS5kZSB8IGh0 dHA6Ly93d3cuZ2llcGEuZGUgDQoNCkdlc2Now6RmdHNmw7xocmVyOiBEaXBsLi1JbmcuIChUVSkg SGFucy1Kb2FjaGltIEdpZWdlcmljaA0KQW10c2dlcmljaHQgT2ZmZW5iYWNoL01haW4gfCBIUkIg MzMyMzYNCg0KVGVsZVRydXNUIFF1YWxpdHkgU2VhbCAg4oCcSVQgU2VjdXJpdHkgbWFkZSBpbiBH ZXJtYW554oCdIHd3dy50ZWxldHJ1c3QuZGUvaXRzbWlnDQotIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tQkVHSU4gUEdQIFNJ R05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mg0KQ29tbWVudDogVXNpbmcgZ3BnNG8gdjMu NS4wLjU1MDQgLSBodHRwOi8vd3d3LmdwZzRvLmRlLw0KQ2hhcnNldDogdXRmLTgNCg0KaVFFY0JB RUJBZ0FHQlFKVlBsM0xBQW9KRUM3c0syV2l0TFB2Z3hZSUFLL3ZjYnFCMEttaWRjc1VFK1FvTTh3 MQ0KMDZMVllBMkZOYnArSjd2a2VleFhkUFFWR21pN0UrVnlsQlJKM092QlU5ODBzdTg0MDFWR0N4 L2hrd2p1U05uNw0KTXVyMGdzM2hrK003WlUxUFhZbW1GNnhidlV4TzdYbS93UjJhMWlLeHBHYk1m aWJlazUzUWdYcnRQcWxLN2JPRQ0KamI1bVo4UzJWSWdiTnRMWUNHVlpEdldzVFRndm85a2JwRTha OHM2QWgrVmhPYytpRGdmNGlCQUZaWHh1blhBUw0Kb0FmWjVSanFyZWdYeWZzVjlZY3d2QXk5R2hn QWJ0MTloZzBsL1lpU3l4cm5XWUo1akEyZHMrZEM0eTVJdmVCUg0KdFB4NzI0ekNyUGZaUUxQUTZs Vm0zbDhWcXFqOFEwWjRueWVnTlhMcEFGWDlXZWdCSVV6UUxBazlibnBDQVc4PQ0KPS9UZ0QNCi0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From nobody Mon Apr 27 09:26: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 AAECE1A898C for ; Mon, 27 Apr 2015 09:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.9 X-Spam-Level: X-Spam-Status: No, score=-8.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 H6VXliUQkFIy for ; Mon, 27 Apr 2015 09:26:44 -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 977301A8973 for ; Mon, 27 Apr 2015 09:26:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Ymlrn-0001sY-4c for ; Mon, 27 Apr 2015 18:26:43 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YmloT-0004Il-AU; Mon, 27 Apr 2015 18:23:17 +0200 From: Werner Koch To: Daniel Ranft References: <87d232lkb6.fsf@alice.fifthhorseman.net> <87618qzlw0.fsf@vigenere.g10code.de> <1429922578.4659.49.camel@scientia.net> <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.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: Daniel Ranft , Christoph Anton Mitterer , "openpgp\@ietf.org" Date: Mon, 27 Apr 2015 18:23:17 +0200 In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.de> (Daniel Ranft's message of "Mon, 27 Apr 2015 18:03:23 +0200") Message-ID: <87pp6pczgq.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: Christoph Anton Mitterer , "openpgp@ietf.org" Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 16:26:45 -0000 On Mon, 27 Apr 2015 18:03, Daniel.Ranft@giepa.de said: > You could use a QR code for at least the business cards? We discussed something like that on the OpenPGP summit a couple of days ago. During one session it was remarked that one of the larger participating projects got research results on QR codes indicating that QR codes don't work reliable for mass deployment. Thus for backing up and syncing private keys they use a letters and digits based code to seed a PRNG. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 27 09:27: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 7E2AA1A898C for ; Mon, 27 Apr 2015 09:27:32 -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 Td3cbYM4ZpXV for ; Mon, 27 Apr 2015 09:27:31 -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 031311A89AE for ; Mon, 27 Apr 2015 09:27:30 -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 D62ED5FA95 for ; Mon, 27 Apr 2015 16:27:28 +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 1BAUAogeYjay for ; Mon, 27 Apr 2015 16:27:27 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 16:27:27 +0000 (UTC) Message-ID: <1430152046.15361.27.camel@scientia.net> From: Christoph Anton Mitterer To: "openpgp@ietf.org" Date: Mon, 27 Apr 2015 18:27:26 +0200 In-Reply-To: <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.de> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <87618qzlw0.fsf@vigenere.g10code.de> <1429922578.4659.49.camel@scientia.net> <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-BIldhY0WQSTnQN7KFDsc" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 16:27:32 -0000 --=-BIldhY0WQSTnQN7KFDsc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 18:03 +0200, Daniel Ranft wrote:=20 > You could use a QR code for at least the business cards? We discussed som= ething like that on the OpenPGP summit a couple of days ago. > The related documentation drafts can be found here: https://github.com/Mo= dernPGP/QR I personally don't like that very much: Typically one will use his smartphone for scanning this, so one entrusts an pretty insecure system (mostly running some proprietary closed code) with telling you the true value of the FP. Cheers, Chris. --=-BIldhY0WQSTnQN7KFDsc 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzE2Mjcy NlowTwYJKoZIhvcNAQkEMUIEQPeUSplJv+BZVAPkU86vF/yWYtQDt4vbUlCY46LNZX9+VfHaNe0B P4OiwhsVGrU1Gu54bOQrrzoHlfPpCtGJm6wwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDMnIockliVPrrQ3FAjABOT3+ZJzojJ On6+w9a4uKOsMeDL41ILuKKl51lUhUhEw9wFGAW+20vmsLYmEWkNwmpSBP/yjtV1ha4j/Yf9uLnn +bvDEkYOgCG9wAWEmiXTxnPX0rNZwkvyx8HBD6x7oVXi2ekWbXuof6oNFbobt4dO3wlHL3d76vaF WwJuvS0AYjY839Kd0WfTEp9mMMP5Xd04Ht/6pJPj0i1fpafPfVMbFqFxRIg4WluwxOOXyAo0yY9h iWF0N6q3tPzq7ZcDiGR+dFxxG4ML4T22gFp+JvxlKZB0OVYZNkzv6WrY550mMSH5Wre4nw2FxQHE EVE2FBWvAAAAAAAA --=-BIldhY0WQSTnQN7KFDsc-- From nobody Mon Apr 27 10:58: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 579D01A9032 for ; Mon, 27 Apr 2015 10:58:12 -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 8XRlLakHwJ3y for ; Mon, 27 Apr 2015 10:58:11 -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 BC3F81A8A0D for ; Mon, 27 Apr 2015 10:58:10 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so88363034lbb.3 for ; Mon, 27 Apr 2015 10:58: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:content-type; bh=HGrvuDvayJ5xJzHjzBbK3eor71iagNyo9avj4HwF3kE=; b=kklSE2qcW3wBGQNprV5f33smS+g+Yz2LFK5Pbhr9tGXoS2WcPR+MJ1GaMfXqWIsZRP 7JIUqgPO6FRNkoPONqmKX/BSKLMHNx46NMiUJMTNRz9HdBMTHgkYLsqm3s6Lc3uMGWsH obXNr722xc4Pyim8jyQBBMDQws6AOCFQGArYwLQqxMSkBHRRWFJ6eVV8wkDJQ8/oHqYY nZik+HeruOkUixSSrm+Nf5tzfCLWT87KNaUHyDFYvviKPYYvAJC20zC7r0f17Eu+KI9J lqjgDFp87MJuBrhxNNaafPXNcvtbMcMo9d6piNHdvjh7eRfdHv15lqbqZ3bSStR2PcdW SPPQ== MIME-Version: 1.0 X-Received: by 10.112.16.167 with SMTP id h7mr11035244lbd.124.1430157489126; Mon, 27 Apr 2015 10:58:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 27 Apr 2015 10:58:08 -0700 (PDT) In-Reply-To: <87pp6pczgq.fsf@vigenere.g10code.de> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <87618qzlw0.fsf@vigenere.g10code.de> <1429922578.4659.49.camel@scientia.net> <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.de> <87pp6pczgq.fsf@vigenere.g10code.de> Date: Mon, 27 Apr 2015 13:58:08 -0400 X-Google-Sender-Auth: 8hCHbgpI6OYDhMkq7HOtgR3JdRY Message-ID: From: Phillip Hallam-Baker To: Daniel Ranft , Christoph Anton Mitterer , "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 17:58:12 -0000 On Mon, Apr 27, 2015 at 12:23 PM, Werner Koch wrote: > On Mon, 27 Apr 2015 18:03, Daniel.Ranft@giepa.de said: > >> You could use a QR code for at least the business cards? We discussed something like that on the OpenPGP summit a couple of days ago. > > During one session it was remarked that one of the larger participating > projects got research results on QR codes indicating that QR codes don't > work reliable for mass deployment. Thus for backing up and syncing > private keys they use a letters and digits based code to seed a PRNG. I can't see the point of that. Encryption of the private key works fine. We have many resources that allow us to deposit chunks of data in the cloud and rely on them being available in the future. Note that here we are talking about THE cloud, not A cloud. While there are many clouds for computing, archival storage of vital data is an example of an application where the network effects come into play. Encrypt the private key(s) under a symmetric key, split the symmetric key into as many shares as you need. Print out the key shares on paper and you are done. From nobody Mon Apr 27 11:10: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 DD2081A90A9 for ; Mon, 27 Apr 2015 11:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 u8PfnnKYJicp for ; Mon, 27 Apr 2015 11:10:08 -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 9D1FF1A9081 for ; Mon, 27 Apr 2015 11:10:07 -0700 (PDT) Received: by labbd9 with SMTP id bd9so86273836lab.2 for ; Mon, 27 Apr 2015 11:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=NHb39+ENAY+yAB1/VX6sZmqLFppcBN/ISSICQ1mlx+g=; b=EIZ0rKreIqunMN3OfXy6wMOVXw251cYfnmd1aimzThOCCdRgQAOZmAmhuNDSMBxsjX xB5Qa1LIQAQmBYU9nb0ZgnAplYYew3fgVy2SIzLl7VWk3uJN586IB5X5MfbkBRQg/kVU vo99/KmrWpyibs8uURBxnFwofm25X8lfOt1sKPHfB78X3+e5D8CXz+3YZ0RwbyD1wSFW pQxHE29A1HMITm4TRO2jPWRR9DqVW6xaR4OV4JiEVWP+3hln3nPMHgHHHcXKRU1KMJCX j4sMMpz4i6Zey2vesrVIh7v/EVVLQFY8BmHPw+9cOKccQxe1MibjtS5za7G7Wdu7H/q6 vXQw== MIME-Version: 1.0 X-Received: by 10.152.197.2 with SMTP id iq2mr11183585lac.103.1430158206008; Mon, 27 Apr 2015 11:10:06 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 27 Apr 2015 11:10:05 -0700 (PDT) Date: Mon, 27 Apr 2015 14:10:05 -0400 X-Google-Sender-Auth: g6LGONsyLJTLfPviVccygy97gFk Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [openpgp] Fingerprint, Base32 or Base32C? 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, 27 Apr 2015 18:10:09 -0000 I would like opinions on whether we should put a running checksum on the fingerprint encoding or not. The simplest encoding of a fingerprint is to take the BASE32 encoding, truncate to the first n characters and group the result into sets of five digits (according to the 7-2 rule). Since each character encodes 5 bits and we have an 8 bit version ID, we have 92 active bits in the following fingerprint: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx The problem typing this sort of code in by hand is that it is a bit error prone. If a mistake is made we don't know where. For a modest increase in complexity, we can add a running checksum at the cost of one bit per block. Con: The above fingerprint with five chunks only gives 87 active bits Con: While we can chain the checksums to give a pretty robust check on the first block, we only have a small chance of detecting an error in the last. Pro: Easier for the user Pro: Since it is easier, a six chunk block might be acceptable giving 111 active bits. Coding Base32C is if anything a bit easier than Base32 since each 5 character chunk is now 24 active bits. We consume bits in increments of 8 bytes. If we want to make things really robust, we probably want to add in a checksum character at the end, either in addition to per block checksums or as an alternative: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx c c = (Sum (x_i)) (mod 5) From nobody Mon Apr 27 13:36: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 83D411A8777 for ; Mon, 27 Apr 2015 13:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.9 X-Spam-Level: X-Spam-Status: No, score=-8.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 SLv4FdCoIMxD for ; Mon, 27 Apr 2015 13:36:44 -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 A8DA31A1A28 for ; Mon, 27 Apr 2015 13:36:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Ymplj-0006Q7-6r for ; Mon, 27 Apr 2015 22:36:43 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YmpjO-0004z6-Hn; Mon, 27 Apr 2015 22:34:18 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <87d232lkb6.fsf@alice.fifthhorseman.net> <87618qzlw0.fsf@vigenere.g10code.de> <1429922578.4659.49.camel@scientia.net> <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.de> <87pp6pczgq.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: Phillip Hallam-Baker , Daniel Ranft , Christoph Anton Mitterer , "openpgp\@ietf.org" Date: Mon, 27 Apr 2015 22:34:18 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 27 Apr 2015 13:58:08 -0400") Message-ID: <87wq0xb99x.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: Christoph Anton Mitterer , "openpgp@ietf.org" , Daniel Ranft Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 20:36:46 -0000 On Mon, 27 Apr 2015 19:58, phill@hallambaker.com said: >> work reliable for mass deployment. Thus for backing up and syncing >> private keys they use a letters and digits based code to seed a PRNG. > > I can't see the point of that. The point is that typing A3HT-378G-WE7Q-.... works more reliable than scanning QR codes. > Encrypt the private key(s) under a symmetric key, split the symmetric > key into as many shares as you need. Print out the key shares on paper Nobody talked about key splitting. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Apr 27 13:40: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 D14051A034C for ; Mon, 27 Apr 2015 13:40:23 -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 ZKGOWwWPmZ2S for ; Mon, 27 Apr 2015 13:40:21 -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 A296E1A032D for ; Mon, 27 Apr 2015 13:40:21 -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 81A4E5FB2C for ; Mon, 27 Apr 2015 20:40:20 +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 IeAsnX-okm9T for ; Mon, 27 Apr 2015 20:40:18 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 20:40:18 +0000 (UTC) Message-ID: <1430167217.658.2.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Mon, 27 Apr 2015 22:40:17 +0200 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-f+ZvExsN9c4Wb93HxogG" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 27 Apr 2015 20:40:24 -0000 --=-f+ZvExsN9c4Wb93HxogG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 14:10 -0400, Phillip Hallam-Baker wrote:=20 > I would like opinions on whether we should put a running checksum on > the fingerprint encoding or not. I'm a bit unsure about the use of this,... can you elaborate on the benefits you think are reached with that?! Isn't the FP already checksum enough by itself? Adding another checksum over the fingerprint shouldn't give more security, or does it (since if it would be so simple to forge similarly looking FPs that the user may type in by accident we'd have completely different problems)? I guess adding a checksum over the fingerprint will just tempt people to only verify that checksum. Cheers, Chris. --=-f+ZvExsN9c4Wb93HxogG 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzIwNDAx N1owTwYJKoZIhvcNAQkEMUIEQCJLC3FhXsTPPYy2A0tfPBDhyZMenlY0H/v3GVEyVchZmbQc026p XrhdMP0esg86al6u/Q5qZUhvxoAggK0qHxgwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCB/5PQBNvN5K2zikd4OUPxDOwA/ulW ScG8zVQ6MtkNhEUuWoQOZjjLOPKSLw8FlwkZwkjTO55Za7WSYMi22YlG+IrFCvG6JVp0xcNkCFsQ 0HhxB0m+SCLlzX4X8bHzxeiNFpJSTMmEUnL2dLXqWovJsH55ABPLfYBikjntaDpYwh0zK2h0dGey me8brmzw3t+RLOzDE9Zw33lv+7bZw59KF+eBvCgclxO4Xoh/j2+klNrXZySnKaP+gBw8m6/GJAvm ZB0+5uY2DhsKojI+3BlwXO8vVeacbWMqwfJPBsqlTm/meHQgMGJR4Ws54oNw7kLrmeGVxQWRdmW5 4/j59yKGAAAAAAAA --=-f+ZvExsN9c4Wb93HxogG-- From nobody Mon Apr 27 13:49: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 40B1B1A1ACA for ; Mon, 27 Apr 2015 13:49:23 -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 UjY1QBddxO_0 for ; Mon, 27 Apr 2015 13:49:22 -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 1D67F1A1A28 for ; Mon, 27 Apr 2015 13:49:22 -0700 (PDT) Received: by layy10 with SMTP id y10so89494836lay.0 for ; Mon, 27 Apr 2015 13:49:20 -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=Thgr5hCQqXCN7cUalALNmnAIfXAJq/lgEhP3fmujxlI=; b=Q0uB0JlGd28VVYweBru1FWHeuxZCpqkJT2wrECy+0kERxTRyMi3LygWV0tb0ddeeBV C3dHWH7NMoeWU81C7qsV8EXN/6mMjl4SA/xSAPBUmgcuEcbIGGQjw1af3S1+2NtV1F4C o7KDnf1yeYErLsFGLBGFWoIjh3u/Q1tGBP2fhAtnHAmDVQYZV3JyBkzdikH6g+pPkl/V 9gciLFyiNPhwTXd3AR12i0grZEiJ+xDSI4SCr/42jylcDrYIAVs+dh201wwy1eJjEfQy Cw0rIAjPvKsfGbBEJOwD73dR5WZXofpc94IY7YypDJRfyD9L/BibVF3EzArGwzLRGnRh l1+w== MIME-Version: 1.0 X-Received: by 10.112.180.137 with SMTP id do9mr4617156lbc.91.1430167760546; Mon, 27 Apr 2015 13:49:20 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 27 Apr 2015 13:49:20 -0700 (PDT) In-Reply-To: <1430167217.658.2.camel@scientia.net> References: <1430167217.658.2.camel@scientia.net> Date: Mon, 27 Apr 2015 16:49:20 -0400 X-Google-Sender-Auth: e6mnjANyUieXlzKz7G8h7tdO-AI 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] Fingerprint, Base32 or Base32C? 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, 27 Apr 2015 20:49:23 -0000 On Mon, Apr 27, 2015 at 4:40 PM, Christoph Anton Mitterer wrote: > On Mon, 2015-04-27 at 14:10 -0400, Phillip Hallam-Baker wrote: >> I would like opinions on whether we should put a running checksum on >> the fingerprint encoding or not. > I'm a bit unsure about the use of this,... can you elaborate on the > benefits you think are reached with that?! > > Isn't the FP already checksum enough by itself? > Adding another checksum over the fingerprint shouldn't give more > security, or does it (since if it would be so simple to forge similarly > looking FPs that the user may type in by accident we'd have completely > different problems)? > > I guess adding a checksum over the fingerprint will just tempt people to > only verify that checksum. The idea is that when someone is typing in the fingerprint, the client can perform a parity check to see if the fingerprint data is correct as the user is typing rather than waiting to the end. From nobody Mon Apr 27 13:57: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 199681A8A7F for ; Mon, 27 Apr 2015 13:57:50 -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 OMQZ35EC7mKD for ; Mon, 27 Apr 2015 13:57:42 -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 4E5F01A88FE for ; Mon, 27 Apr 2015 13:57:42 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so91982414lbb.2 for ; Mon, 27 Apr 2015 13:57:40 -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:content-type; bh=XlOF89a5S2fOt/WSjjPVwsyOctafo0Xp8Oiw97qD2TM=; b=VdEDvai/29ioVdJS+IatkC9lD8y25ELjtzUwG4PVF6w6iZpPATso7j0+oFy2jFvYUM vHOnjdQzLLNyqWqwaXwKIIhwNADTewnis9xHdEbBtgFYzsBWMwv+MPQH8BMMRQwwHSuC GDYjXiJ4d7/NVkL+K2Olquoi+vSKx+Id3wYFio4ionpzCHHuGRS8Hl18PfocC1d3/+uD 35g58N9sE+CEHMN5TeMo95FMebnN7yZyCqYKbFwLzIQ0rbc0E81XgaTKne0Zs5+sRUhI FQtscbF4xwe4jLm8G5T6h2+w+eIfAqd5YGuz2qkBilg6lx5m5+NOWU3682HnFIGPCrI/ tqgA== MIME-Version: 1.0 X-Received: by 10.152.45.97 with SMTP id l1mr11900979lam.55.1430168260866; Mon, 27 Apr 2015 13:57:40 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 27 Apr 2015 13:57:40 -0700 (PDT) In-Reply-To: <87wq0xb99x.fsf@vigenere.g10code.de> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <87618qzlw0.fsf@vigenere.g10code.de> <1429922578.4659.49.camel@scientia.net> <1DC3C8C67280FB4C9A402CB6DB1358F519E90A4A32@S2008SBS.intern.giepa.de> <87pp6pczgq.fsf@vigenere.g10code.de> <87wq0xb99x.fsf@vigenere.g10code.de> Date: Mon, 27 Apr 2015 16:57:40 -0400 X-Google-Sender-Auth: w2ceBoskp4eh1bHibntXNUu7Bmo Message-ID: From: Phillip Hallam-Baker To: Phillip Hallam-Baker , Daniel Ranft , Christoph Anton Mitterer , "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Fingerprints 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, 27 Apr 2015 20:57:50 -0000 On Mon, Apr 27, 2015 at 4:34 PM, Werner Koch wrote: > On Mon, 27 Apr 2015 19:58, phill@hallambaker.com said: > >>> work reliable for mass deployment. Thus for backing up and syncing >>> private keys they use a letters and digits based code to seed a PRNG. >> >> I can't see the point of that. > > The point is that typing > > A3HT-378G-WE7Q-.... > > works more reliable than scanning QR codes. > >> Encrypt the private key(s) under a symmetric key, split the symmetric >> key into as many shares as you need. Print out the key shares on paper > > Nobody talked about key splitting. It can be added to either. The difference between the approaches is as follows With generation from seed we take a secret s and then generate K(s) which requires the generation of the key to be completely standardized. With encryption of the private key we generate and dispose of a random number p and use it as a seed, generate K(p) and then archive an encrypted version under symmetric key s. I prefer the second reason because it can be applied to any public key algorithm and does not require a specific generation approach. Now admittedly when we get to ECC algorithms, generation is not exactly complicated. From nobody Mon Apr 27 14:12: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 3AA901A9136 for ; Mon, 27 Apr 2015 14:12:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 y1q1YTKjQcsp for ; Mon, 27 Apr 2015 14:12:15 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D57C1A8A4F for ; Mon, 27 Apr 2015 14:12:06 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-06v.sys.comcast.net with comcast id M9Bp1q004516pyw019C5TG; Mon, 27 Apr 2015 21:12:05 +0000 Received: from [IPv6:::1] ([71.202.164.227]) by resomta-po-08v.sys.comcast.net with comcast id M9C41q00J4uhcbK019C4Xc; Mon, 27 Apr 2015 21:12:05 +0000 Message-ID: <553EA624.5000903@brainhub.org> Date: Mon, 27 Apr 2015 14:12:04 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: David Gil , "openpgp@ietf.org" References: <1430147364.75064.YahooMailIosMobile@web310005.mail.ne1.yahoo.com> In-Reply-To: <1430147364.75064.YahooMailIosMobile@web310005.mail.ne1.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1430169125; bh=eOezEMO6+uYuKmCryiI5sO0ke3Vdx2p1DlrGz2tO8AA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BrQsbLgwGiwLTY2rlmet3L0iIDfEv2X1pENQFWMkXclyqqTfZCoOHm1JuI7119Yz2 po1XE8pAacD/VDfDsvjcqsFtCnFqvPapDcFL17/SPrhJnZh0Is1vlXuAc8HuF3FOI/ hChCOHXt0lyxSnrokRVIX0rA5sUKaG79JM6lBDTGIaXnJryWwSwqgOhTxRWvhGVKas hqUyR0TMh2UXmjRIfIBlRes7PJq/DIuMQLq5GVhIoNaSGbgvS51CnbReetlUqzfnQ1 hkHrRIc7Tvy/gc5thsw3RIoYMZknUs7WcoC5LiPEkhUFKSFtO4rpmePdaznD8/ao+l MKSVmEdZ4bOOw== Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 27 Apr 2015 21:12:17 -0000 On 04/27/2015 08:09 AM, David Gil wrote: > A hash function which is secure on short inputs may not be secure on > long inputs. This is, indeed, the case (generically) for the MD and > SHA-[12] functions: See papers by Schneier et al. inter alia. > I didn't look at the paper (which one?), but you are saying that if I have SHA-2 signed e-mail, I can concatenate the same message and achieve some "insecurity". As attacker can exploit this insecurity by e.g. prep-ending signed PGP/MIME messages. Most higher-level uses of OpenPGP will probably simply drop duplicated PGP/MIME parts or TAR files, etc. Not only the collision resistance is a more difficult problem (and thus is easier to exploit), the attacker knows the message and the output, which is not the case for S2K. My argument was that other parts of OpenPGP protocol will fail before S2K and we can count on the quick upgrade of the hash function. Of course, one can similarly come up with hypothetical insecurities in PBKDF2, e.g. how it cripples the sponge construction due to iterative nature of PBKDF2 and shrinking the sponge state to the hash output in each iteration... > > At Apr 24, 2015, 11:06:40 PM, Andrey Jivsov wrote: > On 04/24/2015 04:45 AM, Werner Koch wrote: > > On Fri, 24 Apr 2015 09:19, openpgp@brainhub.org > said: > > > >> 2. The Iterated S2K is essentially a > >> > >> M = M1 || M2 || M2 || M2 || ... || M2, where M1 includes the salt. > >> S2K = Hash( M ) > > Actually M2 also includes the salt: > > > > | Then the salt, followed by the passphrase data, is repeatedly > hashed > > | until the number of octets specified by the octet count has been > > | hashed. [...] > > > > > > > I stand corrected. > > My argument holds with even greater simplifications with the > following > adjustment: > > M = M1 || M1 || M1 || M1 || ... || M1, where M1 includes the salt. > S2K = Hash( M ) > > If we use the Hash() which is insecure in this setting, we should > expect troubles in other application of this hash function: e.g. > in digital signatures or MAC. > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Mon Apr 27 14:16: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 7412A1A802A for ; Mon, 27 Apr 2015 14:16:52 -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 vsK0qDvZZb5J for ; Mon, 27 Apr 2015 14:16:50 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::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 175B21A8029 for ; Mon, 27 Apr 2015 14:16:50 -0700 (PDT) Received: by vnbf1 with SMTP id f1so13768836vnb.5 for ; Mon, 27 Apr 2015 14:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=gjgusLUFJgHeVLeQq4d7fZofI9nAJDgQYaZOBg+tYXk=; b=duT+TeJyTOdxewTgoxEElcD/Jv12Rzu6KwlfLglbEhONBfk60PTMT9Amj4trQHewJ6 tORHPJxvqp20xo8fIq7v7NEALSbZJPURtt1j5or3s/FL37Xe2wQxMOPwUFtQ+H/aolTQ yqaI49GCv7hmkXKQxAQmUG91pV0rNFmKiTBLr/5vfxTYXtK9En6M3IWqz4dKTA2XmibB 8UBWi98/PQlXMEYSL3hifnp1nFi9tXvd5Xji1+FnaOtTI2VvWTAs+8kcbOcgjVwOn8Pr C+PAeG35pge+Q0Z/ZaMkepqtfYXHv5TQ0ij3YZnOUnQzFfJ9NXfdil0R/iHEE71QBYBr FUMQ== X-Received: by 10.52.3.10 with SMTP id 10mr30668614vdy.74.1430169409319; Mon, 27 Apr 2015 14:16:49 -0700 (PDT) Received: from hedwig-63.prd.orcali.com (ec2-54-85-253-19.compute-1.amazonaws.com. [54.85.253.19]) by mx.google.com with ESMTPSA id s2sm28330059vdh.8.2015.04.27.14.16.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 14:16:48 -0700 (PDT) Date: Mon, 27 Apr 2015 14:16:48 -0700 (PDT) X-Google-Original-Date: Mon, 27 Apr 2015 21:16:47 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1430169407969.d428cd64@Nodemailer> In-Reply-To: <553EA624.5000903@brainhub.org> References: <553EA624.5000903@brainhub.org> X-Orchestra-Oid: F2CF6C23-7C16-4D0F-8E07-84E35E04F850 X-Orchestra-Sig: 00e373cf1ca1b3d30d3b66fd092074cddb2fb245 X-Orchestra-Thrid: TA0A48A94-F93D-4145-9A0F-E0395A71098E_1498068760491294453 X-Orchestra-Thrid-Sig: dfc7a4662d0dceed1fba3c96af5f437ba2af36bd X-Orchestra-Account: 0447da8b00e2048dffc491a306dc57e8cce80212 From: "David Leon Gil" To: "Andrey Jivsov" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1430169408454" Archived-At: Cc: David Gil , openpgp@ietf.org Subject: Re: [openpgp] 4880bis: Update S2K 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, 27 Apr 2015 21:16:52 -0000 ------Nodemailer-0.5.0-?=_1-1430169408454 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am not advocating for the use of PBKDF2. It is not a particularly good = KDF, though it avoids the defects of S2K. There is one exception: At present, the WebCrypto API does not provide any = good password hash, so PBKDF2 may be the only option for some apps. Again: scrypt is widely used, BSD-licensed code in every language under the= sun is available. and it is much better than S2K. Is there some reason = *not to* use it=3F =E2=80=94 Sent using alpine: an Alternatively Licensed Program for Internet News and = Email On Mon, Apr 27, 2015 at 2:12 PM, Andrey Jivsov wrote: > On 04/27/2015 08:09 AM, David Gil wrote: >> A hash function which is secure on short inputs may not be secure on=20 >> long inputs. This is, indeed, the case (generically) for the MD and=20 >> SHA-[12] functions: See papers by Schneier et al. inter alia. >> > I didn't look at the paper (which one=3F), but you are saying that if = I=20 > have SHA-2 signed e-mail, I can concatenate the same message and = achieve=20 > some =22insecurity=22. As attacker can exploit this insecurity by e.g.= =20 > prep-ending signed PGP/MIME messages. Most higher-level uses of = OpenPGP=20 > will probably simply drop duplicated PGP/MIME parts or TAR files, etc.= =20 > Not only the collision resistance is a more difficult problem (and = thus=20 > is easier to exploit), the attacker knows the message and the output,=20 > which is not the case for S2K. > My argument was that other parts of OpenPGP protocol will fail before=20 > S2K and we can count on the quick upgrade of the hash function. > Of course, one can similarly come up with hypothetical insecurities = in=20 > PBKDF2, e.g. how it cripples the sponge construction due to iterative=20 > nature of PBKDF2 and shrinking the sponge state to the hash output in=20 > each iteration... >> >> At Apr 24, 2015, 11:06:40 PM, Andrey Jivsov wrote: >> On 04/24/2015 04:45 AM, Werner Koch wrote: >> > On Fri, 24 Apr 2015 09:19, openpgp@brainhub.org >> said: >> > >> >> 2. The Iterated S2K is essentially a >> >> >> >> M =3D M1 || M2 || M2 || M2 || ... || M2, where M1 includes the = salt. >> >> S2K =3D Hash( M ) >> > Actually M2 also includes the salt: >> > >> > | Then the salt, followed by the passphrase data, is repeatedly >> hashed >> > | until the number of octets specified by the octet count has = been >> > | hashed. [...] >> > >> > >> > >> I stand corrected. >> >> My argument holds with even greater simplifications with the >> following >> adjustment: >> >> M =3D M1 || M1 || M1 || M1 || ... || M1, where M1 includes the salt.= >> S2K =3D Hash( M ) >> >> If we use the Hash() which is insecure in this setting, we should >> expect troubles in other application of this hash function: e.g. >> in digital signatures or MAC. >> >> >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp ------Nodemailer-0.5.0-?=_1-1430169408454 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am not advocating for the use of PBKDF2. It is not a particularly = good KDF, though it avoids the defects of S2K.

There is one exception: At present, the WebCrypto API does not provide= any good password hash, so PBKDF2 may be the only option for some apps.=

Again: scrypt is widely used, BSD-licensed code in every language = under the sun is available. and it is much better than S2K. Is there some = reason *not to* use it=3F

=E2=80=94
Sent using alpine: an Alternatively Licensed Program for = Internet News and Email


On Mon, Apr 27, 2015 at 2:12 PM= , Andrey Jivsov <openpgp@brainhub.org> = wrote:

On 04/27/2015 = 08:09 AM, David Gil wrote:
> A hash function which is secure on short inputs may not be secure = on=20
> long inputs. This is, indeed, the case (generically) for the MD = and=20
> SHA-[12] functions: See papers by Schneier et al. inter alia.
>

I didn't look at the paper (which one=3F), but you are saying that = if I=20
have SHA-2 signed e-mail, I can concatenate the same message and = achieve=20
some =22insecurity=22. As attacker can exploit this insecurity by e.g.= =20
prep-ending signed PGP/MIME messages. Most higher-level uses of = OpenPGP=20
will probably simply drop duplicated PGP/MIME parts or TAR files, etc.= =20
Not only the collision resistance is a more difficult problem (and = thus=20
is easier to exploit), the attacker knows the message and the output,= =20
which is not the case for S2K.

My argument was that other parts of OpenPGP protocol will fail = before=20
S2K and we can count on the quick upgrade of the hash function.

Of course, one can similarly come up with hypothetical insecurities= in=20
PBKDF2, e.g. how it cripples the sponge construction due to = iterative=20
nature of PBKDF2 and shrinking the sponge state to the hash output = in=20
each iteration...

>
> At Apr 24, 2015, 11:06:40 PM, Andrey Jivsov wrote:
> On 04/24/2015 04:45 AM, Werner Koch wrote:
> > On Fri, 24 Apr 2015 09:19, openpgp@brainhub.org
> <javascript:return> said:
> >
> >> 2. The Iterated S2K is essentially a
> >>
> >> M =3D M1 || M2 || M2 || M2 || ... || M2, where M1 = includes the salt.
> >> S2K =3D Hash( M )
> > Actually M2 also includes the salt:
> >
> > | Then the salt, followed by the passphrase data, is = repeatedly
> hashed
> > | until the number of octets specified by the octet count= has been
> > | hashed. [...]
> >
> >
> >
> I stand corrected.
>
> My argument holds with even greater simplifications with the
> following
> adjustment:
>
> M =3D M1 || M1 || M1 || M1 || ... || M1, where M1 includes the= salt.
> S2K =3D Hash( M )
>
> If we use the Hash() which is insecure in this setting, we = should
> expect troubles in other application of this hash function: e.= g.
> in digital signatures or MAC.
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> openpgp mailing list
> openpgp@ietf.org <javascript:return>
> https://www.ietf.org/mailman/listinfo/openpgp
>

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


------Nodemailer-0.5.0-?=_1-1430169408454-- From nobody Mon Apr 27 15: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 1F2561A8F4E for ; Mon, 27 Apr 2015 15:01:00 -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 EWZEHxet-wA6 for ; Mon, 27 Apr 2015 15:00:55 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 97C521A88A3 for ; Mon, 27 Apr 2015 15:00:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id D763E718A719; Mon, 27 Apr 2015 15:00:54 -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 p0zWS7ss2Doa; Mon, 27 Apr 2015 15:00:45 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 3F781718A6FE; Mon, 27 Apr 2015 15:00:45 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Apr 2015 15:00:45 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Apr 2015 15:00:45 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 27 Apr 2015 15:00:41 -0700 Message-Id: <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas Subject: Re: [openpgp] 4880bis: Update S2K 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, 27 Apr 2015 22:01:00 -0000 > On Apr 25, 2015, at 11:07 AM, Peter Gutmann = wrote: >=20 > Jon Callas writes: >=20 >> I would love to see PBKDF2 in there on the list of things acceptable. >=20 ... > So all that a future PGP RFC needs to do is > leave a hole to slot in the PHC winner. Yeah. But we should have PBKDF2, as well -- or perhaps more completely = PBKDF2-HMAC-, since PBKDF2 is a wrapper around any PRF. = PBKDF2 is the devil you know. It behaves in completely reasonable, = completely understood ways. And it doesn't have the wackiness of the = present S2K. Jon From nobody Mon Apr 27 15:20: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 2D0A21A9136 for ; Mon, 27 Apr 2015 15:20: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 TDApx3vduUMw for ; Mon, 27 Apr 2015 15:20:18 -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 C60001A9111 for ; Mon, 27 Apr 2015 15:20: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 mailgw01.dd24.net (Postfix) with ESMTP id A5D205FACC for ; Mon, 27 Apr 2015 22:20:16 +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 MoVzc07MTIdv for ; Mon, 27 Apr 2015 22:20:14 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 27 Apr 2015 22:20:14 +0000 (UTC) Message-ID: <1430173213.658.6.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Tue, 28 Apr 2015 00:20:13 +0200 In-Reply-To: References: <1430167217.658.2.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-gF9KLsjh7DQWYskGBE/G" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 27 Apr 2015 22:20:19 -0000 --=-gF9KLsjh7DQWYskGBE/G Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 16:49 -0400, Phillip Hallam-Baker wrote:=20 > The idea is that when someone is typing in the fingerprint, the client > can perform a parity check to see if the fingerprint data is correct > as the user is typing rather than waiting to the end. Okay, I see... Well I have no strong opinion against it, but as I've said before,... it seems like "fingerprinting the fingerprint" and I guess it tempts people to check even less carefully - on the other hand, you never can prevent people from doing stupid things, so if someone really just compares the checksum, then it's IMHO his fault, and not the existence of the checksum. Cheers, Chris. --=-gF9KLsjh7DQWYskGBE/G 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzIyMjAx M1owTwYJKoZIhvcNAQkEMUIEQL6SuayiyOw7sXTtUgbSUZa2wZpbpC6eEqu8i8ui4tKTp21MStb3 zm0bIcQ/OTDz8Q4ez2LEPG97Xpikn/hMY44wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCZvy53lnmd5+syUaNPoRZzJxSApsjy +oFiDjvf3N937xow296JdYPmafl4Y+S3bEoWoNp5depufLgRvNTswdfwt9sFodna/IdEdi7GHnRR 5nZRNR9DQSsujAvgz9AcXmbg1F6o/fUe6Kj/j5Rriw5LEp247KRH7PRZ48FPivBYdQ1WEpktWj/a uplFGKqN18j7LKLAX8rI8tI3BqMDx5i0vgARf6aQ/i5QnwAQN7F9zTQuMkizffICDKRXmebUfO9D qH+0jvxIzNx5vCQdUW9KCBXUTNNlK1nEpPdiBXS5Rz8Iy+UplplzKNZsfS4BN5U6N3VzlAhfMRcy CLu2IPZJAAAAAAAA --=-gF9KLsjh7DQWYskGBE/G-- From nobody Mon Apr 27 15:29: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 CE6701ABD35 for ; Mon, 27 Apr 2015 15:29: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 6jpkKqYmhPiI for ; Mon, 27 Apr 2015 15:29:18 -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 408BE1A9252 for ; Mon, 27 Apr 2015 15:29:18 -0700 (PDT) Received: by wiun10 with SMTP id n10so7564863wiu.1 for ; Mon, 27 Apr 2015 15:29:17 -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=xZ7q+ISivDzrIX2rcnSde/PX3MTJhvEag1ey6Wm7ajI=; b=wkzL5ri/c7RHwiOZAmN7k1GZJXLfI1+/vmgyiDz3rZcpnozSL4L2fmiZkXA39ATaz5 ARRXK745Td3qCqezUnhF55aZuo8rGAQk6SirRfCayOZ6O21UvVRwUWIcJVwUlaLVTeEs RF+YRpObYrudiF3hYBaBM6vSleOVY6z0OoIZBdYrQDStEJLdX05ajNaZZYSnbf34w6pn 01C15ahFi9dcwdRCp7NpSqR1SFUXGLoAqSh3PeiP4V+PGpcBCqOuP/HOnEJ3PdwxMY2i 5efYJrZRzw8DmwJUnyNJ3YAryX1SLF984JrZIIce5n7xi6uDBiaa0jbe9gUbGPUX1P6z HYdA== MIME-Version: 1.0 X-Received: by 10.180.98.195 with SMTP id ek3mr24470372wib.57.1430173757068; Mon, 27 Apr 2015 15:29:17 -0700 (PDT) Received: by 10.194.162.35 with HTTP; Mon, 27 Apr 2015 15:29:16 -0700 (PDT) In-Reply-To: <874mo1egir.fsf@vigenere.g10code.de> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> <874mo1egir.fsf@vigenere.g10code.de> Date: Mon, 27 Apr 2015 23:29:16 +0100 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 22:29:20 -0000 On Mon, Apr 27, 2015 at 4:29 PM, Werner Koch wrote: > FWIW: I have no real preference pro or contra a hard expiration time. I have not seen anyone in favour of a hard expiration time explain what it is designed to prevent / enable. I think the new standard should have a real prejudice in favour of excluding anything unless there is a clear justification. It could be that I've just missed something, but I don't think that standard has been reached here yet. What does a hard expiration time technically achieve that a soft expiration time does not. If the answer is encouraging the user to behave in a particular way, that should be enforced / encouraged through other means. I see no security advantage at all. As I say, I may be missing something. From nobody Mon Apr 27 15:43: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 9CB601ACCED for ; Mon, 27 Apr 2015 15:43:37 -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 4-Q6Y86e9K6C for ; Mon, 27 Apr 2015 15:43:36 -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 0CE671ACD0D for ; Mon, 27 Apr 2015 15:43:36 -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 9AC185FAD1; Mon, 27 Apr 2015 22:43:34 +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 l3LMMgrA7gBx; Mon, 27 Apr 2015 22:43:32 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA; Mon, 27 Apr 2015 22:43:32 +0000 (UTC) Message-ID: <1430174611.658.8.camel@scientia.net> From: Christoph Anton Mitterer To: Nicholas Cole Date: Tue, 28 Apr 2015 00:43:31 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> <874mo1egir.fsf@vigenere.g10code.de> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-o6tR+KiIyHwzL9ph8969" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 27 Apr 2015 22:43:37 -0000 --=-o6tR+KiIyHwzL9ph8969 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 23:29 +0100, Nicholas Cole wrote:=20 > What does a hard expiration time technically achieve that a soft > expiration time does not. This has been explained now several times, by several people. --=-o6tR+KiIyHwzL9ph8969 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyNzIyNDMz MVowTwYJKoZIhvcNAQkEMUIEQBLY+7X+3qTYUTUPk2lLw9FQj41Pyqzyydq8mna95YA5+r+lurfO PECXXX1lO3uET2En+aqssfRKDukZY1aiy9MwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQB2ubbQvcyMOmzG8Id56w2p74Sxf3s8 PxjdizlXcVb77zFLdNCDhn6aZOuicLI/8Qvu65rNqfncQOfo1RsKpB3LvSg8Wpn5Mopnuk0XdWOz 6K7MdWniEqCKJr8FaqfbCqHx2QYfm7SsED8B1yjFF0JWfCOg5YyuBzpNW787e7aHb6szLX2yxWQu ZsP5XCYrfy432Q6RVrKkTAgyFVt4shpZaZw/iZd+5jpNU4x30Aj3e2a1DMPyHT+aJo8FNZxv8xbS IvsntdsrtVzFrfmMhHye476jqP9mu4FYbHreYDNHxEtKYWNdmJduAv+h3RD0WCt783W6MPY9/ePJ 7H1HuyGcAAAAAAAA --=-o6tR+KiIyHwzL9ph8969-- From nobody Mon Apr 27 17:43: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 7621E1ACDC5 for ; Mon, 27 Apr 2015 17:43:30 -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 PrOQp0tfIcJy for ; Mon, 27 Apr 2015 17:43:29 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id F112E1ACDC4 for ; Mon, 27 Apr 2015 17:43:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 8AA0A718DA5C; Mon, 27 Apr 2015 17:43:26 -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 9tYoCiiQNjgi; Mon, 27 Apr 2015 17:43:16 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id C4FE8718DA34; Mon, 27 Apr 2015 17:43:16 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Apr 2015 17:43:16 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Apr 2015 17:43:16 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: Date: Mon, 27 Apr 2015 17:43:13 -0700 Message-Id: <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> To: Derek Atkins X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 28 Apr 2015 00:43:30 -0000 >> I read your explanation. I understand it. I just disagree. >>=20 >> I think that hard-expiration is not only a bad idea, but = unenforceable. >=20 > It was enforceable with V3 keys. It is, as Christoph pointed out, no > longer enforceable with V4 keys because it was moved out of the Public > Key Packet and into the SelfSig. :-( I'm well aware of this, Derek. I'm saying that hard expiration is in my = opinion not only impossible even with V3 keys (just rewrite everything), = but a bad idea. >=20 >> It's a *good* thing for Alice to be able to update the expiration = time >> on her key. It encourages putting a limit on (as opposed to no limit) >> if it can be changed later. It also allows advanced systems to be = able >> to do some really cool things with short lived keys. >=20 > This is a reason for SelfSigs to expire. However if the key itself is > stolen/compromised the attacker could then create an updated SelfSig > with an updated expiration. >=20 > If the key itself had an expiration (as it did in v3) then this attack > wouldn't work. But then it also means Alice would *have* to generate = a > new key after the old key expired. (Or, worst case, Alice would have = to > regenerate a new Certificate using the same key parameters and then > obtain all those signatures again). Yeah, and I'm saying that think the current behavior is a good thing, = all in all. Gentlepersons can disagree on this, I'm just giving my = opinion. Jon From nobody Mon Apr 27 18:34: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 985F61ACDFB for ; Mon, 27 Apr 2015 18:34:52 -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 j6VZjPFCAbmW for ; Mon, 27 Apr 2015 18:34:50 -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 8BC701ACDF7 for ; Mon, 27 Apr 2015 18:34:50 -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 180F05FB36; Tue, 28 Apr 2015 01:34:49 +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 96GbdahYPo5V; Tue, 28 Apr 2015 01:34:47 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 28 Apr 2015 01:34:47 +0000 (UTC) Message-ID: <1430184885.658.10.camel@scientia.net> From: Christoph Anton Mitterer To: Jon Callas Date: Tue, 28 Apr 2015 03:34:45 +0200 In-Reply-To: <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-aB2jgg/vLKhv4FXo9etA" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 28 Apr 2015 01:34:52 -0000 --=-aB2jgg/vLKhv4FXo9etA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-27 at 17:43 -0700, Jon Callas wrote: > I'm saying that hard expiration is in my opinion not only impossible > even with V3 keys (just rewrite everything), but a bad idea. Can you please explain both? While the later may be a matter of taste, I can quite see why it shouldn't be possible. If the expiration date is part of the key, the FP and other signatures should change / become invalid as soon as anyone tries to change the time.=20 Cheers, Chris. --=-aB2jgg/vLKhv4FXo9etA 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyODAxMzQ0 NVowTwYJKoZIhvcNAQkEMUIEQMxZPzwIgvGiGUwlWbIuU23+ja75LJz7JLJv5DH2sa/TcabV1Ete 7fQu9ZNy0IFsyKLNkTjs9t72oAQ+qCxYBgcwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDZHvBDRARLlfP4a5k7cJsG2sjK+qpI IM70aLM3m4BWibtskjQp2z9yKiYAaVKbgMDx+UcrozFN8G4GbT2nepazL/Zi3hhzK9HmzrSnTbZ7 0GSBUrKyR54+rVhJIbJpLD0s5gCqY7Pus9oShrHsH/Hn1eygRdFgbEGLI0TEw7CepxBXDFbBHxuy zidNV5PveaLTul5DzTORUK4tRXIh3cG0DnLwZxYqSNAbetzf2AF3ySVLxcYe/3dPSSN0mDrjmk9y uPamXQwryJVUfORDD/ujfb3fCRqLMJBUuXnQ3Q2xYk0bfD/aARPozICeMlPo8S7ZHgKfcQgX41wU Ikj4NOL9AAAAAAAA --=-aB2jgg/vLKhv4FXo9etA-- From nobody Mon Apr 27 19:47: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 709761ACE29 for ; Mon, 27 Apr 2015 19:47:07 -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 Kq2LleQJpUsW for ; Mon, 27 Apr 2015 19:47:04 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 7B0B61ACE27 for ; Mon, 27 Apr 2015 19:47:04 -0700 (PDT) Received: by wgyo15 with SMTP id o15so135620979wgy.2 for ; Mon, 27 Apr 2015 19:47:03 -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=xe9Bc0DvSi4UBO3Zb2LtTG6lmZoy4gLRCVvsuJ0sCug=; b=1oxnuMUhro4kxclAPkLqDVpRl0w/EhLAo9cLG9XZKssRfZH8hmRed4qtwkvG0dpTZS i0rRK7xFwd2OvBpYFoBd8vPMB4qKx+KRaTSPesKD6m2lah6tt98baUPb/6Whyl2y1OOZ 9ISjix+wOa/TdXIYilhiDjB+rmCxJRbQqa0Tg= 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=xe9Bc0DvSi4UBO3Zb2LtTG6lmZoy4gLRCVvsuJ0sCug=; b=YfeS8sceeNUIQhxxCe5x6A22zZQYRHxNVu328rDzQUllIVAYL/RhCjy29b0vdPpE52 h2a79vqiRbU8HOVSf2ig7LAw/Nl0mzHMphaouhmUEEUVeQeUYXGsid3+shGXBjF2cq8l j+j7QEwZmvf/CIF6l39svIMySPcVCBOOLnU9kLvdJLKMtZJZS1F+RzluoZyEKuH54jtO EYjvt5C624cVwS/sPjZZdXgd1Zy3nZo1wlp9ZV2zcsDYVQo2H4RUj8QpB2HTWdHW4QEC K8Q/SWVW2bm0tg2P8KM5FUbv8EDR0ZjUBRrJjb3gzuUTzg0EJxVLjWiNNdI5vRbVRDuJ wXNA== X-Gm-Message-State: ALoCoQn6YWPealyGHDsKrkeNpVzgIcoRbuNdGzyvZwt4BWLWDKEquthKyoI58ewvytMdlH4QxY16 X-Received: by 10.194.185.229 with SMTP id ff5mr27600261wjc.30.1430189223207; Mon, 27 Apr 2015 19:47:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.80 with HTTP; Mon, 27 Apr 2015 19:46:41 -0700 (PDT) In-Reply-To: References: <1430167217.658.2.camel@scientia.net> From: Tom Ritter Date: Mon, 27 Apr 2015 21:46:41 -0500 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 02:47:07 -0000 On 27 April 2015 at 15:49, Phillip Hallam-Baker wrote: > The idea is that when someone is typing in the fingerprint, the client > can perform a parity check to see if the fingerprint data is correct > as the user is typing rather than waiting to the end. This is getting pretty far into usability. Which I don't think is bad, but it's just a bunch of assumptions that weren't unpacked right away, and ignores alternatives. There are lots of ways to compare fingerprints, some of which will not work in the situation at hand. Goals of any fingerprint comparison mechanism should be to reduce the level of effort required by the user, and reduce the sharp edges of failure situations. Some (most?) of the situations one will encounter: a) Comparing two fingerprints that are on the same desktop computer b) Comparing two fingerprints that are on the same mobile device c) Comparing a fingerprint between a desktop and mobile (in either direction) d) Comparing a fingerprint between a desktop and paper e) Comparing a fingerprint between a mobile device and paper (Technically, I really mean 'desktop' to mean 'any computer without a webcam' and mobile device to mean 'any computer with a camera'. So replace 'mobile' with 'laptop' in many instances.) I think QR codes are excellent comparison mechanisms. Look at situations (c) and (e). Desktop (or paper) displays a QR code, Mobile reads the QR code and says 'They match!' What's a less user-effort level and less error-prone mechanism? For situation (a), I would say the answer should be 'copy-and-paste'. I envision a key verification UI as saying (below the displayed QR code) a text box with a label "Or paste the fingerprint beginnging with WXYZ here:". You paste it, if it matches, you're set. For (b).... mobile copy and paste sucks. Fortunately, I'm struggling to come up with a feasible situation where you have a verified fingerprint in one mobile app and you need to get it to a second. It's more likely you have a public key 'pointer' (something that would get you a public key, like a url or fingerprint in an email signature) and you want to use it to get (not verify) a key. And for (d), you have that awkward "Hold the card up to the screen and try and compare them by shifting your eyes up and down". Typing *may* be less error-prone. If it had a running checksum it probably would be. But asking users to type things in feels like it would be really jarring in a user's workflow. -tom From nobody Tue Apr 28 00:06: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 4B3131A07BD for ; Tue, 28 Apr 2015 00:06:46 -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 lK-n42qZztRG for ; Tue, 28 Apr 2015 00:06:44 -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 773CB1A064C for ; Tue, 28 Apr 2015 00:06:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YmzbO-0000jA-Ss for ; Tue, 28 Apr 2015 09:06:42 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YmzWd-0006jT-2O; Tue, 28 Apr 2015 09:01:47 +0200 From: Werner Koch To: Jon Callas References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Jon Callas , Peter Gutmann , Nils Durner , "alessandro.barenghi\@polimi.it" , "openpgp\@ietf.org" Date: Tue, 28 Apr 2015 09:01:46 +0200 In-Reply-To: <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> (Jon Callas's message of "Mon, 27 Apr 2015 15:00:41 -0700") Message-ID: <87mw1sbusl.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: Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 28 Apr 2015 07:06:46 -0000 On Tue, 28 Apr 2015 00:00, jon@callas.org said: > Yeah. But we should have PBKDF2, as well -- or perhaps more completely > PBKDF2-HMAC-, since PBKDF2 is a wrapper around any > PRF. PBKDF2 is the devil you know. It behaves in completely You may be right on this. However, for backward compatibility it is anyway required to implement S2K. Thus I consider it better to wait for the outcome of the PHC and make one of winners the MUST algorithm while keeping S2K-3 as a MAY algorithm for backward compatibility (symmetrically encrypted messages). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 28 04:16: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 E11D21A886E for ; Tue, 28 Apr 2015 04:16:12 -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 jqPVyeLu9rC1 for ; Tue, 28 Apr 2015 04:16:11 -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 7C3251A885E for ; Tue, 28 Apr 2015 04:16:11 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id EB7A16D775; Tue, 28 Apr 2015 07:16:09 -0400 (EDT) Message-ID: <553F6BF8.2080501@iang.org> Date: Tue, 28 Apr 2015 12:16:08 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87d232lkb6.fsf@alice.fifthhorseman.net> In-Reply-To: <87d232lkb6.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 28 Apr 2015 11:16:13 -0000 On 17/04/2015 18:46 pm, Daniel Kahn Gillmor wrote: > * human-representable form of the digest: e.g. hex, base32, common > hyphenation patterns, etc. there are legibility/usability factors > here that i don't know enough to comment on. Just on that, I recently went through an exercise where phones get introduced to phones. Once introduced the phones can speak to servers directly naming their new friends and get high quality information in dense cryptographic form. Users need not be bothered by the arcania. But two people meeting for the first time is a bother, especially as there are no presentations of cryptographic information in the app at all, and we can't rely on the various bluetooth and so forth local interactions. We tried some variants, and in the end, I settled on a 4-letter base26. It is created on one phone (register on server) and typed into the other phone (lookup on server). The base26 alpha was chosen because many phones have tiny keyboards which require hitting a meta key to get out to numerics. This made the Base32, hex and other mixed alphanumerics a pain, it about doubled the workload and more than doubled the error rate. A count of 4 characters was settled on because it was enough to provide some discrimination but not enough to seriously challenge the users. Users found 6 characters to be a bit testy (I include myself in this) whereas people felt that if they couldn't handle 4 characters felt they could blame themselves for the errors not the system. iang ps; The codes themselves once created are only valid for an hour, suitable for a face to face meeting, so there is a lot more space available. ps2; 4 uppercase letters was also used by the military back in the old pencil & paper tactical codes days. At least my military. From nobody Tue Apr 28 04:39: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 94BE01A89FA for ; Tue, 28 Apr 2015 04:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 p0Gziek2tlaT for ; Tue, 28 Apr 2015 04:39:01 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (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 D5DA81A89F2 for ; Tue, 28 Apr 2015 04:38:55 -0700 (PDT) Received: by wgyo15 with SMTP id o15so148009751wgy.2 for ; Tue, 28 Apr 2015 04:38:54 -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=GIr/ONgeiH5DMwBykKgg399l3WyH6ba70AZsf2jLLGE=; b=FtUyigVkJYDuWZxTa/lia8oWe4KKygePqlihUYiKNir4xVh7c3fGAvbaOku871fRyb wdA5t3jaYttccaoV7KmmNrwWkVzCxGIBtk7WJLi2uSjFa5SBylVsYea8Ymusppy5Nrvl kcG70sV3rKgQmxPPJSn0P1t1rzS4Zhdj8PXvEQK5nJKltrdquHO5beHu2icknpgYJIEX 9qQQQDYboDXaMXIAihTSxkB7FPLKAdbZwdfMJZhDtxZParL0e/fdg9ZBi8FaF06H96CF QctMvGIEruARYwlkAcgauNwzPclI59D8rMqkyJaX+DHO2W2KiuoO5xfe5LkGvub26Ri9 RUiA== X-Gm-Message-State: ALoCoQmd+rArkKDtmPXlMCZUqSxWAJLZA+1J+tgvMyKt9So4bg0bxXFYm5r/e13MqU9vfhVJfOTr X-Received: by 10.194.79.226 with SMTP id m2mr31224390wjx.60.1430221134582; Tue, 28 Apr 2015 04:38:54 -0700 (PDT) Received: from [192.168.120.139] ([157.181.227.17]) by mx.google.com with ESMTPSA id n8sm15973439wiy.19.2015.04.28.04.38.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 04:38:53 -0700 (PDT) Message-ID: <553F7149.6000706@epointsystem.org> Date: Tue, 28 Apr 2015 13:38:49 +0200 From: "Daniel A. Nagy" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87d232lkb6.fsf@alice.fifthhorseman.net> <553F6BF8.2080501@iang.org> In-Reply-To: <553F6BF8.2080501@iang.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprints 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, 28 Apr 2015 11:39:02 -0000 Speaking of that, we may want to specify a URL format for the fingerprint which would facilitate the importing or checking of keys through the intent mechanism (it has a different name in iOS, but it's there). That way, QR codes would also become quite straightforward. Cheers, Daniel On 04/28/2015 01:16 PM, ianG wrote: > On 17/04/2015 18:46 pm, Daniel Kahn Gillmor wrote: > >> * human-representable form of the digest: e.g. hex, base32, common >> hyphenation patterns, etc. there are legibility/usability factors >> here that i don't know enough to comment on. > > > > > Just on that, I recently went through an exercise where phones get > introduced to phones. Once introduced the phones can speak to servers > directly naming their new friends and get high quality information in > dense cryptographic form. Users need not be bothered by the arcania. > > But two people meeting for the first time is a bother, especially as > there are no presentations of cryptographic information in the app at > all, and we can't rely on the various bluetooth and so forth local > interactions. > > We tried some variants, and in the end, I settled on a 4-letter base26. > It is created on one phone (register on server) and typed into the > other phone (lookup on server). > > The base26 alpha was chosen because many phones have tiny keyboards > which require hitting a meta key to get out to numerics. This made the > Base32, hex and other mixed alphanumerics a pain, it about doubled the > workload and more than doubled the error rate. > > A count of 4 characters was settled on because it was enough to provide > some discrimination but not enough to seriously challenge the users. > Users found 6 characters to be a bit testy (I include myself in this) > whereas people felt that if they couldn't handle 4 characters felt they > could blame themselves for the errors not the system. > > > > iang > > > ps; The codes themselves once created are only valid for an hour, > suitable for a face to face meeting, so there is a lot more space > available. > > ps2; 4 uppercase letters was also used by the military back in the old > pencil & paper tactical codes days. At least my military. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Tue Apr 28 04:51: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 58EA11A8A1E for ; Tue, 28 Apr 2015 04:51:26 -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 lJDzJQRK93jU for ; Tue, 28 Apr 2015 04:51:22 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBCD1A8A93 for ; Tue, 28 Apr 2015 04:51:22 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id C648D6D735; Tue, 28 Apr 2015 07:51:20 -0400 (EDT) Message-ID: <553F7437.5080804@iang.org> Date: Tue, 28 Apr 2015 12:51:19 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <33FA9189-595F-459D-9695-B941787FCB1A@callas.org> In-Reply-To: <33FA9189-595F-459D-9695-B941787FCB1A@callas.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Key Usage, Designated Revocation 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, 28 Apr 2015 11:51:26 -0000 Just to echo what Jon said... On 24/04/2015 20:42 pm, Jon Callas wrote: > (Pulled into a new subject.) > >> Can someone explain why key usage and preference flags for the primary >> were made part of user id signatures instead of a direct key signature >> or something of the sort? I felt like this added a lot of complexity >> and non-determinism to those parts of the implementation which dealt >> with that. > > Because you want the key owner to issue a signed statement that says "this is how I want you to use my key" and you want that to be part of the self-signature that says "I own this key." You don't want a separate signature, because you don't want them to be torn apart. This is getting into the nature of what a real WoT looks like. In normal human conversational semantics, a statement is meaningless unless it is backed by whosoever said it, and what foundation we've got to believe (rely on) that statement. Unless we can mirror those human lines of trust, the system is approximately worthless for a real WoT. This of course assumes that the goal is a WoT. There may be of course other practical reasons for doing things such as having the key usage & flags in the inner signed key package. Which is to say, it's important to frame the question with the goals... and some of us hold out hope for building a real WoT one day. >> Secondly, (this came up somewhere else), I'm not convinced at all that >> designated revokers (5.2.3.15) are a good idea. Is there a significant >> advantage over just handing the person a revocation certificate of your >> key? I remember deciding against implementing this feature at some point >> in OpenKeychain because the complexity/benefit tradeoff just wasn't >> there. > > Let's face it. Revocation is not as good as people think it is. In the general case it cannot work. There are specific cases where it can work, but you must always account for the case that there is revocation information, you're just not getting it.... That's a pretty good statement. Revocation as an algorithm is too unreliable to be relied upon, and we now have scientific proof of that [0]. What is the role of a cryptographically unreliable algorithm in our thinking? Normally we run a mile from such things, why do we pander to it this time? iang [0] By that I mean, back in the 2000s, CA/PKI's revocation was predicted to not be reliable enough to work well enough to be worth the effort, and when subCAs started failing a few years back, the browser vendors found it necessary to start shipping new browser distros with hard-coded revocation lists in them. In essence, we are seeing the über-CAs move to doing dynamic revocation within the browsers, but they don't call it that, nor do they admit that they are CAs. From nobody Tue Apr 28 05:01: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 C19721A8AA5 for ; Tue, 28 Apr 2015 05:01:31 -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 ydCEdJRbsX1b for ; Tue, 28 Apr 2015 05:01:31 -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 904E71A8A98 for ; Tue, 28 Apr 2015 05:01:30 -0700 (PDT) Received: by laat2 with SMTP id t2so102392503laa.1 for ; Tue, 28 Apr 2015 05:01:29 -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=Kf12w/VybP2khA8Hn2befu839ptQkkzDaYYxCawPjhA=; b=wSt3wOPwTT7/kOraNxHFHa3vnRqDa1CHrH1B+Wun7ZvK6d9p/34NbbU7XsL+mjiYrH 4TX/yx2ppW1JBIoRGN0GZGFpjBdNnmdEuXEDMZSuJeyFO6D9F5KrjPrW/laF59by9832 sw85V3WCRz/ajZeH0JLBsLnZ9WSMbXGuPF/EMihrQNn4pjuPKDuaaNifVbAO3iUDxAtL gFC/On4SMc7mgageB4cKerFv5p2NL34WXswkk0Jdvz7Q8pKw/dGjJJDktil9sylaNtKl eXk096GlDO4Nr/ejvGNinvY67zY3tDs4KOWp7DG3sqe5RrlfxOmGACaWHOpvyHlIe1ht srCA== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr14318051lbc.79.1430222489046; Tue, 28 Apr 2015 05:01:29 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 05:01:28 -0700 (PDT) In-Reply-To: <553F7149.6000706@epointsystem.org> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <553F6BF8.2080501@iang.org> <553F7149.6000706@epointsystem.org> Date: Tue, 28 Apr 2015 08:01:28 -0400 X-Google-Sender-Auth: gsueUQ6N3k-0lWrcR0JcLaOknlo Message-ID: From: Phillip Hallam-Baker To: "Daniel A. Nagy" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprints 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, 28 Apr 2015 12:01:31 -0000 On Tue, Apr 28, 2015 at 7:38 AM, Daniel A. Nagy wrote: > Speaking of that, we may want to specify a URL format for the > fingerprint which would facilitate the importing or checking of keys > through the intent mechanism (it has a different name in iOS, but it's > there). That way, QR codes would also become quite straightforward. Definitely. Which is why I want to have a format that means we only need to go through this once... From nobody Tue Apr 28 05:15: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 963B31A8AD3 for ; Tue, 28 Apr 2015 05:15:50 -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 eLuglE6WPPwX for ; Tue, 28 Apr 2015 05:15:49 -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 7D03F1A8AB3 for ; Tue, 28 Apr 2015 05:15:49 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 40CF66D781; Tue, 28 Apr 2015 08:15:48 -0400 (EDT) Message-ID: <553F79F2.90803@iang.org> Date: Tue, 28 Apr 2015 13:15:46 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 28 Apr 2015 12:15:50 -0000 On 24/04/2015 20:03 pm, Jon Callas wrote: > >> On Apr 20, 2015, at 9:53 AM, Phillip Hallam-Baker wrote: >> >> >> What we need is the PKI equivalent of structured programming. PKIX is >> Pascal. PGP is BASIC. Yes, you can do anything with IF-THEN-GOTO. But >> you probably should not try. > > If only there were a way to do that. > > Let's consider a machine that has a set of simple operations that it can do, like IF-GOTO and another language that did more complex things like IF-THEN-ELSE. If we could make something that could take the complex language and translate it into a set of the simpler statements reliably, then perhaps we could solve that problem. Right. As an analogy, this is the trap that the bitcoin folks are falling into. They believe that because they can express complicated transaction flows in a program, they have encapsulated the contract or agreement between folks. They haven't, what they've achieved is the performance of a contract only, not the entire contract. The wider contract also includes semantics & exceptions, and these cannot typically be coded into a language other than the natural language that the humans use in forming their agreement. Sadly, it seems that human level semantics will remain in wordage, and agent-level performance will be limited to code. The two should work together. Which is why in the CA/PKI world there is a fairly clear separation between the technology and the documentation; the two are supposed to walk hand in hand, and they are supposed to cover distinct areas of the agreement. It is this latter documentation aspect -- e.g., the EULA which should point to PKI's CPS -- that the OpenPGP world is lacking in its thought process. To bring it back to the technology level: an assertion made in OpenPGP that doesn't also in some reliable way point to the doco tree that grounds the statement is approximately worthless. iang From nobody Tue Apr 28 06:10: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 600081A9105 for ; Tue, 28 Apr 2015 06:10:13 -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 45yTXcC78DiG for ; Tue, 28 Apr 2015 06:10:12 -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 0964E1A9120 for ; Tue, 28 Apr 2015 06:10:12 -0700 (PDT) Received: by laat2 with SMTP id t2so103886009laa.1 for ; Tue, 28 Apr 2015 06:10:10 -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=NJkpddYhsejAjNHJSS2kzTODUiAinc4/7Ycejdk6vw0=; b=rhuT1qo5MjITBRUafx1gwZ1y4JnH/gJMJiS4rMp0nP3MzbVzJEl7l52W0rubYDJx4P zB3BkXNRf1QuOtCn+aZDUKT52QsW3r7t0XxKRI6w1mVvNX8uVf+b6+6aXfCym3Hp3XbF CvS3/OKsPXTBhh9jur1bayCfGCCFLFZd0rU9GMngVmJ5uAyr0FGPAkShp99WJj0e06pC ipF1AxWAw1Bw2r9gTkl+SuDNojFLcBom8JLHzHACwG+R6zNpwLYN/tRJGFo+qYBjkHYo MR2PHe4X8KRAM3SgPg8Bnfp0uOb0Vmz/Q3FlmRv52RD1D5+W4hGD1WrelD4cZe38/D0F Uu+Q== MIME-Version: 1.0 X-Received: by 10.112.180.137 with SMTP id do9mr7376986lbc.91.1430226610550; Tue, 28 Apr 2015 06:10:10 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 06:10:10 -0700 (PDT) In-Reply-To: <553F79F2.90803@iang.org> References: <5527B621.3040104@cs.tcd.ie> <87pp74e9js.fsf@littlepip.fritz.box> <87618w7556.fsf@vigenere.g10code.de> <1429189097.1702.85.camel@scientia.net> <552FB9B9.9080002@iang.org> <553F79F2.90803@iang.org> Date: Tue, 28 Apr 2015 09:10:10 -0400 X-Google-Sender-Auth: 0dPvF3b7SRzJk4GVhgTRONJb6s8 Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP 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, 28 Apr 2015 13:10:13 -0000 On Tue, Apr 28, 2015 at 8:15 AM, ianG wrote: > On 24/04/2015 20:03 pm, Jon Callas wrote: >> >> >>> On Apr 20, 2015, at 9:53 AM, Phillip Hallam-Baker >>> wrote: >>> >>> >>> What we need is the PKI equivalent of structured programming. PKIX is >>> Pascal. PGP is BASIC. Yes, you can do anything with IF-THEN-GOTO. But >>> you probably should not try. >> >> >> If only there were a way to do that. >> >> Let's consider a machine that has a set of simple operations that it can >> do, like IF-GOTO and another language that did more complex things like >> IF-THEN-ELSE. If we could make something that could take the complex >> language and translate it into a set of the simpler statements reliably, >> then perhaps we could solve that problem. > > > > Right. As an analogy, this is the trap that the bitcoin folks are falling > into. They believe that because they can express complicated transaction > flows in a program, they have encapsulated the contract or agreement between > folks. > > They haven't, what they've achieved is the performance of a contract only, > not the entire contract. The wider contract also includes semantics & > exceptions, and these cannot typically be coded into a language other than > the natural language that the humans use in forming their agreement. > > Sadly, it seems that human level semantics will remain in wordage, and > agent-level performance will be limited to code. The two should work > together. Which is why in the CA/PKI world there is a fairly clear > separation between the technology and the documentation; the two are > supposed to walk hand in hand, and they are supposed to cover distinct areas > of the agreement. It is this latter documentation aspect -- e.g., the EULA > which should point to PKI's CPS -- that the OpenPGP world is lacking in its > thought process. > > To bring it back to the technology level: an assertion made in OpenPGP that > doesn't also in some reliable way point to the doco tree that grounds the > statement is approximately worthless. This is the reason for the Conditions section in SAML. It provides a mechanism for imposing constraints like acceptance of terms. From nobody Tue Apr 28 07:01: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 1327B1A0143 for ; Tue, 28 Apr 2015 07:01:52 -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 SWyAT1zJdSj7 for ; Tue, 28 Apr 2015 07:01:49 -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 ACD6F1A0119 for ; Tue, 28 Apr 2015 07:01:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8AE26E2036; Tue, 28 Apr 2015 10:01:48 -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 06542-02; Tue, 28 Apr 2015 10:01:46 -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 A3075E2035; Tue, 28 Apr 2015 10:01:46 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3SE1kVU025251; Tue, 28 Apr 2015 10:01:46 -0400 From: Derek Atkins To: Nicholas Cole References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> <874mo1egir.fsf@vigenere.g10code.de> Date: Tue, 28 Apr 2015 10:01:46 -0400 In-Reply-To: (Nicholas Cole's message of "Mon, 27 Apr 2015 23:29:16 +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: "openpgp@ietf.org" Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 28 Apr 2015 14:01:52 -0000 Hi, Nicholas Cole writes: > On Mon, Apr 27, 2015 at 4:29 PM, Werner Koch wrote: > >> FWIW: I have no real preference pro or contra a hard expiration time. > > I have not seen anyone in favour of a hard expiration time explain > what it is designed to prevent / enable. I think the new standard > should have a real prejudice in favour of excluding anything unless > there is a clear justification. It could be that I've just missed > something, but I don't think that standard has been reached here yet. You have seen them. You've just ignored them. It prevents someone who gains access to your private key the ability to keep your public key going past your pre-selected expiration time. Using soft expiration doesn't help in this case because the attacker has access to your private key and could, as a result, issue additional self-sigs with extended expirations. > What does a hard expiration time technically achieve that a soft > expiration time does not. The above. If you want to reuse your key material in a new key/certificate you can, but it would be considered a completely "new key" so existing signatures would be invalid. That's the goal. > If the answer is encouraging the user to behave in a particular way, > that should be enforced / encouraged through other means. I see no > security advantage at all. As I say, I may be missing something. No, it has nothing to do with encouraging specific behavior. But if you don't see a security advantage then you're either not looking or not reading. -derek, who should have paid more attention during the V4 key designs, but was probably on PGP Hiatus at the time. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 28 07:04: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 4907E1ACDCD for ; Tue, 28 Apr 2015 07:04:49 -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 OEtdYTwMSY1s for ; Tue, 28 Apr 2015 07:04:48 -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 5593B1ACDC1 for ; Tue, 28 Apr 2015 07:04:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 28933E2036; Tue, 28 Apr 2015 10:04:47 -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 06542-03; Tue, 28 Apr 2015 10:04:40 -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 5DE9AE2035; Tue, 28 Apr 2015 10:04:40 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3SE4d88025443; Tue, 28 Apr 2015 10:04:39 -0400 From: Derek Atkins To: Jon Callas References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> Date: Tue, 28 Apr 2015 10:04:39 -0400 In-Reply-To: <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> (Jon Callas's message of "Mon, 27 Apr 2015 17:43:13 -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: Werner Koch , Christoph Anton Mitterer , openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 28 Apr 2015 14:04:49 -0000 Jon Callas writes: >>> I read your explanation. I understand it. I just disagree. >>> >>> I think that hard-expiration is not only a bad idea, but unenforceable. >> >> It was enforceable with V3 keys. It is, as Christoph pointed out, no >> longer enforceable with V4 keys because it was moved out of the Public >> Key Packet and into the SelfSig. :-( > > I'm well aware of this, Derek. I'm saying that hard expiration is in > my opinion not only impossible even with V3 keys (just rewrite > everything), but a bad idea. Rewriting means that all the signatures on your key become invalid. It's effectively a completely "new" key/certificate. Sure, there is nothing to prevent a user (or an attacker) from doing that (reusing key material), but then they would have to go out and social engineer certificate signatures in order to gain trust for the "new" key. >>> It's a *good* thing for Alice to be able to update the expiration time >>> on her key. It encourages putting a limit on (as opposed to no limit) >>> if it can be changed later. It also allows advanced systems to be able >>> to do some really cool things with short lived keys. >> >> This is a reason for SelfSigs to expire. However if the key itself is >> stolen/compromised the attacker could then create an updated SelfSig >> with an updated expiration. >> >> If the key itself had an expiration (as it did in v3) then this attack >> wouldn't work. But then it also means Alice would *have* to generate a >> new key after the old key expired. (Or, worst case, Alice would have to >> regenerate a new Certificate using the same key parameters and then >> obtain all those signatures again). > > Yeah, and I'm saying that think the current behavior is a good thing, > all in all. Gentlepersons can disagree on this, I'm just giving my > opinion. Of course. And in many use cases that's probably sufficient. I see use cases where it is not sufficient so I'd like to re-gain that feature. > Jon -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 28 07:14:18 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 C14C01A1AA8 for ; Tue, 28 Apr 2015 07:14:16 -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 DLTXfGZ2wiFp for ; Tue, 28 Apr 2015 07:14:15 -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 8382E1A1AA5 for ; Tue, 28 Apr 2015 07:14:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 03682E2036; Tue, 28 Apr 2015 10:14:13 -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 06462-06; Tue, 28 Apr 2015 10:14:12 -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 60B0FE2035; Tue, 28 Apr 2015 10:14:12 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3SEEB37025892; Tue, 28 Apr 2015 10:14:11 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <1430167217.658.2.camel@scientia.net> Date: Tue, 28 Apr 2015 10:14:11 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 27 Apr 2015 16:49:20 -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: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 14:14:16 -0000 Phillip Hallam-Baker writes: > The idea is that when someone is typing in the fingerprint, the client > can perform a parity check to see if the fingerprint data is correct > as the user is typing rather than waiting to the end. Why would someone type in a fingerprint? Could you give me a use-case for that? The only use case I've ever seen is that you copy-and-paste it onto your business card (or presentation, or other printed/distributed material), and then the verifier performs a visual match later between the printed material and their verification screen. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 28 08:12: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 222B11A854D for ; Tue, 28 Apr 2015 08:12:53 -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 O5EYvBrr0Kpq for ; Tue, 28 Apr 2015 08:12: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 106B61A8758 for ; Tue, 28 Apr 2015 08:12:51 -0700 (PDT) Received: by layy10 with SMTP id y10so106957126lay.0 for ; Tue, 28 Apr 2015 08:12: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=MzAd/xnyU0fV2pLOazPYo5+Jib0AzOuGJnISxbpdSuc=; b=t/XzLs3+Dp12OLRpvDiEPsDG6ydsCEYdj285eAKz8pDlutb0UgxCpaw3zzBGoNhCk4 H2r8Fxp2VoKC8n58yiz5TzyGrbM5MYmawFO+0K1NAM/WinbsVeEhftJg/6F4VpkOdKe7 a44AefBCbHdb5bTlyyxX7ybPkH2IxdEd/Ir1jeeYHhcTYjCuqJcElHHxqBJz9WOig0i8 UwupEKupYYDh2URyHUNxTOIL2sUBKw9ceccVU9RKASVAe5zqWNapkfh2VNpmOTpJ+ZFq zbTCCr0q/0ZCrAB0tgN1Il0qsUQnxqGxsoXxPgoMVnNTbcEs7vtHtdLtZS1g1o4N/3XM ARMA== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr15038901lab.79.1430233969419; Tue, 28 Apr 2015 08:12:49 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 08:12:49 -0700 (PDT) In-Reply-To: References: <1430167217.658.2.camel@scientia.net> Date: Tue, 28 Apr 2015 11:12:49 -0400 X-Google-Sender-Auth: U68uqQuJu-padG7LtmMJmavUQLo Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 15:12:53 -0000 On Tue, Apr 28, 2015 at 10:14 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > >> The idea is that when someone is typing in the fingerprint, the client >> can perform a parity check to see if the fingerprint data is correct >> as the user is typing rather than waiting to the end. > > Why would someone type in a fingerprint? Could you give me a use-case > for that? > > The only use case I've ever seen is that you copy-and-paste it onto your > business card (or presentation, or other printed/distributed material), > and then the verifier performs a visual match later between the printed > material and their verification screen. Well, I would flip it round then and say, why would a user ever interact with a fingerprint other than on a business card? There are many other cases where devices will be exchanging fingerprints under the covers. But I don't expect the user to ever see those. If we meet at IETF and bump iPhones then I don't expect to see a fingerprint unless I open up an 'advanced' tab. Same for email. Lets imagine this email had a header that said: Fingerprint: ufi:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx; holder=phill@hallambaker.com Your email client could collect that automatically and take it as probable cause to suspect that the specified fingerprint might be associated with phill@hallambaker.com. Now as stated, that would not be proof but we can add in mechanisms that would enable a challenge-response verification to be performed automatically and transparently. that is slightly more complex than it sounds because we have to avoid getting fooled by mailing lists, etc. But at this point any mailing list that isn't giving the correct SMTP headers is likely being spam filtered away anyhow. But for these applications we can use a 256 or even 512 bit fingerprint and it isn't necessary to base32 encode it either unless we think it might get translated to a little-fingerprint at some point. Same goes for QR codes. There really is no need for the QR code to be based on the base32 encoding, it can be calculated from the binary or base64. When it comes down to it, business cards and legal documents are the only places I expect the base32 fingerprint to be seen. That said, I am really on the fence on Base32C. Another way to skin the same cat would be to have an interactive protocol with whatever service uses fingerprints as index terms. With a population of a million keys (2^20) a fingerprint should start to become unique after the fourth letter is typed. So the service could easily construct a 'did you mean' concordance. From nobody Tue Apr 28 08:31: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 4D6FB1A6F28 for ; Tue, 28 Apr 2015 08:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611] 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 hWguaueZqIYy for ; Tue, 28 Apr 2015 08:31:42 -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 0F66B1A8778 for ; Tue, 28 Apr 2015 08:31:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DF813E2036; Tue, 28 Apr 2015 11:31:40 -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 07302-03; Tue, 28 Apr 2015 11:31:39 -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 D1F38E2035; Tue, 28 Apr 2015 11:31:38 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3SFVc9X030162; Tue, 28 Apr 2015 11:31:38 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <1430167217.658.2.camel@scientia.net> Date: Tue, 28 Apr 2015 11:31:38 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 28 Apr 2015 11:12:49 -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: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 15:31:44 -0000 Phillip Hallam-Baker writes: > On Tue, Apr 28, 2015 at 10:14 AM, Derek Atkins wrote: >> Phillip Hallam-Baker writes: >> >>> The idea is that when someone is typing in the fingerprint, the client >>> can perform a parity check to see if the fingerprint data is correct >>> as the user is typing rather than waiting to the end. >> >> Why would someone type in a fingerprint? Could you give me a use-case >> for that? >> >> The only use case I've ever seen is that you copy-and-paste it onto your >> business card (or presentation, or other printed/distributed material), >> and then the verifier performs a visual match later between the printed >> material and their verification screen. > > Well, I would flip it round then and say, why would a user ever > interact with a fingerprint other than on a business card? I've seen them on business cards, web sites (not sure why I'd believe that), and printed on Letter paper at keysigning parties. But my question remains unanswered: When would someone ever need to *TYPE* in a fingerprint? The only time that I think a fingerprint would need its own checksum is if users are actually keying a fingerprint in for some reason. I don't see any use case where this would ever happen. > There are many other cases where devices will be exchanging > fingerprints under the covers. But I don't expect the user to ever see > those. If we meet at IETF and bump iPhones then I don't expect to see > a fingerprint unless I open up an 'advanced' tab. Sure, and in these cases you can just use the binary fingerprint directly. Or better yet, exchange the full keys/certificates. [snip] > When it comes down to it, business cards and legal documents are the > only places I expect the base32 fingerprint to be seen. *nods* -- and need to be visually inspected/compared. > That said, I am really on the fence on Base32C. Another way to skin > the same cat would be to have an interactive protocol with whatever > service uses fingerprints as index terms. With a population of a > million keys (2^20) a fingerprint should start to become unique after > the fourth letter is typed. So the service could easily construct a > 'did you mean' concordance. Interesting concept.. But again, why would you be typing it in? What's the use case here? The only use-cases I've seen are where the user visually verifies that the printed fingerprint == the computed fingerprint. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Apr 28 08: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 E3F021ACE0C for ; Tue, 28 Apr 2015 08:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 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, T_FILL_THIS_FORM_SHORT=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 eoRXk7aiif-V for ; Tue, 28 Apr 2015 08:36:52 -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 8AF1B1A8873 for ; Tue, 28 Apr 2015 08:36:40 -0700 (PDT) Received: by layy10 with SMTP id y10so107534100lay.0 for ; Tue, 28 Apr 2015 08:36: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=oCgENM/UX9Vebl3O1uyWR2z9wcg5jF6TC34ZUZyQNyo=; b=z5qlSE3fj7hZ84Iptq/6rylez1NWczedZkuLb8IwQujddz3G4npy6DUfK4kEEXGc8T f7dCkkJrPTBwZiwAoIxQDNJaW3sjTjNPYZ915hPK1f32GoLiIYsDM1PBB3QLJEKf8r+h NN9uqbRHp9vKoi+7fkud3EScJPqHIOL5WLqG8ooCPSyqXguFO0oyh6IYv/VbgGSm/VS9 cbq+nC7cDXRpyC36u2M8EZu71Xt3HS/VIWdJTUnL3RdAqiEU/kGYLcGwENs8EdKUCvFc GtkZ8zWwpKHZ7bdO8XTf1zL1YzTDaFTHNi4+NFWjmiRPutbxzEbDDqLb9seWS8d02cId HO6w== MIME-Version: 1.0 X-Received: by 10.152.45.97 with SMTP id l1mr15326769lam.55.1430235399046; Tue, 28 Apr 2015 08:36:39 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 08:36:38 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> Date: Tue, 28 Apr 2015 11:36:38 -0400 X-Google-Sender-Auth: zde5mIdtIOMc-G7XZL0ocArs7Co Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , IETF OpenPGP , Jon Callas Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 28 Apr 2015 15:36:54 -0000 On Tue, Apr 28, 2015 at 10:04 AM, Derek Atkins wrote: > Of course. And in many use cases that's probably sufficient. I see use > cases where it is not sufficient so I'd like to re-gain that feature. I think this is a use case but a distinct usecase from the usual interpretation of fingerprint on a businesscard. We need a range of fingerprints for different purposes and that is why I want to have the content-type to be part of the data that is being hashed. One use case is to create a persistent identifier that is indexical to a public key they are the holder of. This form of identifier can be a 'life long' identity that is immutable and can be depended no not to change even though the holders name (marriage) and email address are likely to. The way to address that use case is to hash a public key and algorithm identifier and absolutely nothing else and if the identity is going to last a lifetime you probably want that to be just a signature key for an offline root. If the syntax is PKIX then this would be application/pkix-keyinfo. For PGP the content type application/pgp-keyinfo probably makes sense. Another use case is to introduce a key that is going to be used to execute contracts. Here my preferred mechanism would be SAML because that is what the assertion infrastructure was originally architected to support. I can see applications that fall short of binding contracts where it makes sense to expire the fingerprint and to bind it to both an expiration date and a subject identity. If the syntax is PKIX then this would be application/pkix-cert. For PGP the content type application/pgp-keysigning probably makes sense. Long term I would want to redo SAML with {} instead of <> and the result would probably be something like application/json-assertion. But that is currently at the research stage. Yet another use for fingerprint technology is in exchanging and displaying status of append only logs. Over the past couple of weeks I have been looking into that and the results are very encouraging. JSON sequences work extremely well. Much better than might have been hoped. Lets say you go past a billboard in Times Square New York that has a fingerprint on it. You look at your watch and you can see that its the same as the hash of last night's closure on the blockchain. If it is different then you know that someone, somewhere is doing something dishonest or they have messed up big. Important information either way. The fact that your watch has the same closure as everyone else is demonstration that your entire personal digital infrastructure is in sync with the consensus. From nobody Tue Apr 28 08:58: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 2415C1AD049 for ; Tue, 28 Apr 2015 08:58:52 -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 dJxiPcko4jEQ for ; Tue, 28 Apr 2015 08:58:50 -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 3B11D1A89A0 for ; Tue, 28 Apr 2015 08:58:35 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so110838617lbb.3 for ; Tue, 28 Apr 2015 08:58:33 -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=ahEl0DCCDRxp4kQC9BZX4BzO9gNvqP5OoFqy4RMoqXQ=; b=N4AiGtZQAYSIh/IwKwruReG3rCGjceGvyVux9//re5z7iOMtLa4pDNJ7l5vD/hZkzd 7N/yhcSPbU0tHe/Du1tPr6GKfFjrkOX9AwyK2sODudIQpAVByjsb5ulyeOj4qEwamS9M vA3nvVznNICd5Jb9FqqXCX3yWJO7tHmGvrmAUkOrsEMSnk5W6KgmTBBWZX2SKieiLH/R YcO8kSL/g0nK0c+2vASsrwbF5vXwYwklgNEmIktYRQ6QPuqYtWM+L4dqPT40y8bu8KU+ gng8ciCGCceASN2R2SAHoSkL0/Uyz0hah41ZDosfTTRZ6YNDNHY2R5OYdtnzrgrSJ5ps ykOA== MIME-Version: 1.0 X-Received: by 10.112.180.137 with SMTP id do9mr8009667lbc.91.1430236713678; Tue, 28 Apr 2015 08:58:33 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 08:58:33 -0700 (PDT) In-Reply-To: References: <1430167217.658.2.camel@scientia.net> Date: Tue, 28 Apr 2015 11:58:33 -0400 X-Google-Sender-Auth: whYIwNJuzaukFpSDkLb2qiW8G48 Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 15:58:52 -0000 On Tue, Apr 28, 2015 at 11:31 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: >> That said, I am really on the fence on Base32C. Another way to skin >> the same cat would be to have an interactive protocol with whatever >> service uses fingerprints as index terms. With a population of a >> million keys (2^20) a fingerprint should start to become unique after >> the fourth letter is typed. So the service could easily construct a >> 'did you mean' concordance. > > Interesting concept.. But again, why would you be typing it in? What's > the use case here? The only use-cases I've seen are where the user > visually verifies that the printed fingerprint == the computed > fingerprint. Look, my concern here is purely that I don't want to have to redo the code I write this week because someone proposes this as an addition later on. I think we have established that it is not worth doing. If people are reading in a business card why not do OCR on their phone? So we are looking at 95% of the uses of fingerprints being to provide a visual verification of a fingerprint being displayed to them. That looks good to me. We can even (modulo the possibility of ridiculous patent claims) consider a step further and have an image based Base2^20 display of the same data. Lets say we get an open source image library with 2^20 visibly distinct entries. We number the entries and form a Merkle tree over them. This gives us an alphabet where we can check every character against the root hash of the Merkle tree. We then prepend the Merkle tree chain to each gliph making it verifiable against the root fingerprint. We can now have a collection of untrusted servers that serve up this set of glyphs. At 4KB on disk per 120x120 pixel glyph, that is only 4GB. So if Alice is using a 125 bit fingerprint (Work factor 2^117), her Base64 fingerprint is: aaaaa-bbbbb-ccccc-ddddd-eeeee The equivalent Base2-20 fingerprint would be a sequence of images and have a work factor of (2^112) [z]-[z]-[z]-[z]-[z]-[z] Anyone know where we might scrounge a million images? WikiSource perhaps? It would probably behoove us to check them in some fashion but this could be crowdsourced. The idea of using images as an alphabet has ample prior art going back to ancient Egypt. From nobody Tue Apr 28 08:59: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 2E0F71AD09B for ; Tue, 28 Apr 2015 08:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gg2X3dXgl-OM for ; Tue, 28 Apr 2015 08:59: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 8B0881AD09F for ; Tue, 28 Apr 2015 08:59:05 -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 42C195FACC for ; Tue, 28 Apr 2015 15:59:04 +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 L9TOm30-qfeU for ; Tue, 28 Apr 2015 15:59:01 +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 mailgw02.dd24.net (Postfix) with ESMTPSA for ; Tue, 28 Apr 2015 15:59:01 +0000 (UTC) Message-ID: <1430236740.658.40.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 28 Apr 2015 17:59:00 +0200 In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-K3gxTwnHx2gmyTo7/K6M" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 28 Apr 2015 15:59:48 -0000 --=-K3gxTwnHx2gmyTo7/K6M Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-04-28 at 11:36 -0400, Phillip Hallam-Baker wrote:=20 > On Tue, Apr 28, 2015 at 10:04 AM, Derek Atkins wrote: >=20 > > Of course. And in many use cases that's probably sufficient. I see us= e > > cases where it is not sufficient so I'd like to re-gain that feature. >=20 > I think this is a use case but a distinct usecase from the usual > interpretation of fingerprint on a businesscard. >=20 > We need a range of fingerprints for different purposes and that is why > I want to have the content-type to be part of the data that is being > hashed. Maybe it's just me but you seem to often mix up different topics... What has the question of hard expiration times to do with the fingerprint formats, content-types or fingerprint use cases? > One use case is to create a persistent identifier that is indexical to > a public key they are the holder of. This form of identifier can be a > 'life long' identity that is immutable and can be depended no not to > change even though the holders name (marriage) and email address are > likely to. > The way to address that use case is to hash a public key and algorithm > identifier and absolutely nothing else and if the identity is going to > last a lifetime you probably want that to be just a signature key for > an offline root. With that alone you make hard expiration times impossible, and open the window for attacks based on the expiration time not being hard. > Another use case is to introduce a key that is going to be used to > execute contracts. Here my preferred mechanism would be SAML because > that is what the assertion infrastructure was originally architected > to support. >=20 > I can see applications that fall short of binding contracts where it > makes sense to expire the fingerprint and to bind it to both an > expiration date and a subject identity. >=20 > If the syntax is PKIX then this would be application/pkix-cert. For > PGP the content type application/pgp-keysigning probably makes sense. >=20 >=20 > Long term I would want to redo SAML with {} instead of <> and the > result would probably be something like application/json-assertion. > But that is currently at the research stage. All of that goes seems to go way beyond the scope of OpenPGP. We're a generic crypto message format... I don't think we shold mix OpenPGP with 3rd party protocols, unless these are really *basic* (things like BASE32). > Yet another use for fingerprint technology is in exchanging and > displaying status of append only logs. None of our business,... these are higher level apps which may use our stuff.. We need to provide the means for - encryption - signing / authentication / etc. - timestamping - certifying different kinds of identities (names, images, birthdays, etc.) - build trust networks respectively relate the different identities - revocation, expiration - extensibility of the message format and things like these. But it's not our business to make special things form mail, SAML, and so on. Cheers, Chris. --=-K3gxTwnHx2gmyTo7/K6M 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyODE1NTkw MFowTwYJKoZIhvcNAQkEMUIEQMVh2+KLm5KdAlmQ3suBAss9np4A9c3qCZ9JBmBvg6XR8ja3R2/A Lu1gO3m6YOqSsSrz5zXc5i30zC0WpfKsLHQwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAEKtQqUsbw0LrWsqZUVNV5QM09CuFO R4VdNRzld+b7dHJfynZYAX7cW1fZAMUOPg7KwAkGBJFGbjDvr7sQ4NSyP3aLUNI8ME7kTEcVhsVz sE6m3sT/or8EanYEt04jWkPE5zDzv0jMfxWBeJt+0S8xvSEYODZ5L4ap9TR+rGW+Tt2qUBcPl48H lySSW/IKc9R6FXLiz2DcU1Izta4WeD2vH5mhEUro7rPIePZ9v8AsYGZQzWIUhAtEeV0KxTPXyZSC 8sOCrRlDGhJkYLxXxi9AJhFrir6kyZYqm7q0xOXUdzcMCclVqfIh9c76s8exjuYBoEPZmB0314BG UvnxdsxnAAAAAAAA --=-K3gxTwnHx2gmyTo7/K6M-- From nobody Tue Apr 28 09:08: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 01FF01AD0CD for ; Tue, 28 Apr 2015 09:08:08 -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 8p__F4QmC9kA for ; Tue, 28 Apr 2015 09:08:07 -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 105BF1AD0C8 for ; Tue, 28 Apr 2015 09:07:51 -0700 (PDT) Received: by layy10 with SMTP id y10so108259495lay.0 for ; Tue, 28 Apr 2015 09:07: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=yim8Mxb4M7Hg+dddPRO/dMaksvNspebnw9vcPUWQDU4=; b=eNuDnbxJ2u1Nqa0fS/Q/LcD5eXAGGLCeRVu8ZheCYuGoasqHGJuIpdMjFY4XhXtZZI E/0WSlXO+V6UD6NBmDV6KhT2otJKfxqTUR377sCU4NGwEyZPGpcXaZVG53WMNS0CgFOa ATAZQp0/3XNHRvugu871UPzaUOvctv4gVnVH85fQjy4kjd1m0SdomtxoJkS85CPxB8Y7 kUyiz053adLueK2jhjJzHMQ1LQzLVR3a/J/624IMZmx5QqtUzEfQlgW4dP46SCqKfUH1 6roagn7CyhyjYwvKIcy8MUpoODbdlyA5Z0rrAkJesXKPlEcutdCpkRCD9qWwvuvkNB1r WS5g== MIME-Version: 1.0 X-Received: by 10.153.8.133 with SMTP id dk5mr15529142lad.58.1430237269612; Tue, 28 Apr 2015 09:07:49 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 09:07:49 -0700 (PDT) In-Reply-To: <1430236740.658.40.camel@scientia.net> References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> <1430236740.658.40.camel@scientia.net> Date: Tue, 28 Apr 2015 12:07:49 -0400 X-Google-Sender-Auth: TdQoi5wE2r7nAjbdf3CPS0HZE4E 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] rfc3880bis - hard expiration time 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, 28 Apr 2015 16:08:08 -0000 On Tue, Apr 28, 2015 at 11:59 AM, Christoph Anton Mitterer wrote: > On Tue, 2015-04-28 at 11:36 -0400, Phillip Hallam-Baker wrote: >> On Tue, Apr 28, 2015 at 10:04 AM, Derek Atkins wrote: >> >> > Of course. And in many use cases that's probably sufficient. I see use >> > cases where it is not sufficient so I'd like to re-gain that feature. >> >> I think this is a use case but a distinct usecase from the usual >> interpretation of fingerprint on a businesscard. >> >> We need a range of fingerprints for different purposes and that is why >> I want to have the content-type to be part of the data that is being >> hashed. > > Maybe it's just me but you seem to often mix up different topics... > > What has the question of hard expiration times to do with the > fingerprint formats, content-types or fingerprint use cases? Derek and Jon are both discussing opposed use cases within OpenPGP scope. I am pointing out that we are discussing one special case of what should be a generic mechanism. While IETF charters are narrow, we are also supposed to be looking for ways to work with other IETF groups and make our work as useful as possible to other groups. Charter fetishes really don't help. Especially when we don't have a charter yet. Putting the MIME content type in the data to be digested is the right approach for OpenPGP and the right approach for IETF in general. From nobody Tue Apr 28 09:14: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 558FB1AD1F5 for ; Tue, 28 Apr 2015 09:14:07 -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 nFi6QMegIzs1 for ; Tue, 28 Apr 2015 09:14:06 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::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 33E891AD1A3 for ; Tue, 28 Apr 2015 09:13:27 -0700 (PDT) Received: by wgin8 with SMTP id n8so156972984wgi.0 for ; Tue, 28 Apr 2015 09:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=l3u/ibXnz7AzEVbhYHF5o+lAH4OA4CqpoAtAofw+j0Q=; b=qL+AnWETSdZDFnFEu0HhLiCvYE271VUXC2wB9+BYhbiZ5dDRO3k1LTGfvMVxMjau+U vhsNwCS9rAUbJGxWqhjaBTW+oLFukiRIaXG7dz0UBN2K8T0PvJwmkw6Svt7IZ3HRvtB/ amyLO9bMHjk5PXLfmQ0jJurtyEB+iSZtBplzRESxSIg89YfbwlCPXdvbk8ztVNXDhKXF RPh+1vQcnqMuQDoHHKfkeEQB6Mhg59l1PrqV2n7NHCjovRSbTw+ODDFypg0IoHePhe7T 7BYVUlZpCDXX82BSgPOZLAEbKxKqj9CFe7LyyN8mTxN5uBp0tbhzukk/GL4bPLM6Wvg7 YWXQ== X-Received: by 10.180.9.78 with SMTP id x14mr31378640wia.69.1430237605566; Tue, 28 Apr 2015 09:13:25 -0700 (PDT) Received: from [131.175.121.117] (pc121-117.elet.polimi.it. [131.175.121.117]) by mx.google.com with ESMTPSA id l3sm17090476wiv.18.2015.04.28.09.13.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 09:13:25 -0700 (PDT) From: Alessandro Barenghi X-Google-Original-From: Alessandro Barenghi Message-ID: <553FB1AD.7060600@polimi.it> Date: Tue, 28 Apr 2015 16:13:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1430167217.658.2.camel@scientia.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 16:14:07 -0000 On 04/28/2015 03:58 PM, Phillip Hallam-Baker wrote: > The equivalent Base2-20 fingerprint would be a sequence of images and > have a work factor of (2^112) > > [z]-[z]-[z]-[z]-[z]-[z] > > > Anyone know where we might scrounge a million images? WikiSource perhaps? > > It would probably behoove us to check them in some fashion but this > could be crowdsourced. > > The idea of using images as an alphabet has ample prior art going back > to ancient Egypt. In this case, wouldn't it be viable, while keeping a text representation of the fingerprint, to employ a diceware-password-like approach to represent the fingerprint? With a reasonable english dictionary you get ~15 bits per word, which gets you up to a reasonable margin rather fast (~8 words) and is easier to inspect and compare visually. The possible downsides of this approach are: -- The need of storing a standardized dictionary -- The possible mess with internationalization (although employing one dictionary per language and adapting the client to read/print fingerprints in a selectable language may get around this) Cheers Alessandro From nobody Tue Apr 28 09:15: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 E950C1AD1DB for ; Tue, 28 Apr 2015 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_TVD_FUZZY_SECURITIES=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 cxeKllFY8pBY for ; Tue, 28 Apr 2015 09:15:44 -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 58FCD1AD2EC for ; Tue, 28 Apr 2015 09:15:13 -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 0F5AB5FB3F for ; Tue, 28 Apr 2015 16:15:12 +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 ukEmZvaGE5m0 for ; Tue, 28 Apr 2015 16:15:10 +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 ; Tue, 28 Apr 2015 16:15:10 +0000 (UTC) Message-ID: <1430237709.658.53.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 28 Apr 2015 18:15:09 +0200 In-Reply-To: References: <1430167217.658.2.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-vMun4GyRESrzLJxEBNWS" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 16:15:46 -0000 --=-vMun4GyRESrzLJxEBNWS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-04-28 at 11:12 -0400, Phillip Hallam-Baker wrote:=20 > There are many other cases where devices will be exchanging > fingerprints under the covers. And most of the time they should probably work with the keys themselves, than using the fingerprint. > But I don't expect the user to ever see > those. If we meet at IETF and bump iPhones then I don't expect to see > a fingerprint unless I open up an 'advanced' tab. I'd generally refuse to design the next version of OpenPGP targeted around use cases which inherently have very questionable security. Especially smartphones are not really trustworthy for doing secure crpyto,... so you need more reason than "it would be nice for Apple/Android/Smartphone/JavaScript based E2E crypto/etc." in order to convince me. > Same for email. Lets imagine this email had a header that said: >=20 > Fingerprint: ufi:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx; holder=3Dphill@hallambake= r.com >=20 > Your email client could collect that automatically and take it as > probable cause to suspect that the specified fingerprint might be > associated with phill@hallambaker.com. And what's the use/benefit of this? The sender of an email is already identified by it's From: header, an in order to trust that it needs to match a properly signed UID on the key. Works already fine?! Further, this shouldn't be part of an OpenPGP standard,... we're not defining mail. It's ok if we define a fingerprint format, perhaps even URI schemas, but that's it. > Now as stated, that would not be proof but we can add in mechanisms > that would enable a challenge-response verification to be performed > automatically and transparently. that is slightly more complex than it > sounds because we have to avoid getting fooled by mailing lists, etc. > But at this point any mailing list that isn't giving the correct SMTP > headers is likely being spam filtered away anyhow. What kind of challenge response? I.e. what should it prove?=20 > But for these applications we can use a 256 or even 512 bit > fingerprint and it isn't necessary to base32 encode it either unless > we think it might get translated to a little-fingerprint at some > point. > Same goes for QR codes. There really is no need for the QR code to be > based on the base32 encoding, it can be calculated from the binary or > base64. I don't think we should define too much fingerprint formats, especially the "short" are always kinda dangerous... it's like with the key IDs,.. people use it in insecure ways. I'm also highly sceptical towards any formats that are not human readable (e.g. QR). > When it comes down to it, business cards and legal documents are the > only places I expect the base32 fingerprint to be seen. ?? Every piece of software which deals with the keys and shows their FPs for verification? > That said, I am really on the fence on Base32C. Does it have any big advantages over plain BASE32? Cheers, Chris --=-vMun4GyRESrzLJxEBNWS 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyODE2MTUw OVowTwYJKoZIhvcNAQkEMUIEQESZLLkVq7cvHyGqLnz2S56G7c0nMGry6a23AhGuiw4NBoRaptHr RoX9C+2X+Zo1h+vprnHYnyyIDskA2NRvZ3QwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQATP4rVELmOjktZ8sGFPyUxGeUECp3L OZ+LvnM6SlfHIwoWLGN2VaydzzLiO1+Ukl4Vrv9SIAOjVA3O1PGf8WABx0rQUECcbZtxI275fwZC X2adYhV+YFRqys7T+4WRj7zRM3MR9CCr9oDc9Ca/kcvxmeDZkjax6aHKyTwTEIgeZCu6ekg3dHUT guvx03mqsIe4dTq+pKKRldWdO/hBbu/fseJ1HFxs2R7IBZRVxqtxNvWLorp6QhyDQbSeyJNPadJz /QPA4xvxPYoY/xf3rkApTA68GMD0xZbMBOu3guHbzYP2QnZF6/C6sVdeDepS48gPej/GrEDeFpaN eDf2tTGvAAAAAAAA --=-vMun4GyRESrzLJxEBNWS-- From nobody Tue Apr 28 09:57: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 07FF51B2AA9 for ; Tue, 28 Apr 2015 09:57: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 bqQWuInRvKPr for ; Tue, 28 Apr 2015 09:57: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 B8B931B2AAD for ; Tue, 28 Apr 2015 09:57:48 -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 57D175FB6F for ; Tue, 28 Apr 2015 16:57:47 +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 IFi-g2OEkzQx for ; Tue, 28 Apr 2015 16:57:45 +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 mailgw02.dd24.net (Postfix) with ESMTPSA for ; Tue, 28 Apr 2015 16:57:45 +0000 (UTC) Message-ID: <1430240265.658.56.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Tue, 28 Apr 2015 18:57:45 +0200 In-Reply-To: References: <1430167217.658.2.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-mC0rhOu74lV/fTmMS+Yi" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 16:57:55 -0000 --=-mC0rhOu74lV/fTmMS+Yi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-04-28 at 11:58 -0400, Phillip Hallam-Baker wrote:=20 > Look, my concern here is purely that I don't want to have to redo the > code I write this week because someone proposes this as an addition > later on. I guess we're just at the start of the next standard,... writing code now and assuming (and/or demanding) things to be stable is probably a bad idea. Cheers. --=-mC0rhOu74lV/fTmMS+Yi 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyODE2NTc0 NVowTwYJKoZIhvcNAQkEMUIEQC84Qh9MLPg23MGk9Fd6nm1DVtBmoT5Ha7DHJbqim/u1zn07DfH8 V35AR0FDW/lvtxZzWFdCG71TSw5jO97S4V8wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAxxmWZQaeL4AEXeQ+/Tl0CssbJVCo/ Oo9vCiLNCntQzbqX32qegivrF+2OPXhQPdBI/bTtkjkQTDh18EYI7aj2r2JreGJ2SuFHJKta0WFd vSdlmBltme6bd8FF28v9t3bCdeyT4BAqe3Oon1YppdblwX0d+cAQe94LwWbyUxT9Pqqi9pzLeluC nPhwbyTmM793JrpLNH6YjWID5M2CPWAUub/keLhvypnXyKmdMnzqF8jqLY/7qdMadkkh/pzvjmx+ jakxHmSd2Az87Ytl/tZn/eEEzHU3PL1yB0I4ixAsSPdIgVWn4Ohl/oYofO6XGisU4LRUU3SQQSOM OF1s23cQAAAAAAAA --=-mC0rhOu74lV/fTmMS+Yi-- From nobody Tue Apr 28 10:01: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 1A0BA1B2ACA for ; Tue, 28 Apr 2015 10:01:06 -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 EFMMe8y_69BI for ; Tue, 28 Apr 2015 10:01:04 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 7F62D1B2ACF for ; Tue, 28 Apr 2015 10:01:04 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so744303lbb.3 for ; Tue, 28 Apr 2015 10:01: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=AzkRR4qsdk3/exg0v4zwm1H37L7g05rF/vwU/4Kcz0g=; b=s4JtMZkmvhMtkHFABno7OQKJwd4Ks0wH1q5Jeo6HRSZXW2Brc1Kl6D4/zdM3FqzJ9W YogsBmNdd/nVtxq7xdTGOMaVTUzVMj4UNHxytAG9l/80T9iq5P7akHu6HhWA3gFP9ORV MBrQ30H4MYKhF6KxWASx8+dcXo+g22LTXR3B8PZ3Nd82SxoUkzOp1n2Z5lN0xEwFdrBJ 0WNu3NnAj0ynUG76kDcynGTrJLkf6pqmjKLKvL2Qhfn5UTyMoXWP8bq/v/NLx5eSuPEH eLi/5OiDh40b6HDV2mueggC5epHxzhBnQaEbugMwx4wnoiuUSRtV3TD3Lf1YXRByctQw QLaw== MIME-Version: 1.0 X-Received: by 10.152.197.2 with SMTP id iq2mr15423845lac.103.1430240462977; Tue, 28 Apr 2015 10:01:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 10:01:02 -0700 (PDT) In-Reply-To: <553FB1AD.7060600@polimi.it> References: <1430167217.658.2.camel@scientia.net> <553FB1AD.7060600@polimi.it> Date: Tue, 28 Apr 2015 13:01:02 -0400 X-Google-Sender-Auth: KGSA5aabfqUmE-nbX6HfIxCL1Xw Message-ID: From: Phillip Hallam-Baker To: Alessandro Barenghi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 17:01:06 -0000 On Tue, Apr 28, 2015 at 12:13 PM, Alessandro Barenghi wrote: > On 04/28/2015 03:58 PM, Phillip Hallam-Baker wrote: > >> The equivalent Base2-20 fingerprint would be a sequence of images and >> have a work factor of (2^112) >> >> [z]-[z]-[z]-[z]-[z]-[z] >> >> >> Anyone know where we might scrounge a million images? WikiSource perhaps? >> >> It would probably behoove us to check them in some fashion but this >> could be crowdsourced. >> >> The idea of using images as an alphabet has ample prior art going back >> to ancient Egypt. > > In this case, wouldn't it be viable, while keeping a text representation > of the fingerprint, to employ a diceware-password-like approach to > represent the fingerprint? Interesting idea. Oddly enough, I have an intern who is already working on something very similar. > With a reasonable english dictionary you get ~15 bits per word, which > gets you up to a reasonable margin rather fast (~8 words) and is easier > to inspect and compare visually. 32768 words is very do-able. Hunspell English has 621,180 by the looks. Not quite a million but it is quite likely we could get there with affixation rules, plurals, etc. First thing is probably to parse the flat file and then throw out words that are too short, too long or too similar and see what is left. > The possible downsides of this approach are: > -- The need of storing a standardized dictionary > -- The possible mess with internationalization (although employing one > dictionary per language and adapting the client to read/print > fingerprints in a selectable language may get around this) There would have to be different languages for different locales, naturally. But in general, I think the pictures plus the words would be fine. From nobody Tue Apr 28 10:04: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 84AFF1B2ACC for ; Tue, 28 Apr 2015 10:04:18 -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 ednYE4RKal_K for ; Tue, 28 Apr 2015 10:04:17 -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 076391B2AE1 for ; Tue, 28 Apr 2015 10:04:07 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so932816lbb.0 for ; Tue, 28 Apr 2015 10:04:05 -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=vN0kW1Urk+ZSLc4gSLm49MCFhloF8YY6qWPREKMycfU=; b=0K58EDmkD3Vz+bJUGd1s8T3N9wAEkeqPbGrgmtewaY0I1hT2fmeTDm60+uArcVVU6k agi6za1U/W86RfcmPDrvhkYdCDKKuFbbIliKyH13VZb8Zlvg99CvoTV0H9H0HlG6F+wB VYaaciGrRXrr+2AsLJOJVui+AtRvKf0Oqk1ojLk8bCR8v27gEM9zmtbD5HIihe7Wd9Lo uqi12MLBRQGbEbqO0UMLerx9OoQVbmhd9hcou2avWDu0nQj1Ommds7er9VJMG9LKA5iy E6ggaqcvJx7r7Qi39KsxCmphPy3m9KqLXuucu8Y+HAPfvU+V1w9LI+vWzFz41kcpzkU8 sTWA== MIME-Version: 1.0 X-Received: by 10.152.45.97 with SMTP id l1mr15663504lam.55.1430240645534; Tue, 28 Apr 2015 10:04:05 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 10:04:05 -0700 (PDT) In-Reply-To: <1430240265.658.56.camel@scientia.net> References: <1430167217.658.2.camel@scientia.net> <1430240265.658.56.camel@scientia.net> Date: Tue, 28 Apr 2015 13:04:05 -0400 X-Google-Sender-Auth: ooGEzXcxhQjSEL9RzA38AWHWmkw 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] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 17:04:18 -0000 On Tue, Apr 28, 2015 at 12:57 PM, Christoph Anton Mitterer wrote: > On Tue, 2015-04-28 at 11:58 -0400, Phillip Hallam-Baker wrote: >> Look, my concern here is purely that I don't want to have to redo the >> code I write this week because someone proposes this as an addition >> later on. > > I guess we're just at the start of the next standard,... writing code > now and assuming (and/or demanding) things to be stable is probably a > bad idea. My concern is that when a nincompoop decided to release code implementing the tag in HTML he gave the community less than 16 hours to review before he had made it a fait accompli. As a result the tag still does not handle displays with resolutions other than 75dpi consistently twenty years later. Once code ships it is very hard to put the toothpaste back in the tube. From nobody Tue Apr 28 10:14: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 B90141A8A13 for ; Tue, 28 Apr 2015 10:14:53 -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 Dy5skCoAA0gp for ; Tue, 28 Apr 2015 10:14:52 -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 662741B2AD6 for ; Tue, 28 Apr 2015 10:14:52 -0700 (PDT) Received: from [174.252.50.203] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Yn95q-00032G-D6; Tue, 28 Apr 2015 13:14:46 -0400 Date: Tue, 28 Apr 2015 10:14:37 -0700 From: Bill Frantz To: Phillip Hallam-Baker 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79143a512fdfaa47fe4506ea51c4fcbb70350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.252.50.203 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 17:14:53 -0000 On 4/28/15 at 10:01 AM, phill@hallambaker.com (Phillip=20 Hallam-Baker) wrote: >32768 words is very do-able. Hunspell English has 621,180 by the >looks. Not quite a million but it is quite likely we could get there >with affixation rules, plurals, etc. Do remember that, as languages go, English has a rather large=20 vocabulary. I don't know of any languages where 32K is a=20 problem, but when over 100K or so, there is a problem. Also,=20 even in English, we may want to limit the words to common words=20 with different pronunciations, avoiding the there, their,=20 they're problem. While this group probably won't pick the word list, we do need=20 to keep it relatively small. Cheers - Bill -------------------------------------------------------------- Bill Frantz | There are now so many exceptions to the 408-356-8506 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray From nobody Tue Apr 28 10:20: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 2D8681B2B30 for ; Tue, 28 Apr 2015 10:20:44 -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 7QQK1MXEH3as for ; Tue, 28 Apr 2015 10:20:43 -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 32D7C1B2B12 for ; Tue, 28 Apr 2015 10:20:32 -0700 (PDT) Received: by lagv1 with SMTP id v1so1138839lag.3 for ; Tue, 28 Apr 2015 10:20:30 -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=ELC8rNlwn9s1PDh6y+toPQHc9ZbfukMfa9eCkJpjqKY=; b=ZYnYv88geufhqnsoi7kPSypOShJ9cn8T+9w4q2ChNJm1VNqFoZ9zx2svPyB+2J6lNd pFo+YxX59R1UkmT6ZDkZmGT5/fI3Anzvm9KAzCDh0aMFtlJ6khqV0nnjuYyYMZNfrNjS ktgUj+pui64swe98/bqbE6ONEF/TL0+11CJjJLpsntnkmcd8Pnl49HFjSjsY+eXgJt80 FAfKMxjvzZohJSyzQKGh/l/j5nGMzrkmtnV1AB2qdpu6R6LKP58G31Y0Antq3aYOXfv1 bnwfalO6paKvmubesEPlZJMF/bU7rKq9TyErUDv8z+1//izQgJKrqUAkF4TP5wFMo0Bo OpIQ== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr15533288lbc.79.1430241630700; Tue, 28 Apr 2015 10:20:30 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Apr 2015 10:20:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Apr 2015 13:20:30 -0400 X-Google-Sender-Auth: zi-BqEqmcYcotQcjVDwH3sO0YRQ Message-ID: From: Phillip Hallam-Baker To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 17:20:44 -0000 32K words is much easier to check visually. And such a word list would probably compress to 150KB which can be embedded in devices easily enough. "Before we begin our banquet, I would like to say a few words. And here they are: Nitwit! Blubber! Oddment! Tweak! Thank you." On Tue, Apr 28, 2015 at 1:14 PM, Bill Frantz wrote: > On 4/28/15 at 10:01 AM, phill@hallambaker.com (Phillip Hallam-Baker) wrote: > >> 32768 words is very do-able. Hunspell English has 621,180 by the >> looks. Not quite a million but it is quite likely we could get there >> with affixation rules, plurals, etc. > > > Do remember that, as languages go, English has a rather large vocabulary. I > don't know of any languages where 32K is a problem, but when over 100K or > so, there is a problem. Also, even in English, we may want to limit the > words to common words with different pronunciations, avoiding the there, > their, they're problem. > > While this group probably won't pick the word list, we do need to keep it > relatively small. > > Cheers - Bill > > -------------------------------------------------------------- > Bill Frantz | There are now so many exceptions to the > 408-356-8506 | Fourth Amendment that it operates only by > www.pwpconsult.com | accident. - William Hugh Murray > From nobody Tue Apr 28 10:27: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 21DD51A894C for ; Tue, 28 Apr 2015 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=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 3r1wsC7eZtAR for ; Tue, 28 Apr 2015 10:27: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 6A81D1A00EC for ; Tue, 28 Apr 2015 10:27:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A256DE2035; Tue, 28 Apr 2015 13:27: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 08127-01; Tue, 28 Apr 2015 13:27:05 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id D1A7BE2036; Tue, 28 Apr 2015 13:27:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1430242025; bh=9iVP421mm0ky6V75vvz6tk+GdnrYuwBNmNGyt/Ri+yU=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=ntErcstM1QW87Ut5/+YjeGo0CgHt67nGx/BLC+m7FpI61DZK9RgYbFPgwLbrCLxKd r8tOkm6sg4O3kR6jI7nM55lgc/qzZ13F5SZjVEnxw62gI1pDIFvb20iZIu1Ih3mqqP EJfFgdGhOpY5+XQ1sqRZ9qvHEs5uJJkB8HQf1jSE= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 28 Apr 2015 13:27:05 -0400 Message-ID: <33d263d48ef1009b33d9e98e50e5b63d.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Tue, 28 Apr 2015 13:27:05 -0400 From: "Derek Atkins" To: "Phillip Hallam-Baker" 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: IETF OpenPGP , Bill Frantz Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 28 Apr 2015 17:27:15 -0000 Reminds me of the usability portion of Neil Haller's (et al) S/KEY system. It used a dictionary of 2048 words, choosing 6 to encode a 64-bit number. -derek On Tue, April 28, 2015 1:20 pm, Phillip Hallam-Baker wrote: > 32K words is much easier to check visually. And such a word list would > probably compress to 150KB which can be embedded in devices easily > enough. > > "Before we begin our banquet, I would like to say a few words. And > here they are: Nitwit! Blubber! Oddment! Tweak! Thank you." > > On Tue, Apr 28, 2015 at 1:14 PM, Bill Frantz > wrote: >> On 4/28/15 at 10:01 AM, phill@hallambaker.com (Phillip Hallam-Baker) >> wrote: >> >>> 32768 words is very do-able. Hunspell English has 621,180 by the >>> looks. Not quite a million but it is quite likely we could get there >>> with affixation rules, plurals, etc. >> >> >> Do remember that, as languages go, English has a rather large >> vocabulary. I >> don't know of any languages where 32K is a problem, but when over 100K >> or >> so, there is a problem. Also, even in English, we may want to limit the >> words to common words with different pronunciations, avoiding the there, >> their, they're problem. >> >> While this group probably won't pick the word list, we do need to keep >> it >> relatively small. >> >> Cheers - Bill >> >> -------------------------------------------------------------- >> Bill Frantz | There are now so many exceptions to the >> 408-356-8506 | Fourth Amendment that it operates only by >> www.pwpconsult.com | accident. - William Hugh Murray >> > > _______________________________________________ > 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 Tue Apr 28 10:55: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 318921A8A57 for ; Tue, 28 Apr 2015 10:55:40 -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 hbdUe_r9_u60 for ; Tue, 28 Apr 2015 10:55:38 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 9C7D61A897C for ; Tue, 28 Apr 2015 10:55:38 -0700 (PDT) Received: by widdi4 with SMTP id di4so150129358wid.0 for ; Tue, 28 Apr 2015 10:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FtGjDg9asKaKg7nrFlEOVn9uj1RbnFLySHvjoQG+J7g=; b=LkOMmA460r3xP3gEBCxaeZ/x8AMxvMPFINRCWhSIJeZI9sGqfBZ9+kv3QRDu1pHx01 jFAFLJCjC65aTUPI6AHuxSxrUY2BOgRAFV8tb/PY3Idi80rKdLHjEajCi9zhYONvUG6r Nkw0A1XGRxn7Y7bS4hc5pOoJcUlJEV5NpJxEX037risZGSmppJ2yX3pReT3+RPRD0UT8 2RfwDS5ObNxxVNVwxPhIJgWoLoLS0/URBkJrW2z2Cvx5IYm7olHvrXfEtY1MfWkKVgvk dROG7ewmR26ZGsChUe3NTmqwuybiw8RjejwEluKIkgVhsn47E/hJk/SKwif+dgbXgHzE A2Nw== X-Received: by 10.194.91.129 with SMTP id ce1mr35112165wjb.53.1430243737371; Tue, 28 Apr 2015 10:55:37 -0700 (PDT) Received: from [192.168.188.46] (x55b40682.dyn.telefonica.de. [85.180.6.130]) by mx.google.com with ESMTPSA id a18sm9292072wja.46.2015.04.28.10.55.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 10:55:36 -0700 (PDT) Message-ID: <553FC996.3010500@googlemail.com> Date: Tue, 28 Apr 2015 19:55:34 +0200 From: Nils Durner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jon Callas , Peter Gutmann , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> In-Reply-To: <87mw1sbusl.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 28 Apr 2015 17:55:40 -0000 >> PRF. PBKDF2 is the devil you know. It behaves in completely > [...] Thus I consider it better to wait for > the outcome of the PHC I agree; and I'm not convinced a future standard should be built on past technology - apart from being for the sake of backwards compatibility. The PBKDF2 argument is today's version of a 2000's "AES is fine and well, but we should also include DESede - it's the devil you know". Besides that, what do others think about OpenPGP's variant of CFB - in particular the computationally cheap oracle it entails? Should it also be updated, perhaps with an authenticating cipher mode which might also kill the MDC birdie with the same stone? With the CAESAR competition conclusion being a bit more down the road - end of 2017 - what would a suitable AE mode be? Regards, Nils From nobody Tue Apr 28 12:16: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 621C51A01A5 for ; Tue, 28 Apr 2015 12:16:47 -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 u1HpPKVpYtSI for ; Tue, 28 Apr 2015 12:16:45 -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 4EB7B1A011F for ; Tue, 28 Apr 2015 12:16:45 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YnAzr-0001sy-No for ; Tue, 28 Apr 2015 21:16:43 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YnAv2-0000Vy-AH; Tue, 28 Apr 2015 21:11:44 +0200 From: Werner Koch To: Nils Durner References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Nils Durner , Jon Callas , Peter Gutmann , "alessandro.barenghi\@polimi.it" , "openpgp\@ietf.org" Date: Tue, 28 Apr 2015 21:11:43 +0200 In-Reply-To: <553FC996.3010500@googlemail.com> (Nils Durner's message of "Tue, 28 Apr 2015 19:55:34 +0200") Message-ID: <87618g83v4.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: "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 28 Apr 2015 19:16:47 -0000 On Tue, 28 Apr 2015 19:55, ndurner@googlemail.com said: > Besides that, what do others think about OpenPGP's variant of CFB - in > particular the computationally cheap oracle it entails? Should it also > be updated, perhaps with an authenticating cipher mode which might also That is already on the list. See for example AEAD at https://wiki.gnupg.org/rfc4880bis > With the CAESAR competition conclusion being a bit more down the road - > end of 2017 - what would a suitable AE mode be? Is it correct that the outcome of that competition might be a non-online algorithm, meaning it it can't be used in a streaming mode (pipeline)? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 28 13:56: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 F1B171A8A61 for ; Tue, 28 Apr 2015 13:56: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 FNn03m9ydxy8 for ; Tue, 28 Apr 2015 13:56:40 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 B8B2F1A894E for ; Tue, 28 Apr 2015 13:54:34 -0700 (PDT) Received: by widdi4 with SMTP id di4so155722089wid.0 for ; Tue, 28 Apr 2015 13:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0jeZoLzihvCr/MFrVl3H/w+z9FHtllNnhd5thQScZC4=; b=T7nTjVB1kCt0KzUEuuTuNgbES9zxXPzJzmTfJuCHP+4FTmKDrZ5WsaLcRmtmdPJmlY FvUbyYhdINNLTLWLd+U3I8NMYXFu9p34HDICDzPivok7CAS1lLwqYgYUCkokeabKvQqT 1W5mMfSZncG+nCqimeCDI3qgDTf9i9yD1h/rlCU1Y7pX04aN0AWbl2WOdSvN8DHKZ6XL qI2wFRaNt/BhAx/N3hVfTRT65LM3N1tIvTyhOzOtEO9TQH8M/ZD6MPaMbC+drcPMMKiX ckBy0Jif9Z2Z8YWRPX0o7wFlDcTVONoJFCWNxPehbpPnAOJidnvVm2AuB7bJPjbOmxpL B5Mg== X-Received: by 10.180.81.104 with SMTP id z8mr2631457wix.5.1430254473484; Tue, 28 Apr 2015 13:54:33 -0700 (PDT) Received: from [192.168.188.20] (x55b40682.dyn.telefonica.de. [85.180.6.130]) by mx.google.com with ESMTPSA id k9sm18133732wia.6.2015.04.28.13.54.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 13:54:32 -0700 (PDT) Message-ID: <553FF387.9000501@googlemail.com> Date: Tue, 28 Apr 2015 22:54:31 +0200 From: Nils Durner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jon Callas , Peter Gutmann , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> In-Reply-To: <87618g83v4.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 28 Apr 2015 20:56:48 -0000 >> [OpenPGP CFB replacement] > That is already on the list. See for example AEAD at > https://wiki.gnupg.org/rfc4880bis ah, thanks! >> With the CAESAR competition conclusion being a bit more down the road = - >> end of 2017 - what would a suitable AE mode be? > Is it correct that the outcome of that competition might be a non-onlin= e > algorithm, meaning it it can't be used in a streaming mode (pipeline)? This is not a stated requirement as per the Call for Submissions, that's right. NORX is an online candidate, but I cannot say if there are any other non-online ciphers in the lineup. Regards, Nils From nobody Tue Apr 28 14:33: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 101381A036B for ; Tue, 28 Apr 2015 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17 X-Spam-Level: X-Spam-Status: No, score=-17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 tCAJjeIfIncv for ; Tue, 28 Apr 2015 14:33:04 -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 8C0801A1E0E for ; Tue, 28 Apr 2015 14:33:04 -0700 (PDT) Received: from omp1018.mail.ne1.yahoo.com (omp1018.mail.ne1.yahoo.com [98.138.89.162]) by mrout5.yahoo.com (8.14.9/8.14.9/y.out) with ESMTP id t3SLWVj9053995 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 28 Apr 2015 14:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1430256752; bh=mUI+ZkiOTh6j491g6i7yVyUvoW9u/O8F3NqiR9DDCho=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject; b=A+RtGYnA9uKUxjGr/vKKS44fK9a9Pbw0lTMrirRepfaHmVQ7NuMlqqfCzvmRuK8uc 15QDHnpu/vbPdN9ngO4x5NcjHmGXM94nRDHuMHCL8Vba8VXig479Ztu0O8/NIyBYD4 c5JktYmd7X13qSJtDze7gZG/3wJalMVotUsXbPF4= Received: (qmail 27486 invoked by uid 1000); 28 Apr 2015 21:32:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1430256751; bh=xfm7ZdvLjaeh+HQMY7dg5/YebM/PC+OHVa0Uy4Zf+9M=; h=Date:From:Reply-To:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type; b=MHX4pQPKcEyee0m8GCt3W1fzu+Ga6QuxsUNchW7V9S5fwIwuMDDLKEn8K3OeaIDdeiH2l8VP6FYjTgPN5n8eQ9P/0nfcGFeQLjVOs6XrDhNfFGH1NA7Km48yQcjlf0737qE4/bZlqpuOHn/wl5uZNq/rPfbpyJpdXPAFrDef9eE= X-YMail-OSG: VZaUibsVM1lZRlutDYHpgFO9j5ggDljeOZkBB3Lxo_BWTOiqMaVFw8bfzPzk5WK XV6uZksOYJFmRp9AVajoeZX8nMN4RNICX7xKVC8kSKVgZhj7.JArtZPothisbC7sei18DULSh4dt h2JaNVQ9629gYR306dGyKi_G_ZCTE5FgdBGj.g8YN4rZBPSrsdcjPgnU7QT0T3SdPq6TQl.VoWi8 LbgxfSoRuTiXqQr3U9xGPmzgQjzQmrEIpRaDJ_g-- Received: by 98.138.105.208; Tue, 28 Apr 2015 21:32:30 +0000 Date: Tue, 28 Apr 2015 21:32:29 +0000 (UTC) From: David Gil To: Nils Durner , Jon Callas , Peter Gutmann , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" Message-ID: <476839674.6368308.1430256749356.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <553FF387.9000501@googlemail.com> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> <553FF387.9000501@googlemail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6368307_1320853166.1430256749351" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 256752002 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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: Tue, 28 Apr 2015 21:33:06 -0000 ------=_Part_6368307_1320853166.1430256749351 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There isn't any particular need to wait for the outcome of CAESAR on this o= ne: SIV mode has been standardized, and is appropriate for messages. (In pa= rticular, it is a misuse-resistant / "robust" AEAD mode.) I would consider streaming encryption as entirely out of scope for this WG.= =C2=A0- dlg =20 On Tuesday, April 28, 2015 1:57 PM, Nils Durner wrote: =20 =20 >> [OpenPGP CFB replacement] > That is already on the list.=C2=A0 See for example AEAD at > https://wiki.gnupg.org/rfc4880bis ah, thanks! >> With the CAESAR competition conclusion being a bit more down the road - >> end of 2017 - what would a suitable AE mode be? > Is it correct that the outcome of that competition might be a non-online > algorithm, meaning it it can't be used in a streaming mode (pipeline)? This is not a stated requirement as per the Call for Submissions, that's right. NORX is an online candidate, but I cannot say if there are any other non-online ciphers in the lineup. Regards, Nils _______________________________________________ openpgp mailing list openpgp@ietf.org https://www.ietf.org/mailman/listinfo/openpgp ------=_Part_6368307_1320853166.1430256749351 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There isn't any particular need to wait for t= he outcome of CAESAR on this one: SIV mode has been standardized, and is ap= propriate for messages. (In particular, it is a misuse-resistant / "robust"= AEAD mode.)

= I would consider streaming encryption as entirely out of scope for this WG.=
 
<= div id=3D"yui_3_16_0_1_1430253842421_62814">
- dlg


<= br>
On Tuesday, Apr= il 28, 2015 1:57 PM, Nils Durner <ndurner@googlemail.com> wrote:
=



= >> [OpenPGP CFB replacement]
> That is already o= n the list.  See for example AEAD at
> http= s://wiki.gnupg.org/rfc4880bis

ah, = thanks!

>> With the CAESAR compe= tition conclusion being a bit more down the road -
>&g= t; end of 2017 - what would a suitable AE mode be?
> I= s it correct that the outcome of that competition might be a non-online
> algorithm, meaning it it can't be used in a streaming m= ode (pipeline)?

This is not a stated r= equirement as per the Call for Submissions, that's
right.= NORX is an online candidate, but I cannot say if there are any
other non-online ciphers in the lineup.


Regards,

= Nils


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


------=_Part_6368307_1320853166.1430256749351-- From nobody Tue Apr 28 21:51: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 EF9101AC402 for ; Tue, 28 Apr 2015 21:51:56 -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 MqsAP4aNX0lF for ; Tue, 28 Apr 2015 21:51:53 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 B2FCC1AC3FB for ; Tue, 28 Apr 2015 21:51:53 -0700 (PDT) Received: by igblo3 with SMTP id lo3so107779378igb.1 for ; Tue, 28 Apr 2015 21:51:53 -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=IYd0w1cSgI7P4QbGfz0G+A0zcSGzD0/6q+OXRjPfr1k=; b=YTGOFF8lfteBtLuZKepBCF7EhBfAVlmZhi4zDOCiVkoaXu7NN+tzMzsOrbjkw8+QWA BI1bSimi/aKZ8JIPwDW9FoAoI56m/m04jYhJYP6FSXqGYVCWHrBMgBHXDUfaxokZpXfY j+LAb2wFc/i9hbghmZu42zZ0i+ioRntq61y/cfQ7J5+w+yDOaFVShWfeVH47gx8pWZgl paOnzigfkhWJzArkDikpHGdJD5KdwkYKhFjX8CtDScLWSXZaBCzDJDalnzIv6e9p6hLp XnGu5HNS8Tih/uH4Vq+ZVZxdMSYSlrhti6pPnTukAL2FXLRGyAB54EGVOIt9IZMPXW0b /oKw== X-Received: by 10.107.164.6 with SMTP id n6mr25809435ioe.54.1430283113236; Tue, 28 Apr 2015 21:51:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.109.67 with HTTP; Tue, 28 Apr 2015 21:51:32 -0700 (PDT) In-Reply-To: <553FF387.9000501@googlemail.com> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> <553FF387.9000501@googlemail.com> From: David Leon Gil Date: Tue, 28 Apr 2015 21:51:32 -0700 Message-ID: To: Nils Durner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 04:51:57 -0000 (I think I emailed about this already, but from an account which gets dropped by DMARC policy.) There is a perfectly good (standardized even!) robust authenticated encryption mode: SIV. A nonce-length of 128-bits (which you get using a 128-bit block cipher) is rather short, but note that for asymmetric encryption modes, a new key is used per message. I think that streaming encryption is well outside the scope of this WG. Is there some compelling argument that it is required for encrypting email messages? From nobody Tue Apr 28 21: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 826511AC411 for ; Tue, 28 Apr 2015 21:57: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 Dzb_FocmgV6j for ; Tue, 28 Apr 2015 21:56:58 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 12B621AC40B for ; Tue, 28 Apr 2015 21:56:58 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so109612716igb.0 for ; Tue, 28 Apr 2015 21:56: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 :content-type; bh=XZHaaAXgCsov8x4xEUPA8z0/13dhYHJMkHEEj5vYPGk=; b=HYTophTDMUp4DIT0GcsxOQ3rdGSyBy2g4c5zEX2Tu85CA/VVR2ibh3rvYqMLUz/K3t xjcM+RVF+UDs53rv7vCoykSlhW19ntf/97ulvLOECrZmmCO1bDYaUqBrldYEZPHpBSI0 eAKVsO/ELkYC9jRzvcScbghzQecuxzvsFAisCQqWAjif8ySbH+dy6E5RVCzjEMT2WOoC EMM13+l9g+J8ecgsChpRzWpEiwrqK+EKNHr8cO+iygvYO0S9sqDQ8GEd3Sw3tBHfKM19 akKIwoLFq77PCBt7EGFjENdz+HOdgeARyBUwdEazkIcgzKo6FS1bm5nREXN01u5iyi7K UliQ== X-Received: by 10.42.233.142 with SMTP id jy14mr1460329icb.55.1430283417525; Tue, 28 Apr 2015 21:56:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.109.67 with HTTP; Tue, 28 Apr 2015 21:56:36 -0700 (PDT) In-Reply-To: <87mw1sbusl.fsf@vigenere.g10code.de> References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> From: David Leon Gil Date: Tue, 28 Apr 2015 21:56:36 -0700 Message-ID: To: Jon Callas , Peter Gutmann , Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 04:57:01 -0000 On Tue, Apr 28, 2015 at 12:01 AM, Werner Koch wrote: > On Tue, 28 Apr 2015 00:00, jon@callas.org said: > > keeping S2K-3 as a MAY algorithm for backward compatibility > (symmetrically encrypted messages). I agree, but only to the extent that the language is limited to decryption. E.g.: An implementation MAY decrypt SKESKs using the deprecated S2K algorithm, but MUST NOT create new SKESKs using those algorithms. From nobody Tue Apr 28 23:21: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 E50B11ACDC3 for ; Tue, 28 Apr 2015 23:21:48 -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 169KRWsuQqsC for ; Tue, 28 Apr 2015 23:21:47 -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 20B541ACDB6 for ; Tue, 28 Apr 2015 23:21:47 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YnLNR-0007Lh-Ha for ; Wed, 29 Apr 2015 08:21:45 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YnLHQ-0002YA-F5; Wed, 29 Apr 2015 08:15:32 +0200 From: Werner Koch To: David Leon Gil References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> <553FF387.9000501@googlemail.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: David Leon Gil , Nils Durner , "alessandro.barenghi\@polimi.it" , "openpgp\@ietf.org" , Jon Callas , Peter Gutmann Date: Wed, 29 Apr 2015 08:15:32 +0200 In-Reply-To: (David Leon Gil's message of "Tue, 28 Apr 2015 21:51:32 -0700") Message-ID: <87wq0v794r.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: Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 06:21:49 -0000 On Wed, 29 Apr 2015 06:51, coruus@gmail.com said: > I think that streaming encryption is well outside the scope of this > WG. Is there some compelling argument that it is required for > encrypting email messages? OpenPGP is not only for email but even for that it is important. Being able to process data in one pass is a MUST. It has actually been a design criteria for all core IETF protocols. Think only about backups. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Apr 28 23:21: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 11E481ACDB6 for ; Tue, 28 Apr 2015 23:21:50 -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 yw371mqYPyKp for ; Tue, 28 Apr 2015 23:21:48 -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 5716C1ACDB7 for ; Tue, 28 Apr 2015 23:21:47 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YnLNR-0007Lw-RC for ; Wed, 29 Apr 2015 08:21:45 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YnLIV-0002Yd-6R; Wed, 29 Apr 2015 08:16:39 +0200 From: Werner Koch To: David Leon Gil References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.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 , Jon Callas , Peter Gutmann , Nils Durner , "alessandro.barenghi\@polimi.it" , "openpgp\@ietf.org" Date: Wed, 29 Apr 2015 08:16:39 +0200 In-Reply-To: (David Leon Gil's message of "Tue, 28 Apr 2015 21:56:36 -0700") Message-ID: <87sibj792w.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: Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 06:21:50 -0000 On Wed, 29 Apr 2015 06:56, coruus@gmail.com said: > An implementation MAY decrypt SKESKs using the deprecated S2K > algorithm, but MUST NOT create new SKESKs using those algorithms. Nope. That depends on the capabilities of the recipient. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Apr 29 03:12: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 7A0BF1ACD0C for ; Wed, 29 Apr 2015 03:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.43 X-Spam-Level: X-Spam-Status: No, score=0.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PROFILE2=1.981, HELO_EQ_DE=0.35, 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 STO7Cg4-jEs5 for ; Wed, 29 Apr 2015 03:12:10 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id AA9361A2130 for ; Wed, 29 Apr 2015 03:12:10 -0700 (PDT) Received: from p5ddfa0d2.dip0.t-ipconnect.de ([93.223.160.210] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1YnOyM-0004On-0T; Wed, 29 Apr 2015 10:12:06 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YnOvM-0008EH-OY; Wed, 29 Apr 2015 12:12:06 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1YnOvL-000742-V1; Wed, 29 Apr 2015 12:09:00 +0200 Date: Wed, 29 Apr 2015 12:08:59 +0200 Message-ID: <87d22nfdqc.wl-neal@walfield.org> From: "Neal H. Walfield" To: Alessandro Barenghi In-Reply-To: <553FB1AD.7060600@polimi.it> References: <1430167217.658.2.camel@scientia.net> <553FB1AD.7060600@polimi.it> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 29 Apr 2015 10:12:12 -0000 At Tue, 28 Apr 2015 16:13:33 +0000, Alessandro Barenghi wrote: > On 04/28/2015 03:58 PM, Phillip Hallam-Baker wrote: > > > The equivalent Base2-20 fingerprint would be a sequence of images and > > have a work factor of (2^112) > > > > [z]-[z]-[z]-[z]-[z]-[z] > > > > > > Anyone know where we might scrounge a million images? WikiSource perhaps? > > > > It would probably behoove us to check them in some fashion but this > > could be crowdsourced. > > > > The idea of using images as an alphabet has ample prior art going back > > to ancient Egypt. > > In this case, wouldn't it be viable, while keeping a text representation > of the fingerprint, to employ a diceware-password-like approach to > represent the fingerprint? > > With a reasonable english dictionary you get ~15 bits per word, which > gets you up to a reasonable margin rather fast (~8 words) and is easier > to inspect and compare visually. I wonder if less if not more. If you look at the diceware list, it has "easy to remember words" like "aaaa", "abner" and "adair". And, this list is just 7776 words long. These are not only hard for a native speaker to memorize, but also for those who speak english as a second language. If we are going to make a new word list, I would recommend using something based on the voice of america simply word list. This includes 1500 simple words, which all english speakers with basic proficiency are familiar with. Alternatively, there is the PGP Biometric word list [1], which aren't as simple, but are phonetically distinct. [1] https://en.wikipedia.org/wiki/Biometric_word_list Neal From nobody Wed Apr 29 07:06: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 3B0F71A6F33 for ; Wed, 29 Apr 2015 07:06:14 -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 DMHFXCo4cojA for ; Wed, 29 Apr 2015 07:06: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 BC7FB1A701E for ; Wed, 29 Apr 2015 07:02:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2B13BE2038; Wed, 29 Apr 2015 10:02:40 -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 15169-02; Wed, 29 Apr 2015 10:02:37 -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 7FCEEE2035; Wed, 29 Apr 2015 10:02:37 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3TE2aR0029406; Wed, 29 Apr 2015 10:02:36 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> <1430236740.658.40.camel@scientia.net> Date: Wed, 29 Apr 2015 10:02:36 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 28 Apr 2015 12:07:49 -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: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 29 Apr 2015 14:06:14 -0000 Phillip, Phillip Hallam-Baker writes: > On Tue, Apr 28, 2015 at 11:59 AM, Christoph Anton Mitterer > wrote: >> On Tue, 2015-04-28 at 11:36 -0400, Phillip Hallam-Baker wrote: >>> On Tue, Apr 28, 2015 at 10:04 AM, Derek Atkins wrote: >>> >>> > Of course. And in many use cases that's probably sufficient. I see use >>> > cases where it is not sufficient so I'd like to re-gain that feature. >>> >>> I think this is a use case but a distinct usecase from the usual >>> interpretation of fingerprint on a businesscard. >>> >>> We need a range of fingerprints for different purposes and that is why >>> I want to have the content-type to be part of the data that is being >>> hashed. >> >> Maybe it's just me but you seem to often mix up different topics... >> >> What has the question of hard expiration times to do with the >> fingerprint formats, content-types or fingerprint use cases? > > Derek and Jon are both discussing opposed use cases within OpenPGP > scope. I am pointing out that we are discussing one special case of > what should be a generic mechanism. > > While IETF charters are narrow, we are also supposed to be looking for > ways to work with other IETF groups and make our work as useful as > possible to other groups. > > Charter fetishes really don't help. Especially when we don't have a charter yet. > > > Putting the MIME content type in the data to be digested is the right > approach for OpenPGP and the right approach for IETF in general. You are still, as Christoph pointed out, mixing topics. I think we all would appreciate it if you kept to the thread topics, or at least make it clear how and why you are jumping ship. On the face of it, talking about hard expiration times has NOTHING to do with fingerprint formats. It is, however, tangentially related only because part of what Jon and I are discussing is whether the (OPTIONAL!) hard expiration time should be in a portion of the data structure that gets included in signature and fingerprint calculations. Now, whether the user decides to use that optional feature is, of course, up to the user. If they choose not to (i.e., leave it at 0) then the fingerprint (and signatures) would cover the key material forever. However if they DO decide to use the feature (and set an expiration time) then the fingerprint would change if someone tried to manipulate that expiration time (also invalidating all existing signatures). Still, this discussion is absolutely completely orthogonal to fingerprint output formats, using text or image representations, or whether to include a checksum in the (printed) fingerprint. For these types of discussions please use a different thread. Thanks, > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 29 07:10: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 AC3721A1ADC for ; Wed, 29 Apr 2015 07:10:28 -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 d43UdVkIK3T5 for ; Wed, 29 Apr 2015 07:10:27 -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 83F071A8935 for ; Wed, 29 Apr 2015 07:07:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 551BBE2038; Wed, 29 Apr 2015 10:07:10 -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 15169-03; Wed, 29 Apr 2015 10:07:08 -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 B4BC5E2035; Wed, 29 Apr 2015 10:07:08 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3TE78ar029626; Wed, 29 Apr 2015 10:07:08 -0400 From: Derek Atkins To: Phillip Hallam-Baker References: <1430167217.658.2.camel@scientia.net> <1430240265.658.56.camel@scientia.net> Date: Wed, 29 Apr 2015 10:07:08 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 28 Apr 2015 13:04:05 -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: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 29 Apr 2015 14:10:28 -0000 Phillip Hallam-Baker writes: > On Tue, Apr 28, 2015 at 12:57 PM, Christoph Anton Mitterer > wrote: >> On Tue, 2015-04-28 at 11:58 -0400, Phillip Hallam-Baker wrote: >>> Look, my concern here is purely that I don't want to have to redo the >>> code I write this week because someone proposes this as an addition >>> later on. >> >> I guess we're just at the start of the next standard,... writing code >> now and assuming (and/or demanding) things to be stable is probably a >> bad idea. > > My concern is that when a nincompoop decided to release code > implementing the tag in HTML he gave the community less than 16 > hours to review before he had made it a fait accompli. As a result the > tag still does not handle displays with resolutions other than > 75dpi consistently twenty years later. > > Once code ships it is very hard to put the toothpaste back in the tube. I think you'll get more than 16 hours to study things here. So let's not be more melodramatic than usual, please. Indeed, you've had many more that that so far and still haven't provided a use case for someone to actually need to type in a fingerprint such that a checksum would be useful. All I've received is "but.. but.. someone COULD come up with one" or this example of the HTML img tag, neither of which is useful to anyone to decide to add (apparently needless) complexity when we're trying to reduce complexity. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 29 07:11: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 D2B0D1A9166 for ; Wed, 29 Apr 2015 07:11:30 -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 FYq3LTpqDbtr for ; Wed, 29 Apr 2015 07:11:28 -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 BDF031A86EA for ; Wed, 29 Apr 2015 07:08:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 48482E2038; Wed, 29 Apr 2015 10:08: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 15169-04; Wed, 29 Apr 2015 10:08:29 -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 20156E2035; Wed, 29 Apr 2015 10:08:29 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3TE8Swk029713; Wed, 29 Apr 2015 10:08:28 -0400 From: Derek Atkins To: David Leon Gil References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> <553FF387.9000501@googlemail.com> <87wq0v794r.fsf@vigenere.g10code.de> Date: Wed, 29 Apr 2015 10:08:28 -0400 In-Reply-To: <87wq0v794r.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 29 Apr 2015 08:15:32 +0200") 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: Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 14:11:31 -0000 Werner Koch writes: > On Wed, 29 Apr 2015 06:51, coruus@gmail.com said: > >> I think that streaming encryption is well outside the scope of this >> WG. Is there some compelling argument that it is required for >> encrypting email messages? > > OpenPGP is not only for email but even for that it is important. Being > able to process data in one pass is a MUST. It has actually been a > design criteria for all core IETF protocols. Think only about backups. +1. Streaming data has been and always should be in-scope for OpenPGP. > Salam-Shalom, > > Werner -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 29 07:15: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 C219F1A6F33 for ; Wed, 29 Apr 2015 07:15:27 -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_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, FRT_PROFILE2=1.981, 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 PtzK4KxOuRq6 for ; Wed, 29 Apr 2015 07:15:26 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::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 D01F81A8932 for ; Wed, 29 Apr 2015 07:13:26 -0700 (PDT) Received: by layy10 with SMTP id y10so21120712lay.0 for ; Wed, 29 Apr 2015 07:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=af7N8bYypFLgUfvhhofRfmGXli7WUZdzc6BCkFdsDiQ=; b=ZKYio39Y+Vv5f6oM9VW6syuON0fDR/osG/56L4TsJMtBKrMwyZPQ8M8jY1MEX2sGCt aK9kynRNAUM/Br6n72S3wimBUkZOPyasI3YYomcAccAdOyb9IkRgSh9UTG1sxVp0TKwD yV0DbNYwjFyIDQemm8yqeKtCbIknEz2r+gY0BreN/38Pc8g35I+vA54/M1A4GUni/okF TtFtgmktLEBRbdcFhWNobeO7Upf2T3N69dPuQWVHLFJ7XvHmFcdQIB5RZSgBycPC8dN5 7aIb8USKrDcyJ76cvFuCs7yO96TNzlnI+eXy4wX0wkI8AOiT2gLApv8ayS22eQ5cokT4 oaKQ== MIME-Version: 1.0 X-Received: by 10.153.7.104 with SMTP id db8mr15086820lad.124.1430316805285; Wed, 29 Apr 2015 07:13:25 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 29 Apr 2015 07:13:25 -0700 (PDT) Date: Wed, 29 Apr 2015 10:13:25 -0400 X-Google-Sender-Auth: cfa3cuRo4wKSiMUKXKGytcgIkxo Message-ID: From: Phillip Hallam-Baker To: "Neal H. Walfield" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Alessandro Barenghi , IETF OpenPGP Subject: [openpgp] Crowdsourcing Base214 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, 29 Apr 2015 14:15:27 -0000 On Wed, Apr 29, 2015 at 6:08 AM, Neal H. Walfield wrote: > I wonder if less if not more. > > If you look at the diceware list, it has "easy to remember words" like > "aaaa", "abner" and "adair". And, this list is just 7776 words long. > These are not only hard for a native speaker to memorize, but also for > those who speak english as a second language. > > If we are going to make a new word list, I would recommend using > something based on the voice of america simply word list. This > includes 1500 simple words, which all english speakers with basic > proficiency are familiar with. > > Alternatively, there is the PGP Biometric word list [1], which aren't > as simple, but are phonetically distinct. > > [1] https://en.wikipedia.org/wiki/Biometric_word_list The larger the alphabet, the shorter the fingerprint. Since there is no need to keep the images/words on the device, the size of the dictionary is not that critical. Fingerprints with the PGP biometric list are rather too long. Looking at the options, it seems like somewhere between 13 and 16 (inclusive) is the sweet spot. Above 64K entries, curating the list is just too hard. Back in 1995, memory constraints were very different. I would very much like to keep the size of the fingerprint within the 7+/-2 working memory limit and provide at least 100 effective bits. That requires each glyph encode at least 14 bits. Presenting images in two sets of four seems to work quite well on an Apple Watch. And a smartphone seems to be able to present eight at once without too much hassle. The big advantage to 14 bits is that it then allows a direct mapping to the CJK unified characters in Unicode. This looks to me to be an excellent opportunity to engage the wider community and to crowdsource parts of the process. There are hundreds of people willing to help. Give each person a part of the image space to curate and we can have the process done pretty quick. So lets say someone has 'road motor transport' for 256 entries. She then breaks that down into 'cars', 'trucks', 'buses', 'motorcycles' and then within each category finds 64 distinctly different examples. Someone else does the same for 'unpowered transport', 'marine transport', etc. A wiki is probably sufficient for the necessary collaboration. The purpose of this isn't just to get the best result. Engage the community and they become advocates and early adopters. And we need advocates who are not from the crypto community. For the word lists, I am thinking that the best approach is to start off with a fairly large dictionary and filter it by putting it through google translate and seeing what distinct words survive translation from English to French and back. Then take the dictionary and machine translate it into 16 odd different languages as a starting point and compute Merkle trees over each individual corpus. Probably the thing to do is begin with a Base 2^14 scheme which could be expanded if desired to 2^16. From nobody Wed Apr 29 07:16: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 71F0B1A1A6D for ; Wed, 29 Apr 2015 07:16:32 -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 SVCj-szU0ri2 for ; Wed, 29 Apr 2015 07:16:31 -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 48B9B1A1F02 for ; Wed, 29 Apr 2015 07:15:13 -0700 (PDT) Received: by labbd9 with SMTP id bd9so21129146lab.2 for ; Wed, 29 Apr 2015 07:15:11 -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=XfSOLklJ4qXUEz+91Mooo0PwgDR5kvnx+/llT+2aL1A=; b=kcLoATm4IDZJ52gHEJs8VkPyvgK90AwgC+PJ27NZDycdldKkATeZ8ky6yMPhxg0LuF PLcgYDpvNVsEuZwODqw41g1bT94tnHw5ndytbf02inj9MDFvMSQGbtSUKF1h1Ox110TB rREoav57To/KjGm6jcV7yb3BXgIL0eaiM+gV6Dn9HQ3i4eln+afut29SXLTXF2LyQKkA 2JWJ3pJpDfjzKYtveKtu7sktYGV6RURPLIiyn/+709K1f5u/j3Te+OMI+GY2hoY5ceJO eY3oCktxAdKcQddii+UEYMqSnION7Brz36ok6wiS7yYxRzvZM7cJy998fVLK0sNuBAWC yk9g== X-Received: by 10.152.28.34 with SMTP id y2mr19423623lag.14.1430316911860; Wed, 29 Apr 2015 07:15:11 -0700 (PDT) MIME-Version: 1.0 References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <87sibj792w.fsf@vigenere.g10code.de> In-Reply-To: <87sibj792w.fsf@vigenere.g10code.de> From: David Leon Gil Date: Wed, 29 Apr 2015 14:15:11 +0000 Message-ID: To: Jon Callas , Nils Durner , Peter Gutmann , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=089e0158c57a72a0bf0514dd9b55 Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 14:16:32 -0000 --089e0158c57a72a0bf0514dd9b55 Content-Type: text/plain; charset=UTF-8 A SHOULD NOT might be more appropriate in this case. On Tue, Apr 28, 2015 at 11:21 PM Werner Koch wrote: > On Wed, 29 Apr 2015 06:56, coruus@gmail.com said: > > > An implementation MAY decrypt SKESKs using the deprecated S2K > > algorithm, but MUST NOT create new SKESKs using those algorithms. > > Nope. That depends on the capabilities of the recipient. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > --089e0158c57a72a0bf0514dd9b55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A SHOULD NOT might be more appropriate in this case.
On Tue, Apr 28, 2015 at 11:21 PM Werner Koch <wk@gnupg.org> wrote:
On Wed, 29 Apr 2015 06:56, coruus@gmail.com said:

> An implementation MAY decrypt SKESKs using the deprecated S2K
> algorithm, but MUST NOT create new SKESKs using those algorithms.

Nope.=C2=A0 That depends on the capabilities of the recipient.


Shalom-Salam,

=C2=A0 =C2=A0Werner

--
Die Gedanken sind frei.=C2=A0 Ausnahmen regelt ein Bundesgesetz.

--089e0158c57a72a0bf0514dd9b55-- From nobody Wed Apr 29 07:18: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 652BF1A1C04 for ; Wed, 29 Apr 2015 07:18:23 -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 PtsSFUgfN_WL for ; Wed, 29 Apr 2015 07:18:21 -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 3944A1A1BB8 for ; Wed, 29 Apr 2015 07:18:21 -0700 (PDT) Received: by lagv1 with SMTP id v1so21133468lag.3 for ; Wed, 29 Apr 2015 07:18:19 -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=Xhc7MvfZVPzp1aHvScvf2ESirpjpuaC9LWM0/VY0CZI=; b=NtWh/97rMb0UIliY1zpdK9AMmSqUiESCcqqcERm4hGt8D+F1kVR/JbZj9SPfMIMNRd sVNV9VH8Yqf3AbBAQ6vFQ00vNROOavkUy8GwHbn8JbEtTcDBLvA1W2NsnVA51th1v6PG KTut/mL0Ug7FLeHHf2SxfHs6OWtqikk2nG/KXmTqE4dTvJBeB544+l6F7iNK5eBsP66Q th6DXgqV7MDeKnTd8UgXV1ID3lKtHb/r6mSvdCkrVGrw6snIiPI+MX0U/uZmFnHfwBu6 EjWI4WnXjF8RlVUBEUET5MZf0KkEp5tnXvjS6CDs/ZbrEGfHz8/rT5nuqaP3WozKMCIm u2Ug== X-Received: by 10.152.234.139 with SMTP id ue11mr19198776lac.28.1430317099713; Wed, 29 Apr 2015 07:18:19 -0700 (PDT) MIME-Version: 1.0 References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> <553FF387.9000501@googlemail.com> <87wq0v794r.fsf@vigenere.g10code.de> In-Reply-To: From: David Leon Gil Date: Wed, 29 Apr 2015 14:18:19 +0000 Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=001a1133a85ca509790514dda632 Archived-At: Cc: Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 14:18:23 -0000 --001a1133a85ca509790514dda632 Content-Type: text/plain; charset=UTF-8 I think that both I and Tom Ritter have previously linked to Adam Langley's post on this: Doing this right requires 'packetizing' data and computing partial authenticators. I also am not sure how backups are in scope for a network working group... Is there something I'm missing? On Wed, Apr 29, 2015 at 7:08 AM Derek Atkins wrote: > Werner Koch writes: > > > On Wed, 29 Apr 2015 06:51, coruus@gmail.com said: > > > >> I think that streaming encryption is well outside the scope of this > >> WG. Is there some compelling argument that it is required for > >> encrypting email messages? > > > > OpenPGP is not only for email but even for that it is important. Being > > able to process data in one pass is a MUST. It has actually been a > > design criteria for all core IETF protocols. Think only about backups. > > +1. > > Streaming data has been and always should be in-scope for OpenPGP. > > > Salam-Shalom, > > > > Werner > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > --001a1133a85ca509790514dda632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that both I and Tom Ritter have previously linked to Adam Langley&#= 39;s post on this: Doing this right requires 'packetizing' data and= computing partial authenticators.

I also am not sure how backups a= re in scope for a network working group... Is there something I'm missi= ng?
On Wed, Apr 29, 2015 at 7:08 AM Derek Atk= ins <derek@ihtfp.com> wrote:
Werner Koch <wk@gnupg.org> writes:

> On Wed, 29 Apr 2015 06:51, coruus@gmail.com said:
>
>> I think that streaming encryption is well outside the scope of thi= s
>> WG. Is there some compelling argument that it is required for
>> encrypting email messages?
>
> OpenPGP is not only for email but even for that it is important.=C2=A0= Being
> able to process data in one pass is a MUST.=C2=A0 It has actually been= a
> design criteria for all core IETF protocols.=C2=A0 Think only about ba= ckups.

+1.

Streaming data has been and always should be in-scope for OpenPGP.

> Salam-Shalom,
>
>=C2=A0 =C2=A0 Werner

--
=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.com=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
--001a1133a85ca509790514dda632-- From nobody Wed Apr 29 07:19: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 68D641A1C04 for ; Wed, 29 Apr 2015 07:19:28 -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 JVaQHpku1SPy for ; Wed, 29 Apr 2015 07:19:27 -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 ECFC71A1BE9 for ; Wed, 29 Apr 2015 07:19:26 -0700 (PDT) Received: by labbd9 with SMTP id bd9so21232682lab.2 for ; Wed, 29 Apr 2015 07:19:25 -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=a3CV7Zm8WHKmIFmKs1lNJkG1rKYgr57Rzr+ECh8aq/k=; b=ZxWyPeWLe7zaq7UxPvga2kN9pDsUOayuDBOLkC1QXZIo/HgpBbgy8CkbzJ81VWCZ5I IUGnYkIRFCiYTCbgZqZLz+0sDlzluzdrXOQye+meYIkA1JdKA9CnfxHXsjBroLDaRBrb ZRl0BW22tmGnBgH+Pd44Vp4HQR1OWQWfXJFyDUyeNhOvEKrAd/aB156uQedaMS7lpSS3 ogcZTH9H3cbp2kzKWBg2YuiiRhVaGvqsAH+pGyRROyjcIXQEolosY3GwNc/DW4/1tYv9 TNRTaav+VwMRbVFdu2PLswQlNoioyp8GcmWga6vI+1zTPY5JpTvrHLyjSJmtPNFu3CVd 9hzg== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr19280980lab.79.1430317165529; Wed, 29 Apr 2015 07:19:25 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 29 Apr 2015 07:19:25 -0700 (PDT) In-Reply-To: References: <1430167217.658.2.camel@scientia.net> <1430240265.658.56.camel@scientia.net> Date: Wed, 29 Apr 2015 10:19:25 -0400 X-Google-Sender-Auth: E9uOVnttXgTlXKpkRVZyBuTT7UQ Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 29 Apr 2015 14:19:28 -0000 On Wed, Apr 29, 2015 at 10:07 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > >> On Tue, Apr 28, 2015 at 12:57 PM, Christoph Anton Mitterer >> wrote: >>> On Tue, 2015-04-28 at 11:58 -0400, Phillip Hallam-Baker wrote: >>>> Look, my concern here is purely that I don't want to have to redo the >>>> code I write this week because someone proposes this as an addition >>>> later on. >>> >>> I guess we're just at the start of the next standard,... writing code >>> now and assuming (and/or demanding) things to be stable is probably a >>> bad idea. >> >> My concern is that when a nincompoop decided to release code >> implementing the tag in HTML he gave the community less than 16 >> hours to review before he had made it a fait accompli. As a result the >> tag still does not handle displays with resolutions other than >> 75dpi consistently twenty years later. >> >> Once code ships it is very hard to put the toothpaste back in the tube. > > I think you'll get more than 16 hours to study things here. So let's > not be more melodramatic than usual, please. My point was, I don't want to be the next nincompoop. > Indeed, you've had many more that that so far and still haven't provided > a use case for someone to actually need to type in a fingerprint such > that a checksum would be useful. All I've received is > "but.. but.. someone COULD come up with one" or this example of the HTML > img tag, neither of which is useful to anyone to decide to add > (apparently needless) complexity when we're trying to reduce complexity. Yes, I conceded that already. I think it is pretty clear that if anyone wants to resurrect Base32C they have to show a really good use case that can't be addressed by an autocomplete/autocorrect service. From nobody Wed Apr 29 07:21: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 4BA111A6FF1 for ; Wed, 29 Apr 2015 07:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 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, FRT_PROFILE2=1.981, 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 8vPj8SHDbmkh for ; Wed, 29 Apr 2015 07:21:16 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 5089B1A700D for ; Wed, 29 Apr 2015 07:21:13 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so21367472lbb.3 for ; Wed, 29 Apr 2015 07:21:11 -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=ioWyh6fV4df8pHzGWI78kQoZ2SW/FJdN4BwjLYVja1k=; b=ynIzEL6Yb4s+qvmwcHkD1q20W9GY1Z1D0cAapYkj8AaH0liC/v062c4VUwmVAUeHbF KHgmLFkmkOhZzAs5aiHygJNMY5iorNvaForDpEf/IBUqAi9HmZD+F+XdXlyDJIRI+fTl UZJCmX+2zPN2+POz5MUWffW5q9jRCtaKb1bEV8wvlCTaRsaNkpUzTnhg9xUuM7op5e6M fAIc9oSv8fzpWveS2501Fmk2ipgvdVdn2+n0BPuVZipfL3n5gAzcfDLF7t8oBaM2g4/H 4mu6D9RO0DXAH2H79hbHZ2hlTBJxBkhB9TBeamDgZOkf7EWejdI65MPLBlddIB+HgyVr nH/A== X-Received: by 10.112.167.166 with SMTP id zp6mr19432065lbb.80.1430317271849; Wed, 29 Apr 2015 07:21:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Leon Gil Date: Wed, 29 Apr 2015 14:21:11 +0000 Message-ID: To: Phillip Hallam-Baker , "Neal H. Walfield" Content-Type: multipart/alternative; boundary=001a11c32b04e7a0b60514ddb039 Archived-At: Cc: Alessandro Barenghi , IETF OpenPGP Subject: Re: [openpgp] Crowdsourcing Base214 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, 29 Apr 2015 14:21:18 -0000 --001a11c32b04e7a0b60514ddb039 Content-Type: text/plain; charset=UTF-8 64k words is quite feasible. If someone is interested enough in this topic to write up a Mechanical Turk job, I'm happy to pay for running it. On Wed, Apr 29, 2015 at 7:15 AM Phillip Hallam-Baker wrote: > On Wed, Apr 29, 2015 at 6:08 AM, Neal H. Walfield > wrote: > > > I wonder if less if not more. > > > > If you look at the diceware list, it has "easy to remember words" like > > "aaaa", "abner" and "adair". And, this list is just 7776 words long. > > These are not only hard for a native speaker to memorize, but also for > > those who speak english as a second language. > > > > If we are going to make a new word list, I would recommend using > > something based on the voice of america simply word list. This > > includes 1500 simple words, which all english speakers with basic > > proficiency are familiar with. > > > > Alternatively, there is the PGP Biometric word list [1], which aren't > > as simple, but are phonetically distinct. > > > > [1] https://en.wikipedia.org/wiki/Biometric_word_list > > > The larger the alphabet, the shorter the fingerprint. Since there is > no need to keep the images/words on the device, the size of the > dictionary is not that critical. > > Fingerprints with the PGP biometric list are rather too long. Looking > at the options, it seems like somewhere between 13 and 16 (inclusive) > is the sweet spot. Above 64K entries, curating the list is just too > hard. > > Back in 1995, memory constraints were very different. > > > I would very much like to keep the size of the fingerprint within the > 7+/-2 working memory limit and provide at least 100 effective bits. > That requires each glyph encode at least 14 bits. > > Presenting images in two sets of four seems to work quite well on an > Apple Watch. And a smartphone seems to be able to present eight at > once without too much hassle. > > The big advantage to 14 bits is that it then allows a direct mapping > to the CJK unified characters in Unicode. > > > > This looks to me to be an excellent opportunity to engage the wider > community and to crowdsource parts of the process. There are hundreds > of people willing to help. Give each person a part of the image space > to curate and we can have the process done pretty quick. > > So lets say someone has 'road motor transport' for 256 entries. She > then breaks that down into 'cars', 'trucks', 'buses', 'motorcycles' > and then within each category finds 64 distinctly different examples. > Someone else does the same for 'unpowered transport', 'marine > transport', etc. > > A wiki is probably sufficient for the necessary collaboration. > > > The purpose of this isn't just to get the best result. Engage the > community and they become advocates and early adopters. And we need > advocates who are not from the crypto community. > > > For the word lists, I am thinking that the best approach is to start > off with a fairly large dictionary and filter it by putting it through > google translate and seeing what distinct words survive translation > from English to French and back. > > Then take the dictionary and machine translate it into 16 odd > different languages as a starting point and compute Merkle trees over > each individual corpus. > > > Probably the thing to do is begin with a Base 2^14 scheme which could > be expanded if desired to 2^16. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a11c32b04e7a0b60514ddb039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 64k words is quite feasible. If someone is interested enough in this topic = to write up a Mechanical Turk job, I'm happy to pay for running it.
=
On Wed, Apr 29, 2015 at 7:15 AM Phillip Hallam-B= aker <phill@hallambaker.com= > wrote:
On Wed, Apr 29, 2015 at 6:08 = AM, Neal H. Walfield <neal@walfield.org> wrote:

> I wonder if less if not more.
>
> If you look at the diceware list, it has "easy to remember words&= quot; like
> "aaaa", "abner" and "adair".=C2=A0 And, = this list is just 7776 words long.
> These are not only hard for a native speaker to memorize, but also for=
> those who speak english as a second language.
>
> If we are going to make a new word list, I would recommend using
> something based on the voice of america simply word list.=C2=A0 This > includes 1500 simple words, which all english speakers with basic
> proficiency are familiar with.
>
> Alternatively, there is the PGP Biometric word list [1], which aren= 9;t
> as simple, but are phonetically distinct.
>
> [1] https://en.wikipedia.org/wiki/Biometric_word_list


The larger the alphabet, the shorter the fingerprint. Since there is
no need to keep the images/words on the device, the size of the
dictionary is not that critical.

Fingerprints with the PGP biometric list are rather too long. Looking
at the options, it seems like somewhere between 13 and 16 (inclusive)
is the sweet spot. Above 64K entries, curating the list is just too
hard.

Back in 1995, memory constraints were very different.


I would very much like to keep the size of the fingerprint within the
7+/-2 working memory limit and provide at least 100 effective bits.
That requires each glyph encode at least 14 bits.

Presenting images in two sets of four seems to work quite well on an
Apple Watch. And a smartphone seems to be able to present eight at
once without too much hassle.

The big advantage to 14 bits is that it then allows a direct mapping
to the CJK unified characters in Unicode.



This looks to me to be an excellent opportunity to engage the wider
community and to crowdsource parts of the process. There are hundreds
of people willing to help. Give each person a part of the image space
to curate and we can have the process done pretty quick.

So lets say someone has 'road motor transport' for 256 entries. She=
then breaks that down into 'cars', 'trucks', 'buses'= ;, 'motorcycles'
and then within each category finds 64 distinctly different examples.
Someone else does the same for 'unpowered transport', 'marine transport', etc.

A wiki is probably sufficient for the necessary collaboration.


The purpose of this isn't just to get the best result. Engage the
community and they become advocates and early adopters. And we need
advocates who are not from the crypto community.


For the word lists, I am thinking that the best approach is to start
off with a fairly large dictionary and filter it by putting it through
google translate and seeing what distinct words survive translation
from English to French and back.

Then take the dictionary and machine translate it into 16 odd
different languages as a starting point and compute Merkle trees over
each individual corpus.


Probably the thing to do is begin with a Base 2^14 scheme which could
be expanded if desired to 2^16.

_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--001a11c32b04e7a0b60514ddb039-- From nobody Wed Apr 29 07:23: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 CBCF21A6FFC for ; Wed, 29 Apr 2015 07:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PROFILE2=1.981, SPF_HELO_PASS=-0.001, 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 jVSPyWqASN3y for ; Wed, 29 Apr 2015 07:23:32 -0700 (PDT) Received: from singpolyma.net (singpolyma.net [184.107.182.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB821A6F3C for ; Wed, 29 Apr 2015 07:23:32 -0700 (PDT) Received: by singpolyma.net (Postfix, from userid 1000) id 1CC11F2127; Wed, 29 Apr 2015 14:23:31 +0000 (UTC) Date: Wed, 29 Apr 2015 09:23:31 -0500 From: Stephen Paul Weber To: Phillip Hallam-Baker Message-ID: <20150429142331.GA1334@xobs-novena> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed 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.23 (2014-03-12) Archived-At: Cc: Alessandro Barenghi , "Neal H. Walfield" , IETF OpenPGP Subject: Re: [openpgp] Crowdsourcing Base214 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, 29 Apr 2015 14:23:33 -0000 >> If we are going to make a new word list, I would recommend using >> something based on the voice of america simply word list. This >> includes 1500 simple words, which all english speakers with basic >> proficiency are familiar with. The project I maintain for encoding binary to works used an interesting criteria (I did not select this criteria, I only maintain the software) for the wordlist: From nobody Wed Apr 29 07:27: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 0EFB31A1B87 for ; Wed, 29 Apr 2015 07:27: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 1KyZO4QaYp59 for ; Wed, 29 Apr 2015 07:27:22 -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 39F021A1B6C for ; Wed, 29 Apr 2015 07:27:21 -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 1A1BB5FB15 for ; Wed, 29 Apr 2015 14:27:20 +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 UU-uBlLWrUnK for ; Wed, 29 Apr 2015 14:27:18 +0000 (UTC) Received: from heisenberg.fritz.box (ppp-188-174-18-198.dynamic.mnet-online.de [188.174.18.198]) (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, 29 Apr 2015 14:27:18 +0000 (UTC) Message-ID: <1430317637.13237.22.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 29 Apr 2015 16:27:17 +0200 In-Reply-To: References: <1430167217.658.2.camel@scientia.net> <1430240265.658.56.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-atgzssozQRmZDDsaZQC6" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Fingerprint, Base32 or Base32C? 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, 29 Apr 2015 14:27:29 -0000 --=-atgzssozQRmZDDsaZQC6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-29 at 10:19 -0400, Phillip Hallam-Baker wrote:=20 > > I think you'll get more than 16 hours to study things here. So let's > > not be more melodramatic than usual, please. > My point was, I don't want to be the next nincompoop. Then the best thing is probably to wait a bit and not start implementing (and "selling") things before the real discussions have even started. Actually, I think that (often quite stupid) "activism" than can be seen in many areas of crypto recently (e.g. "web based E2E crypto" which some groups/companies try to sell .... I mean WTF!??!)... are quite concerning. If I'd be the NSA and would want to sustainably weaken crypt... that's just how I'd do it.=20 Cheers, Chris. --=-atgzssozQRmZDDsaZQC6 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQyOTE0Mjcx N1owTwYJKoZIhvcNAQkEMUIEQARG0b1iNjLVZ0wESgZ1+OeuQHTXRxKaZihWvWuEX6OToIprap14 r3VG0kYbYEOu+mWTLZzqbQb8S47QJxNXTDgwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDig9ypnD5sdpjmzPNBm4C+upu2OLNY wze8c+BaJ5yVdpJy17FtrtQdnDLkWSBrK2OD3FYUfW5QkAKN2LWmff+/ANReSDWbQHk1o/5odQSd AysQKyU3U2/s1iSZTNQwAwwflHRuBX8pqsbbM5EWUN8qpW9o+maRNDc7JboVVIxInpV4YBJJG9MK p6srWbn+Sn7uCQnaAwSksiKGt3VujyQt6kte9PzSVMvPLQehHpS3CSoYXwhWf9z+Xy7gVZmuyfxl jA/Xazsy9YO9E+UuDd0Cg2eBz8m7htjWXQpxPi9q5Yn6uAbl4fFbBR4uQn/vjh6C+N1tsCC+i5l4 FnOkeE+VAAAAAAAA --=-atgzssozQRmZDDsaZQC6-- From nobody Wed Apr 29 07:29: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 310F21A1A7E for ; Wed, 29 Apr 2015 07:28: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 WjxvF2zohJbi for ; Wed, 29 Apr 2015 07:28:56 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 3C9C81A1DBE for ; Wed, 29 Apr 2015 07:28:56 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so21650967lbc.1 for ; Wed, 29 Apr 2015 07:28:54 -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=sHCBhlXW7LErh+cVnpe5wgPFru69usEPjiBgvMDNfeo=; b=vx+VH8ajn6bmR2EW4ZNGWWNV1UTcESDsiv1PQkgdsIYbt174iHLTgwgVHat/EUJqZd whSHHCV23zU3408t0qGDCXphXAaQBCaHBD+cbqJG6M1+BnkJFHKc+jzy63TMwBiTXtxB vNdiIOfPkGwmdviLk59QyYyw9MeUAedrOY/ndWlfIgrsxruDdkO5WbW3NUCKrUraOthY kQyT3xeg/3zyiJQNvIJGsgVSOrrLpUWSb8b4oHYGIFUUakb3lV80KeTUXnD6/KuDv5lL 3lcWLpGSbu8tY7ZwVnIVJHvKRgTrmu91zfBlgTWZ5gqly9sAAFsVkFYn7dMFIFvsThgJ PXXQ== MIME-Version: 1.0 X-Received: by 10.152.6.1 with SMTP id w1mr18783115law.91.1430317734819; Wed, 29 Apr 2015 07:28:54 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 29 Apr 2015 07:28:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Apr 2015 10:28:54 -0400 X-Google-Sender-Auth: zXx4KQWw4GsDi8hEVmMqvY80NiY Message-ID: From: Phillip Hallam-Baker To: David Leon Gil Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Alessandro Barenghi , "Neal H. Walfield" , IETF OpenPGP Subject: Re: [openpgp] Crowdsourcing Base214 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, 29 Apr 2015 14:28:58 -0000 On Wed, Apr 29, 2015 at 10:21 AM, David Leon Gil wrote: > 64k words is quite feasible. If someone is interested enough in this topic > to write up a Mechanical Turk job, I'm happy to pay for running it. While the offer is much appreciated, I think that there is a large body of folk who want to be actively engaged in this work but haven't until now because they don't write code, don't do crypto etc. This is something those people are likely to want to work on. If there was a question of funding, we can sell off spots to commercial companies to insert glyphs. Microsoft would probably pay a few bucks to insert 64 Minecraft images. And that would clear the copyright issues nicely. From nobody Wed Apr 29 07:37: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 D0D0B1A1B87 for ; Wed, 29 Apr 2015 07:36:59 -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 dT9wZMLWfIVt for ; Wed, 29 Apr 2015 07:36:58 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 EB6271A1BCB for ; Wed, 29 Apr 2015 07:36:51 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so21813337lbb.2 for ; Wed, 29 Apr 2015 07:36: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=J/5/JqjC+vpLP4MQoi3cZ6yptOmEvUOrEZY1F+wN7xk=; b=IHU0g3ByPnkC5UB5MlzoSsFFbKlXKgpwL7ZPcG0sstqkZUytxJeAEvLp/qRkuyJ631 u4Lji4x4mMCCsWTeNjSpiNZt+jS3UUG0jDdD2S3tiPPudCCscp2S2Lm/P8jVr04cDyG0 +mMeKBXJ5RQLo0D9t5uMAna1oLSm73EQgK0255sZtyFP8ZFUjw6wMiekHmW6TYvOS5N5 VkJiLqe1gEwrbtQ9QeyCuc8GudDVxBYcJBIx7iLtIiw7w1gc4885uYlcPv76zu5UGj53 asxwM6ndVLz9FEBJo4B7vrtANVju7TGufNMfRYgc1w7P05RcfeEdhQHtNGnvmYbKDEH4 9PGQ== MIME-Version: 1.0 X-Received: by 10.112.16.42 with SMTP id c10mr19313290lbd.103.1430318210474; Wed, 29 Apr 2015 07:36:50 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 29 Apr 2015 07:36:50 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> <1430236740.658.40.camel@scientia.net> Date: Wed, 29 Apr 2015 10:36:50 -0400 X-Google-Sender-Auth: w_gf7FO-YXPSLcg8ZYAYqUGEnaE Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 29 Apr 2015 14:37:00 -0000 On Wed, Apr 29, 2015 at 10:02 AM, Derek Atkins wrote: > Phillip, > > Phillip Hallam-Baker writes: > >> On Tue, Apr 28, 2015 at 11:59 AM, Christoph Anton Mitterer >> wrote: >>> On Tue, 2015-04-28 at 11:36 -0400, Phillip Hallam-Baker wrote: >>>> On Tue, Apr 28, 2015 at 10:04 AM, Derek Atkins wrote: >>>> >>>> > Of course. And in many use cases that's probably sufficient. I see use >>>> > cases where it is not sufficient so I'd like to re-gain that feature. >>>> >>>> I think this is a use case but a distinct usecase from the usual >>>> interpretation of fingerprint on a businesscard. >>>> >>>> We need a range of fingerprints for different purposes and that is why >>>> I want to have the content-type to be part of the data that is being >>>> hashed. >>> >>> Maybe it's just me but you seem to often mix up different topics... >>> >>> What has the question of hard expiration times to do with the >>> fingerprint formats, content-types or fingerprint use cases? >> >> Derek and Jon are both discussing opposed use cases within OpenPGP >> scope. I am pointing out that we are discussing one special case of >> what should be a generic mechanism. >> >> While IETF charters are narrow, we are also supposed to be looking for >> ways to work with other IETF groups and make our work as useful as >> possible to other groups. >> >> Charter fetishes really don't help. Especially when we don't have a charter yet. >> >> >> Putting the MIME content type in the data to be digested is the right >> approach for OpenPGP and the right approach for IETF in general. > > You are still, as Christoph pointed out, mixing topics. I think we all > would appreciate it if you kept to the thread topics, or at least make > it clear how and why you are jumping ship. > > On the face of it, talking about hard expiration times has NOTHING to do > with fingerprint formats. It is, however, tangentially related only > because part of what Jon and I are discussing is whether the (OPTIONAL!) > hard expiration time should be in a portion of the data structure that > gets included in signature and fingerprint calculations. The reason I raised fingerprints is that it is the only thing that causes it to make a difference. Precise language is critical. You were confusing people when you talked about expiring a key. That is impossible for the reason Jon points out. Using the terms 'key' and 'key binding assertion' interchangeably leads to confusion. From nobody Wed Apr 29 08:05: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 973471A92FA for ; Wed, 29 Apr 2015 08:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_ORG=0.611, T_DKIM_INVALID=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 jzfMT2z6nEgu for ; Wed, 29 Apr 2015 08:05: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 34A791A9235 for ; Wed, 29 Apr 2015 08:05:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id EE6D3E2035; Wed, 29 Apr 2015 11:05: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 15894-04; Wed, 29 Apr 2015 11:05:24 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 43F90E2036; Wed, 29 Apr 2015 11:05:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1430319924; bh=D+sp4ODgjyGWfrHlFEgM3DJdsBxE/MUAmukezVSBtHA=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=Q4SqXUXEVqYx9uFED30TS36rgGVjn9sIA0NC+GveyveTMO5LdlCjPKTEfrlxNB93h 7WeTPWK3RBpdldrWStKrYlOLY79Z1NE6N+GlTx8Bs8sKBQywbsolZ4iN8hnaSNoNAM /huRl3tpkjNdkiU6EJXmNjW9caLrk4oD89pui9OQ= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 29 Apr 2015 11:05:24 -0400 Message-ID: In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> <1430236740.658.40.camel@scientia.net> Date: Wed, 29 Apr 2015 11:05:24 -0400 From: "Derek Atkins" To: "Phillip Hallam-Baker" 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: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 29 Apr 2015 15:05:32 -0000 Phill, On Wed, April 29, 2015 10:36 am, Phillip Hallam-Baker wrote: > On Wed, Apr 29, 2015 at 10:02 AM, Derek Atkins wrote: [snip] >> On the face of it, talking about hard expiration times has NOTHING to do >> with fingerprint formats. It is, however, tangentially related only >> because part of what Jon and I are discussing is whether the (OPTIONAL!) >> hard expiration time should be in a portion of the data structure that >> gets included in signature and fingerprint calculations. > > The reason I raised fingerprints is that it is the only thing that > causes it to make a difference. Not exactly. It also would affect all signatures on the key. > Precise language is critical. You were confusing people when you > talked about expiring a key. That is impossible for the reason Jon > points out. If by "key" you purely mean the "N,e" values (in RSA terms) then yes, you are correct that there is absolutely no way to revoke a key. (PS: I call this the "key material" specifically to be precise) However if you embed the expiration time into the Key Packet (see below) then you CAN cause a validator to raise questions about potentially "bad" signatures if your private key data gets compromised because any signatures made after the "hard expiration" would be considered invalid. For example, what would you do if you saw a signature dated 2014-12-31 on a key that claimed it was generated on 2015-04-01? (Note that the generation date *IS* still included in V4, and therefore included in fingerprint/keyid/signature calculations). So yes, while you could still reuse the "key materal" in a new "key" (again, see below for nomenclature), if we returned the hard expiration value (ala V3) then it would be a "different" key, which a distinct keyid/fingerprint. It means the WoT would do its job (existing signatures would not apply to the "new" key with the "old" (copied) key material. And signatures made with the new key would either use the new keyid (going back to the WoT non-verified key) or, if they tried to fake it as use the original keyid would revert back to my argument of the previous paragraph, where the dates would need to be forged too which, eventually, stop making sense. I suppose we could raise the question, what is the definition of "revoked"? > Using the terms 'key' and 'key binding assertion' interchangeably > leads to confusion. I've not been using those terms interchangeably. If I have please refer me to my messages where I did so I can make sure I clarify my statements. For the record, when I say "Key" I mean the OpenPGP Public Key Packet (c.f. RFC4880 sec 5.5.2). When I say "key binding assertion" (which I really don't -- I use the phrase "signature" or "selfsig") I am referring to... a signature. ala RFC4880 sec 5.2). Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Apr 29 08:12: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 1FA151A023E for ; Wed, 29 Apr 2015 08:12:11 -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 JsH8dQMpssMA for ; Wed, 29 Apr 2015 08:12:09 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 5C9CF1A0222 for ; Wed, 29 Apr 2015 08:12:09 -0700 (PDT) Received: by wiun10 with SMTP id n10so69663925wiu.1 for ; Wed, 29 Apr 2015 08:12: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 :content-type; bh=tAbjq0e6H9iIN3HbGVsrbAKN0gY1D4DBe2/3nZIIUA4=; b=lMv1185iLJj5dATTw6PBfUUn1OkRnOcwtQ385DLxXFXAfAoLGfD3OOwinllqEhJqLr hpxEmMtZqichBh8/S2Q2qEzgcggO2o2CvjZvm0nm1hjzkz7xmdmtz6voHxR67uqc77Yy maswXKwabOUAYH2A3u3azBvD8P1cn0sWzlvlUPIHJ3iglaMjlMaa3P+idrGslU71v+DM yyR4v/oNefWtoQQiR9+Vaf079uFnWb1B911oRdnq/rdXQh4O+Hmi+Qc9j6mojPUKEyC7 0GBCLMNDgjlsiNtU7W/kTaEHe/FaCx2olEhuZ8knRx9Sqoe2dHF35/CiQ1sxhapHxZ7E 4n/g== MIME-Version: 1.0 X-Received: by 10.180.81.104 with SMTP id z8mr9599218wix.5.1430320328088; Wed, 29 Apr 2015 08:12:08 -0700 (PDT) Received: by 10.194.162.35 with HTTP; Wed, 29 Apr 2015 08:12:07 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <553E26D1.4020304@dominikschuermann.de> <1430144158.15361.2.camel@scientia.net> <553E466C.9030709@dominikschuermann.de> <1e5ffa216a806361377f52e8d69f58e5.squirrel@mail2.ihtfp.org> <874mo1egir.fsf@vigenere.g10code.de> Date: Wed, 29 Apr 2015 16:12:07 +0100 Message-ID: From: Nicholas Cole To: "openpgp@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 29 Apr 2015 15:12:11 -0000 On Tue, Apr 28, 2015 at 3:01 PM, Derek Atkins wrote: > Hi, > > Nicholas Cole writes: > >> On Mon, Apr 27, 2015 at 4:29 PM, Werner Koch wrote: >> >>> FWIW: I have no real preference pro or contra a hard expiration time. >> >> I have not seen anyone in favour of a hard expiration time explain >> what it is designed to prevent / enable. I think the new standard >> should have a real prejudice in favour of excluding anything unless >> there is a clear justification. It could be that I've just missed >> something, but I don't think that standard has been reached here yet. > > You have seen them. You've just ignored them. > > It prevents someone who gains access to your private key the ability to > keep your public key going past your pre-selected expiration time. > Using soft expiration doesn't help in this case because the attacker has > access to your private key and could, as a result, issue additional > self-sigs with extended expirations. No. I haven't ignored them. What you cut out of my email was the point I made that assuming an attacker is in a position to forge or coerce an extension of the key expiration time but would not be in a position to forge or coerce a new key is a very niche model of an attacker. That was the point I made. Unless you think that scenario is likely, I am against adding complexity to the new standard, even if it is small complexity. Please don't tell me I ignored something I didn't. I completely understand the *technical* point being made. What I do not understand is whether the use-case is realistic. Has there *ever* been a confirmed attack that this feature would have prevented? N. From nobody Wed Apr 29 09:24: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 F0CFA1A89A1 for ; Wed, 29 Apr 2015 09:24:44 -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 O9igeOg1ldwI for ; Wed, 29 Apr 2015 09:24:42 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 7E60E1A887C for ; Wed, 29 Apr 2015 09:24:42 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so135034762wic.1 for ; Wed, 29 Apr 2015 09:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y4sAJLbwIoYREJpFGtJJvtHnJBs0pHFJWgGCiJrY9ms=; b=Pek59FRZCcGK3ag++Fk0v3SkH6CHDWqzR/0r1Vsov5gdu+vyPU4Vs4zj8WiF+SOo37 3AtlXErVNla9UvYUvnVQeoaEUr+SEHr0GsjOZ7Qtxk0UvbRmEPdilbmS3KNq4EoKJdpO HMIW79/DQNiyNvV92snfa/SHD/XShMSl9frcxpDlNyswYUR+FhWAGj8sv6Xy6UfyW3Yt UBb8oB/DhJqiYaYKQlOM5MEXbXv+RMMoTByn8yrZlLkfKUOqpCGaKDVH4fz0PpsmiGRK 1zHGvyqyxU6qrHXt5Soy0OMd5BPgOs+wTjx7/rQm+twyFrcoHEvLEHacrDarwOuqYUAH YE0A== X-Received: by 10.194.80.98 with SMTP id q2mr9821196wjx.50.1430324681289; Wed, 29 Apr 2015 09:24:41 -0700 (PDT) Received: from [192.168.188.20] (x55b408a8.dyn.telefonica.de. [85.180.8.168]) by mx.google.com with ESMTPSA id nb9sm21865439wic.10.2015.04.29.09.24.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 09:24:40 -0700 (PDT) Message-ID: <554105C6.2000002@googlemail.com> Date: Wed, 29 Apr 2015 18:24:38 +0200 From: Nils Durner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Leon Gil , Derek Atkins References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> <553FF387.9000501@googlemail.com> <87wq0v794r.fsf@vigenere.g10code.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 16:24:45 -0000 > I also am not sure how backups are in scope for a network working > group... Is there something I'm missing? My application of OpenPGP is encryption of data at rest on potentially memory constrained devices for storage in the cloud. So +1 for streaming. Regards, Nils From nobody Wed Apr 29 09:32: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 8500F1A89FE for ; Wed, 29 Apr 2015 09:32:53 -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 2NMbf1MaF2vp for ; Wed, 29 Apr 2015 09:32:52 -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 0BA9C1A89FB for ; Wed, 29 Apr 2015 09:32:52 -0700 (PDT) Received: by wiun10 with SMTP id n10so72461630wiu.1 for ; Wed, 29 Apr 2015 09:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Y0f7Jje066E5cpICqN+WSkpiqSk1y1+vZJgN8w9C90A=; b=bQWKltfT28OdLR9h5y+4U7dwWnmdgOncAU+Ax6BHablPnG8FV1ITM+YKFugeBmaXaO jL41yhMwNilPvHi6iXv1jUuDS2zSJDbZTKi92mYMKlNAl5nFStAskhOzYNQ8SJiDzT9f CDrfNXUe52w4172KhNF0nVjJmNBbzn55Wt4p61T37HQHx1ZoCJ7vZc4hB1cGBC6qmuWS 9ccpJK0wEcD9Oqu5nuHB7lcJybh+bT6h10x6aRm8lDUY0STA5l7nkOIDU9s/84dxj+Ax VRgDjY9L+Z9YJN66eY3a29Zod7TiSqwSJv8O0KoaN723Lc+/isa0yWqizX/tQ3aFOHYv dkUQ== X-Received: by 10.194.11.73 with SMTP id o9mr44648162wjb.116.1430325170771; Wed, 29 Apr 2015 09:32:50 -0700 (PDT) Received: from [192.168.188.20] (x55b408a8.dyn.telefonica.de. [85.180.8.168]) by mx.google.com with ESMTPSA id gu7sm21894987wib.21.2015.04.29.09.32.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 09:32:49 -0700 (PDT) Message-ID: <554107B0.4040303@googlemail.com> Date: Wed, 29 Apr 2015 18:32:48 +0200 From: Nils Durner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Leon Gil , Jon Callas , Peter Gutmann , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <87sibj792w.fsf@vigenere.g10code.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] 4880bis: Update S2K 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, 29 Apr 2015 16:32:53 -0000 > > An implementation MAY decrypt SKESKs using the deprecated S2K > > algorithm, but MUST NOT create new SKESKs using those algorithms.= > > Nope. That depends on the capabilities of the recipient. > OpenPGP currently offers great compatibility/interoperability. That's not something I would want to see given away simply because S2K-3 is not perceived hype-du-jour compliant without being an actual security problem= =2E +1 for S2K-3 as MAY algo Regards, Nils From nobody Wed Apr 29 10:14: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 BA5E51ACD2D for ; Wed, 29 Apr 2015 10:14: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 eMQOi-vK7wDK for ; Wed, 29 Apr 2015 10:14:13 -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 958E11ACD92 for ; Wed, 29 Apr 2015 10:13:58 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so25475345lbc.1 for ; Wed, 29 Apr 2015 10:13: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=7ow2v3ItjFohfM/R6X1FycTD5RNpFhryb8mkFbibqa0=; b=YbeAalBC+ZwWYPCALTc+UmrO9s0D78Szlgt9djQLVgHLq5fqpLVq+jwJvvTdG6jEW1 nDrGtNQfE3yH/QfxiDcSnkoS+RuG9d2acXwGTabuDbrNW0CXlWTOFKNGjJIZ4ZahBLx8 gws4ZhGno9hPGVQ5YbouVQABoOayKlUi4WZTvj/1htcZ3HZ8u/P9YBB+L2HkAXLU09xi f7lut9E/LzaLAyUkql86fA6txAkADoBfJCRqYQwSAKepII1weO79z6RmUU3gDnHHuTTe q0UppFAnY3cpRTDLZBWI9KVDJjdVUZ+yiR22VfbvsyjD3WFlHnJr4qWlxyB/sWrCCVh2 nyig== MIME-Version: 1.0 X-Received: by 10.112.16.167 with SMTP id h7mr81364lbd.124.1430327637032; Wed, 29 Apr 2015 10:13:57 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 29 Apr 2015 10:13:56 -0700 (PDT) In-Reply-To: References: <5527B621.3040104@cs.tcd.ie> <87CC28F9-4614-4F48-AFE0-EBF2B890EAA6@callas.org> <1429144776.1702.75.camel@scientia.net> <87a8y2znee.fsf_-_@vigenere.g10code.de> <09495422-87FF-4463-91E2-E33830EA4D56@callas.org> <1429617025.11806.88.camel@scientia.net> <672F6B4F-17C7-4020-B6BE-9DAAB7D944A9@callas.org> <93AFAC85-762A-4D4A-AC83-A2D20EE4E555@callas.org> <1430236740.658.40.camel@scientia.net> Date: Wed, 29 Apr 2015 13:13:56 -0400 X-Google-Sender-Auth: GRlcOZX2aCeL0HYg8gfAy4gEiwE Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] rfc3880bis - hard expiration time 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, 29 Apr 2015 17:14:14 -0000 On Wed, Apr 29, 2015 at 11:05 AM, Derek Atkins wrote: > Phill, > > On Wed, April 29, 2015 10:36 am, Phillip Hallam-Baker wrote: >> The reason I raised fingerprints is that it is the only thing that >> causes it to make a difference. > > Not exactly. It also would affect all signatures on the key. > >> Precise language is critical. You were confusing people when you >> talked about expiring a key. That is impossible for the reason Jon >> points out. > > If by "key" you purely mean the "N,e" values (in RSA terms) then yes, you > are correct that there is absolutely no way to revoke a key. (PS: I call > this the "key material" specifically to be precise) However if you embed > the expiration time into the Key Packet (see below) then you CAN cause a > validator to raise questions about potentially "bad" signatures if your > private key data gets compromised because any signatures made after the > "hard expiration" would be considered invalid. > > For example, what would you do if you saw a signature dated 2014-12-31 on > a key that claimed it was generated on 2015-04-01? (Note that the > generation date *IS* still included in V4, and therefore included in > fingerprint/keyid/signature calculations). That is precisely why I would not call that a key. There are two possibilities: 1) A new Key Packet was created that reused an existing key 2) The signature is making a false claim. There are protocols that allow the generation time of keys to be established with certainty within tightly controlled bounds. Specifically, not before one block chain output and not after another. Possibility (1) does occur by accident rather too often. Specifically when an insufficiently random pool is used to generate the key :( One of the things we discovered doing XKMS was that there was a ridiculous number of duplicates for certain keys... Now if you include the fingerprint of the KeyPacket within the scope of the signature, this issue does not occur. Alternatively you can fix the date of a signature exactly via a blockchain. > I suppose we could raise the question, what is the definition of "revoked"? Again, I would assert that it is a statement about a certificate, key packet, key assertion, etc. and not actually a key. From nobody Wed Apr 29 10:28:18 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 C03381ACCFE for ; Wed, 29 Apr 2015 10:28:17 -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 PqkmfA2eX-p1 for ; Wed, 29 Apr 2015 10:28:17 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 A59D91A1A11 for ; Wed, 29 Apr 2015 10:28:16 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so25717682lbb.2 for ; Wed, 29 Apr 2015 10:28:15 -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=B/0vpL5CSP4yKgvFn9zqHLXFK7uVXovZI62ishx4D2g=; b=GTMYOPDi2FiECFdsv0cHXlGnyoxVVA4deTv4n4S6vC8k/zwy4EvE2THd9zV3UVxx5F EoGLNdd7GpR5sfv9PUxq3IDFZ36XZugEhs6xdkHX66moyiVYITb3bupY9A/o7p7q8NOA y5LXe5cMmAeQ3HgKK9g9KrnNVaS2hHyMFbsEgWs0xM5P8MDqs1Yi40k0Z0kUxMR2+ZwY VWlcshLZGLzKivaXDF7aGsFc8okU0mQa4SbjmXfvVsMD9Hb78I4rQivVAhMMWuGUPvxB ycbfH6KV7zrNFy7ckR3QBNpGoo1n8PYgU0Z/cJ+0Oav7U7pcJ1qf0AFHyGqE8QUVfTiG o3dQ== MIME-Version: 1.0 X-Received: by 10.112.16.42 with SMTP id c10mr88673lbd.103.1430328495262; Wed, 29 Apr 2015 10:28:15 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 29 Apr 2015 10:28:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Apr 2015 13:28:14 -0400 X-Google-Sender-Auth: ADnBm5RnmecDa_bcxSgmk8SQP94 Message-ID: From: Phillip Hallam-Baker To: David Leon Gil Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Alessandro Barenghi , "Neal H. Walfield" , IETF OpenPGP Subject: Re: [openpgp] Crowdsourcing Base214 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, 29 Apr 2015 17:28:17 -0000 I have been thinking about the steganography aspects. 8! = 40320 So lets say you decide to encrypt your private key with a 128 bit key and then convert the result to words from the code book. You could then write a sentence using the phrase and keep it in a handy place if you ever need it again. If the words get jumbled up, there is a manageable number of decryption attempts required (40K). From nobody Thu Apr 30 01:06: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 C3D5C1ACEF8 for ; Thu, 30 Apr 2015 01:06:53 -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 Ht7bl4tCjadX for ; Thu, 30 Apr 2015 01:06:51 -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 D9A751ACEFA for ; Thu, 30 Apr 2015 01:06:45 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YnjUa-0006Vx-2j for ; Thu, 30 Apr 2015 10:06:44 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YnjPL-0000FO-Qb; Thu, 30 Apr 2015 10:01:19 +0200 From: Werner Koch To: David Leon Gil References: <5527B621.3040104@cs.tcd.ie> <877ftkqhr4.fsf@vigenere.g10code.de> <87egnbs4fp.fsf@vigenere.g10code.de> <5538A5A9.2020703@polimi.it> <2F8871E0-3DF9-4EF3-A136-5F104BF7307F@callas.org> <9A043F3CF02CD34C8E74AC1594475C73AB0075D3@uxcn10-tdc05.UoA.auckland.ac.nz> <6EAE2413-E6BD-41EB-9A0D-9A56EB18B07B@callas.org> <87mw1sbusl.fsf@vigenere.g10code.de> <553FC996.3010500@googlemail.com> <87618g83v4.fsf@vigenere.g10code.de> <553FF387.9000501@googlemail.com> <87wq0v794r.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 , Derek Atkins , Nils Durner , "alessandro.barenghi\@polimi.it" , "openpgp\@ietf.org" , Jon Callas , Peter Gutmann Date: Thu, 30 Apr 2015 10:01:19 +0200 In-Reply-To: (David Leon Gil's message of "Wed, 29 Apr 2015 14:18:19 +0000") Message-ID: <878uda59kg.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: Nils Durner , "alessandro.barenghi@polimi.it" , "openpgp@ietf.org" , Jon Callas , Peter Gutmann , Derek Atkins Subject: Re: [openpgp] 4880bis: Update S2K 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, 30 Apr 2015 08:06:53 -0000 On Wed, 29 Apr 2015 16:18, coruus@gmail.com said: > I think that both I and Tom Ritter have previously linked to Adam Langley's > post on this: Doing this right requires 'packetizing' data and computing IIRC, that is about "cat foo | decrypt | tar xf -" There are lot of reasons why storing data on a system may fail. It does not help if you are early notified about tampered data instead of checking that after having processed all data. For example an attacker might tamper with the last blocks of the data and your intermittent checks won't help at all. Using Unix tools requires workmanship. Unix is a set of tools which are very powerful if used right. For example for using above quoted pipeline you need to make sure several things: For example, is your tar safe and does not follow ".." file name parts. Of course you unpack into a freshly created subdirectory to avoid cluttering the current directory. You need to check that all tools finished with success, have all kind of extra checks applied to verify signatures during "decrypt", and only then to the mv dance to replace old data by the freshly untared one. Remember: Unix is a user-friendly; it is just picky with whom it chooses to be friends. I would also like to a have a random access encrypted data format option but I doubt that this should be the goal of OpenPGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.