From nobody Fri May 1 12:14:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCAC1AD1DB for ; Fri, 1 May 2015 12:14:18 -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 tsfiukmD9YsR for ; Fri, 1 May 2015 12:14:17 -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 DAE6F1AD0A2 for ; Fri, 1 May 2015 12:14:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A298EBE75; Fri, 1 May 2015 20:14:15 +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 WiqpdaCnOTCy; Fri, 1 May 2015 20:14:14 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.30.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C32EBE59; Fri, 1 May 2015 20:14:14 +0100 (IST) Message-ID: <5543D086.1000503@cs.tcd.ie> Date: Fri, 01 May 2015 20:14: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: "openpgp@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Daniel Kahn Gillmor , cdl@asgaard.org Subject: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 01 May 2015 19:14:18 -0000 Hi all, First - many thanks to all of you who volunteered to help by chairing. It's really encouraging that so many were willing and able, which was the case for I think everyone who volunteered. Having spoken to a few folks, I'm delighted to say that Daniel Kahn Gillmor and Christopher Liljenstolpe (both cc'd on this) have agreed to help out as chairs for the re-formed openpgp WG. Christopher has lots of experience with chairing in the IETF and dkg as you know is very active in lots of security things including PGP so I think they should be a great team to help us move forward. Daniel and Christopher will take it from here with the intent being to try craft a charter along the lines we've already discussed on the list and I'll start the formal chartering process once they tell me that's sufficiently baked (so no need for a BoF before starting). And then we all can get moving on getting the work done. So please join me in thanking Christopher and Daniel for being willing to help out and please help them by continuing to contribute as constructively as you have collectively been doing. Cheers and thanks again all, Stephen. From nobody Fri May 1 14: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 A837A1B2CED for ; Fri, 1 May 2015 13:43:08 -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 eK13oXeD5kg9 for ; Fri, 1 May 2015 13:43:06 -0700 (PDT) Received: from smtp5.emailarray.com (smtp5.emailarray.com [65.39.216.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6671A017F for ; Fri, 1 May 2015 13:43:05 -0700 (PDT) Received: (qmail 67505 invoked by uid 89); 1 May 2015 20:43:04 -0000 Received: from unknown (HELO ?204.29.149.87?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp5.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 May 2015 20:43:04 -0000 From: "Christopher LILJENSTOLPE" To: "Stephen Farrell" Date: Fri, 01 May 2015 13:43:02 -0700 Message-ID: <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> In-Reply-To: <5543D086.1000503@cs.tcd.ie> References: <5543D086.1000503@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: X-Mailman-Approved-At: Fri, 01 May 2015 14:24:44 -0700 Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 01 May 2015 20:43:08 -0000 Greetings, and thank's Stephen (I think) for the opportunity Daniel and I have been talking a bit about the working group, and a charter. We'd like to put some of those ideas to the list for discussion. Ideally, it would be good if we could have some consensus about a charter within the next week or two to start the formation process. We would like to scope this WG fairly tightly, therefore: 1) The primary charter goal would be create a RFC4880bis document. a) At the end of that process, we would either re-charter, or close. b) Other documents (informational or bcp) MAY be entertained by the WG, but are not required for the WG to complete it's task, nor will their progress "keep the WG from closing" 2) We will require at least two independent reviews (from within the WG) of an individual submission before a document is considered a candidate for WG acceptance. The chairs will help chide reviewers, but we want to see interest in the WG in a document before it progresses. 3) We are going to try and run this group virtually as much as possible (i.e. we will only physically meet if necessary). What do you all think about these as chartering concepts? Christopher On 1 May 2015, at 12:14, Stephen Farrell wrote: > Hi all, > > First - many thanks to all of you who volunteered to help by chairing. > It's really encouraging that so many were willing and able, which was > the case for I think everyone who volunteered. > > Having spoken to a few folks, I'm delighted to say that Daniel Kahn > Gillmor and Christopher Liljenstolpe (both cc'd on this) have agreed > to help out as chairs for the re-formed openpgp WG. > > Christopher has lots of experience with chairing in the IETF and dkg > as you know is very active in lots of security things including PGP > so I think they should be a great team to help us move forward. > > Daniel and Christopher will take it from here with the intent being > to try craft a charter along the lines we've already discussed on the > list and I'll start the formal chartering process once they tell me > that's sufficiently baked (so no need for a BoF before starting). And > then we all can get moving on getting the work done. > > So please join me in thanking Christopher and Daniel for being > willing to help out and please help them by continuing to contribute > as constructively as you have collectively been doing. > > Cheers and thanks again all, > Stephen. -- 李柯睿 Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf From nobody Fri May 1 18:43: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 828AE1A00E7 for ; Fri, 1 May 2015 18:43:06 -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 91Rh9uG4iYgU for ; Fri, 1 May 2015 18:43:04 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d: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 6FC1B1A00E6 for ; Fri, 1 May 2015 18:43:04 -0700 (PDT) Received: by qgeb100 with SMTP id b100so44577822qge.3 for ; Fri, 01 May 2015 18:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RuigANG8GvbELD4Sztua2b0WTWR4oiDkfNnejSXaBic=; b=rczt006IUkpm5LP8GMH6S3A+zJ8EveIf6iOGcEQsjmgbDMCLbCUgEOe43Puctj9i7a CzrCEWRJA6HmdxI/3buQGlHdYGQU74+owAlooKtGpJMSdxkiGVOL/Fs1F05v7FODOD6m 9ghbItzKCkwF6A69RjkRZpsGpKQSZm6f4araPohwKPtBNFc2Xs0sWpuH8GHlVDFEVAcz KQ/BxHYc3xDQBkRGyRMJz6vyG7gjIFsy51fYtAt9AATR8gx9o6yHv4OIS9iWo2eE1Cah lYb2+Q44Ef1o8dgckXWopIibaYm1JY7rh6+nIOQUPvhsMFgKbxPVBJCKrHFCMnCGkvKr qV0w== X-Received: by 10.55.41.195 with SMTP id p64mr24596923qkp.107.1430530983799; Fri, 01 May 2015 18:43:03 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id f9sm14322366qhe.34.2015.05.01.18.43.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 May 2015 18:43:02 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> Date: Fri, 1 May 2015 21:43:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <744793BA-2139-4194-9E40-665E968DFBF5@gmail.com> References: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> To: Christopher LILJENSTOLPE Archived-At: Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor , Stephen Farrell Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 02 May 2015 01:43:06 -0000 Sent from my iPhone > On May 1, 2015, at 4:43 PM, "Christopher LILJENSTOLPE" w= rote: >=20 > Greetings, and thank's Stephen (I think) for the opportunity Thanks for taking this on. >=20 > Daniel and I have been talking a bit about the working group, and a cha= rter. We'd like to put some of those ideas to the list for discussion. Ide= ally, it would be good if we could have some consensus about a charter withi= n the next week or two to start the formation process. >=20 > We would like to scope this WG fairly tightly, therefore: >=20 > 1) The primary charter goal would be create a RFC4880bis document. > a) At the end of that process, we would either re-charter, or close. > b) Other documents (informational or bcp) MAY be entertained by the WG, b= ut are not required for the WG to complete it's task, nor will their prog= ress "keep the WG from closing" >=20 > 2) We will require at least two independent reviews (from within the WG) o= f an individual submission before a document is considered a candidate for W= G acceptance. The chairs will help chide reviewers, but we want to see inte= rest in the WG in a document before it progresses. >=20 > 3) We are going to try and run this group virtually as much as possible (i= .e. we will only physically meet if necessary). >=20 > What do you all think about these as chartering concepts? Tight scope, making sure there is adequate interest in drafts, and operating= mostly on list all sounds good. Thank you, Kathleen >=20 > Christopher >=20 >=20 >=20 >> On 1 May 2015, at 12:14, Stephen Farrell wrote: >>=20 >> Hi all, >>=20 >> First - many thanks to all of you who volunteered to help by chairing. >> It's really encouraging that so many were willing and able, which was >> the case for I think everyone who volunteered. >>=20 >> Having spoken to a few folks, I'm delighted to say that Daniel Kahn >> Gillmor and Christopher Liljenstolpe (both cc'd on this) have agreed >> to help out as chairs for the re-formed openpgp WG. >>=20 >> Christopher has lots of experience with chairing in the IETF and dkg >> as you know is very active in lots of security things including PGP >> so I think they should be a great team to help us move forward. >>=20 >> Daniel and Christopher will take it from here with the intent being >> to try craft a charter along the lines we've already discussed on the >> list and I'll start the formal chartering process once they tell me >> that's sufficiently baked (so no need for a BoF before starting). And >> then we all can get moving on getting the work done. >>=20 >> So please join me in thanking Christopher and Daniel for being >> willing to help out and please help them by continuing to contribute >> as constructively as you have collectively been doing. >>=20 >> Cheers and thanks again all, >> Stephen. >=20 >=20 > -- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Avt tace, avt loqvere meliora silentio > Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc > Current vCard here: http://www.asgaard.org/cdl/cdl.vcf >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Fri May 1 19:57:43 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB87C1A0163 for ; Fri, 1 May 2015 19:57:41 -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 P7VjAUXTx1W9 for ; Fri, 1 May 2015 19:57:40 -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 936FE1A0155 for ; Fri, 1 May 2015 19:57:40 -0700 (PDT) Received: by wgin8 with SMTP id n8so104518611wgi.0 for ; Fri, 01 May 2015 19:57:39 -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=Dx177kSXRHLegMqRjEcEiN2uWkdRNou52An6ZpatkBQ=; b=vYWmVCZ6To2ovTWEan/uhEPO3btjD8MD2pwxkK9BJPG+aHDavCp7dnZcmX1j0qVzXM BhWane7xumMLjDKrUzYKW6Tk39G7KoCCKsxPCo/ca03urhUCW3VAfHqWonBtt9wxWThi xfaTce5IgYQCZp4z68Vx0/OrSxd9ksk/0ekl8= 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=Dx177kSXRHLegMqRjEcEiN2uWkdRNou52An6ZpatkBQ=; b=AhP385MCQdHc6FEAajb6M00bc1P9e0F6XElrhROlnSLoBzugJTLIXA4TH7B+OjMuCw /8SmR8PsEQE0nX7kn9L0g9rYLxklB7lJEq04b/ZIK4i/V3YcUg3Vr6wL8l+7EyT+ngj0 aBQi38knwCWaC+ekprTEwdeuRIY9S3avn3Hjb7fMDBFWEpVaxgDhGWcJBUeCf5mXopes YQiqFTgEeQwqcfphWmt/PLOA8HRLUIWspJi8PU7hZNEXVl1dl9W3CgZMi6tumYEWQtw8 sumqI90+90Zi8nNc1jsZjNeQMwq4mVRg4yBG6OJqhO+XeE9768dH5D+SuUJ4vc/I2Zfw O5dQ== X-Gm-Message-State: ALoCoQl/5DW9b0jLfrN7Yqd+rkFK+QIu6veSb/1vL6Y2AussdadkSCKoodm9c5grZsKrykvsYP0y X-Received: by 10.180.231.4 with SMTP id tc4mr1661466wic.27.1430535459338; Fri, 01 May 2015 19:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.141.80 with HTTP; Fri, 1 May 2015 19:57:18 -0700 (PDT) In-Reply-To: References: <1430167217.658.2.camel@scientia.net> <553FB1AD.7060600@polimi.it> From: Tom Ritter Date: Fri, 1 May 2015 21:57:18 -0500 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Alessandro Barenghi , 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: Sat, 02 May 2015 02:57:42 -0000 On 28 April 2015 at 12:01, Phillip Hallam-Baker wrote: > On Tue, Apr 28, 2015 at 12:13 PM, Alessandro Barenghi >> 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. On this topic, I'll point to this usability study some of us designed, but never had the opportunity to conduct: https://github.com/tomrittervg/crypto-usability-study -tom From nobody Fri May 1 21:43: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 5F95E1A03A5 for ; Fri, 1 May 2015 21:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_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 TldMAo4VKi5s for ; Fri, 1 May 2015 21:42:58 -0700 (PDT) Received: from smtp2.emailarray.com (smtp.emailarray.com [69.28.212.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AFF1A03A3 for ; Fri, 1 May 2015 21:42:58 -0700 (PDT) Received: (qmail 76927 invoked by uid 89); 2 May 2015 04:42:56 -0000 Received: from unknown (HELO ?204.29.149.87?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp2.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 May 2015 04:42:56 -0000 From: "Christopher LILJENSTOLPE" To: "Kathleen Moriarty" Date: Fri, 01 May 2015 21:42:55 -0700 Message-ID: <8CB70A56-7CB9-41C9-B2A6-7A21A2FBC895@asgaard.org> In-Reply-To: <744793BA-2139-4194-9E40-665E968DFBF5@gmail.com> References: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> <744793BA-2139-4194-9E40-665E968DFBF5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor , Stephen Farrell Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 02 May 2015 04:43:00 -0000 You are welcome Kathleen Christopher On 1 May 2015, at 18:43, Kathleen Moriarty wrote: > Sent from my iPhone > >> On May 1, 2015, at 4:43 PM, "Christopher LILJENSTOLPE" >> wrote: >> >> Greetings, and thank's Stephen (I think) for the opportunity > > Thanks for taking this on. >> >> Daniel and I have been talking a bit about the working group, and a >> charter. We'd like to put some of those ideas to the list for >> discussion. Ideally, it would be good if we could have some >> consensus about a charter within the next week or two to start the >> formation process. >> >> We would like to scope this WG fairly tightly, therefore: >> >> 1) The primary charter goal would be create a RFC4880bis document. >> a) At the end of that process, we would either re-charter, or close. >> b) Other documents (informational or bcp) MAY be entertained by the >> WG, but are not required for the WG to complete it's task, nor >> will their progress "keep the WG from closing" >> >> 2) We will require at least two independent reviews (from within the >> WG) of an individual submission before a document is considered a >> candidate for WG acceptance. The chairs will help chide reviewers, >> but we want to see interest in the WG in a document before it >> progresses. >> >> 3) We are going to try and run this group virtually as much as >> possible (i.e. we will only physically meet if necessary). >> >> What do you all think about these as chartering concepts? > Tight scope, making sure there is adequate interest in drafts, and > operating mostly on list all sounds good. > > Thank you, > Kathleen >> >> Christopher >> >> >> >>> On 1 May 2015, at 12:14, Stephen Farrell wrote: >>> >>> Hi all, >>> >>> First - many thanks to all of you who volunteered to help by >>> chairing. >>> It's really encouraging that so many were willing and able, which >>> was >>> the case for I think everyone who volunteered. >>> >>> Having spoken to a few folks, I'm delighted to say that Daniel Kahn >>> Gillmor and Christopher Liljenstolpe (both cc'd on this) have agreed >>> to help out as chairs for the re-formed openpgp WG. >>> >>> Christopher has lots of experience with chairing in the IETF and dkg >>> as you know is very active in lots of security things including PGP >>> so I think they should be a great team to help us move forward. >>> >>> Daniel and Christopher will take it from here with the intent being >>> to try craft a charter along the lines we've already discussed on >>> the >>> list and I'll start the formal chartering process once they tell me >>> that's sufficiently baked (so no need for a BoF before starting). >>> And >>> then we all can get moving on getting the work done. >>> >>> So please join me in thanking Christopher and Daniel for being >>> willing to help out and please help them by continuing to contribute >>> as constructively as you have collectively been doing. >>> >>> Cheers and thanks again all, >>> Stephen. >> >> >> -- >> 李柯睿 >> Avt tace, avt loqvere meliora silentio >> Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc >> Current vCard here: http://www.asgaard.org/cdl/cdl.vcf >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp -- 李柯睿 Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf From nobody Sat May 2 02:57: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 1BBA41A1B92 for ; Sat, 2 May 2015 02:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-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 foh-7L1hH4Pd for ; Sat, 2 May 2015 02:57:14 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 350441A1A46 for ; Sat, 2 May 2015 02:57:14 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id AE79011C1625 for ; Sat, 2 May 2015 19:57:12 +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 8iOOoPDwiBVc for ; Sat, 2 May 2015 19:57:03 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 3736111C1618 for ; Sat, 2 May 2015 19:57:02 +1000 (EST) Message-ID: <55449F61.5070401@adversary.org> Date: Sat, 02 May 2015 19:56:49 +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: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> In-Reply-To: <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mvjcPjAcLo3iKmjwmBIxn6r6WrFAPDss8" Archived-At: Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 02 May 2015 09:57:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mvjcPjAcLo3iKmjwmBIxn6r6WrFAPDss8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/05/2015 6:43 am, Christopher LILJENSTOLPE wrote: > Greetings, and thank's Stephen (I think) for the opportunity >=20 > Daniel and I have been talking a bit about the working group, and a= > charter. We'd like to put some of those ideas to the list for > discussion. Ideally, it would be good if we could have some consensus > about a charter within the next week or two to start the formation proc= ess. >=20 > We would like to scope this WG fairly tightly, therefore: >=20 > 1) The primary charter goal would be create a RFC4880bis document. > a) At the end of that process, we would either re-charter, or close.= > b) Other documents (informational or bcp) MAY be entertained by the > WG, but are not required for the WG to complete it's task, nor will > their progress "keep the WG from closing" Sounds good and it's not like any extraneous docs can't be rolled into some other proposal if needed, maybe even stand alone informational RFCs. > 2) We will require at least two independent reviews (from within the WG= ) > of an individual submission before a document is considered a candidate= > for WG acceptance. The chairs will help chide reviewers, but we want t= o > see interest in the WG in a document before it progresses. Also fine. > 3) We are going to try and run this group virtually as much as possible= > (i.e. we will only physically meet if necessary). Excellent, I know I've said before that operating online as much as possible is my preference. Flying to the USA or Europe right now is completely out of the question in my case. That said, depending on the nature of any physical meeting, providing a means of participation for those of us a little farther afield would be good. PPAU does this every year for our congresses so it's feasible, usually with a designated person to monitor an IRC channel for responses and video or audio streaming via whatever method is most appropriate (for audio a Mumble server will do in a pinch). > What do you all think about these as chartering concepts? Sounds like a good plan. Regards, Ben --mvjcPjAcLo3iKmjwmBIxn6r6WrFAPDss8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVRJ9iAAoJEH/y03E1x1U8brkMAMzz90F01Eg6SgnHW9/8pv1R 52sgYIQ3dIht10hUfUOr+hbbYM584dkQlQPscfcGIUhObG3Wl25tR8CQ88jDtC+E jn3hi/Ba4ZP0DfgDt7o1a8r26DDGNlz0flF6s6Mtab+Kk5Gux45BQVM72LNbo1AJ ULwfWKb48bdgO6CvQDplhfPo3G7yHHU22YjuMIsdsUKMJxOgCwAbLfdR6A/esDtX x7wP0h7cZBO7yfz5r7r+liqblMl90tcNzvzmI2kbYlFO7dwWivuG+vv9avY+uuR+ qw++5zTSA/m+UchX5F0nkVS21a69/3IduAQ83pOewa3fVznB9PyRoHUMxqW406aT WYciESr20C0QcDMX6/jfPYH/AuKDR2DiXQf4I33i2NfjNuiH1Ozssz3CVwrBG9xW 8a8mThTgJy/D7Lo1Vhg6q7wow8y5DBfTNBOKBrAXLsIoZdUiUPL59Ft2uh0QCRp7 DttgjkQPlAr2hcOfCEe5uDp8MaQNv7LItW8HU1OjxA== =UZff -----END PGP SIGNATURE----- --mvjcPjAcLo3iKmjwmBIxn6r6WrFAPDss8-- From nobody Sun May 3 15: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 EC8BB1A8AA8 for ; Sun, 3 May 2015 15:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 YPzUQklRwUB5 for ; Sun, 3 May 2015 15:41:40 -0700 (PDT) Received: from smtp4.emailarray.com (smtp4.emailarray.com [65.39.216.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6201A8AF0 for ; Sun, 3 May 2015 15:41:06 -0700 (PDT) Received: (qmail 23325 invoked by uid 89); 3 May 2015 22:41:04 -0000 Received: from unknown (HELO ?204.29.149.87?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp4.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 May 2015 22:41:04 -0000 From: "Christopher LILJENSTOLPE" To: "Ben McGinnes" Date: Sun, 03 May 2015 15:40:47 -0700 Message-ID: In-Reply-To: <55449F61.5070401@adversary.org> References: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> <55449F61.5070401@adversary.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_D85C75CC-1B20-4F26-8814-DD31CC9E19E7_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] [eX-bulk] : Re: chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 03 May 2015 22:41:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_D85C75CC-1B20-4F26-8814-DD31CC9E19E7_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings Ben, Comments in line.... On 2 May 2015, at 2:56, Ben McGinnes wrote: > On 2/05/2015 6:43 am, Christopher LILJENSTOLPE wrote: >> Greetings, and thank's Stephen (I think) for the opportunity >> >> Daniel and I have been talking a bit about the working group, and a >> charter. We'd like to put some of those ideas to the list for >> discussion. Ideally, it would be good if we could have some consensus= >> about a charter within the next week or two to start the formation pro= cess. >> >> We would like to scope this WG fairly tightly, therefore: >> >> 1) The primary charter goal would be create a RFC4880bis document. >> a) At the end of that process, we would either re-charter, or close. >> b) Other documents (informational or bcp) MAY be entertained by the >> WG, but are not required for the WG to complete it's task, nor will= >> their progress "keep the WG from closing" > > Sounds good and it's not like any extraneous docs can't be rolled into > some other proposal if needed, maybe even stand alone informational > RFCs. That's our thoughts. > >> 2) We will require at least two independent reviews (from within the W= G) >> of an individual submission before a document is considered a candidat= e >> for WG acceptance. The chairs will help chide reviewers, but we want = to >> see interest in the WG in a document before it progresses. > > Also fine. Thx > >> 3) We are going to try and run this group virtually as much as possibl= e >> (i.e. we will only physically meet if necessary). > > Excellent, I know I've said before that operating online as much as > possible is my preference. Flying to the USA or Europe right now is > completely out of the question in my case. > > That said, depending on the nature of any physical meeting, providing > a means of participation for those of us a little farther afield would > be good. PPAU does this every year for our congresses so it's > feasible, usually with a designated person to monitor an IRC channel > for responses and video or audio streaming via whatever method is most > appropriate (for audio a Mumble server will do in a pinch). I've been at the end of an IRC/Jabber room trying to get attention for me= etings I can't attend, so I have felt that frustration. When I chair, I = TRY and have on of the chairs watching the room(s), as well as the scribe= =2E It doesn't always work, but we will try to make it as easy as possi= ble. Christopher > >> What do you all think about these as chartering concepts? > > Sounds like a good plan. > > > Regards, > Ben > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf --=_MailMate_D85C75CC-1B20-4F26-8814-DD31CC9E19E7_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVRqP7AAoJEGmx2Mt/+Iw/rZ4H/32BSpsCiQi4ALUV3odFtkPC 6+vLL6Fm0lPT35MD6Q8EJ4b7hjeR1xvC6QI+IWOZONMnIbX8K7EUgqcgh7Me5MiA XgLSO1f+0BM3YzI3jtmkt79V67m7vUKpZyITAeH67q1ihdAB/5zPPtlo2FIvC89Y XGsjnJn7XkHTuZACGKRLiUtP69uFLqX5JL68rSBRtF2b5SlAOQyNFi8TRySbHuuc HeNSj0wBTehh7bMOTORUvZxOjWBw3pMLLIkU2YTF9HLOYDqQdUcUMfi7nR/Fmtl2 Ri0b1rjNr12JsaYv28jK21p+ftw9ZUVXZjT59G4ruEuOQ7ytO1PgL4yYqFu32XA= =XE9h -----END PGP SIGNATURE----- --=_MailMate_D85C75CC-1B20-4F26-8814-DD31CC9E19E7_=-- From nobody Mon May 4 02:21: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 4F26B1AC431 for ; Mon, 4 May 2015 02: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 Tr9NpMmmh3s0 for ; Mon, 4 May 2015 02: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 661E41AC41D for ; Mon, 4 May 2015 02:21:48 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YpCZO-0008D6-Hb for ; Mon, 04 May 2015 11:21:46 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YpCVD-0008FJ-Bh; Mon, 04 May 2015 11:17:27 +0200 From: Werner Koch To: "Christopher LILJENSTOLPE" References: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.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: "Christopher LILJENSTOLPE" , "Stephen Farrell" , "openpgp\@ietf.org" , Daniel Kahn Gillmor Date: Mon, 04 May 2015 11:17:26 +0200 In-Reply-To: <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> (Christopher LILJENSTOLPE's message of "Fri, 01 May 2015 13:43:02 -0700") Message-ID: <87ioc8zopl.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor , Stephen Farrell Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 04 May 2015 09:21:50 -0000 Hi, and thanks for taking up this job. On Fri, 1 May 2015 22:43, cdl@asgaard.org said: > 1) The primary charter goal would be create a RFC4880bis document. > a) At the end of that process, we would either re-charter, or close. > b) Other documents (informational or bcp) MAY be entertained by the > WG, but are not required for the WG to complete it's task, nor will > their progress "keep the WG from closing" I am fine with that. I am a bit curious why the IETF seems to have a policy to have only short living working groups. A hint to a document explaining that would be appreciated. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon May 4 06:20: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 CD56D1A00AE for ; Mon, 4 May 2015 06:20:50 -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 FFXcWtB-BHgH for ; Mon, 4 May 2015 06:20:47 -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 70A7D1A00A8 for ; Mon, 4 May 2015 06:20:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6174EE2036; Mon, 4 May 2015 09:20:45 -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 00359-03; Mon, 4 May 2015 09:20:43 -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 5B367E2035; Mon, 4 May 2015 09:20:43 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t44DKgbt022260; Mon, 4 May 2015 09:20:42 -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: Mon, 04 May 2015 09:20:42 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 29 Apr 2015 13:13: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] 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, 04 May 2015 13:20:51 -0000 Phillip Hallam-Baker writes: >> 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. Sorry, but that horse has already left the barn. This is precisely OpenPGP nomenclature. A Key is a packet that contains a set of data, part of which is what I would call the "Key Material" but it also includes other data. > There are two possibilities: > > 1) A new Key Packet was created that reused an existing key Let's use correct OpenPGP nomenclature, please. A new Key was created that reused existing key material. I'll point out that this can happen using any protocol. Indeed, I've reused key material for my X509 certs too (at least before Heartbleed -- I've regenerated them all since then). > 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. Please stop conflating fingerprint and signatures; they are two separate things. However you are correct in that the data included in the fingerprint hash is also included in signature hash. This is why you either get both or neither. Using the V3 Key format, if you reuse the key material and change the expiration date then you have just changed the data going into the fingerprint and signature hashes, which means you change the fingerprint and invalidate all hashes. Using the V4 Key format this is not the case because the expiration date is no longer in the Key, but got moved into the SelfSig. >> 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. You're thinking in X509 terms. This is OpenPGP. The terms *are* different, as well as the ability to encode and do things. Particularly, in OpenPGP you *can* have a Key (which obviously includes its key material) without a Signature, and that *IS* a valid data structure (although I would propose that most people wouldn't trust it). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 4 06:26: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 3B4AC1A00B7 for ; Mon, 4 May 2015 06:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 xvEBx8_6ZOv2 for ; Mon, 4 May 2015 06:26:15 -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 10BF21A00AE for ; Mon, 4 May 2015 06:26:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E304EE2038; Mon, 4 May 2015 09:26: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 00328-05; Mon, 4 May 2015 09:26: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 CFA57E2036; Mon, 4 May 2015 09:26:11 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t44DQBYD022674; Mon, 4 May 2015 09:26:11 -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: Mon, 04 May 2015 09:26:11 -0400 In-Reply-To: (Nicholas Cole's message of "Wed, 29 Apr 2015 16:12:07 +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: Mon, 04 May 2015 13:26:16 -0000 Nicholas Cole writes: > 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. I don't see it as a niche at all. It's quite possible for an attacker to have obtained the secret key without the user being aware. They could have spent the resources to factor N (for RSA) or surrepticiously obtained a backup data and determined the users' passphrase. None of these positions would put the attacker into a position to cause the original user to generate a new key. If you mean that they could generate a new OpenPGP Key Packet using the same Key Material, you are correct... Anyone could do that, even without the secret data. However, in the case of V3 keys doing so would change the fingerprint and invalidate all existing signatures. So it's no different than an attacker generating a new key with your email address and posting it to the keyserver to say she is you. However with V4, an attacker with access to the secret material COULD create a new SelfSig with an extended expiration. This is a very different (and expanded) attack surface, becuase it means they could take over your existing Key+Signature/Certificate, precisely because changing the expiration does NOT invalidate all existing signatures on the Key. > 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. It is absolutely realistic! > Has there *ever* been a confirmed attack that this feature would have > prevented? Yes. > N. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 4 06:31: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 BCA071A00BD for ; Mon, 4 May 2015 06:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE17Ns_FQmoZ for ; Mon, 4 May 2015 06:31:42 -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 3AAFB1A00AE for ; Mon, 4 May 2015 06:31:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E9DAFE2036; Mon, 4 May 2015 09: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 00359-06; Mon, 4 May 2015 09: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 E0182E2035; Mon, 4 May 2015 09:31:38 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t44DVZEA023075; Mon, 4 May 2015 09:31:35 -0400 From: Derek Atkins To: Stephen Farrell References: <5543D086.1000503@cs.tcd.ie> Date: Mon, 04 May 2015 09:31:35 -0400 In-Reply-To: <5543D086.1000503@cs.tcd.ie> (Stephen Farrell's message of "Fri, 01 May 2015 20:14:14 +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" , Daniel Kahn Gillmor , cdl@asgaard.org Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 04 May 2015 13:31:43 -0000 Congrats to DKG and Chris! My hats off to you (literally :) Good Luck, and let me know if there's any way I can help. -derek PS: I do have two drafts that I posted to this list last year that I'd like to progress. I've already received multiple independent reviews :) Stephen Farrell writes: > Hi all, > > First - many thanks to all of you who volunteered to help by chairing. > It's really encouraging that so many were willing and able, which was > the case for I think everyone who volunteered. > > Having spoken to a few folks, I'm delighted to say that Daniel Kahn > Gillmor and Christopher Liljenstolpe (both cc'd on this) have agreed > to help out as chairs for the re-formed openpgp WG. > > Christopher has lots of experience with chairing in the IETF and dkg > as you know is very active in lots of security things including PGP > so I think they should be a great team to help us move forward. > > Daniel and Christopher will take it from here with the intent being > to try craft a charter along the lines we've already discussed on the > list and I'll start the formal chartering process once they tell me > that's sufficiently baked (so no need for a BoF before starting). And > then we all can get moving on getting the work done. > > So please join me in thanking Christopher and Daniel for being > willing to help out and please help them by continuing to contribute > as constructively as you have collectively been doing. > > Cheers and thanks again all, > Stephen. > > > > _______________________________________________ > 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 May 4 06:33: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 714601A00C3 for ; Mon, 4 May 2015 06:33:33 -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 S_mt7oSkcPvy for ; Mon, 4 May 2015 06:33:32 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9676E1A00BF for ; Mon, 4 May 2015 06:33:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6B51DE2036; Mon, 4 May 2015 09:33: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 00328-08; Mon, 4 May 2015 09:33: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 AF4E3E2035; Mon, 4 May 2015 09:33:29 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t44DXTO8023264; Mon, 4 May 2015 09:33:29 -0400 From: Derek Atkins To: "Christopher LILJENSTOLPE" References: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> <87ioc8zopl.fsf@vigenere.g10code.de> Date: Mon, 04 May 2015 09:33:29 -0400 In-Reply-To: <87ioc8zopl.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 04 May 2015 11:17:26 +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" , Daniel Kahn Gillmor , Stephen Farrell Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 04 May 2015 13:33:33 -0000 Werner Koch writes: > Hi, > > and thanks for taking up this job. > > On Fri, 1 May 2015 22:43, cdl@asgaard.org said: > >> 1) The primary charter goal would be create a RFC4880bis document. >> a) At the end of that process, we would either re-charter, or close. >> b) Other documents (informational or bcp) MAY be entertained by the >> WG, but are not required for the WG to complete it's task, nor will >> their progress "keep the WG from closing" > > I am fine with that. > > I am a bit curious why the IETF seems to have a policy to have only > short living working groups. A hint to a document explaining that would > be appreciated. There isn't a written policy on it. But from personal expierience people get burned out after a while. When a WG first starts there is usually a lot of energy, but that fades, so groups that last a long time tend to attrophy. > Shalom-Salam, > > Werner -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon May 4 07:43: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 A13331A1A7D for ; Mon, 4 May 2015 07:43:42 -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 4nP7dLYzxAvD for ; Mon, 4 May 2015 07:43:40 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010: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 70F6C1A1A91 for ; Mon, 4 May 2015 07:43:40 -0700 (PDT) Received: by lagv1 with SMTP id v1so105613190lag.3 for ; Mon, 04 May 2015 07:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZSsvkWdpEuILx5Z9h0wnCtKaHEySIUsfR5kiRvr45lI=; b=l29gUsFfc49sBKrGNRunzSPlstUsaPZNrY+DHbYpSNPlZva8+SiHM2Svb4nsEu4KqF 2A8KMSyDAu1LRX6g/kABrfhRLs//Lw1tUz6UalyXPxjQbu6z+lDgVcV/POxkTRlApjUD +DFMhyuBpCRf/xLRzsDVbtLm9L2i5zz+zq/O9CL3Qb3BUiQQLufXRsIQJIodUQJrkVRA SpddJTqGQts1q2BFMRBDDzCx2oN/2ywzJNG2+bP12eafO9+vXGCNKcE1yIA4xOUKYsP8 saxWKzOdy6TkGVeHkzcJOphqB0Qsv83GTweSU02LFuiqeBS2JsIyA0eXrG246bVs6CCg vQMQ== MIME-Version: 1.0 X-Received: by 10.152.45.97 with SMTP id l1mr20224544lam.55.1430750618864; Mon, 04 May 2015 07:43:38 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 4 May 2015 07:43: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> <1430236740.658.40.camel@scientia.net> Date: Mon, 4 May 2015 10:43:38 -0400 X-Google-Sender-Auth: dCsd-RhHh2WF0pduZKk3VgnFpEM 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: Mon, 04 May 2015 14:43:42 -0000 On Mon, May 4, 2015 at 9:20 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: > >>> 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. > > Sorry, but that horse has already left the barn. This is precisely > OpenPGP nomenclature. A Key is a packet that contains a set of data, > part of which is what I would call the "Key Material" but it also > includes other data. It is not the nomenclature of the field. People are getting confused. And no wonder. People don't know if what you are talking about is a public key or a PGP 'key'. And you seem to be getting confused yourself. From nobody Mon May 4 07:48: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 B656A1A1AAE for ; Mon, 4 May 2015 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zLk_04IuNQt for ; Mon, 4 May 2015 07:48:38 -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 67DBB1A1A87 for ; Mon, 4 May 2015 07:48:35 -0700 (PDT) Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw02.dd24.net (Postfix) with ESMTP id E4AB65FB35 for ; Mon, 4 May 2015 14:48:33 +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 muuDQ0xryniq for ; Mon, 4 May 2015 14:48: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 mailgw02.dd24.net (Postfix) with ESMTPSA for ; Mon, 4 May 2015 14:48:32 +0000 (UTC) Message-ID: <1430750911.28399.22.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Mon, 04 May 2015 16:48: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> <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> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-JkiPf9UiyrzU7Fmt8wwC" 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, 04 May 2015 14:48:40 -0000 --=-JkiPf9UiyrzU7Fmt8wwC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-05-04 at 10:43 -0400, Phillip Hallam-Baker wrote:=20 > It is not the nomenclature of the field. >=20 > People are getting confused. And no wonder. People don't know if what > you are talking about is a public key or a PGP 'key'. And you seem to > be getting confused yourself. Unfortunately "key" is used in many contexts, but I think that David is right and that one must at least assume it to be the term that means key material + UIDs etc. Anyway... do we really need to nitpick about that question? o.O Cheers, Chris. --=-JkiPf9UiyrzU7Fmt8wwC 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUwNDE0NDgz MVowTwYJKoZIhvcNAQkEMUIEQANznyLXZMMrr3SZ57+jnfjDAo4AzjABUoGeCIcoVE2CSCv5n27Y gPZ7pTwDcZkWgV4FgYGwSaVhn0a9vfjMcD8wagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCfNhWmfPL5DdbNK+MCfiSFMiT0KNAo Nc0DaQ4x8sNPsZiYFocpbG3ayvlHoWmJ3oA5k3JmhGoOGaWLBAuGeub38uJSf2VTmt7Ieyo8hpKT Wne1drYuB1Q4/xxGG4muD3InDfKl9abcdwEoTGYX2rp0U6zHO+UJVZHf97yl49QYbCR9vvD7qhl/ FBwX6IWQMF/K9gGjVLb7cRU2Kv7LOSkJVv7KW1M+ZDFlWYalJi5d3XZ8ObXEFLpyOpPnaSxySU/O 5ACKqH4BLEuGpV7IGsJwisMsu8EJdqKkxBovlnxc/sjtyks+PAU2JOuPhKilaIrys5TJhpk1vhVc SbvlXjL1AAAAAAAA --=-JkiPf9UiyrzU7Fmt8wwC-- From nobody Mon May 4 08:02: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 725DC1A1B5B for ; Mon, 4 May 2015 08:02:50 -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 JU--JXqApOZK for ; Mon, 4 May 2015 08:02:49 -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 11B231A1A83 for ; Mon, 4 May 2015 08:02:49 -0700 (PDT) Received: by wizk4 with SMTP id k4so124992054wiz.1 for ; Mon, 04 May 2015 08:02:47 -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=GE9g06MZU8yFjxizeD4jh7Rb55fS86bxr4S6XHqOPtc=; b=gUI4cjBtZmndT1PI5uK239vapLv2antvw2nRXDAZS9o+z9bZtdl/SXPxyHRhF/bCN/ yXRRrBSE7ykImAXeWhZRaoMvwHgjsHRh4GTAA55zAc85YqpcoHWTmyo8p7sDMoRtIHT/ MyBycpzza8sz2R4hKOp8zSXNEivh9XbzEtjFPsOTHZSS3Z4m3FsxWrprMye8UJfUE99X PeRLdOwTwenM4MLSuwX7Sq4Yf7DiQUX1+Z1CW4oCIPUMBtqDAqQpyhuBy3lgl3JIVhsQ 5HGMxjeZiNDazk0oV3VJMjq2VIg1t4EFkTucE/3o0nvMcrwZwY4egl8+Qlg+QDjgmilC l87Q== MIME-Version: 1.0 X-Received: by 10.194.57.209 with SMTP id k17mr41513974wjq.33.1430751767793; Mon, 04 May 2015 08:02:47 -0700 (PDT) Received: by 10.194.162.35 with HTTP; Mon, 4 May 2015 08:02:47 -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: Mon, 4 May 2015 16:02:47 +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, 04 May 2015 15:02:50 -0000 On Mon, May 4, 2015 at 2:26 PM, Derek Atkins wrote: [snip] >> Has there *ever* been a confirmed attack that this feature would have >> prevented? > > Yes. Citation please? From nobody Mon May 4 08:09: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 A9A331A1BAC for ; Mon, 4 May 2015 08:09:57 -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 ut3IZfJVKljR for ; Mon, 4 May 2015 08:09:56 -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 590631A1BB5 for ; Mon, 4 May 2015 08:09:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2B650E2035; Mon, 4 May 2015 11:09:55 -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 01064-10; Mon, 4 May 2015 11:09:52 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id D068EE2038; Mon, 4 May 2015 11:09:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1430752192; bh=6upsg/3Ddx2JNrgpbahgex3pIsw9oSiHOaee4ctsuH4=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=shCt7n3TqouAnsoSruJjP747BYZOxp/fuXT3JpbIJ/qAS7VDiWSIFZMRQ9a0N7b06 hFHDY9C+6XFfvUmobhxdGOnXZBjUl2/95qyo3K1eFOefmcNEzhXSYhS1+h1n/rrnzO AL3ZSOfBYXFDCcHoPjJxq/NED4rdjLCtdx7EieBY= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 4 May 2015 11:09:52 -0400 Message-ID: <3bbe54de26a4b3895489c6ee378c475c.squirrel@mail2.ihtfp.org> 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: Mon, 4 May 2015 11:09:52 -0400 From: "Derek Atkins" To: "Nicholas Cole" 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, 04 May 2015 15:09:57 -0000 On Mon, May 4, 2015 11:02 am, Nicholas Cole wrote: > On Mon, May 4, 2015 at 2:26 PM, Derek Atkins wrote: > > [snip] > >>> Has there *ever* been a confirmed attack that this feature would have >>> prevented? >> >> Yes. > > Citation please? I'm afraid I am not at liberty to disclose that information. Sorry. However even back in 1993 there were projects to test the strength of PGP Key Material based on factoring attacks. The RSA-129 project came about through one of those discussions, and I seem to recall that at least one RSA Key was factored after RSA-129. I don't have a reference for that effort (and my google fu isn't working immediately). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue May 5 06:44: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 9E4A51ACD75 for ; Tue, 5 May 2015 06:43: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 p2J0gkWRRliJ for ; Tue, 5 May 2015 06:43: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 EABB51ACD72 for ; Tue, 5 May 2015 06:43:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7404EE2036; Tue, 5 May 2015 09:43:55 -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 10631-01; Tue, 5 May 2015 09:43: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 81B01E2035; Tue, 5 May 2015 09:43:53 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t45DhqqS026547; Tue, 5 May 2015 09:43:52 -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: Tue, 05 May 2015 09:43:52 -0400 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 4 May 2015 10:43: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 , 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, 05 May 2015 13:43:59 -0000 Phillip Hallam-Baker writes: > On Mon, May 4, 2015 at 9:20 AM, Derek Atkins wrote: >> Phillip Hallam-Baker writes: >> >>>> 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. >> >> Sorry, but that horse has already left the barn. This is precisely >> OpenPGP nomenclature. A Key is a packet that contains a set of data, >> part of which is what I would call the "Key Material" but it also >> includes other data. > > It is not the nomenclature of the field. Umm, it is exactly the nomenclature PGP/OpenPGP has been using since, oh, 1992. It may not match the X509/PKIX world, but lucky for us we don't have to do that. :-D > People are getting confused. And no wonder. People don't know if what > you are talking about is a public key or a PGP 'key'. And you seem to > be getting confused yourself. No, I know exactly what I'm talking about, but trying to explain it to people that don't innately grok the (Open)PGP nomenclature requires the use of additional phrases. A PGP Key (aka Key) is a packet that contains a version, algorithm, key material, creation date, etc. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue May 5 08:24: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 727DD1B2EF4 for ; Tue, 5 May 2015 08:24:26 -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 jHDTevlY0J81 for ; Tue, 5 May 2015 08:24:25 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C914B1A8885 for ; Tue, 5 May 2015 08:24:24 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so131363253lbb.0 for ; Tue, 05 May 2015 08:24: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=H1ZZQG5+e7jsgPtF4VhEntsxDrnBDGr8iL/k/Dljy8o=; b=lknNttFx3Kw1PWQXgUXMWryjuXthoxdd7n7uO7f0QC18g1BXVf5QGHzkPm2zrTk8tz AtSDOzHnIwgUuAAKdG49GzJhnY0VRfm0jrevVMjHOPAncnit5DaYTGrSyifGz9V7heQ2 HdrcsNCL5BHY9hs+8ji0Pv+3jh6skckhnyzLO6aJJ0yykj80bLT5yFTiM69JMDJtL3I5 DJO3JsXq76jnynrwzia6zzp2rdSMT3hZgFsSvdIAm2wr27bHxKpfw2HEwlrEluzbWsOQ XNbHiZaVqxsZYd2AykN9qkOZ2ujqFwJtgRl4/TPhg4zZnSRKODMVdE4/7DG/4PoAwKol f3hA== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr24681106lbc.79.1430839463340; Tue, 05 May 2015 08:24:23 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 5 May 2015 08:24:23 -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: Tue, 5 May 2015 11:24:23 -0400 X-Google-Sender-Auth: cEOyh2p63LOoIfXCR2KNOrhTDAg 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: Tue, 05 May 2015 15:24:26 -0000 On Tue, May 5, 2015 at 9:43 AM, Derek Atkins wrote: > Phillip Hallam-Baker writes: >>> Sorry, but that horse has already left the barn. This is precisely >>> OpenPGP nomenclature. A Key is a packet that contains a set of data, >>> part of which is what I would call the "Key Material" but it also >>> includes other data. >> >> It is not the nomenclature of the field. > > Umm, it is exactly the nomenclature PGP/OpenPGP has been using since, > oh, 1992. It may not match the X509/PKIX world, but lucky for us we > don't have to do that. :-D I am pretty sure that Diffie, Rivest et. al. have been using the term 'key' to refer to a public key, a private key or a symmetric key and nothing else since the mid 70s. It is not a question of matching the PKIX world. Lauren Kohnfelder set out the nomenclature back in the 80s. >> People are getting confused. And no wonder. People don't know if what >> you are talking about is a public key or a PGP 'key'. And you seem to >> be getting confused yourself. > > No, I know exactly what I'm talking about, but trying to explain it to > people that don't innately grok the (Open)PGP nomenclature requires the > use of additional phrases. A PGP Key (aka Key) is a packet that > contains a version, algorithm, key material, creation date, etc. Where we are now is that we have two PKIs that don't talk to each other. That means we can't use keys from the PGP system with TLS and we can't use keys from the PKIX system with PGP message formats. And both cause problems. I would really like to be able to use some sort of client side public key based authentication with HTTPS web sites. That means using keys that are in the user space. Do we really want to insist on the user having to maintain two separate sets of keys for the different protocols? If you want to call a key packet a PGPKey, fine. But we are working in a standards organization here and one of the things that requires us to do is to ensure that our nomenclature is consistent across the organization. Key fingerprints are useful for far more than just email. I am just working on setting up Web Service that is distributed across a set of hosts. Now obviously for external purposes, those hosts are going to acquire WebPKI certificates. But how do I authenticate the host to either the CA or LRA? The simplest solution is to use a public key pair. Lets say the fingerprint of the public key is: MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI Lets also say that there is some TPM capability on the platform so that I can store the private key on the platform in such a fashion that I can issue instructions to make use of the key with the above identifier but can't extract it from the machine without electron microscope type effort. So each host has a config file that looks something like: {"Service" : "Confirmation", "HostKey" : "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI", "Domain" : "example.com", "CA" : {"dns" : "acme.example.com", {"root" : "SJE2U-OVCFK-JBVIS-S2JZD-EKURS-IJDVE"}} And the ACME LRA server would have a config file containing a line something like: {Hosts : [ "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI", "MI5GT-ERCTJ-ZNFER-2BGRD-UOT2C-KFGU2-NCEKF", "MGVEV-KHIJK-EISK2-JJJU2-SSSIR-FU4SS-RJBBF", "MERCP-JZKEE-R2NGN-KE6WS-KKVGV-CWKUI"] } The combination of these techniques allows me to address one of the biggest headaches in TLS admin which is how to authenticate a host before it has a certificate. By far the biggest reason for bad certs is that admins lose control of their private keys. Automating the process allows me to go to short lived certs (24 hour rollover). The point of a certificate is to establish a trust relationship. That is a different problem to setting up the underlying security relationship. Regardless of what you want to use to configure your external trust relationship (PGP, PKIX, whatever), this is a different problem to setting up the security relationships. From nobody Tue May 5 10:08: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 ADE341A039C for ; Tue, 5 May 2015 10:07:57 -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 6MTluI3tJuSI for ; Tue, 5 May 2015 10:07:54 -0700 (PDT) Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3971D1A0302 for ; Tue, 5 May 2015 10:07:46 -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 7E03D5FB4D; Tue, 5 May 2015 17:07:44 +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 grva8hh5E54m; Tue, 5 May 2015 17:07:42 +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, 5 May 2015 17:07:42 +0000 (UTC) Message-ID: <1430845661.28399.65.camel@scientia.net> From: Christoph Anton Mitterer To: Phillip Hallam-Baker Date: Tue, 05 May 2015 19:07:41 +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> <1430236740.658.40.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-Yxv9M+m/ZEPsCN/8N0Op" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Cc: IETF OpenPGP , 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, 05 May 2015 17:07:57 -0000 --=-Yxv9M+m/ZEPsCN/8N0Op Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-05-05 at 11:24 -0400, Phillip Hallam-Baker wrote:=20 > I am pretty sure that Diffie, Rivest et. al. have been using the term > 'key' to refer to a public key, a private key or a symmetric key and > nothing else since the mid 70s. I don't think they are the standards body defining which words to use for what. > Where we are now is that we have two PKIs that don't talk to each > other. That means we can't use keys from the PGP system with TLS rfc6091 > and > we can't use keys from the PKIX system with PGP message formats. And > both cause problems. Why? I don't see any need why e.g. OpenPGP should be compatible with it. Actually I'm quite happy it's not. > I would really like to be able to use some sort of client side public > key based authentication with HTTPS web sites. That means using keys > that are in the user space. Do we really want to insist on the user > having to maintain two separate sets of keys for the different > protocols? I don't think you or anyone else here will solve the fundamental problems of "web crypto" (i.e. TLS and X.509),... nor will we be able to make the world take over OpenPGP for it. And again you seem to mix in completely unrelated topics here. Please focus. > If you want to call a key packet a PGPKey, fine. But we are working in > a standards organization here and one of the things that requires us > to do is to ensure that our nomenclature is consistent across the > organization. It's important that the nomenclature is consistent within the standard/documents we produce... but apart from that it's probably impossible to reach that goal. "Key" alone can have many colloquial meanings,.. public key, private key, the key material, the pair of public/private key, the key material +metadata, + the UID. > Key fingerprints are useful for far more than just email. >=20 > I am just working on setting up Web Service that is distributed across > a set of hosts. Now obviously for external purposes, those hosts are > going to acquire WebPKI certificates. But how do I authenticate the > host to either the CA or LRA? >=20 > The simplest solution is to use a public key pair. Lets say the > fingerprint of the public key is: >=20 > MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI >=20 > Lets also say that there is some TPM capability on the platform so > that I can store the private key on the platform in such a fashion > that I can issue instructions to make use of the key with the above > identifier but can't extract it from the machine without electron > microscope type effort. >=20 >=20 > So each host has a config file that looks something like: >=20 > {"Service" : "Confirmation", > "HostKey" : "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI", > "Domain" : "example.com", > "CA" : {"dns" : "acme.example.com", > {"root" : "SJE2U-OVCFK-JBVIS-S2JZD-EKURS-IJDVE"}} >=20 > And the ACME LRA server would have a config file containing a line > something like: >=20 > {Hosts : [ > "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI", > "MI5GT-ERCTJ-ZNFER-2BGRD-UOT2C-KFGU2-NCEKF", > "MGVEV-KHIJK-EISK2-JJJU2-SSSIR-FU4SS-RJBBF", > "MERCP-JZKEE-R2NGN-KE6WS-KKVGV-CWKUI"] } >=20 > The combination of these techniques allows me to address one of the > biggest headaches in TLS admin which is how to authenticate a host > before it has a certificate. By far the biggest reason for bad certs > is that admins lose control of their private keys. Automating the > process allows me to go to short lived certs (24 hour rollover). What has all this to do with our discussions here? At least I can't see anything, apart from that I feel the need to comment that any rollover techniques are IMHO security wise stupid. Let's focus on concrete questions about OpenPGP. Cheers, Chris. --=-Yxv9M+m/ZEPsCN/8N0Op 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUwNTE3MDc0 MVowTwYJKoZIhvcNAQkEMUIEQKtagubxrdT7qakLkqF3IfkRPj7g1uPbUtHUsWWrLDUrxMQ+t914 +IoEgfYdXH0wEQrB4ZMUtyGdys6gEyr8NbYwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQDct7qBltq8vipHj0M3vy5ydIbOWVIB J4tu4v1KlE2poqXlJTCCSQqfA4mw7IGHgBMxH8cJqEizdO89xDAaxdAmamZjoHjpOLPG+Zc26JKH L2ih/lMwmPB6f+Dn2BCVU1OhjgcJDEYnI6WZaqZ6Wv87EXgiXLNl1qHpL3e7ekukXbw8GiebPvFc G78x2cS8l/dGPsw2yulgDvSGCo/QLx80FvcRNO5IvhZVUsuyMx4jwa0l7iRHilk+GwNtt8LXajS1 S+GCGiRbZ3sR97epsIs/Rrf76XbLgxak2wWqurQ6HMnhbF3Bpm7HdmIobHCIevbQhflk2MDt3GL/ Qao3o8H1AAAAAAAA --=-Yxv9M+m/ZEPsCN/8N0Op-- From nobody Tue May 5 13:16: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 241E61ACE9F for ; Tue, 5 May 2015 13:16:51 -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 LG82-ke9A2ls for ; Tue, 5 May 2015 13:16:49 -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 403FB1ACE89 for ; Tue, 5 May 2015 13:16:49 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YpjGp-0004b1-Mm for ; Tue, 05 May 2015 22:16:47 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YpjDW-0005tx-5g; Tue, 05 May 2015 22:13:22 +0200 From: Werner Koch 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> 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 , Derek Atkins , Christoph Anton Mitterer , IETF OpenPGP Date: Tue, 05 May 2015 22:13:21 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 5 May 2015 11:24:23 -0400") Message-ID: <87y4l2vl3y.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 , IETF OpenPGP , 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, 05 May 2015 20:16:52 -0000 On Tue, 5 May 2015 17:24, phill@hallambaker.com said: > Where we are now is that we have two PKIs that don't talk to each > other. That means we can't use keys from the PGP system with TLS and I don't know what the second PKI is in your book. OpenPGP is not a PKI and does not define one. This thread is on how we may change OpenPGP's expiration time feature. It is not about other protocols or ideas. Please change the subject to to discuss off topic things. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue May 5 14:23: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 6A4321ACEBC for ; Tue, 5 May 2015 14:23:17 -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 wVkecdm8n0vn for ; Tue, 5 May 2015 14:23:15 -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 028DB1B2A19 for ; Tue, 5 May 2015 14:23:14 -0700 (PDT) Received: from localhost (p5798EDDB.dip0.t-ipconnect.de [87.152.237.219]) by mail.mugenguild.com (Postfix) with ESMTPSA id 1B6545FD0E for ; Tue, 5 May 2015 23:20:32 +0200 (CEST) From: Vincent Breitmoser To: openpgp@ietf.org Date: Tue, 05 May 2015 22:04:20 +0200 Message-ID: <874mnqpvp3.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Key Validity Scenarios X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 05 May 2015 21:23:17 -0000 --=-=-= Content-Type: text/plain Bringing up a topic related to expirations, one thing that has bothered me for a while is that the validity periods of keys, in terms of expiration and revocation, are very ambiguous. Consider these scenarios: - Key expired two weeks ago. Status of a signature from three weeks ago? - Key revoked two weeks ago, because it was compromised. Status of a signature from three weeks ago? - Key revoked two weeks ago, because no reason given. Status of a signature from three weeks ago? - Key revoked two weeks ago, because it was superseded. Status of a signature from three weeks ago? It's possible to argue for all extremes in all of these scenarios, and the conservative choice would always be to reject the signature, however this is not necessarily applicable for all implementation circumstances. So the possibilities here are: a) try to cover the key validity for most scenarios in the standard. this seems tricky because I don't think all needs can be covered. b) leave the main standard purely focused on data format, but add an informational one with this sort of definitions. c) add an explicit definition about treatment of retrograde signatures to the expiration and revocation signatures themselves, i.e. delegate to the implementation which creates the key. d) none of the above, i.e. leave it to the implementation which uses the key. I'd like b), but that one implies a bunch of extra work. - V --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVSTS7AAoJEHvRgyDerfoR/cEQALOHZQKJsu+l1uB7NEjb58rv 8bW1G6BmLVvSIO8d4urlOsjehVCa/d3POsU52vOnRtRn92fylbsNpFAqdpoycyAM AQM7SCaupk7uYXDx/kgy7YfdG8T5a5bKB/wmo9K56P0HtkqJnQO9s1oNxeb5H42p 5fjrvBLuOtyDfSwkm4HQ+NlqHjqJV15OKJJboFIs+W4ZnZ9Asfq7U9eQvjOy+Sg6 sP5JkHNH10zXEFkY+PiK5ytHZtKKrQjf4iQw0KN1LwKJ1vyN4rzJ3NpTMv5z827z GdCvhCi8c+9mvycygerBJiNBcf1pZUXz/1pL31PS6IFSCTYy2jS0q2K1pJpByh4Q BsWvbiMWfBDVVXgfpgSwjKxn/BWOD5zr/l/gm8FqyGt9xoEaGcsqDW3+n6LvTOMf MMCoX+7penvdCJWH7BJp/Euj0yo2pxENDfsmX0fgfFwb/X2xAM50BrDg/db5Z1iV gBMRcomRbXwOiBwjOWLjGGXmyt+/8HW3iJNwzHBuT1zvdH5jB67LhIdU5nfgh5Re 8pOtK4IznCsQf5mcM4CkTD6fD98S5unfJXlU2MmKjYblp8IUKYetEI/9IabuEP7p jp3FBm/3tbjpvtQ9XwePCNLKJvdB4OnYWCEZju1/WeQOJ5C6nDw3T4ZGpYZIIobs pQf9YJcjSufkRSMCeJhI =BVGg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 14:43: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 371CD1B29D6 for ; Tue, 5 May 2015 14:43: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 am_cgqHgBK9s for ; Tue, 5 May 2015 14:43:06 -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 EF7BC1B29EB for ; Tue, 5 May 2015 14:42:53 -0700 (PDT) Received: from localhost (p5798EDDB.dip0.t-ipconnect.de [87.152.237.219]) by mail.mugenguild.com (Postfix) with ESMTPSA id C604F5FD0E; Tue, 5 May 2015 23:40:11 +0200 (CEST) References: <87d232lkb6.fsf@alice.fifthhorseman.net> From: Vincent Breitmoser To: Derek Atkins Date: Tue, 05 May 2015 23:26:17 +0200 Message-ID: <871tiupupe.fsf@littlepip.fritz.box> In-reply-to: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" 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, 05 May 2015 21:43:10 -0000 --=-=-= Content-Type: text/plain On 20 Apr 2015, Derek Atkins wrote: >>> 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? ;) I would like to pick up on this point again: What's wrong with 160 bit fingerprints? The bit length seems more than sufficient to cover any Mooreian doubts, a more relevant issue would be weaknesses in the hashing algorithm itself, where the status is that in its 20 years not even a collision has been found for SHA-1. Seeing talk about fingerprints which "still fit into one line" and "maybe moving to SHA3-512" while at the same time asserting that manual verification of fingerprints should still be a thing, I'm a little concerned about the direction this is going... - V --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVSTlWAAoJEHvRgyDerfoRZJEQALqsvzuIH0oYgUARZJoheVpM TyKjwMgeaes8wiOVb6UEvN54pG4MNtQeqnO8XaNVG8AScMMiOvdrAfxwRxao3N+f VF25BSjIG/o+kUiofMRP0MGsbQUXd/cHjL0BgeJVnlIwJkkAcU1Jt2h/A0+viX0R RVF81C4Skq5mlrUzPEbjmGHfse6AAZM/UAtHcMbOWRciY0f4DFnbxugD5zOc/QPP gc/t2CK/pxVO5BsNMOsgOTBqCXHcFftezEq0D2U0nZyTM+qX2ai1iUn71FfOS4LQ 2hhbv/5dsmUVKbjIO5A1aZENNYHdlqm6mXcWrKvI6e+Dpvl6Q7bEf0jdS45bW/EO NcqrYX7mTjlUiv31Xm8pF6nMRuVz7aBs+HVK0C5knzKLNVU5CvHg39OdvfauhrZL nPZ5LCB0iZPuADaXgzqcyjSh2+r24u3EdNzVu613b5TO0Z7DK1o5gD/WIF+u4ctC TrZ89j2SsREfjRtQjV2qxAeN2CVRtJ3uvbYkYQ50VBaVhZrWYeTJG3yj9RdRomIB z/YOxeje2zlBNWMMphVeHrtSXTX3Zf7xw35OCBG4eZXK9ECUX64YfoeJJx4cusaw zrb6GO2sW77s5MEVYGtMs/k1EXWG7vepOlelqwvu9t5/7jkezzOav/YnbluNJl4s fSVMXAN0qhUFNDPL3sJ5 =15ne -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 16:42: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 8216D1A89B1 for ; Tue, 5 May 2015 16:42: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 0T04_VoAV4QG for ; Tue, 5 May 2015 16:42:37 -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 D396A1A89B0 for ; Tue, 5 May 2015 16:42: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 mailgw02.dd24.net (Postfix) with ESMTP id 4DAF85FB88 for ; Tue, 5 May 2015 23:42:35 +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 VKKxhoDHMZ6S for ; Tue, 5 May 2015 23:42:33 +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 ; Tue, 5 May 2015 23:42:33 +0000 (UTC) Message-ID: <1430869352.28399.104.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 06 May 2015 01:42:32 +0200 In-Reply-To: <874mnqpvp3.fsf@littlepip.fritz.box> References: <874mnqpvp3.fsf@littlepip.fritz.box> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-KWheid4e5lTMvOXH+Ij8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Archived-At: Subject: Re: [openpgp] Key Validity Scenarios X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 05 May 2015 23:42:41 -0000 --=-KWheid4e5lTMvOXH+Ij8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-05-05 at 22:04 +0200, Vincent Breitmoser wrote:=20 > Bringing up a topic related to expirations, one thing that has bothered > me for a while is that the validity periods of keys, in terms of > expiration and revocation, are very ambiguous. Well that's one of the points I've mentioned in my original wishlist: While I don't think we should overly aggressive define trust models, some of the questions you answer are not well defined, so one can basically only hope that the implementation makes a sane choice. But such ambiguities always leave up some space for meta-level attacks, social engineering and so on. > - Key expired two weeks ago. Status of a signature from three weeks ago? IMHO not well defined. One may e.g. choose to consider the signature still valid, but not the key... and e.g. an implementation may then say "valid signature from a trusted but expired key". In addition it may e.g. make some "guess"... like when they expiration is 5 days ago it may just print the warning... but if it was 10 years ago it would start to flash the screen like mad and play alert sirens at all sound devices. One clearly sees... nothing well defined... quite ambiguous. > - Key revoked two weeks ago, because it was compromised. Status of a > signature from three weeks ago? Not sure whether it's formally standardised, but it's clear that the signature needs to be considered invalid in any case, as the attacker can of course forge any date. > - Key revoked two weeks ago, because no reason given. Status of a > signature from three weeks ago? Again... not defined. I (personally) would probably say that in case of "no reason given" one must assume the worst case (key compromise - the revocation certs may have been created for that purpose at the key creation, but without a reason, since it wasn't known yet). So same as directly above. > - Key revoked two weeks ago, because it was superseded. Status of a > signature from three weeks ago? As above.... not well defined. I'd probably choose something like the first paragraph above. > a) try to cover the key validity for most scenarios in the standard. > this seems tricky because I don't think all needs can be covered. > b) leave the main standard purely focused on data format, but add an > informational one with this sort of definitions. I have no strong opinion whether such definitions should be part of the "core RFC", but they should be definitely standard and mandatory defined. The reason is simply that people may actually depend their security on such things being used/interpreted as they should (whatever that is). Cheers, Chris. --=-KWheid4e5lTMvOXH+Ij8 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUwNTIzNDIz MlowTwYJKoZIhvcNAQkEMUIEQAN0udFWu5PfrQtvPL7k7U8C0ASceqN4Pbio2ayrgQtwJVcsfq5B BzWyBBhuZ6ghw5YzN+W44t6CnRI1pcnoAnAwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQApwedzofQ1AimebpjCXOezAKiUzQ+p bx0Zsxp/VroZPEQJAhJX8+wj+qDzqC7po75CO2w/T1A+/+M3YjzgtJN3d8PQGZvE/WRYChywYwkd QOCLYAr8ju6RNLVmrco3r4/NK5F9VId8Na3Zch7LTllB2anyAzmrOwAYMPgGmgW1UP05QBcVls3q 9V1eCrxBSMKf+jD30UJPY6TTk2PtQVJZTOhqiZBSkSR2gIQuDheKUesaEenOJuSFETwqDB2lL5ZX vDGv81T05L4tQqvaY9Zn4h1kgt/CNSrB56VoTcqNUCG06PYsj7ftAuJoTDxshe/9w6AibcJjpTAh ny4J2F14AAAAAAAA --=-KWheid4e5lTMvOXH+Ij8-- From nobody Tue May 5 16:48: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 0FCFC1A89B1 for ; Tue, 5 May 2015 16:48:09 -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 3P2IjJ6PcXz5 for ; Tue, 5 May 2015 16:48:07 -0700 (PDT) Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4033E1A8967 for ; Tue, 5 May 2015 16:48:07 -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 200B65FB88 for ; Tue, 5 May 2015 23:48:06 +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 H7Mm-Ar1Gn_W for ; Tue, 5 May 2015 23:48:04 +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 ; Tue, 5 May 2015 23:48:04 +0000 (UTC) Message-ID: <1430869683.28399.109.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 06 May 2015 01:48:03 +0200 In-Reply-To: <871tiupupe.fsf@littlepip.fritz.box> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-vFuRacPrygMWx7bWGYwi" 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: Tue, 05 May 2015 23:48:09 -0000 --=-vFuRacPrygMWx7bWGYwi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-05-05 at 23:26 +0200, Vincent Breitmoser wrote:=20 > I would like to pick up on this point again: What's wrong with 160 bit > fingerprints? The bit length seems more than sufficient to cover any > Mooreian doubts, a more relevant issue would be weaknesses in the > hashing algorithm itself, Hmm but if it can be easily done, is there anything that speaks against? I think hashes up to 512 bit are still commonly "accepted" (even with just hex encoding)... and I see no strong reason why we couldn't move to e.g. RFC 4648 base32. Actually others do similar things as well (e.g. OpenSSH). And if it doesn't hurt, I rather go for the stronger, even if it should never become necessary. > where the status is that in its 20 years not > even a collision has been found for SHA-1. At least no one publicly known ;-) Cheers, Chris --=-vFuRacPrygMWx7bWGYwi 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUwNTIzNDgw M1owTwYJKoZIhvcNAQkEMUIEQH04q7Ywqw2vX/t8HqVaThixZx2Xz5Q/pCiTE4g6y0GS7NnQxfH+ naQaJ29lKW4HIj1gh74S4pop3dvWrJAEhLEwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAF0xy4xslStXPCD8x3QxYAqddFx8Fp pTbqdTBXvoRc459I6b4SwQOkGntS/kIFKVEzXb3lPCO78C/Kn6ti517GQjoH+o/ZkLdG3Nm6v4ne Hqq7WRGX7Iwpr1gfqmdmwXDaXLzNfKkVfJ0+cg33zdF8RTH45NIFEzrM961UBNeR0l/Beh3Uk5n4 I3lmvjb/TxXjLI+KN5O8cJ3J8MhtEJ2xOF6HkJ4OpgXwvMMJUt224hi/fzOqj/iBggsJZVojdPu8 aRuJAV84gPx2L0hFIA+3WGTlXvY5rn05NlA1LMs1UQSaBLQgXpUa/te5JeVb42W2BUs8X24P7r9N Y/x/OIaIAAAAAAAA --=-vFuRacPrygMWx7bWGYwi-- From nobody Tue May 5 18:35: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 2F0EF1A89BB for ; Tue, 5 May 2015 18:34: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 FR8_Tlkjh7zo for ; Tue, 5 May 2015 18:34:58 -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 CFB851A89FC for ; Tue, 5 May 2015 18:34:57 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so142222325lbc.1 for ; Tue, 05 May 2015 18:34: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=1USYm1oSOh7ex1nWYDbvV+WR+b/KvKQzSM35xOApAg8=; b=vv4AbSrBEfoay8elTP8/zxmNrxdrhe4kUcDEKqYa50AFA1CKReRodsWBlnzAvdWzsZ fzdSz53Lr8hlvpF7wqZmAe0z28x/BIrONW92DnLPITfDdQfsnAetNt+bNj1bKs99hYZr QArom9NhlG0kuf4nXeliDDiIRFZi93sRtnMK1lvB4gXTbuofveTRn4Q4g4My28syIC8M 2T5tWt8k2IjGUPwO4dN0rvSemmNzY/ChH88olbuhtf4zyeDr98P/1UT/9Mugpw42xFeh SrfU9odseUQomqZpJIotKmkCTZa/bmoZpITnwWxDvJhHo6penaH9G9+sN3u9ajAOCIcd Tv2w== MIME-Version: 1.0 X-Received: by 10.152.178.193 with SMTP id da1mr16950312lac.58.1430876096417; Tue, 05 May 2015 18:34:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 5 May 2015 18:34:56 -0700 (PDT) In-Reply-To: <1430869683.28399.109.camel@scientia.net> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> Date: Tue, 5 May 2015 21:34:56 -0400 X-Google-Sender-Auth: otIgDP5pguIM4Bs2pKyS6NYiPog 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] 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, 06 May 2015 01:34:59 -0000 On Tue, May 5, 2015 at 7:48 PM, Christoph Anton Mitterer wrote: > On Tue, 2015-05-05 at 23:26 +0200, Vincent Breitmoser wrote: >> I would like to pick up on this point again: What's wrong with 160 bit >> fingerprints? The bit length seems more than sufficient to cover any >> Mooreian doubts, a more relevant issue would be weaknesses in the >> hashing algorithm itself, The problem isn't the bit length, it is the fact that it is really hard for the IETF to endorse use of SHA-1 in some places but not others. There is really no reason to think that the current attacks make SHA-1 risky in the WebPKI but we are having to swap it out anyway. At some level, the cost of explaining why SHA-1 is safe for a particular use outweighs the benefits of keeping it. > Hmm but if it can be easily done, is there anything that speaks against? I don't think so. Particularly if we are going to Base32 encoding and make sure that there is no confusion between the legacy SHA-1 fingerprints and the new ones. > I think hashes up to 512 bit are still commonly "accepted" (even with > just hex encoding)... and I see no strong reason why we couldn't move to > e.g. RFC 4648 base32. > Actually others do similar things as well (e.g. OpenSSH). Which is why I would like to move to a fingerprint format that can be used with any protocol. Do it once, do it right and we don't have to do it again. > And if it doesn't hurt, I rather go for the stronger, even if it should > never become necessary. We do not even need to decide on a strength. Just make is so that the number of significant bits is however many bits that are provided. We can all use SHA-2-512 or SHA-3-512 and truncate to 125, 150, 250... bits as the application requires. From nobody Wed May 6 00:34:44 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F55F1A8763 for ; Wed, 6 May 2015 00:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhK6rDHYXPd8 for ; Wed, 6 May 2015 00:34:41 -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 4C8451A875D for ; Wed, 6 May 2015 00:34:40 -0700 (PDT) Received: from localhost (p57B2DEA7.dip0.t-ipconnect.de [87.178.222.167]) by mail.mugenguild.com (Postfix) with ESMTPSA id 331F05FD07; Wed, 6 May 2015 09:31:58 +0200 (CEST) References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> From: Vincent Breitmoser To: Phillip Hallam-Baker Date: Wed, 06 May 2015 09:16:22 +0200 In-reply-to: Message-ID: <87y4l2noqd.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christoph Anton Mitterer , 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, 06 May 2015 07:34:43 -0000 On 6 May 2015, Phillip Hallam-Baker wrote: >> Hmm but if it can be easily done, is there anything that speaks >> against? There is such a thing as over-engineering, and increasing a fingerprint bit length upwards of 160 bits "just because we can" seems to go in that direction. 160 bits is all the hashes ever calculated by the entire bitcoin network bitcoin network times all the hashes ever calculated by the entire bitcoin network. Someone said "length is important", I wanted to bring that point back into discussion. I would really prefer not to have every user of FuturePGP read 25 rather than 20 characters to people just because we thought "why not" on this list. The last thing openpgp needs is stronger technical security assertions at the cost of usability. - V From nobody Wed May 6 03:56: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 58D5C1A88FE for ; Wed, 6 May 2015 03:56:51 -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 Zbf_4atchxhe for ; Wed, 6 May 2015 03:56:49 -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 60C9A1A8850 for ; Wed, 6 May 2015 03:56:49 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Ypx0R-0007q6-Mt for ; Wed, 06 May 2015 12:56:47 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YpwxJ-0008P2-Nf; Wed, 06 May 2015 12:53:33 +0200 From: Werner Koch To: Vincent Breitmoser References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <87y4l2noqd.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 , Phillip Hallam-Baker , Christoph Anton Mitterer , IETF OpenPGP Date: Wed, 06 May 2015 12:53:33 +0200 In-Reply-To: <87y4l2noqd.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Wed, 06 May 2015 09:16:22 +0200") Message-ID: <87wq0mt1si.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 , Phillip Hallam-Baker , 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, 06 May 2015 10:56:51 -0000 On Wed, 6 May 2015 09:16, look@my.amazin.horse said: > There is such a thing as over-engineering, and increasing a fingerprint > bit length upwards of 160 bits "just because we can" seems to go in that We also need to consider policy requirements. As Phillip already mentioned it is hard to explain why SHA-1 is sufficient. In particular because we use it in a crypto context. It seems to be hard enough to explain why using SHA-1 would be sufficient to map a string to a restricted character set (for DNS) even without any crypto context. For example: RedHat did a FIPS-140 validation of Libgcrypt and this required that RMD-160 is disabled in Libgcrypt. Now, for historic reasons GnuPG uses this hash algorithm to map user ids to fixed length strings for use in trustdb.gpg. With the Libgcrypt change I had to put separate RMD-160 code into GnuPG to avoid regressions (only Libgcrypt was validated). Eventually the same will happen to SHA-1. To be future proof we should get away from SHA-1 for fingerprints and use SHA-256 (or SHA-512) instead. The external representation and even the internal use in OpenPGP is a different issue and I am all in favor for truncating it to 32 bytes for internal use and printing only up to 20 bytes. This avoids extra work and SHA-256 is anyway required. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed May 6 04:49: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 3AB391A88F7 for ; Wed, 6 May 2015 04:49:25 -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 9uFSajgSRqRM for ; Wed, 6 May 2015 04:49: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 0F6E01A88F5 for ; Wed, 6 May 2015 04:49:22 -0700 (PDT) Received: from localhost (gate.ibr.cs.tu-bs.de [134.169.34.1]) by mail.mugenguild.com (Postfix) with ESMTPSA id 4B9635FAA9; Wed, 6 May 2015 13:46:40 +0200 (CEST) References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <87y4l2noqd.fsf@littlepip.fritz.box> <87wq0mt1si.fsf@vigenere.g10code.de> From: Vincent Breitmoser To: Werner Koch Date: Wed, 06 May 2015 13:36:40 +0200 In-reply-to: <87wq0mt1si.fsf@vigenere.g10code.de> Message-ID: <87wq0mncy0.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Cc: Christoph Anton Mitterer , Phillip Hallam-Baker , 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, 06 May 2015 11:49:25 -0000 --=-=-= Content-Type: text/plain On 6 May 2015, Werner Koch wrote: > To be future proof we should get away from SHA-1 for fingerprints > and use SHA-256 (or SHA-512) instead. I have no quarrel with changing the hash algo. If it improves security at no cost of usability or complexity - go for it. > The external representation and even the internal use in OpenPGP is a > different issue and I am all in favor for truncating it to 32 bytes > for internal use and printing only up to 20 bytes. This avoids extra > work and SHA-256 is anyway required. Sounds good to me. I'm just afraid that if "something stronger" is available, people are going to use it. Design decisions and established culture on top of the standard tend to be maximum conservative. Sort of if you don't use the "full fingerprint" you're not doing "everything you can" and people will use all 32 bytes no matter if it was ever intended that way. That's not a huge deal, we just need to keep it in mind. I would leave the fingerprint length at 20 bytes in the standard, if an implementation chooses to use more internally that's up to them. Defining the fingerprint to be 32 bytes, then adding "for printing, it SHOULD be truncated to 20 bytes" seems silly. - V --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVSf+3AAoJEHvRgyDerfoReKgP/R7075ArRBC68Su3ABhr1NY6 tFKaQILDGYzE9vQaFlb5U2Wk7D5zjEkD/W3C6HYuhm3d2s3HecnSPadpZH+2vTmn W48b/wgp7biR2QrDAWArAXkm3EA6oqmYnxOzySk0V6W557XMMS+Y8+p6EOGdskzw n+amVJnFh3zLyP7rrngpnP8Vsz30+4Fc0VuqntFIdwOv+JXatMICVTaeqG4DK7hp oP6ruu9htsrv2NbSFXGkMmlbq7mGHFWZuLKRMvIQW8MFBdc+Pj0xoNaDZgsz3RCM 5c55a+uOtGFxd+If0bwPqCWAMIADucwZJkLwiQ0GiC+P0x3Be2PHwUEunMMKn830 c9SG8EYiXQjakMhLDeLVvIDJPwou5BxW1Hc0J3gP9R3SOv20WP11kdwHiKp5dZjm jCUrmHnPl7LUoVDwJ8kWiYa92qsQpb7lUo6ytginmdbEq0diPxlsFw50adPaSOak 0YlGnVF1Izldw3l7G8WCo5/JKBzht1TeMkQhl2E6YeapfJD5PVA34DzS36dJyrre kBe0mUx8VKwGCvsLSrE9D3ewsy2EUOr60abR0jS9HEggoxQ9KYlRgx+uVdqT/+Qd oEE1NTlnF2te2Cca/m+u86ChcLIK0NqZE1491OFcTGxKlg9skRqnTBIzyXsrGfVz 2OCU6qjpkkQAW3EyIaYA =f0EM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 6 07:31: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 8A10E1ACD96 for ; Wed, 6 May 2015 07:31:20 -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 ENDZgoRInBPw for ; Wed, 6 May 2015 07:31:11 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5561A1ACD9B for ; Wed, 6 May 2015 07:31:11 -0700 (PDT) Received: from [174.252.48.113] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Yq0Lu-0000TJ-32; Wed, 06 May 2015 10:31:10 -0400 Date: Wed, 6 May 2015 07:31:09 -0700 From: Bill Frantz To: Christoph Anton Mitterer X-Priority: 3 In-Reply-To: <1430869352.28399.104.camel@scientia.net> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79e179810f8584bf0c89718ce532776680350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.252.48.113 Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] Key Validity Scenarios X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 06 May 2015 14:31:20 -0000 On 5/6/15 at 4:42 PM, calestyo@scientia.net (Christoph Anton=20 Mitterer) wrote: >>- Key expired two weeks ago. Status of a signature from three weeks ago? >IMHO not well defined. >One may e.g. choose to consider the signature still valid, but not the >key... and e.g. an implementation may then say "valid signature from a >trusted but expired key". >In addition it may e.g. make some "guess"... like when they expiration >is 5 days ago it may just print the warning... but if it was 10 years >ago it would start to flash the screen like mad and play alert sirens at >all sound devices. This answer is clearly wrong for several useful scenarios. For example: I am looking at a ten year old audit report for a company=20 prepared by an audit firm. The audit firm signed it with their=20 then-current key, which they change regularly, following "best=20 industry practices". It is not a red light alert for the key to=20 be expired. It is not a red light alert for the data to be old.=20 The only time an alert is justified is when the key expired=20 before the signature was made. 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 Wed May 6 08:07: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 384C61ACE02 for ; Wed, 6 May 2015 08:07: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 giSOvAcZLmJg for ; Wed, 6 May 2015 08:07:24 -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 AFA611A8AAC for ; Wed, 6 May 2015 08:07:08 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so9827199lbb.2 for ; Wed, 06 May 2015 08:07:07 -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=0JlmICjTnbMoMYkbMjwRsEgFSBYUUAzhNkCuiVwlqzQ=; b=chxAqUe6MKukmypWaoY1e7WGLvBuzaTc7KD8vzWoFdfV9Rhehcos3/ES+xeABFlTGf Nj+yzUV3IL3n3q8BsjB8TstbyU3PgQ5InNOdn5RCvVitAiZZNnqmdoDBw6Egq2iilS8y bWtPWVbr+rOfU9Yka6CWO+ITsz8gRbMNdNpNXLQFCg6lyTRV9RSUzYLExtuBxwrYwpLP ladR7pIaLH5RiLOv2iJwX9uRBIffwgdIUGSCdWiStQeqLNWgmeNV596vKln9GlsRfziF 7vVaUqvG7MCu6Vhc68n3CmrChZQZECdQhjPHyqd5guIS/ZQ2PIhS++gIeNP+36uRITYC 2qNA== MIME-Version: 1.0 X-Received: by 10.112.16.42 with SMTP id c10mr7735456lbd.103.1430924827201; Wed, 06 May 2015 08:07:07 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 6 May 2015 08:07:07 -0700 (PDT) In-Reply-To: References: <1430869352.28399.104.camel@scientia.net> Date: Wed, 6 May 2015 11:07:07 -0400 X-Google-Sender-Auth: EuMDKMBY9vTWRKaJfSrSYAQYoc0 Message-ID: From: Phillip Hallam-Baker To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , IETF OpenPGP Subject: Re: [openpgp] Key Validity Scenarios X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 06 May 2015 15:07:25 -0000 We have been going round on the question of how to validate a signature for 25 years now. I have yet to see a rigorous approach with S/MIME or PGP and I suspect that is because it is impossible to address the problem using just a signature. But the problem can be addressed quite easily with a blockchain approach. The first thing to do is to draw up a lifecycle for the keybinding as a finite state machine: [Valid] Expire -> [Expired] Revoke -> [Revoked] [Expired] Revoke -> [Revoked] The next thing to do is to decide why you are checking the signature: 1) To see if the key holder still backs an assertion 2) To see if the key holder backed an assertion at the time the signature was created 3) To see if the key holder backed an assertion at the time the signature was received The mapping of these criteria to the state machine states is pretty straightforward. If we are checking key signings, certificate chains, SAML assertions, etc. we have a type 1 problem. If we are checking a contract in an archive system then we have a type 2 problem. But for email, we have a type 3 situation. Working with existing infrastructure, the way to check the signature of PGP mail would be to look at the time the message was received. The way to solve the problem comprehensively is to intern all key bindings and signatures in an unforgeable notary log as they are created. From nobody Wed May 6 11:13: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 C0DE41A88FD for ; Wed, 6 May 2015 11:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 w2GQZB_V3obL for ; Wed, 6 May 2015 11:13:09 -0700 (PDT) Received: from smtp1.emailarray.com (smtp1.emailarray.com [65.39.216.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678621B2DDB for ; Wed, 6 May 2015 11:12:57 -0700 (PDT) Received: (qmail 77159 invoked by uid 89); 6 May 2015 18:12:55 -0000 Received: from unknown (HELO ?204.29.149.87?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp1.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 May 2015 18:12:55 -0000 From: "Christopher LILJENSTOLPE" To: "Werner Koch" Date: Wed, 06 May 2015 11:12:54 -0700 Message-ID: <428BCDDC-17AD-4EF3-BC19-E71FF462C79B@asgaard.org> In-Reply-To: <87ioc8zopl.fsf@vigenere.g10code.de> References: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> <87ioc8zopl.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_4946B0A1-A5F0-4288-B4E5-3CF9E97B2696_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor , Stephen Farrell Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 06 May 2015 18:13:11 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_4946B0A1-A5F0-4288-B4E5-3CF9E97B2696_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings Werner, Our friendly AD can chime in here, but here's my take. Working Groups have a tendency to continue to exist past their "use-by" d= ate. As they do, the quality and velocity of their output tends to decli= ne. There are some counterexamples, but, unfortunately, there are a lot = of positive proof-points. What we've tried to do is have long-lived "res= earch this area and see if there is something we can do" work move into t= he IRTF, and leave the IETF for actually actioning on specific requiremen= ts. = However, this is, after all, the community's working group, so if the com= munity feels that the scope (and therefore, duration) should be more expa= nsive, we can propose that for a charter, but the larger the charter, the= more "convincing" we need to do, especially if the technology is mature = like PGP is. Christopher On 4 May 2015, at 2:17, Werner Koch wrote: > Hi, > > and thanks for taking up this job. > > On Fri, 1 May 2015 22:43, cdl@asgaard.org said: > >> 1) The primary charter goal would be create a RFC4880bis document. >> a) At the end of that process, we would either re-charter, or close. >> b) Other documents (informational or bcp) MAY be entertained by the >> WG, but are not required for the WG to complete it's task, nor will= >> their progress "keep the WG from closing" > > I am fine with that. > > I am a bit curious why the IETF seems to have a policy to have only > short living working groups. A hint to a document explaining that woul= d > be appreciated. > > > Shalom-Salam, > > Werner > > -- = > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe --=_MailMate_4946B0A1-A5F0-4288-B4E5-3CF9E97B2696_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVSlmmAAoJEGmx2Mt/+Iw/SdIH/2DscApYT2uMZJsN6MqbblGt cd4Y5Uh6CoJks/YQCZFCy3uPX+R6vCmWylu7jcQWXWS1fRnH2QZk50ZwBMpMdYe/ lXEBr4XS3q2PjDuUHQvZjUzCIOsr1shC59FveNIrvWOpW/6m/tBUFShxalWNA1Sc XTKmnjDxGgBjEXTv5e6ExNI0lNiR7WQKiWqSq8kDVwNURZLFc0d6RPFNz7bv8W9k yLhiVExq4wqG0G1hRlVyMO60ULOcclwvGd+9syrtA31lGXCz0dfYXq3DQ+CIy01d pQhuNPTxpH3cP6Wl8UcemUTcQYCnaudLs11Zm8EQlQZuJHilsEFUYNB5/A1JfJg= =sOwZ -----END PGP SIGNATURE----- --=_MailMate_4946B0A1-A5F0-4288-B4E5-3CF9E97B2696_=-- From nobody Wed May 6 11:33: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 34E9E1A870B for ; Wed, 6 May 2015 11:33:26 -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 VSRR2TH7SW7X for ; Wed, 6 May 2015 11:33:24 -0700 (PDT) Received: from smtp5.emailarray.com (smtp5.emailarray.com [65.39.216.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03DC1A1E0B for ; Wed, 6 May 2015 11:33:21 -0700 (PDT) Received: (qmail 17001 invoked by uid 89); 6 May 2015 18:33:20 -0000 Received: from unknown (HELO ?204.29.149.87?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp5.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 May 2015 18:33:19 -0000 From: "Christopher LILJENSTOLPE" To: "Vincent Breitmoser" Date: Wed, 06 May 2015 11:33:16 -0700 Message-ID: In-Reply-To: <87wq0mncy0.fsf@littlepip.fritz.box> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <87y4l2noqd.fsf@littlepip.fritz.box> <87wq0mt1si.fsf@vigenere.g10code.de> <87wq0mncy0.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_28DD80C0-017B-4F5A-9CF4-B32E880EE5C8_="; micalg=sha1; protocol="application/pkcs7-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] [eX-bulk] : Re: 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, 06 May 2015 18:33:26 -0000 This is an S/MIME signed message (RFC 5652 and 5751). --=_MailMate_28DD80C0-017B-4F5A-9CF4-B32E880EE5C8_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 6 May 2015, Werner Koch wrote: >> To be future proof we should get away from SHA-1 for fingerprints >> and use SHA-256 (or SHA-512) instead. > > I have no quarrel with changing the hash algo. If it improves security= > at no cost of usability or complexity - go for it. > >> The external representation and even the internal use in OpenPGP is a >> different issue and I am all in favor for truncating it to 32 bytes >> for internal use and printing only up to 20 bytes. This avoids extra >> work and SHA-256 is anyway required. > > Sounds good to me. I'm just afraid that if "something stronger" is > available, people are going to use it. Design decisions and establishe= d > culture on top of the standard tend to be maximum conservative. Sort o= f > if you don't use the "full fingerprint" you're not doing "everything yo= u > can" and people will use all 32 bytes no matter if it was ever intended= > that way. That's not a huge deal, we just need to keep it in mind. > > I would leave the fingerprint length at 20 bytes in the standard, if an= > implementation chooses to use more internally that's up to them. > Defining the fingerprint to be 32 bytes, then adding "for printing, it > SHOULD be truncated to 20 bytes" seems silly. I think this is a reasonable approach. The phrasing I would use would be= something along the lines of: Any implementation MUST accept a 20 byte fingerprint for validation, cons= isting of the first 20 bytes of the calculated fingerprint. An implementation MAY output, or accept, a longer fingerprint, if desired= =2E An implementation MAY output, or accept, the legacy SHA-1 fingerprint, fo= r interoperability, but it's use SHOULD be discouraged. The use of RFC 4648 would make things easier, btw, and also signal the ne= w fingerprint model. The concept will be familiar to anyone who uses git, btw. Christopher > > - V > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe --=_MailMate_28DD80C0-017B-4F5A-9CF4-B32E880EE5C8_= Content-Description: S/MIME digital signature Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM5DCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGqDCCBZCg AwIBAgIDAoO3MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNTA2MjE1ODA3WhcNMTIwNTA3MDcwNjI2WjBCMSAwHgYDVQQNExc0MjA4MTMtcTIxTFE2NURH d3libWE4aDEeMBwGCSqGSIb3DQEJARYPY2RsQGFzZ2FhcmQub3JnMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA41Mhpd4Mgd/OgpeB7iTvafaQgExd/B+ONL//xHcZZDapR9pAxA0KNfM9 JmatX462tvsLA6ysn5MQHgddgxJnZKnJhvAhUyxwIDh12vPOXr9bFN/Iqcrsy1Y+MYmiY4hW4+8l S9hRK92hkgqhNMQxD3f96uRI45J7iIzVevXLlPikDt56CPmJQU0arWohSi0G4/oM0yBE08uqqJkX ey0GlVlU8GLfB/F2O+qL5kyYBSi5cDIoQsG8gcdp/RTBgeHcMTUBcmPFr8lkYrkhONBWaO6By16j fglMYfArgLHNT6UzdHR/glNdztxrvE9cZFaQvlFgAwg2osiNqHzCKYvEYwIDAQABo4IDWjCCA1Yw CQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0G A1UdDgQWBBQpXHgHzlaAvogpKAUTBbhLi22KUTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y 1LhRgjAaBgNVHREEEzARgQ9jZGxAYXNnYWFyZC5vcmcwggHRBgNVHSAEggHIMIIBxDCCAcAGCysG AQQBgbU3AQICMIIBrzAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBk ZjCCAUUGCCsGAQUFBwICMIIBNzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgEBGoIBClRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNz IDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5IHBvbGljeSBhbmQgbWF5IGJlIHJlbGllZCB1cG9uIG9ubHkgZm9yIHRoZSBpbnRl bmRlZCBwdXJwb3NlIGFuZCBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGln YXRpb25zLiBMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhMDYGA1UdHwQvMC0w K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2Ns aWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNs YXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAgMjjqdWaANq8zC6EHSIW/qDlfy5C0b6Fo5JtaIwQ08hnY5uQdq6B DyQPHPqpjSsdIomJXo64v2Wa98LzPnKZDMrLZWLnAaoZYre/sHPTN65+Lt8ih8DplmGOtUASmdPq S6lThhXnRVnEV5+UG4PAL95yLWDKkZlUKywo5qfW13D0CoxtZ9JDKXpR/IUwn/9N4TmTE3fsUQgl n82b8GDQ5pBGI9ABkpugPntpzwIbSJcl2S05/SpKJjwte0FcdE37aqvjY22byYntgOCHpGnBSQYc 5af30VKFdYmvTFvovLE14NPyR7aklfBbVuNzEFfkH6yzze6ffYNnJ17A2YdbAjGCAbwwggG4AgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwKDtzAJBgUrDgMCGgUAMA0GCSqGSIb3 DQEBAQUABIIBAAXR5V5yT/FE5g2YpDBqUPdLnSufM5uCilJG4IUNtk7bvsf/Bv0QvaZfNpq4T/E2 Av8YSPJwB7AD17H5Tozt8emc0xORY8qaoWphhITv8Wu+QAgJ2nCIED91sijNAmSj0PtyoR3tXxjO RJc12WXvXVT8T6p6Q8cIX9cV57rC6qUOL/FYy1ftW1wGdbzp1W3/8hdvLOwJHQiZs3hqrCEmUwHV KX73zhsDnFlrvkOGpiSD/qrnjfzvSO4bHqvriU4KTEfsSpMNFLyHIwBr5EkI4ZpTJlWAGrA4cZMr UPn2SqY2GR6yEh5vZxOPaF8glmaiLpjiOvL6rRrU6bvbB+OL/LYAAAAAAAA= --=_MailMate_28DD80C0-017B-4F5A-9CF4-B32E880EE5C8_=-- From nobody Wed May 6 11:34: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 97D5F1A8028 for ; Wed, 6 May 2015 11:34: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 7azCEF7ZOuO3 for ; Wed, 6 May 2015 11:34:51 -0700 (PDT) Received: from smtp5.emailarray.com (smtp5.emailarray.com [65.39.216.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BDD1A1E0B for ; Wed, 6 May 2015 11:34:51 -0700 (PDT) Received: (qmail 19422 invoked by uid 89); 6 May 2015 18:34:50 -0000 Received: from unknown (HELO ?204.29.149.87?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp5.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 May 2015 18:34:50 -0000 From: "Christopher LILJENSTOLPE" To: "Vincent Breitmoser" Date: Wed, 06 May 2015 11:34:42 -0700 Message-ID: <3658B688-5B15-4E0F-8D5C-422AC10A982E@asgaard.org> In-Reply-To: References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <87y4l2noqd.fsf@littlepip.fritz.box> <87wq0mt1si.fsf@vigenere.g10code.de> <87wq0mncy0.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_D636DFBC-BBB3-4444-9140-D6836E4C8C4E_="; micalg=sha1; protocol="application/pkcs7-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: Cc: Werner Koch , Christoph Anton Mitterer , Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] [eX-bulk] : Re: 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, 06 May 2015 18:34:53 -0000 This is an S/MIME signed message (RFC 5652 and 5751). --=_MailMate_D636DFBC-BBB3-4444-9140-D6836E4C8C4E_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ooops, forgot to reassert the bit.... On 6 May 2015, at 11:33, Christopher LILJENSTOLPE wrote: > > >> On 6 May 2015, Werner Koch wrote: >>> To be future proof we should get away from SHA-1 for fingerprints >>> and use SHA-256 (or SHA-512) instead. >> >> I have no quarrel with changing the hash algo. If it improves securit= y >> at no cost of usability or complexity - go for it. >> >>> The external representation and even the internal use in OpenPGP is a= >>> different issue and I am all in favor for truncating it to 32 bytes >>> for internal use and printing only up to 20 bytes. This avoids extra= >>> work and SHA-256 is anyway required. >> >> Sounds good to me. I'm just afraid that if "something stronger" is >> available, people are going to use it. Design decisions and establish= ed >> culture on top of the standard tend to be maximum conservative. Sort = of >> if you don't use the "full fingerprint" you're not doing "everything y= ou >> can" and people will use all 32 bytes no matter if it was ever intende= d >> that way. That's not a huge deal, we just need to keep it in mind. >> >> I would leave the fingerprint length at 20 bytes in the standard, if a= n >> implementation chooses to use more internally that's up to them. >> Defining the fingerprint to be 32 bytes, then adding "for printing, it= >> SHOULD be truncated to 20 bytes" seems silly. > > I think this is a reasonable approach. The phrasing I would use would = be something along the lines of: > > Any implementation MUST accept a 20 byte fingerprint for validation, co= nsisting of the first 20 bytes of the calculated fingerprint. > An implementation MAY output, or accept, a longer fingerprint, if desir= ed. > An implementation MAY output, or accept, the legacy SHA-1 fingerprint, = for interoperability, but it's use SHOULD be discouraged. > > The use of RFC 4648 would make things easier, btw, and also signal the = new fingerprint model. > > The concept will be familiar to anyone who uses git, btw. > > > Christopher > >> >> - V >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp > > > -- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Avt tace, avt loqvere meliora silentio > Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc > Current vCard here: http://www.asgaard.org/cdl/cdl.vcf > keybase: https://keybase.io/liljenstolpe_______________________________= ________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe --=_MailMate_D636DFBC-BBB3-4444-9140-D6836E4C8C4E_= Content-Description: S/MIME digital signature Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM5DCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGqDCCBZCg AwIBAgIDAoO3MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNTA2MjE1ODA3WhcNMTIwNTA3MDcwNjI2WjBCMSAwHgYDVQQNExc0MjA4MTMtcTIxTFE2NURH d3libWE4aDEeMBwGCSqGSIb3DQEJARYPY2RsQGFzZ2FhcmQub3JnMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA41Mhpd4Mgd/OgpeB7iTvafaQgExd/B+ONL//xHcZZDapR9pAxA0KNfM9 JmatX462tvsLA6ysn5MQHgddgxJnZKnJhvAhUyxwIDh12vPOXr9bFN/Iqcrsy1Y+MYmiY4hW4+8l S9hRK92hkgqhNMQxD3f96uRI45J7iIzVevXLlPikDt56CPmJQU0arWohSi0G4/oM0yBE08uqqJkX ey0GlVlU8GLfB/F2O+qL5kyYBSi5cDIoQsG8gcdp/RTBgeHcMTUBcmPFr8lkYrkhONBWaO6By16j fglMYfArgLHNT6UzdHR/glNdztxrvE9cZFaQvlFgAwg2osiNqHzCKYvEYwIDAQABo4IDWjCCA1Yw CQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0G A1UdDgQWBBQpXHgHzlaAvogpKAUTBbhLi22KUTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y 1LhRgjAaBgNVHREEEzARgQ9jZGxAYXNnYWFyZC5vcmcwggHRBgNVHSAEggHIMIIBxDCCAcAGCysG AQQBgbU3AQICMIIBrzAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBk ZjCCAUUGCCsGAQUFBwICMIIBNzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgEBGoIBClRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNz IDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5IHBvbGljeSBhbmQgbWF5IGJlIHJlbGllZCB1cG9uIG9ubHkgZm9yIHRoZSBpbnRl bmRlZCBwdXJwb3NlIGFuZCBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGln YXRpb25zLiBMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhMDYGA1UdHwQvMC0w K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2Ns aWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNs YXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN BgkqhkiG9w0BAQUFAAOCAQEAgMjjqdWaANq8zC6EHSIW/qDlfy5C0b6Fo5JtaIwQ08hnY5uQdq6B DyQPHPqpjSsdIomJXo64v2Wa98LzPnKZDMrLZWLnAaoZYre/sHPTN65+Lt8ih8DplmGOtUASmdPq S6lThhXnRVnEV5+UG4PAL95yLWDKkZlUKywo5qfW13D0CoxtZ9JDKXpR/IUwn/9N4TmTE3fsUQgl n82b8GDQ5pBGI9ABkpugPntpzwIbSJcl2S05/SpKJjwte0FcdE37aqvjY22byYntgOCHpGnBSQYc 5af30VKFdYmvTFvovLE14NPyR7aklfBbVuNzEFfkH6yzze6ffYNnJ17A2YdbAjGCAbwwggG4AgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwKDtzAJBgUrDgMCGgUAMA0GCSqGSIb3 DQEBAQUABIIBAMKJj6YysAp5qVwq/tX/WGDUxZ9thu3XkmLOO+9XRcov/UpUSG9ixupNvf3o671u C637nFl1ffdHCor6HKo9g5SAWZn/5YjEYmBbGx8VDa+C4KSHFtIBxQq6v46kSsEG934odgshNJMs 3lATJlOuE6uumCLdQUT/5GNWCZ6V3Tm6boXuZ7eK4rvyR4TARrGOW7RDmqhIKo8ns8cwx9P6abhO Mslrtg8EXD6voHXmI1WO7Z9RKX/iZ9r2jtoJ5r2uTz4NWjn5LDT6YekjG93T3db1yn8xlBHOTG7L ZlWxqQNwmUU9183FdTRmz3/EhnpkAuIcavAUAHQHqsjjYBYmXZYAAAAAAAA= --=_MailMate_D636DFBC-BBB3-4444-9140-D6836E4C8C4E_=-- From nobody Wed May 6 11:38: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 CE1851A6FF5 for ; Wed, 6 May 2015 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQpIong8mRf8 for ; Wed, 6 May 2015 11:38: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 5FE161A6FFA for ; Wed, 6 May 2015 11:38:16 -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 1BBFD5FC1B for ; Wed, 6 May 2015 18:38:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id mb62cqk1W2SY for ; Wed, 6 May 2015 18:38:13 +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 ; Wed, 6 May 2015 18:38:12 +0000 (UTC) Message-ID: <1430937492.28399.127.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Wed, 06 May 2015 20:38:12 +0200 In-Reply-To: References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-FZpOAnf54mig3SF4AAbC" 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, 06 May 2015 18:38:22 -0000 --=-FZpOAnf54mig3SF4AAbC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-05-05 at 21:34 -0400, Phillip Hallam-Baker wrote:=20 > I don't think so. Particularly if we are going to Base32 encoding and > make sure that there is no confusion between the legacy SHA-1 > fingerprints and the new ones. Which is easily achieved when we add some algo/version qualifier as it was propsed before. > Which is why I would like to move to a fingerprint format that can be > used with any protocol. Do it once, do it right and we don't have to > do it again. In principle I'd agree... apart from that I don't believe we'll never have to do it again (in the sense of exchanging the algo). However, as for the "core" standard I'd still only specify a simplest form of a fingerprint string format. e.g. something like : and then for the "current" algo/version e.g. 0: (i.e. the length would be dependant on . Any further specifications, like how to map this into URLs or that like should probably go into a separate RFC. As should any further "formats" like a QR code representation of the FP. > We do not even need to decide on a strength. Just make is so that the > number of significant bits is however many bits that are provided. We > can all use SHA-2-512 or SHA-3-512 and truncate to 125, 150, 250... > bits as the application requires. I'm a bit sceptical about that... I think we rather should specify some lengths/format and at least not encourage implementations to choose what they think would be enough (cause then we have folks like GNOME which take the first and last byte or so *grin*) Cheers, Chris. --=-FZpOAnf54mig3SF4AAbC 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUwNjE4Mzgx MlowTwYJKoZIhvcNAQkEMUIEQEscwMGYQc2wQyuS4aQN/zsqBtYcTuE5MgdCzIAACdr8W+Emi2s6 2cjscedpjt0zQzJ991i8k7RBTuPefHIgMZUwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQAJwinQbuudDVxsS8fnHyj0v7j+D4wV k30zdiiSK+ltarPPKBwA50eS+qnBN7EcOzyynFE2IfiPQ4v5tm+6iYl2JqpPn0Lg14xpvaH/aNrk ZrMDiagnY+2yFgNs6r2+8Pd+UeYuM/v5S2t23y4VMXjoUCEZzpjnfPJsqUjoBQdEjusf14Oeypso WZ4MCUJ6mQrdE2AaMeNwexJwBD/Gy95n4ZF+LjVGyzN7SoD0E/bcxE0BXifL3pilyum7h2XNMamy vlp5oGsXOzsYD2NWbA20Wi0gmSAjIZjh/3sXOVMKFqoSE8SEufJyvoSTr50NFHFLAsViPwRPFimA lUb42pcAAAAAAAAA --=-FZpOAnf54mig3SF4AAbC-- From nobody Wed May 6 11:44: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 8E72B1A9053 for ; Wed, 6 May 2015 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On7H7mKnSacP for ; Wed, 6 May 2015 11:43:59 -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 1A7ED1A8F4B for ; Wed, 6 May 2015 11:43:59 -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 DAF145FB93 for ; Wed, 6 May 2015 18:43:57 +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 wwuFR5YFU87N for ; Wed, 6 May 2015 18:43:56 +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 ; Wed, 6 May 2015 18:43:56 +0000 (UTC) Message-ID: <1430937835.28399.133.camel@scientia.net> From: Christoph Anton Mitterer To: openpgp@ietf.org Date: Wed, 06 May 2015 20:43:55 +0200 In-Reply-To: <87y4l2noqd.fsf@littlepip.fritz.box> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <87y4l2noqd.fsf@littlepip.fritz.box> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-WJykquBe77ki48mFIg1c" 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, 06 May 2015 18:44:00 -0000 --=-WJykquBe77ki48mFIg1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-05-06 at 09:16 +0200, Vincent Breitmoser wrote:=20 > There is such a thing as over-engineering, and increasing a fingerprint > bit length upwards of 160 bits "just because we can" seems to go in that > direction. Technically you may be right, but I think it's nevertheless the wrong paradigm to approach security... "wrong" of course in the sense that there are different paradigms and I'm on the other side ;-) Generally we don't know for sure what our attackers (especially the big ones like NSA) are capable of (right now), but it's likely that they're at least some years ahead in terms of research. Neither do we know for sure how cryptoanalysis moves on. My paradigm is to generally assume the worst case respectively strengthen crypto the most possible so that it's still usable (in the technical sense). Cheers, Chris. --=-WJykquBe77ki48mFIg1c 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUwNjE4NDM1 NVowTwYJKoZIhvcNAQkEMUIEQIpvxjKPV6cfbc3wKGJKOGGpLb1Ip3HulBkjdLHqbIOZNXMVHe6w AM6Xj8doK5nVicKradbgjiJ3tTs4zwduB9AwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQBNxwA5ncD5qKMeLfXzdoWqtMSLTnVX BBidt4iQDyCWoetxim9e6D6cjgNqwWs4kCufii6HGlTzhYGv2gvRPAPh1Z7hxJP5PDWjryH5BYnR z83K+NVw8RpJoER+BPOuWABuV1YP6qOqQ5kCPWqJZaZHr00bJAccWwaGjCCAMwxZtNJS2bCs397r YqoVMkyl2zQ25JWXd9KYGUjSUoZy6h3OMIPCtYy+gP2BZJDDbYJR+hR9G1rI2LLYk6NFJjT4Nb9P Tr3hFkxfp65MW2gmU9PDLteNBzdJqJD81fwfkLk5P34VRuav7laqpbbHMmZv+T3/YdsVEZHQZ6UA 9W9E6tlhAAAAAAAA --=-WJykquBe77ki48mFIg1c-- From nobody Wed May 6 13:38: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 639BE1B2EE0 for ; Wed, 6 May 2015 13:38:32 -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 cNM296gtzaIp for ; Wed, 6 May 2015 13:38:30 -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 042351ACE26 for ; Wed, 6 May 2015 13:38:29 -0700 (PDT) Received: by layy10 with SMTP id y10so16308505lay.0 for ; Wed, 06 May 2015 13: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=QG4R5ozi0+xwzjRHW40Kt3XEeeJ+dryPbdTX19GE0D8=; b=boGIRfOPzkiiYVMrLL87ZL3X9Onu/uo3YIWO79w3JpMn432j7DvLdeL26y0mTs5kDB xZwm7EqEfOMszpJss4iki+m9gq86kiwGsnXsd+AC9WYbN5tpXe6pfh6XJPzbWqP0UB/+ g9o1MnIVq07F3EF6U8vtsr8hyawFo8PvRA2X4WyEpCnW6lSeEENL2A76+7udsStwAUGe 6tsTaQDFKsVtIBtPiagWBDnq8tty12XMotm2+a8z7ymqoi2RkaXJU4LDvBCFSAz6QFwk 1kgNHPRlVlGx40KiQZnLsnK0GEjkgiwDfYS2l2w+VGWsqK97QM1cHX/bDFQ3JA13A77W BFgA== MIME-Version: 1.0 X-Received: by 10.112.202.103 with SMTP id kh7mr404663lbc.118.1430944708323; Wed, 06 May 2015 13:38:28 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 6 May 2015 13:38:27 -0700 (PDT) In-Reply-To: <1430937492.28399.127.camel@scientia.net> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.camel@scientia.net> Date: Wed, 6 May 2015 16:38:27 -0400 X-Google-Sender-Auth: rvkmlsH0Z4qAu7sDlwzdfsNhkeU Message-ID: From: Phillip Hallam-Baker To: Christoph Anton Mitterer Content-Type: multipart/mixed; boundary=001a11c3699a08bf8d05156fc785 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, 06 May 2015 20:38:32 -0000 --001a11c3699a08bf8d05156fc785 Content-Type: text/plain; charset=UTF-8 On Wed, May 6, 2015 at 2:38 PM, Christoph Anton Mitterer wrote: > On Tue, 2015-05-05 at 21:34 -0400, Phillip Hallam-Baker wrote: >> I don't think so. Particularly if we are going to Base32 encoding and >> make sure that there is no confusion between the legacy SHA-1 >> fingerprints and the new ones. > Which is easily achieved when we add some algo/version qualifier as it > was propsed before. One of the reasons I suggested the code numbers for SHA-2 and SHA-3 that I did earlier is they guarantee that the first letter of the fingerprint will be M (SHA-2 'Merkle') or S (SHA-3 'Spongeworthy'). Thus ensuring that they are distinct from SHA1 fingerprints. >> Which is why I would like to move to a fingerprint format that can be >> used with any protocol. Do it once, do it right and we don't have to >> do it again. > In principle I'd agree... apart from that I don't believe we'll never > have to do it again (in the sense of exchanging the algo). The leading byte gives both the method of constructing the hash and the algorithm to use. I suggest we define code points for SHA-2 and SHA-3 using an identical construction approach. > However, as for the "core" standard I'd still only specify a simplest > form of a fingerprint string format. > e.g. something like > : > and then for the "current" algo/version e.g. > 0: > (i.e. the length would be dependant on . I think we can go even simpler: Fingerprint = Base32ify (BinaryFP) BinaryFP = ID + H( HashedValue) HashedValue = ':' Since the MIME content registry does not permit entries with a colon in the tag, this is guaranteed to be unambiguous. And since a Content-Type can be defined for any data object that might need to be hashed, it can support any content. All the PGP related information would go in the field, so that would include the PGP format version identifier, algorithm code, etc, etc. > Any further specifications, like how to map this into URLs or that like > should probably go into a separate RFC. > As should any further "formats" like a QR code representation of the FP. All that would be needed in the PGP spec would be a definition of the PGP Key Packet and a MIME registration (if not already registered). We should definitely split the consideration of QR codes etc out of the PGP doc. We probably want to define the QR code in such a way that a device can recognize that a QR code is intended to be a PGP key and handle it appropriately. We also want to make sure we don't waste bits in QR space. And it has to be possible to convert an ascii fingerprint to QR format. >> We do not even need to decide on a strength. Just make is so that the >> number of significant bits is however many bits that are provided. We >> can all use SHA-2-512 or SHA-3-512 and truncate to 125, 150, 250... >> bits as the application requires. > I'm a bit sceptical about that... I think we rather should specify some > lengths/format and at least not encourage implementations to choose what > they think would be enough (cause then we have folks like GNOME which > take the first and last byte or so *grin*) If we are using Base32 and character groups of 5 characters (7-2 rule), the keys naturally come in 25 bit increments. A 125 bit fingerprint has 117 bits and looks like this: MFRTK-NJSMF-STOMR-WG5ST-ONZXGA If we go for 150 bits we get: MFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB >From a security point of view, we really don't need to go beyond 128 bits unless we are planning to use 256 bit encryption. I think that either of those is acceptable on a business card. The QR code equivalent is manageable even without format tweaks (attached). In 'under the covers' applications the user does not need to see, I would hope we would support use of the 256 bit or full 512 bit fingerprint. I would also hope we can use the possibility of an online store to 'stretch' a fingerprint. If the user types in a 25 character fingerprint, the system can get the rest off a key service. --001a11c3699a08bf8d05156fc785 Content-Type: image/jpeg; name="qr_code_without_logo.jpg" Content-Disposition: attachment; filename="qr_code_without_logo.jpg" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i9d6z07l1 iVBORw0KGgoAAAANSUhEUgAAAXIAAAFyAQMAAADS6sNKAAAABlBMVEX///8AAABVwtN+AAABqUlE QVQIme2aTa6DMAyELXGAHImrcyQOgOQ2/okjoO3uPQ2aWYRCvmQT27GtilAURVEU9T/S0CE+bP3b JouKtJzbyOPy/tKCl3Wfv80IeUy+H/vW+f5LVjVqiW/DRsjD87qHl+cE+Sfxru7vIh7PyT+Bt4f5 e3r5e9Ey7UEema98LIJ6DT/yN/IA/CRLxSIpW/SeIQ/Gv2/ppCyKezz3S7u/Xu2HPBavNZeu7t/a CATkcfnqffh9LSNH69NT+UwekRerjXV4uYXy8HKbuEZ28lC8pdWtXD0zb99DLvZAHon3E7cCyoBI xaye0hB5YL5qJy+Vp6b1WEkelo+0K+0h+yEyBvLQfFKxSPz6di+/K5rJo/GqUzzPzOx7f4w8DB+l 1FRPmT0c85bkkXlJp3fLcBOo9tfnIEEegLc5R2XUU359m8hj86eV0Q/JLlcN5DH5PPfMsl1ZXpGH 5/3FXH1UyWvfwdBrfCAPxo+zt6C+qs5Fle4i5B/Bn5rW1Q8h/xTeLMCamvGny5t+F3kw3h4tsuxq ZWpl3uSB+dBxBj7d1+SheIqiKIqi/lIvCqvVFlqH44EAAAAASUVORK5CYII= --001a11c3699a08bf8d05156fc785-- From nobody Wed May 6 13:44: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 918791B2F19 for ; Wed, 6 May 2015 13:44: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 xg4dIjMzyIak for ; Wed, 6 May 2015 13:44:49 -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 985D41B2F15 for ; Wed, 6 May 2015 13:44:45 -0700 (PDT) Received: from localhost (p57B2DEA7.dip0.t-ipconnect.de [87.178.222.167]) by mail.mugenguild.com (Postfix) with ESMTPSA id 648355FB02; Wed, 6 May 2015 22:42:02 +0200 (CEST) References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.camel@scientia.net> From: Vincent Breitmoser To: Phillip Hallam-Baker Date: Wed, 06 May 2015 22:43:03 +0200 In-reply-to: Message-ID: <87vbg5o2pz.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Christoph Anton Mitterer , 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, 06 May 2015 20:44:51 -0000 On 6 May 2015, Phillip Hallam-Baker wrote: > In 'under the covers' applications the user does not need to see, I > would hope we would support use of the 256 bit or full 512 bit > fingerprint. Hm. Do you have a specific purpose for that in mind? - V From nobody Wed May 6 14:07: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 5769A1B2F55 for ; Wed, 6 May 2015 14:07: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 z9zY4Zbbwoij for ; Wed, 6 May 2015 14:07:53 -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 2D5311B2F5F for ; Wed, 6 May 2015 14:07:53 -0700 (PDT) Received: by laat2 with SMTP id t2so16763188laa.1 for ; Wed, 06 May 2015 14:07: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=+eKit5Q5RdnVuGa3+5N1mVHSEvydfylipa0OXASIvrc=; b=qK65qQwYpI2qNFmTcPB2lmCCCsAIVNNqujS2Gc+ozAoTYHUzFSH6n0AE9vk6bR09hY EmZzVWno0YQAM8OIl/cSCYUA513ADJ461BuDFFt6U7r5YJdMuZcyPtyTwXh3hBeKeKUj LjNb/vGyKH4rjThc9F9khBXMcZwvJbPyXvESqeajUbGP0dwdf7o6uw9E+FotI9NnkuVs qNJMEpJN9tnGJy4nyJ7qlIE+6dGpSwSPcij9+et1C2G2JYrXQA80iyX3qEASMm2yI4wX D2HmjeIcGTvSlcMn+LIu4A5A8974GAYeSmeyD2Fim7NMdOM/cjzpmesGgK+M0TUWKeif KlBw== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr474051lbc.79.1430946471697; Wed, 06 May 2015 14:07:51 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 6 May 2015 14:07:51 -0700 (PDT) In-Reply-To: <87vbg5o2pz.fsf@littlepip.fritz.box> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.camel@scientia.net> <87vbg5o2pz.fsf@littlepip.fritz.box> Date: Wed, 6 May 2015 17:07:51 -0400 X-Google-Sender-Auth: 8PrghXJHHWYhg--FsvXtTgYKE4o Message-ID: From: Phillip Hallam-Baker To: Vincent Breitmoser Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christoph Anton Mitterer , 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, 06 May 2015 21:07:54 -0000 On Wed, May 6, 2015 at 4:43 PM, Vincent Breitmoser wrote: > > On 6 May 2015, Phillip Hallam-Baker wrote: >> In 'under the covers' applications the user does not need to see, I >> would hope we would support use of the 256 bit or full 512 bit >> fingerprint. > > Hm. Do you have a specific purpose for that in mind? Any time someone is using a WF-256 bit key. But also in the notary systems used for timestamping and such From nobody Wed May 6 14:31: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 75F131B2FA9 for ; Wed, 6 May 2015 14:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 u090xuawnwsv for ; Wed, 6 May 2015 14:31: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 86E831ACDD7 for ; Wed, 6 May 2015 14:31:16 -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 31F225FC2B for ; Wed, 6 May 2015 21:31:15 +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 BrrhyZNd4dfL for ; Wed, 6 May 2015 21:31:13 +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 ; Wed, 6 May 2015 21:31:13 +0000 (UTC) Message-ID: <1430947872.28399.206.camel@scientia.net> From: Christoph Anton Mitterer To: IETF OpenPGP Date: Wed, 06 May 2015 23:31:12 +0200 In-Reply-To: References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.camel@scientia.net> Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-2uWN7Ic1noI2cSLBODLq" 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, 06 May 2015 21:31:18 -0000 --=-2uWN7Ic1noI2cSLBODLq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-05-06 at 16:38 -0400, Phillip Hallam-Baker wrote:=20 > One of the reasons I suggested the code numbers for SHA-2 and SHA-3 > that I did earlier is they guarantee that the first letter of the > fingerprint will be M (SHA-2 'Merkle') or S (SHA-3 'Spongeworthy'). > Thus ensuring that they are distinct from SHA1 fingerprints. > The leading byte gives both the method of constructing the hash and > the algorithm to use. I suggest we define code points for SHA-2 and > SHA-3 using an identical construction approach. In principle I'd like to see that both algos can generally be used with a future OpenPGP, given the different class (Merkle-Damgard vs Sponge), generally for the FP and other areas. But I guess the majority here would want to have only one algorithm, at least for the FP. Is there any broad consensus already about SHA2 vs. SHA3 (except the traditionalist argument)? > I think we can go even simpler: >=20 > Fingerprint =3D Base32ify (BinaryFP) >=20 > BinaryFP =3D ID + H( HashedValue) > HashedValue =3D ':' Isn't that what I've said? Or what is ID in your text? At least I think the user should directly see the algorithm/version without needing to decode the baseXXX. > Since the MIME content registry does not permit entries with a colon > in the tag, this is guaranteed to be unambiguous. And since a > Content-Type can be defined for any data object that might need to be > hashed, it can support any content. >=20 > All the PGP related information would go in the field, so that > would include the PGP format version identifier, algorithm code, etc, > etc. Nah... that's bad IMHO... I really would want to know which algo I use without turning on some BASExx decoder (which doesn't mean that one cannot include it there as well). And what's the content-type then in your thinking, if it's not the algo? Just the information "this is a OpenPGP fingerprint"? Then as I've said previously,.. I think this doesn't need to be part of the core standard of OpenPGP,... but if it would be really just a handful of MIME types e.g. one for "OpenPGP fingerprint" I would neither strongly oppose this. > We should definitely split the consideration of QR codes etc out of > the PGP doc. We probably want to define the QR code in such a way that > a device can recognize that a QR code is intended to be a PGP key and > handle it appropriately. We also want to make sure we don't waste bits > in QR space. And it has to be possible to convert an ascii fingerprint > to QR format. I should perhaps notice again, that in general it's IMHO rather a bad idea to standardise "fingerprint formats" which are not directly readable (including QR code or things like OpenSSH's ASCII art version of the FP). > From a security point of view, we really don't need to go beyond 128 > bits unless we are planning to use 256 bit encryption. (The later, ) which would be nice...=20 We already have curves for that... Cheers, Chris. --=-2uWN7Ic1noI2cSLBODLq 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 ggFjMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUwNjIxMzEx MlowTwYJKoZIhvcNAQkEMUIEQM5idAxZMPJFxQicgFahv4LvELbaLrCe0c2HISwfbzwcJJOUYqnB 1VKVLpB7iQh6Lfo61u49tFH0q9+soqqKOkYwagYJKwYBBAGCNxAEMV0wWzBUMRQwEgYDVQQKEwtD QWNlcnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQDExNDQWNl cnQgQ2xhc3MgMyBSb290AgMCOakwbAYLKoZIhvcNAQkQAgsxXaBbMFQxFDASBgNVBAoTC0NBY2Vy dCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBD bGFzcyAzIFJvb3QCAwI5qTANBgkqhkiG9w0BAQEFAASCAQCUb0Ixo0V/urkTIJ/eVEx598qZbWh2 AsWH0SfRtHD53eTQUbUixXKhiRma37gRZKnhIjMByz/e0cubff+WMKexzf+DoCGxq+uyWrLN6SNw EaS/O2FvPcer0QeB9X6Zboqpwm+8krhrc8IKpNsfSGO1oFkhS45mYyHPWr7Plhe4+DfcYT2nn9vM VoO0b0940N34akb6Ips3jHKRvdY7/ZlbPxq4HZKlQq06E7yi3pMtXaCyqAjG/PZTUFL06SNrP5QD shZN1NhMWa4dUFaTH/tjuC2r7cSvzS8HgoP2eE+U71cRUTQYxyOtIXWEsdoJhhyoVu+R7h32msN/ m+8moCfiAAAAAAAA --=-2uWN7Ic1noI2cSLBODLq-- From nobody Wed May 6 15:14: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 8D1611B2A25 for ; Wed, 6 May 2015 15:14:39 -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 r0SVaiNCx0Dm for ; Wed, 6 May 2015 15:14:37 -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 5B64A1B29DA for ; Wed, 6 May 2015 15:14:37 -0700 (PDT) Received: by lbcga7 with SMTP id ga7so18028570lbc.1 for ; Wed, 06 May 2015 15:14: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=Yoo8VsQihaqUvcwsREo5ZN8xSTtcToqD45w+JtWfBgc=; b=JhNgqZsFMLSITHrpD7aGyHNTPD/1UoUKKh6HE8/N+/qJE3EFil7e0VXTpNW+XVgbMH JwIySlpd3pLS6F/jmtDW1n+LUXo9y8Ll+67AmGb1YScYTwfJ8usuKkm7HTb0lZr+GnYZ R8tAmhiQfh9iTtzFX12lHfVP0QTZt27cNqa5n/sQLeQUsUo9v/vpeIlyqLaZU8alTxP0 ulYMJ0c8xDrBia1GlNXqLj15TnYAOIMvsowU89IZ0JPtuM2U00L4iMV+vZeD1e6xCJs+ dMb2vRpdUhzqwVbEkbAymdLTXqhMyMlCJnjX3MtSJDRS924p+ntgutrtBPHrBly/65/l NyRA== MIME-Version: 1.0 X-Received: by 10.152.179.39 with SMTP id dd7mr638281lac.118.1430950475880; Wed, 06 May 2015 15:14:35 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 6 May 2015 15:14:35 -0700 (PDT) In-Reply-To: <1430947872.28399.206.camel@scientia.net> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.camel@scientia.net> <1430947872.28399.206.camel@scientia.net> Date: Wed, 6 May 2015 18:14:35 -0400 X-Google-Sender-Auth: pqqcvQYxJoJ8rA4SE69eAgPZ81E 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] 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, 06 May 2015 22:14:39 -0000 On Wed, May 6, 2015 at 5:31 PM, Christoph Anton Mitterer wrote: > On Wed, 2015-05-06 at 16:38 -0400, Phillip Hallam-Baker wrote: >> One of the reasons I suggested the code numbers for SHA-2 and SHA-3 >> that I did earlier is they guarantee that the first letter of the >> fingerprint will be M (SHA-2 'Merkle') or S (SHA-3 'Spongeworthy'). >> Thus ensuring that they are distinct from SHA1 fingerprints. > > >> The leading byte gives both the method of constructing the hash and >> the algorithm to use. I suggest we define code points for SHA-2 and >> SHA-3 using an identical construction approach. > In principle I'd like to see that both algos can generally be used with > a future OpenPGP, given the different class (Merkle-Damgard vs Sponge), > generally for the FP and other areas. > > But I guess the majority here would want to have only one algorithm, at > least for the FP. > Is there any broad consensus already about SHA2 vs. SHA3 (except the > traditionalist argument)? The folk I have spoken to were of the opinion that the SHA3 contest actually confirmed people's confidence in SHA2. So I don't see a need to jump to the next bright shiny object. SHA3 is supported in pretty much every stack now, SHA3 is still a bit of a work in progress. So I would suggest that SHA-2-512 be REQUIRED and SHA-3-512 be RECOMMENDED. > > >> I think we can go even simpler: >> >> Fingerprint = Base32ify (BinaryFP) >> >> BinaryFP = ID + H( HashedValue) >> HashedValue = ':' > Isn't that what I've said? Or what is ID in your text? > > At least I think the user should directly see the algorithm/version > without needing to decode the baseXXX. Yes, and this should hold for both the base32 version and when doing a hex dump of a binary fingerprint. So the ID should be a byte and the top 5 bits should result in a letter in the range G-Z. >> All the PGP related information would go in the field, so that >> would include the PGP format version identifier, algorithm code, etc, >> etc. > Nah... that's bad IMHO... I really would want to know which algo I use > without turning on some BASExx decoder (which doesn't mean that one > cannot include it there as well). The hash algorithm id is in the . The field needs to have the algorithm of the public key. > And what's the content-type then in your thinking, if it's not the algo? > Just the information "this is a OpenPGP fingerprint"? yes. > Then as I've said previously,.. I think this doesn't need to be part of > the core standard of OpenPGP,... but if it would be really just a > handful of MIME types e.g. one for "OpenPGP fingerprint" I would neither > strongly oppose this. I think the OpenPGP system would end up using at least two codes, one would be 'OpenPGP fingerprint' and the other would be for 'Something like TRANS that does not have ASN.1'. Fixing key signatures in time has a lot of security value that I can demonstrate in terms of work function. From nobody Thu May 7 01:21: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 3EC481A8782 for ; Thu, 7 May 2015 01:21:52 -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 elJcdUaiQFWM for ; Thu, 7 May 2015 01:21:50 -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 54D681A86F0 for ; Thu, 7 May 2015 01:21:50 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YqH40-0003g2-Et for ; Thu, 07 May 2015 10:21:48 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YqGzQ-0003ZU-MN; Thu, 07 May 2015 10:17:04 +0200 From: Werner Koch To: "Christopher LILJENSTOLPE" References: <5543D086.1000503@cs.tcd.ie> <00BAFF30-71CF-4F28-AFB4-E233299BF671@asgaard.org> <87ioc8zopl.fsf@vigenere.g10code.de> <428BCDDC-17AD-4EF3-BC19-E71FF462C79B@asgaard.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: "Christopher LILJENSTOLPE" , "openpgp\@ietf.org" , Daniel Kahn Gillmor , Stephen Farrell Date: Thu, 07 May 2015 10:17:04 +0200 In-Reply-To: <428BCDDC-17AD-4EF3-BC19-E71FF462C79B@asgaard.org> (Christopher LILJENSTOLPE's message of "Wed, 06 May 2015 11:12:54 -0700") Message-ID: <87ioc4u7i7.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor , Stephen Farrell Subject: Re: [openpgp] chairs for chartering process X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 07 May 2015 08:21:52 -0000 On Wed, 6 May 2015 20:12, cdl@asgaard.org said: > Working Groups have a tendency to continue to exist past their > "use-by" date. As they do, the quality and velocity of their output > tends to decline. There are some counterexamples, but, unfortunately, I understand. > more expansive, we can propose that for a charter, but the larger the > charter, the more "convincing" we need to do, especially if the > technology is mature like PGP is. I am fine with >>> 1) The primary charter goal would be create a RFC4880bis document. >>> a) At the end of that process, we would either re-charter, or close. this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu May 7 05:09: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 839D81A8845 for ; Thu, 7 May 2015 05:09:29 -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 npE3L2gsn5no for ; Thu, 7 May 2015 05:09:28 -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 E03541A886A for ; Thu, 7 May 2015 05:09:27 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 693216D826; Thu, 7 May 2015 08:09:26 -0400 (EDT) Message-ID: <554B55F5.1060307@iang.org> Date: Thu, 07 May 2015 13:09:25 +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> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.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: Thu, 07 May 2015 12:09:30 -0000 +1 on PHB's plan. On 6/05/2015 21:38 pm, Phillip Hallam-Baker wrote: > On Wed, May 6, 2015 at 2:38 PM, Christoph Anton Mitterer >>> We do not even need to decide on a strength. Just make is so that the >>> number of significant bits is however many bits that are provided. We >>> can all use SHA-2-512 or SHA-3-512 and truncate to 125, 150, 250... >>> bits as the application requires. >> I'm a bit sceptical about that... I think we rather should specify some >> lengths/format and at least not encourage implementations to choose what >> they think would be enough (cause then we have folks like GNOME which >> take the first and last byte or so *grin*) For b-cards and so forth it isn't nearly as important to specify a length or strength for security reasons. People can roll their own business cards any time they want to change, and often they want something shorter so that it fits nicely. This is a manageable risk. > If we are using Base32 and character groups of 5 characters (7-2 > rule), the keys naturally come in 25 bit increments. > > A 125 bit fingerprint has 117 bits and looks like this: > MFRTK-NJSMF-STOMR-WG5ST-ONZXGA > > If we go for 150 bits we get: > MFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB Concur - this is good. It also nicely skips 160 bits, so we can even imply the new hash from the length. > In 'under the covers' applications the user does not need to see, I > would hope we would support use of the 256 bit or full 512 bit > fingerprint. I would also hope we can use the possibility of an online > store to 'stretch' a fingerprint. If the user types in a 25 character > fingerprint, the system can get the rest off a key service. Right, under the hood, use the full hash. Why muck around? iang From nobody Thu May 7 05:14: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 338F11A88C2 for ; Thu, 7 May 2015 05:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBHKOwqNdAMD for ; Thu, 7 May 2015 05:14:54 -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 EE9661A88A6 for ; Thu, 7 May 2015 05:14:53 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 1D9B86D826; Thu, 7 May 2015 08:14:53 -0400 (EDT) Message-ID: <554B573C.4060607@iang.org> Date: Thu, 07 May 2015 13: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: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.camel@scientia.net> <1430947872.28399.206.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: Thu, 07 May 2015 12:14:55 -0000 On 6/05/2015 23:14 pm, Phillip Hallam-Baker wrote: > On Wed, May 6, 2015 at 5:31 PM, Christoph Anton Mitterer > wrote: >> Is there any broad consensus already about SHA2 vs. SHA3 (except the >> traditionalist argument)? > > The folk I have spoken to were of the opinion that the SHA3 contest > actually confirmed people's confidence in SHA2. So I don't see a need > to jump to the next bright shiny object. > > SHA3 is supported in pretty much every stack now, SHA3 is still a bit > of a work in progress. > > So I would suggest that SHA-2-512 be REQUIRED and SHA-3-512 be RECOMMENDED. All the above is reasonable. However there is one further argument in favour of SHA-3 which is that it is going to come in the form of a much larger / more powerful toolkit. It's no longer "just a hash." It has specific modes attached to it that can do, for example, AE, and that AE mode has (I gather) been used for the CAESAR competition. Point being, there is a chance that we can do the whole symmetric part with only one algorithm... :-o Now I know this will give people the heebie jeebies, so what I'd say now is that we delay a firm decision until NIST have published their spec on SHA-3 and then review it to get the true story. My information is based on a presentation I saw by the Keccak team, so possibly I'm way off base. NIST will clarify this all. iang From nobody Thu May 7 05:21: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 5ECD91A88A6 for ; Thu, 7 May 2015 05:21: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 K5rTVn1Q8hpE for ; Thu, 7 May 2015 05:21:14 -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 B6D331A87EA for ; Thu, 7 May 2015 05:21:14 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id BB0216D82F; Thu, 7 May 2015 08:21:13 -0400 (EDT) Message-ID: <554B58B8.9060806@iang.org> Date: Thu, 07 May 2015 13:21:12 +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: <874mnqpvp3.fsf@littlepip.fritz.box> In-Reply-To: <874mnqpvp3.fsf@littlepip.fritz.box> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Key Validity Scenarios X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 07 May 2015 12:21:16 -0000 You're talking about the status of signatures for the purpose of human signing, not keys nor digsigs. Such things as human signing digsigs can only be assumed / used within some form of context. Such a context could be a CPS or a contractual agreement (eg rules of keysigning party) or a cooperative (eg CAcert) or a law (eg Estonia & EU Directive). Without such an approach, the notion of human signing lacks foundation. With such an approach, it is up to the approach to decide what the status of signatures for human signing is. In other words, it is out of scope of OpenPGP as it is currently constructed. iang On 5/05/2015 21:04 pm, Vincent Breitmoser wrote: > > Bringing up a topic related to expirations, one thing that has bothered > me for a while is that the validity periods of keys, in terms of > expiration and revocation, are very ambiguous. > > Consider these scenarios: > > - Key expired two weeks ago. Status of a signature from three weeks ago? > > - Key revoked two weeks ago, because it was compromised. Status of a > signature from three weeks ago? > > - Key revoked two weeks ago, because no reason given. Status of a > signature from three weeks ago? > > - Key revoked two weeks ago, because it was superseded. Status of a > signature from three weeks ago? > > It's possible to argue for all extremes in all of these scenarios, and > the conservative choice would always be to reject the signature, however > this is not necessarily applicable for all implementation circumstances. > > So the possibilities here are: > > a) try to cover the key validity for most scenarios in the standard. > this seems tricky because I don't think all needs can be covered. > > b) leave the main standard purely focused on data format, but add an > informational one with this sort of definitions. > > c) add an explicit definition about treatment of retrograde signatures > to the expiration and revocation signatures themselves, i.e. delegate to > the implementation which creates the key. > > d) none of the above, i.e. leave it to the implementation which uses the > key. > > I'd like b), but that one implies a bunch of extra work. So, yes, b). BUt old chinese proverb: be careful what you wish for! iang From nobody Thu May 7 06:21: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 64E751A9081 for ; Thu, 7 May 2015 06:21: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 K06lum3HDE7t for ; Thu, 7 May 2015 06:21:41 -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 DC4F41A9080 for ; Thu, 7 May 2015 06:21:40 -0700 (PDT) Received: by lagv1 with SMTP id v1so30408062lag.3 for ; Thu, 07 May 2015 06:21: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=rvVS2I01fTFz5pYS4BRsLH70rU3lOKaczC0jxzJpmvw=; b=JZOKBhjMGjcjYmhZVLu6Lr9o6E+vD9o+rPjEzXpswFdF35MpayBwSiYj/yrqZfRM2Q 4+JJm/+68U6rfdu3hzYADx7wlQi6oVuqWjL+Xwvah0tyS3Lw4xQwsN4ltSrAqhA62drb DWseYHcIHSfeJ7XyBWO4tLFqNGK+rrE+IBISghhOeGKOKYMp6QGdp3GQigLir98VglhE sozCYb/YdDkSvDz2cgXrq6qhqQLeZ+nu6VnfhJ+tFjieKplemPU2gwmd+frvNJ3dHP8u xj7jfIfrOwU3QzwNSmhq51uuKtLkMoe6YYGqO8ntCst5xarT0ZMNCnWm//EszgFZzmG5 So1Q== MIME-Version: 1.0 X-Received: by 10.112.16.42 with SMTP id c10mr3052275lbd.103.1431004899418; Thu, 07 May 2015 06:21:39 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 7 May 2015 06:21:39 -0700 (PDT) In-Reply-To: <554B573C.4060607@iang.org> References: <87d232lkb6.fsf@alice.fifthhorseman.net> <871tiupupe.fsf@littlepip.fritz.box> <1430869683.28399.109.camel@scientia.net> <1430937492.28399.127.camel@scientia.net> <1430947872.28399.206.camel@scientia.net> <554B573C.4060607@iang.org> Date: Thu, 7 May 2015 09:21:39 -0400 X-Google-Sender-Auth: wZ35bj17x2u2jKkYwMhqQHiZHv0 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: Thu, 07 May 2015 13:21:45 -0000 On Thu, May 7, 2015 at 8:14 AM, ianG wrote: > On 6/05/2015 23:14 pm, Phillip Hallam-Baker wrote: >> >> On Wed, May 6, 2015 at 5:31 PM, Christoph Anton Mitterer >> wrote: > > >>> Is there any broad consensus already about SHA2 vs. SHA3 (except the >>> traditionalist argument)? >> >> >> The folk I have spoken to were of the opinion that the SHA3 contest >> actually confirmed people's confidence in SHA2. So I don't see a need >> to jump to the next bright shiny object. >> >> SHA3 is supported in pretty much every stack now, SHA3 is still a bit >> of a work in progress. >> >> So I would suggest that SHA-2-512 be REQUIRED and SHA-3-512 be >> RECOMMENDED. > > > > > All the above is reasonable. However there is one further argument in > favour of SHA-3 which is that it is going to come in the form of a much > larger / more powerful toolkit. It's no longer "just a hash." > > It has specific modes attached to it that can do, for example, AE, and that > AE mode has (I gather) been used for the CAESAR competition. > > Point being, there is a chance that we can do the whole symmetric part with > only one algorithm... :-o > > Now I know this will give people the heebie jeebies, so what I'd say now is > that we delay a firm decision until NIST have published their spec on SHA-3 > and then review it to get the true story. My information is based on a > presentation I saw by the Keccak team, so possibly I'm way off base. NIST > will clarify this all. On the platforms I use, I can expect SHA-3 to arrive in due course but it isn't going to expose that functionality without a completely new API. >From a design point of view it is clear that SHA-2 and SHA-3 are the choices and one will be REQUIRED and the other RECOMMENDED. Which is which has no immediate implications and does not even become an issue until last call. I have text and I have code for the SHA-2 version. I can get a standalone draft done next week and then we don't need to keep circling on this. From nobody Thu May 7 07:53: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 CE9491A90FE for ; Thu, 7 May 2015 07:53: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 4S-wXXxlBbk4 for ; Thu, 7 May 2015 07:53:44 -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 664FB1A90FB for ; Thu, 7 May 2015 07:53:44 -0700 (PDT) Received: by layy10 with SMTP id y10so32579695lay.0 for ; Thu, 07 May 2015 07:53:43 -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=TR95qpIoizhVm9+wvnLlr1V6qbNSyTri9H8GLB68lnU=; b=mvH6XYFBgRniytgtzdZAkg5GxSbMh6vzbm1gGrTQecGOWOkxjwGkkY36LBHi+/OfEx K9o9RpWKHvO+nbWuY7MkZHzgNM/2D32idNjlE9GFz26OpeNdRVjMGgF1nSgMhAoriLPh w0L8+T+LOYdeAWH5+hCWNknquIo3mKWO+4w5PqPMTuGKftog0g9uAlRc2UpfFybTsOZU czDchLoxc7eiMzyKsOIf8JJurpRYFKqSGsKwMHNpFdV/VrlXMPAbD3uiPL0lxxIFtECK Ky4Rmibn0XbKYm2WpYEpSt1Yrzilt6EqipLwZnd+xk2uHk8187wJ08ZGrmmLPXOV2ucC QZqQ== MIME-Version: 1.0 X-Received: by 10.152.6.1 with SMTP id w1mr3279836law.91.1431010422907; Thu, 07 May 2015 07:53:42 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 7 May 2015 07:53:42 -0700 (PDT) In-Reply-To: <554B58B8.9060806@iang.org> References: <874mnqpvp3.fsf@littlepip.fritz.box> <554B58B8.9060806@iang.org> Date: Thu, 7 May 2015 10:53:42 -0400 X-Google-Sender-Auth: Xtw3cfwgxvNjTIbw5XPPzR5W5NE Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Key Validity Scenarios X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 07 May 2015 14:53:46 -0000 On Thu, May 7, 2015 at 8:21 AM, ianG wrote: > You're talking about the status of signatures for the purpose of human > signing, not keys nor digsigs. > > Such things as human signing digsigs can only be assumed / used within some > form of context. Such a context could be a CPS or a contractual agreement > (eg rules of keysigning party) or a cooperative (eg CAcert) or a law (eg > Estonia & EU Directive). Without such an approach, the notion of human > signing lacks foundation. With such an approach, it is up to the approach > to decide what the status of signatures for human signing is. > > In other words, it is out of scope of OpenPGP as it is currently > constructed. It is out of scope. But we don't really understand what that scope is right now. My vision for IETF next generation public key apparatus is that we should arrive at a next generation system round about 2020 that offers a superset of the capabilities of PKIX, OpenPGP and SAML. I don't expect that to be a single consistent infrastructure. In fact, I think it is going to look very much like electrical plugs do today with different countries having different shaped plugs, different voltages and different frequencies. And that is going to have long term consequences for applications in that I think we are going to have to accept that the equivalent of 'switching power supplies' is going to be required. If you want to use an infrastructure for using digital signatures on transaction documents then you should look at the SAML assertion infrastructure. That is what the assertion layer was designed to do. At this point I do not want to redo SAML-lite in OpenPGP. Nor do I want to invest further effort in XML or ASN.1. While they are both capable of supporting the necessary features, they are clearly not capable of achieving an industry wide consensus. So right now what I would like us to focus on in developing a well defined specification for an OpenPGP 'wall socket' that people can plug an email messaging application into. From nobody Thu May 7 21:44: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 D422B1A86EE for ; Thu, 7 May 2015 21:44:41 -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 JHf1G4R-ZnvU for ; Thu, 7 May 2015 21:44:40 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E97D1A8967 for ; Thu, 7 May 2015 21:44:39 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E13A2F984; Fri, 8 May 2015 00:44:37 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 902FC20408; Fri, 8 May 2015 00:44:13 -0400 (EDT) From: Daniel Kahn Gillmor To: Vincent Breitmoser , openpgp@ietf.org In-Reply-To: <874mnqpvp3.fsf@littlepip.fritz.box> References: <874mnqpvp3.fsf@littlepip.fritz.box> User-Agent: Notmuch/0.20~rc1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Fri, 08 May 2015 00:44:13 -0400 Message-ID: <871tirlluq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Key Validity Scenarios X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 08 May 2015 04:44:42 -0000 Hi Vincent-- On Tue 2015-05-05 16:04:20 -0400, Vincent Breitmoser wrote: > Bringing up a topic related to expirations, one thing that has bothered > me for a while is that the validity periods of keys, in terms of > expiration and revocation, are very ambiguous. Thanks for raising this. Your subject line is about "key validity", but all your scenarios below are about "signature validity". Much of this is covered in the "Reason for Revocation" section of RFC 4880 already: https://tools.ietf.org/html/rfc4880#section-5.2.3.23 > Consider these scenarios: > > - Key expired two weeks ago. Status of a signature from three weeks ago? This is a "valid signature from an expired key", which means "the keyholder made this assertion with their key at a time that the key was legitimate for them to use." > - Key revoked two weeks ago, because it was compromised. Status of a > signature from three weeks ago? This is an "invalid signature", because it was made with a compromised key. Compromised keys can forge any date they like in the signature, so nothing about them can be relied on. > - Key revoked two weeks ago, because no reason given. Status of a > signature from three weeks ago? This is also an "invalid signature". if no reason was given, we should assume the worst. > - Key revoked two weeks ago, because it was superseded. Status of a > signature from three weeks ago? This is a "valid signature from a revoked key", which means "the keyholder made this assertion with their key at a time that the key was legitimate for them to use." Note that there are really only two cases here, given that the signing key (whether revoked or expired) is considered not currently valid. The two cases are: a) invalid signature (should never be relied on for anything) b) valid signature from a no-longer-valid key It's pretty straightforward to dismiss signatures that fall into category (a). It is harder to know generically what to do what to do with signatures in category (b), because that gets into "trust models". Trust models are attempts to formalize/standardize who should be willing to rely on which cryptographic assertions for what purpose. So dealing with a signature from category (b), how i would interpret it would very much depends on what the signature was (data signature over signed e-mail? identity certification? authorization statement delegating access to a service?), who the keyholder is, and what question i'm trying to answer by reviewing the signature. It might also depend on how much time was elapsed, and other human factors that might not be directly implementable in software. hth, --dkg From nobody Mon May 18 16:44: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 7A8A71B2B62 for ; Mon, 18 May 2015 16:44:06 -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_50=0.8, 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 1_GhF-Qf971o for ; Mon, 18 May 2015 16:44:05 -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 292891B2B61 for ; Mon, 18 May 2015 16:44:05 -0700 (PDT) Received: by igcau1 with SMTP id au1so1540194igc.1 for ; Mon, 18 May 2015 16:44:04 -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=Xn5GaIDGL94BmwqWETxSIigettmcZfnOMSF476vW0EU=; b=Xk5tlGqZU/63EU4cOCNXTw/H7qdSbT9SxrA/DKGoFWOk6nfMR04SCijvfbISpeyWp6 bhjspmJwG4cBct45PlrHqNHvJWANFZL0YPu6BHofrjYHbGkDpAry1BsvM69oQHWuBz53 nzsQ9N/d/fK2n4H69cPqSwf7jKS+iVzjfGePb6JA9flEhRKoDytHdxCud/Yl5WOBUxQP UI/nH/rO79pKMt73IEXm3BIp6YoEMg0kMgAhRasR4JVoUY0XalB3iB1OU4m8mmTUoMHV 4gjHLOX2OCRctz92R0h2gVnTCINqMr0vx7z7gMwHRoIqkZu6fhGNg8uVdV5mJKlBZTh4 14qQ== X-Received: by 10.50.112.73 with SMTP id io9mr17962522igb.18.1431992644522; Mon, 18 May 2015 16:44:04 -0700 (PDT) MIME-Version: 1.0 From: Wyllys Ingersoll Date: Mon, 18 May 2015 23:44:03 +0000 Message-ID: To: "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a9c12e5d9c8051663c4bb Archived-At: Subject: [openpgp] List problems? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 18 May 2015 23:44:06 -0000 --047d7b3a9c12e5d9c8051663c4bb Content-Type: text/plain; charset=UTF-8 Just checking in - all traffic from this list suddenly stopped on May 7. Seems odd... --047d7b3a9c12e5d9c8051663c4bb Content-Type: text/html; charset=UTF-8
Just checking in - all traffic from this list suddenly stopped on May 7. Seems odd...
--047d7b3a9c12e5d9c8051663c4bb-- From nobody Tue May 19 03:06: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 ACBCD1A700B for ; Tue, 19 May 2015 03:06:58 -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 VSXj4dcmRBJ9 for ; Tue, 19 May 2015 03:06:56 -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 A642A1A6FFC for ; Tue, 19 May 2015 03:06:56 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YueQI-0004J3-OP for ; Tue, 19 May 2015 12:06:54 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YueLt-0004R2-QZ; Tue, 19 May 2015 12:02:21 +0200 From: Werner Koch To: Wyllys Ingersoll 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: Wyllys Ingersoll , "openpgp\@ietf.org" Date: Tue, 19 May 2015 12:02:21 +0200 In-Reply-To: (Wyllys Ingersoll's message of "Mon, 18 May 2015 23:44:03 +0000") Message-ID: <87iobodgwi.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] rfc4880bis basics (was: List problems?) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 19 May 2015 10:06:58 -0000 On Tue, 19 May 2015 01:44, wyllys@gmail.com said: > Just checking in - all traffic from this list suddenly stopped on May 7. > Seems odd... Well, we are all waiting for someone to do the first move. I know that we do not have a charter yet but we agreed on developing rfc4880bis. This raises the question who will act as editor and what format to use for editing. How would the general procedure be: Convert 4880 into a source format and put that into a public repo? A good starting point might be to merge 4880 with 5581 (Camellia) and 6637 (ECC). With that all in one document we can then deprecate v3 and other stuff before we start working on a v5 key format or new features. Although I am not a big fan of Markdown there is a nice tool to convert a Markdown document to the RFC XML and finally to an I-D/RFC: pandoc2rfc at tools.ietf.org. The advantage is that a simple text file can be easily diffed and put into git. [It would be nice if the IETF could provide such a public repo.] Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri May 22 15: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 EDCA01A896A for ; Fri, 22 May 2015 15:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9xHupnaOFD9 for ; Fri, 22 May 2015 15:04:46 -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 F31411A8980 for ; Fri, 22 May 2015 15:04:44 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so21437700lbb.2 for ; Fri, 22 May 2015 15:04:43 -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=EZPUEWbPrtna6IF7Kx17WOz21+ldB5tUoOBAsmp5Ylg=; b=kFD6sGMNsernea9ND8szIKbhAkMy+KaQ/qs/5muH0BVqVkpIs5wuRi6tj9ISp2kSh8 SpA+Megc4wW8WxrEATh+zi5NzNW5/pVjuAbXI2Qh1q1S67AJDIRxouzbcJEJkqQgTHML JnydmyhBGG8bq78MPGGtefAIuIuoxQbEKNIubwumgwnGrXvWQtHxPJGPPQ+z5fuECid+ piHFl/fQnpQIuqAou1319iQSzJN4kzdA6XXyRNVn+BQo48WJbqRf7XEMvkQd5yE++O8n YWAZA5KV1TPJjHTbMjBQ+H2eiJdYFulCpvqSOIyfxd5jJIpNhVYRBIsLUfVxuVJEs6zw 9I3Q== MIME-Version: 1.0 X-Received: by 10.112.72.40 with SMTP id a8mr5252033lbv.58.1432332283471; Fri, 22 May 2015 15:04:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 22 May 2015 15:04:43 -0700 (PDT) Date: Fri, 22 May 2015 18:04:43 -0400 X-Google-Sender-Auth: mQUIUYbPxmIGREWcFW0Z75QDrEs Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: multipart/alternative; boundary=001a11c23e2ef4ec830516b2d89e Archived-At: Subject: [openpgp] Uniform Data Fingerprint draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 22 May 2015 22:04:47 -0000 --001a11c23e2ef4ec830516b2d89e Content-Type: text/plain; charset=UTF-8 I wrote up the discussion we had on the list as a draft to capture the convo. Have not done acknowledgements yet as some folk like to be asked first. https://tools.ietf.org/html/draft-hallambaker-udf-00 Comments welcome. While this might seem like more than is needed for the OpenPGP protocol, I think the OpenPGP infrastructure needs fingerprints for both OpenPGP key packages and for software distributions. Otherwise you need an OpenPGP disto to verify your OpenPGP disto. --001a11c23e2ef4ec830516b2d89e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wrote up the discussion we had on the list as a draft to= capture the convo.=C2=A0

Have not done acknowledgements= yet as some folk like to be asked first.


Commen= ts welcome.


While this might seem l= ike more than is needed for the OpenPGP protocol, I think the OpenPGP infra= structure needs fingerprints for both OpenPGP key packages and for software= distributions. Otherwise you need an OpenPGP disto to verify your OpenPGP = disto.


--001a11c23e2ef4ec830516b2d89e-- From mofosyne@gmail.com Fri May 22 08:34:03 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC31A0262 for ; Fri, 22 May 2015 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.807 X-Spam-Level: X-Spam-Status: No, score=0.807 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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 skWG-4bw7Cpe for ; Fri, 22 May 2015 08:33:59 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2362E1A0196 for ; Fri, 22 May 2015 08:33:59 -0700 (PDT) Received: by yhom41 with SMTP id m41so5218876yho.1 for ; Fri, 22 May 2015 08:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bTV+rmLlfNKRvtMPN380i6UXr/eNA0QWAuOKnpJoB9Y=; b=WHboXcHre8j3+PgOhtsKNiZrESoV+YtHX/18k80eoac81p2p5tsxDkxshiiRjstpQF P9I/P54uU7LCBQs54+wqVL5RCdvDKfeHK0IGOgou5pC2fUc8206u5EGBwCc3JQTeYXdu uYiTfuDT+Prz5ZnRpL7Q7lE7bQmABewfhfxZDdOEqmd2nuRoYrO9/4+5imUdg0aQ1MTr eFu4VogDixy0YyfhPbNsrSnIMSOuljFSyxL69g+a8mkjg2a4Oi8CI8P7htAdUrEWWso2 DH/2jZPyJ3BDmZcdPLd0fqjgmtqXYIghw23rP3QU9YoYoYbg2DLj82CW9C7cWl0DZPG1 6uyg== MIME-Version: 1.0 X-Received: by 10.170.92.84 with SMTP id j81mr9832945yka.97.1432308838433; Fri, 22 May 2015 08:33:58 -0700 (PDT) Received: by 10.129.133.193 with HTTP; Fri, 22 May 2015 08:33:58 -0700 (PDT) Date: Sat, 23 May 2015 01:33:58 +1000 Message-ID: From: mofo syne To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=001a113a8c1a860a4d0516ad6363 Archived-At: X-Mailman-Approved-At: Fri, 22 May 2015 19:13:32 -0700 Subject: [openpgp] OPENPGP URI PROPOSAL (DRAFT) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 22 May 2015 15:48:48 -0000 --001a113a8c1a860a4d0516ad6363 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You might see a few copies around. This one is edited and streamlined with some advice from Hasimir to help keep this proposal focused. Last updated: 2015-05-23 - edit: Switched from `openpgp://` to `openpgp:` as noted by hobarrera. Also sent to openpgp@ietf.org for further discussion= . This is only a concept of specifically "alternative to openpgp blocks as uri" at the moment, so exact implementation is still up in the air. The main aim is to spur discussion. *=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D* *OPENPGP URI PROPOSAL (DRAFT)* *=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D* *## Brief/Objective ####################* This proposal is to provide an alternative to the openpgp block messages, in the form of a uri ( e.g. `http://` ). This would make such messages more web friendly, as well as taking advantage of autolaunching apps to handle such messages. Such links may be embedded within email messages or webclients, or as a 2d barcode on a physical poster. This aims to be flexible and futureproof, by supporting any mix of variables or payload that may be thrown in it's way (e.g. percent encoding, base64, etc... ) This will hopefully make accessing and using openpgp as convenient as datauri (transmitting data), and mailto (launches email handlers easily). *## Schema Description ##* openpgp: [] [;key:value] [;key::value] <;::payload_data> * `openpgp:` - is the start of the openpgp uri ( This is the scheme name that calls for a handler) * `;` - is used as a delimiter. * `[;key:value]` - for simple keyvalues: `;name:clark` * `[;key::value]` - `::` - is used to aid visual inspection, since the content would be more of a long complex string, rather than a simple key:value pair - `[;key?length:value]` - safely read in string: `;name?10::clark;kent= ` - `[;key?encoding:value]` - `;sig!base64::f4h5k34589ht...` * `<;::payload_data>` - payload do not require key value. But it has optional encoding and length (Which may have a default setting based on mode. E.g. public keys are often always encoded in base64 ) - `;::f4h5k34589ht...` - `;!base64::f4h5k34589ht...` - `;!octet?100::8BinaryStream` - `;!json?17::{"key":[1,2,3,4]}` * `$encoding` - is used to define how the string is encoded, e.g. base64,json,1010101 * `?length` - is used to define how many characters to read ahead as a string. Afterwards, it will just keep scanning for the next `;` or end of string. * `#type` this might be needed if we need to declare the type of a variable (undecided if it is needed in this standard proposal) *### Mode keywords ###* So far this is what I thought for gpg keywords for the `` * `pubkey` =3D public key * `prvkey` =3D private key * `encmsg` =3D encrypted message * `sigmsg` =3D signed message * `fprint` =3D key fingerprint *### extra thoughts ###* * http://tools.ietf.org/html/rfc1738 - Uniform Resource Locators (URL) * http://tools.ietf.org/html/rfc3986 - Uniform Resource Identifier (URI): Generic Syntax * http://tools.ietf.org/html/rfc3987 - Internationalized Resource Identifiers (IRIs) *# Structure Examples #############* e.g. For pubkey: openpgp:pubkey;version:GnuPG+v2;!base64:: For pubkey (with implied encoding. Default for pubkey mode payload is base64): openpgp:pubkey;version:GnuPG+v2;:: For encrypted msg: openpgp:msg;version:GnuPG+v2;!base64:: or a signed message openpgp:sigmsg;hash:SHA1;sig:;!:: *# Potential Usage ###############* * Storing messages in QR or NFC allows for secure verifiable posters. - This could allow people to trust messages stuck on posters on the streets. E.g. safety information from organizations - Paper letters could contain important messages/keys that can be then decrypted/collected via a smartphone. * Easier handling of messages in webrowsers via webrowsers plugins that can recognise the uri handler calls. - E.g. Clicking on a url will automatically open up a openpgp program that automatically processes the message. * IRC? Could have real time signing of messages with inlines opengpg uri (with the appropriate plugins) * Can do anything that a normal openpgp block can do (But with the main advantage of being url safe, unless intentionally in octet mode etc...) - So can override the need for keyserver uris, # Considerations ############### * Even if we do eventually come to a standard. What can we do to encourage web browser coders to whitelist `opengpg:` scheme name, and thus allow external programs or plugins to handle the uri. This is since some browsers use a whitelist (I think firefox uses a whitelist, since preferences only shows certain schemes). *# Uri Mockups ################* Pubkey: openpgp:pubkey;version:GnuPG+v2;!base64::mQENBFVS5CYBCACmDH67cDfC+0ow2FVX4u= zsiOfA1OA4ZSJVwVjBQeotgr3a5CWCWSbW+kw3CjlRQXcL4bxTNisGAfrtn78+GkEmS48mb9kAP= i084flEBHmgHbzo0TI3az74S3UI3ZkLxuAdfD4G7BuVn7YPzOa3OgD3FW1zZ3EGsHSl3+i0QZZ0= fPvi4OkC+w4vDjrkUGR/afy7AzQhYzMA22kf3PTvZMxS0RLJvoRbnyoGjd1aQZPJD4mMziBaySR= KEdhAbIrogu2nW0M2aJmwiW1Sgp8PP8bH2PJPgXFKaRTucm3k2IdsxVx0u29VJiSq4ktrYm8cJ3= ABfUWbd/4adUFMbqwY2UhBABEBAAG0M0p1c3R3YW50dG9oYXZlZnVuNTYgPGp1c3R3YW50dG9oY= XZlZnVuNTZAd2FzdGUuY29tPokBOQQTAQgAIwUCVVLkJgIbAwcLCQgHAwIBBhUIAgkKCwQWAgMB= Ah4BAheAAAoJEGNU/RWXfXCybfQH/jZLLuWdeqOj/bNFx6OHxNLc8hYKbuje+xtZNP4gagCJboi= AxPoWDfrhVQLKfKwR2mslAqQWdLSL1w93C/L1ByzXUz5sXA2YOTGVLXMU0aKQxYg3hBPqyc66F2= 6Rz8mVLnOHGQoGvlVA4CMFNwEpS3lMkxbNyoQLeS1wXJsZN8VmDa5vqzQySCmOuBJ0rDqbwLrYN= shPVqdo1G7U0uoTjPTI65+GlKvtXLxqn/R7c/aywqE9qinK/L0uyiQ4itA0er6TwI8d8B1Fw8Jv= bDmJNx24zHqOjZWL1Osn5o7ZH31AmFH7VFFJWtcYkpgTf2KETZ/PvkPPV/RL0q9FiKcB7725AQ0= EVVLkJgEIAMl4rKSFfLXrB3MlwmNZqp66/5ixBm8FN1o3Hj9/xhiHWWZWwmkL3pfWVGI4GvFpOy= h26VTv6Hvt54rvaqGYPZsz2jRO8PmVQs8g3CmC21F20jqi1fNu8m50ntrvK6qOK0pC7l7XXXkLw= F9ChwxE8ott3WKALMS6+Z8RD0h/2SoNfW80dMLyDr2MzZdEB+dX6FM3YajkVaaIrhesedOsPoJO= pPJc/K0BF71YjecesUUJZFdGm5v5UkgPbptuXgRFQWbQcj0kpQT4oxjwUImLYWb86cSJn6Bw7aH= D9h/7ZHF5Q/N8s5fsl6lAEPEI2hTTh0SJE5g8qqL5YRfX7QBy1d0AEQEAAYkBHwQYAQgACQUCVV= LkJgIbDAAKCRBjVP0Vl31wsnapB/9D0IBTxRNfWz3jsUbcfnI5Vu4V7mBu9B6rO6NfgpMirf2Xa= PmC13nQjR3WFZqd6JeJ1GPupkhleau1oViVHvKB7rfKOUqt0MNecWuHNu7tGp2q+k0NTEnA8/F5= BGj3yxKdWNZ1farQDVnz39Pcj17XZK7R6FXLcQRf/yMjkipp6AAzADMTulsu86JAo4TLix83SsS= XEzdID8p0REVRZZCTI8VHxlGjKOJBUu2K6IL5P80NMbEfHqXpxroftQhsuMQPGhlMgzDlWe7Mt+= H5i/v3Sa4dKEQ0fW3kX/abF0xo4zDvbsRgoMgC8Z4QBfW29SAWMlSEqgl+yP6S59CPWwJ1=3DVz= Yv encmsg: openpgp:encmsg;!base64::hQIMA2gg7mYL/9/3ARAAnICjOZZ2BPY/ly2y8kMN7wvnKKrWiIF= 8y4is5Az6+irsFc4XlAJ8ieKAQsxE9E8nopRoZySe9L6bPDQPr8dq1kYPN9eFaNkW+E1z0B1iV4= c3LrT1iGLsDrNJEODB8zytkYayc75RkuuA3iRkZj5Qco1fiv3DVNlnYRyPkXVQBwVVUPXaSowWH= CMCPMS+ZmiNiqNd4ZiN3Dah7mB87mK5ed8rZM03RBtS4QPpR9t3Ku4y1W58FuAeFqf3CrLpDrf/= 4U3+98RiI1Z3/zsqjblXZ0/uuNDQnFZvgpOZ1q6Ry1Z3N03U94vgvs3XjrIm6raQajBXrvGsQIb= gbSEkBldzNA0r0afcTPeaHTaOMcHqGA68b7Ju9yvYVk0BSyVbrW/oK93wT4SAxgq8wCPKlocp+K= Zx6qofSf7v/SdIKwMRgm2r2X0lTQTggElVG3sc00YcqS2a1kizmLPeyTOjai1Nt3vhySGFO48+S= GUXbeMdtMtJEmjk9SFquVHEUkcd1/0X89OWnVn+vDuhtKMvAWhLFGC+m9pXCA6YJxWZwPTtTmFS= OdsnYFEEU5J/jpl7Rmtev3AaBsZKRwgQlP24vz4zBzfMatTxLu7KBLeneyRPvzMe16dolYJtBSS= Fj7R0iXEy5GhKGLuckGWPL9mCzgGT8NSJZVPsrCoAYCo75hEnSEzSTQGJlgriakR505zTMr4YtS= DZnNZh9XFwZ2Wy64PwO5DexBgytHIEFQrqULfGoWUMYlIJAzDmkDx7eWcDwyWo5tZ8Uiv0pGJC6= iM6krgs=3D/Kcn fingerprint: openpgp:fprint;version:OpenPGPv3;name:clark+kent;::43:51:43:a1:b5:fc:8b:b7:= 0a:3a:a9:b1:0f:66:73:a8 openpgp:fprint;::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8 Some potential future json (Not easy to transmit however, due to non uri standard characters in json ): openpgp:testmode;key!json?17::{"key":[1,2,3,4]} --001a113a8c1a860a4d0516ad6363 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You might see a few copies around. This one is edited= and streamlined with some advice from Hasimir to help keep this proposal f= ocused.

Last updated: 2015-05-23 - edit: Switched = from `openpgp://` to `openpgp:` as noted by hobarrera. Also sent to openpgp@ietf.org for further discussion.

This is only a concept of specifically "altern= ative to openpgp blocks as uri" at the moment, so exact implementation= is still up in the air. The main aim is to spur discussion.=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
OPENPGP URI PROPOSAL (DR= AFT)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

## Bri= ef/Objective ####################

This proposa= l is to provide an alternative to the openpgp block messages, in the form o= f a uri ( e.g. `http://` ). This would make such messages more web friendly= , as well as taking advantage of autolaunching apps to handle such messages= . Such links may be embedded within email messages or webclients, or as a 2= d barcode on a physical poster.

This aims to be fl= exible and futureproof, by supporting any mix of variables =C2=A0or payload= that may be thrown in it's way (e.g. percent encoding, base64, etc... = )

This will hopefully make accessing and using ope= npgp as convenient as datauri (transmitting data), and mailto (launches ema= il handlers easily).=C2=A0

## Schema Descriptio= n ##

=C2=A0 =C2=A0 openpgp: =C2=A0 [<mode&g= t;] =C2=A0 [;key:value] =C2=A0 [;key<?length><!encoding>::value= ] =C2=A0 <;<?length><!encoding>::payload_data>=C2=A0

* `openpgp:` =C2=A0 =C2=A0 =C2=A0 - is the start of th= e openpgp uri ( This is the scheme name that calls for a handler)
* `;` =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- is used as = a delimiter.
* `[;key:value]` =C2=A0 =C2=A0 - =C2=A0for simple ke= yvalues: `;name:clark`
* `[;key<?length><!encoding>::= value]`
=C2=A0- `::` =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- is used to aid visual inspection, since= the content would be more of a long complex string, rather than a simple k= ey:value pair
=C2=A0- `[;key?length:value]` =C2=A0 =C2=A0 - safel= y read in string: `;name?10::clark;kent`
=C2=A0- `[;key?encoding:= value]` =C2=A0 - `;sig!base64::f4h5k34589ht...`
* `<;<?leng= th><!encoding>::payload_data>`=C2=A0
=C2=A0- payload = do not require key value. But it has optional encoding and length (Which ma= y have a default setting based on mode. E.g. public keys are often always e= ncoded in base64 )
=C2=A0- `;::f4h5k34589ht...`
=C2=A0-= `;!base64::f4h5k34589ht...`
=C2=A0- `;!octet?100::8BinaryStream`=
=C2=A0- `;!json?17::{"key":[1,2,3,4]}`
* `$e= ncoding` =C2=A0 - is used to define how the string is encoded, e.g. base64,= json,1010101
* `?length` =C2=A0 =C2=A0 - is used to define how ma= ny characters to read ahead as a string. Afterwards, it will just keep scan= ning for the next `;` or end of string.

* `#type` = this might be needed if we need to declare the type of a variable (undecide= d if it is needed in this standard proposal)

##= # Mode keywords ###

So far this is what I thou= ght for gpg keywords for the `<mode>`

* `pub= key` =3D public key
* `prvkey` =3D private key
* `encms= g` =3D encrypted message
* `sigmsg` =3D signed message
= * `fprint` =3D key fingerprint

### extra though= ts ###

* http://tools.ietf.org/html/rfc1738 - Uniform Resource Locator= s (URL)
* http://t= ools.ietf.org/html/rfc3986 - Uniform Resource Identifier (URI): Generic= Syntax
* http://t= ools.ietf.org/html/rfc3987 - Internationalized Resource Identifiers (IR= Is)


# Structure Examples #######= ######

e.g.=C2=A0

For= pubkey:

=C2=A0 =C2=A0 openpgp:pubkey;version:GnuP= G+v2;!base64::<base64 data>

For pubkey (with= implied encoding. Default for pubkey mode payload is base64):
=C2=A0 =C2=A0 openpgp:pubkey;version:GnuPG+v2;::<base64 dat= a>

For encrypted msg:

= =C2=A0 =C2=A0 openpgp:msg;version:GnuPG+v2;!base64::<base64 data>

or a signed message

=C2=A0 = =C2=A0 openpgp:sigmsg;hash:SHA1;sig:<base64>;!::<percent encoded m= essage>
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0=C2=A0
# Potential Usage ###############

* S= toring messages in QR or NFC allows for secure verifiable posters.
=C2=A0- This could allow people to trust messages stuck on posters on the= streets. E.g. safety information from organizations
=C2=A0- Pape= r letters could contain important messages/keys that can be then decrypted/= collected via a smartphone.

* Easier handling of m= essages in webrowsers via webrowsers plugins that can recognise the uri han= dler calls.=C2=A0
=C2=A0- E.g. Clicking on a url will automatical= ly open up a openpgp program that automatically processes the message.
<= /div>

* IRC? Could have real time signing of messages wi= th inlines opengpg uri (with the appropriate plugins)

<= div>* Can do anything that a normal openpgp block can do (But with the main= advantage of being url safe, unless intentionally in octet mode etc...)
=C2=A0- So can override the need for keyserver uris,

=
# Considerations ###############

* Even= if we do eventually come to a standard. What can we do to encourage web br= owser coders to whitelist `opengpg:` scheme name, and thus allow external p= rograms or plugins to handle the uri. This is since some browsers use a whi= telist (I think firefox uses a whitelist, since preferences only shows cert= ain schemes).

# Uri Mockups ################

Pubkey:

=C2=A0 =C2=A0 o= penpgp:pubkey;version:GnuPG+v2;!base64::mQENBFVS5CYBCACmDH67cDfC+0ow2FVX4uz= siOfA1OA4ZSJVwVjBQeotgr3a5CWCWSbW+kw3CjlRQXcL4bxTNisGAfrtn78+GkEmS48mb9kAPi= 084flEBHmgHbzo0TI3az74S3UI3ZkLxuAdfD4G7BuVn7YPzOa3OgD3FW1zZ3EGsHSl3+i0QZZ0f= Pvi4OkC+w4vDjrkUGR/afy7AzQhYzMA22kf3PTvZMxS0RLJvoRbnyoGjd1aQZPJD4mMziBaySRK= EdhAbIrogu2nW0M2aJmwiW1Sgp8PP8bH2PJPgXFKaRTucm3k2IdsxVx0u29VJiSq4ktrYm8cJ3A= BfUWbd/4adUFMbqwY2UhBABEBAAG0M0p1c3R3YW50dG9oYXZlZnVuNTYgPGp1c3R3YW50dG9oYX= ZlZnVuNTZAd2FzdGUuY29tPokBOQQTAQgAIwUCVVLkJgIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBA= h4BAheAAAoJEGNU/RWXfXCybfQH/jZLLuWdeqOj/bNFx6OHxNLc8hYKbuje+xtZNP4gagCJboiA= xPoWDfrhVQLKfKwR2mslAqQWdLSL1w93C/L1ByzXUz5sXA2YOTGVLXMU0aKQxYg3hBPqyc66F26= Rz8mVLnOHGQoGvlVA4CMFNwEpS3lMkxbNyoQLeS1wXJsZN8VmDa5vqzQySCmOuBJ0rDqbwLrYNs= hPVqdo1G7U0uoTjPTI65+GlKvtXLxqn/R7c/aywqE9qinK/L0uyiQ4itA0er6TwI8d8B1Fw8Jvb= DmJNx24zHqOjZWL1Osn5o7ZH31AmFH7VFFJWtcYkpgTf2KETZ/PvkPPV/RL0q9FiKcB7725AQ0E= VVLkJgEIAMl4rKSFfLXrB3MlwmNZqp66/5ixBm8FN1o3Hj9/xhiHWWZWwmkL3pfWVGI4GvFpOyh= 26VTv6Hvt54rvaqGYPZsz2jRO8PmVQs8g3CmC21F20jqi1fNu8m50ntrvK6qOK0pC7l7XXXkLwF= 9ChwxE8ott3WKALMS6+Z8RD0h/2SoNfW80dMLyDr2MzZdEB+dX6FM3YajkVaaIrhesedOsPoJOp= PJc/K0BF71YjecesUUJZFdGm5v5UkgPbptuXgRFQWbQcj0kpQT4oxjwUImLYWb86cSJn6Bw7aHD= 9h/7ZHF5Q/N8s5fsl6lAEPEI2hTTh0SJE5g8qqL5YRfX7QBy1d0AEQEAAYkBHwQYAQgACQUCVVL= kJgIbDAAKCRBjVP0Vl31wsnapB/9D0IBTxRNfWz3jsUbcfnI5Vu4V7mBu9B6rO6NfgpMirf2XaP= mC13nQjR3WFZqd6JeJ1GPupkhleau1oViVHvKB7rfKOUqt0MNecWuHNu7tGp2q+k0NTEnA8/F5B= Gj3yxKdWNZ1farQDVnz39Pcj17XZK7R6FXLcQRf/yMjkipp6AAzADMTulsu86JAo4TLix83SsSX= EzdID8p0REVRZZCTI8VHxlGjKOJBUu2K6IL5P80NMbEfHqXpxroftQhsuMQPGhlMgzDlWe7Mt+H= 5i/v3Sa4dKEQ0fW3kX/abF0xo4zDvbsRgoMgC8Z4QBfW29SAWMlSEqgl+yP6S59CPWwJ1=3DVzY= v

encmsg:

=C2=A0 =C2=A0 o= penpgp:encmsg;!base64::hQIMA2gg7mYL/9/3ARAAnICjOZZ2BPY/ly2y8kMN7wvnKKrWiIF8= y4is5Az6+irsFc4XlAJ8ieKAQsxE9E8nopRoZySe9L6bPDQPr8dq1kYPN9eFaNkW+E1z0B1iV4c= 3LrT1iGLsDrNJEODB8zytkYayc75RkuuA3iRkZj5Qco1fiv3DVNlnYRyPkXVQBwVVUPXaSowWHC= MCPMS+ZmiNiqNd4ZiN3Dah7mB87mK5ed8rZM03RBtS4QPpR9t3Ku4y1W58FuAeFqf3CrLpDrf/4= U3+98RiI1Z3/zsqjblXZ0/uuNDQnFZvgpOZ1q6Ry1Z3N03U94vgvs3XjrIm6raQajBXrvGsQIbg= bSEkBldzNA0r0afcTPeaHTaOMcHqGA68b7Ju9yvYVk0BSyVbrW/oK93wT4SAxgq8wCPKlocp+KZ= x6qofSf7v/SdIKwMRgm2r2X0lTQTggElVG3sc00YcqS2a1kizmLPeyTOjai1Nt3vhySGFO48+SG= UXbeMdtMtJEmjk9SFquVHEUkcd1/0X89OWnVn+vDuhtKMvAWhLFGC+m9pXCA6YJxWZwPTtTmFSO= dsnYFEEU5J/jpl7Rmtev3AaBsZKRwgQlP24vz4zBzfMatTxLu7KBLeneyRPvzMe16dolYJtBSSF= j7R0iXEy5GhKGLuckGWPL9mCzgGT8NSJZVPsrCoAYCo75hEnSEzSTQGJlgriakR505zTMr4YtSD= ZnNZh9XFwZ2Wy64PwO5DexBgytHIEFQrqULfGoWUMYlIJAzDmkDx7eWcDwyWo5tZ8Uiv0pGJC6i= M6krgs=3D/Kcn
=C2=A0 =C2=A0=C2=A0
fingerprint:

=C2=A0 =C2=A0 openpgp:fprint;version:OpenPGPv3;name:clark+= kent;::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

=
=C2=A0 =C2=A0 openpgp:fprint;::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:= 66:73:a8
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0=C2=A0
<= div>Some potential future json (Not easy to transmit however, due to non ur= i standard characters in json ):

=C2=A0 =C2=A0 ope= npgp:testmode;key!json?17::{"key":[1,2,3,4]}
=C2=A0 =C2= =A0=C2=A0
--001a113a8c1a860a4d0516ad6363-- From nobody Wed May 27 02:42:03 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A0D1A9166 for ; Wed, 27 May 2015 02:42:02 -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 xfSjTzTMSDNm for ; Wed, 27 May 2015 02:42:00 -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 AE91E1A9162 for ; Wed, 27 May 2015 02:42:00 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YxXqZ-0002cb-1J for ; Wed, 27 May 2015 11:41:59 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YxXkX-0002TA-3i; Wed, 27 May 2015 11:35:45 +0200 From: Werner Koch To: Wyllys Ingersoll References: <87iobodgwi.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: Wyllys Ingersoll , "openpgp\@ietf.org" Date: Wed, 27 May 2015 11:35:45 +0200 In-Reply-To: <87iobodgwi.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 19 May 2015 12:02:21 +0200") Message-ID: <87pp5m1hxq.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] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 27 May 2015 09:42:02 -0000 On Tue, 19 May 2015 12:02, wk@gnupg.org said: > and put that into a public repo? A good starting point might be to > merge 4880 with 5581 (Camellia) and 6637 (ECC). With that all in one Everyone to shy to comment on this? I guess I have to take this then. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed May 27 09:12: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 4F63B1A1B4A for ; Wed, 27 May 2015 09:12:03 -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 82MBVui7pvY8 for ; Wed, 27 May 2015 09:12:01 -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 42D711A1B29 for ; Wed, 27 May 2015 09:12:01 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yxdvy-0008Et-Od for ; Wed, 27 May 2015 18:11:58 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YxdpS-0003X7-Mt for ; Wed, 27 May 2015 18:05:14 +0200 From: Werner Koch To: openpgp@ietf.org 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: openpgp@ietf.org Date: Wed, 27 May 2015 18:05:14 +0200 In-Reply-To: (Wyllys Ingersoll's message of "Mon, 18 May 2015 23:44:03 +0000") Message-ID: <87fv6i0zwl.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] rfc4880bis: Converted to pandoc and errata applied. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 27 May 2015 16:12:03 -0000 Hi! I took rfc4880, converted it to pandoc and applied the verified errata items. I have it in a git repo at: This is a first step towards a RFC4880bis. By running pandoc2rfc abstract.mkd middle.mkd back.mkd you may create a draft.txt whcih should be mostly identical to RFC4880. The biblio entries for the normative section are a bit different and those from the informational section are missing. Tables are used instead of simple list to allow the use of references. Some parts are copied verbatim from the RFC without new pandoc markup. Author addresses and the boilerplate information may not be correct. What's next? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed May 27 10: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 492F21A875E for ; Wed, 27 May 2015 10:06:36 -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 67BVo2tSVwMB for ; Wed, 27 May 2015 10:06:34 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6BF1A875C for ; Wed, 27 May 2015 10:06:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id C2E20747C07D; Wed, 27 May 2015 10:06:32 -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 ikKOr14Gj0F9; Wed, 27 May 2015 10:06:32 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 9C783747C06F; Wed, 27 May 2015 10:06:30 -0700 (PDT) Received: from [10.0.23.123] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 27 May 2015 10:06:32 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 27 May 2015 10:06:32 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jon Callas In-Reply-To: <87iobodgwi.fsf@vigenere.g10code.de> Date: Wed, 27 May 2015 10:06:29 -0700 Message-Id: <9ECD3C3B-CE5E-4FC7-B433-7D7F1DCF05D6@callas.org> References: <87iobodgwi.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: Wyllys Ingersoll , Jon Callas , "openpgp@ietf.org" Subject: Re: [openpgp] rfc4880bis basics (was: List problems?) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 27 May 2015 17:06:36 -0000 > On May 19, 2015, at 3:02 AM, Werner Koch wrote: >=20 > On Tue, 19 May 2015 01:44, wyllys@gmail.com said: >> Just checking in - all traffic from this list suddenly stopped on May = 7. >> Seems odd... >=20 > Well, we are all waiting for someone to do the first move. >=20 > I know that we do not have a charter yet but we agreed on developing > rfc4880bis. This raises the question who will act as editor and what > format to use for editing. >=20 > How would the general procedure be: Convert 4880 into a source format > and put that into a public repo? A good starting point might be to > merge 4880 with 5581 (Camellia) and 6637 (ECC). With that all in one > document we can then deprecate v3 and other stuff before we start > working on a v5 key format or new features. >=20 > Although I am not a big fan of Markdown there is a nice tool to = convert > a Markdown document to the RFC XML and finally to an I-D/RFC: = pandoc2rfc > at tools.ietf.org. The advantage is that a simple text file can be > easily diffed and put into git. [It would be nice if the IETF could > provide such a public repo.] I can get someone the original source, which is using Tim Dierks's = markup language, which has a Perl translator. That should be easier than = dealing with the RFC final. Jon From nobody Wed May 27 13:55: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 8EC801A1A7F for ; Wed, 27 May 2015 13:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.8 X-Spam-Level: ** X-Spam-Status: No, score=2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_84=0.6, MANGLED_DIET=2.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 kApkhfQynqEc for ; Wed, 27 May 2015 13:55:21 -0700 (PDT) Received: from smtp6.emailarray.com (smtp6.emailarray.com [65.39.216.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CABE1A0E10 for ; Wed, 27 May 2015 13:55:21 -0700 (PDT) Received: (qmail 61546 invoked by uid 89); 27 May 2015 20:55:19 -0000 Received: from unknown (HELO ?172.24.10.75?) (Y2RsQGFzZ2FhcmQub3JnQDE5OC4xNDcuMjI2LjY=) (POLARISLOCAL) by smtp6.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 May 2015 20:55:19 -0000 From: "Christopher LILJENSTOLPE" To: "Werner Koch" Date: Wed, 27 May 2015 13:55:17 -0700 Message-ID: In-Reply-To: <87fv6i0zwl.fsf@vigenere.g10code.de> References: <87fv6i0zwl.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_1EF8D44B-A6CB-420E-AC69-E42949EDE509_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: x Archived-At: Cc: openpgp@ietf.org Subject: Re: [openpgp] [eX-bulk] : rfc4880bis: Converted to pandoc and errata applied. X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 27 May 2015 20:55:24 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_1EF8D44B-A6CB-420E-AC69-E42949EDE509_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, Thank's for the work Werner. Christopher On 27 May 2015, at 9:05, Werner Koch wrote: > User-Agent*(Gnus+v5.13), 0.01000, > In-Reply-To*message, 0.01000, > User-Agent*Gnus/5.13, 0.01000, > User-Agent*Gnus/5.13+(Gnus, 0.01000, > From*Koch, 0.01000, > Subject*Converted, 0.01000, > regelt, 0.01000, > In-Reply-To*of+"Mon, 0.01000, > boilerplate+information, 0.01000, > Gedanken+sind, 0.01000, > sind+frei, 0.01000, > In-Reply-To*of, 0.01000, > Die+Gedanken, 0.01000, > In-Reply-To*23, 0.01000, > User-Agent*(Gnus, 0.01000, > Url*gnupg, 0.01000, > User-Agent*v5.13), 0.01000, > In-Reply-To*message+of, 0.01000, > In-Reply-To*18, 0.01000, > List-Help*ietf.org?subject=3Dhelp>, 0.98857, > List-Help*request+ietf.org?subject=3Dhelp>, 0.98857 > > Hi! > > I took rfc4880, converted it to pandoc and applied the verified errata > items. I have it in a git repo at: > > > > This is a first step towards a RFC4880bis. By running > > pandoc2rfc abstract.mkd middle.mkd back.mkd > > you may create a draft.txt whcih should be mostly identical to RFC4880.= > The biblio entries for the normative section are a bit different and > those from the informational section are missing. Tables are used > instead of simple list to allow the use of references. Some parts are > copied verbatim from the RFC without new pandoc markup. Author > addresses and the boilerplate information may not be correct. > > What's next? > > > Salam-Shalom, > > Werner > > > -- = > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- = =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe --=_MailMate_1EF8D44B-A6CB-420E-AC69-E42949EDE509_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVZi81AAoJEGmx2Mt/+Iw/aD0H/3RJ2mWX4SrL1hamb5l/FkJ0 7W1OJOdQJiS88lH0oYUrYYCuP9+bV1AN9kNnuZ9EZ4xfsR0xDryKvKA+WikvKOXI BebfyQ3rr25hQHwzQyj9CexD9INMEnyophVfrT4+IwR8f2UZYENwbSjJkrx28IVq XurX8I2lK+/ePjyLeRGttYFJTAKfjJv4aim8YZP6K/4qOx89u5FE9e5ZbWgWe7JS ejErqLtY5zptI21fNydKSW1TTLZEij6dW5O48ACVws2mCyc5OfApSHtBzehmQ/gi g5m/GQty0w0iooqLmfYRhevkYHqUtF+46jQPs1q4ydN1VCa7wUc20YhYEc8b2Lg= =JZ/V -----END PGP SIGNATURE----- --=_MailMate_1EF8D44B-A6CB-420E-AC69-E42949EDE509_=-- From nobody Thu May 28 09:34: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 69E371B2C43 for ; Thu, 28 May 2015 09:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 cJYY9W_0MYSW for ; Thu, 28 May 2015 09:34:02 -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 A52C31A001B for ; Thu, 28 May 2015 09:34:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D4688E2036; Thu, 28 May 2015 12:34: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 14622-06; Thu, 28 May 2015 12:33:58 -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 AEE8BE2035; Thu, 28 May 2015 12:33:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1432830838; bh=D3jYXStrNQaYSrmOb2DW11D7iS7VsXJeu8AwbF5a8gE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=oE0nTqLHOjLqh4sjRfpPatWZga+Vx/R/FSjGvHqJJ6mBsrMriBcf4Ei1t0/42cYjR Typ4zc3wNp+IdJqEjtM6RAaxYbf8vMpNfpYlLwmKmJZwC0aWDIrS5xW5DyXnsBTLFr UJPrVHO0K7RwTlg1yHPpn5z1eDFmj4DE2tjn1qmc= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4SGXwdB025514; Thu, 28 May 2015 12:33:58 -0400 From: Derek Atkins To: Wyllys Ingersoll References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> Date: Thu, 28 May 2015 12:33:58 -0400 In-Reply-To: <87pp5m1hxq.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 27 May 2015 11:35:45 +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] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 28 May 2015 16:34:03 -0000 Werner Koch writes: > On Tue, 19 May 2015 12:02, wk@gnupg.org said: > >> and put that into a public repo? A good starting point might be to >> merge 4880 with 5581 (Camellia) and 6637 (ECC). With that all in one > > Everyone to shy to comment on this? I guess I have to take this then. I'm not sure we need to merge in 5581 and 6637. I think it's perfectly reasonable to leave those as separate documents, unless you're expecting to make them MTI? > Shalom-Salam, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu May 28 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 497981A1B67 for ; Thu, 28 May 2015 10:27:03 -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 dKEPMWIRHHcp for ; Thu, 28 May 2015 10:27:01 -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 7052A1A0015 for ; Thu, 28 May 2015 10:27:01 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yy1a7-0002ws-OY for ; Thu, 28 May 2015 19:26:59 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yy1U1-00081N-UU; Thu, 28 May 2015 19:20:41 +0200 From: Werner Koch To: Derek Atkins References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.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 , Wyllys Ingersoll , "openpgp\@ietf.org" Date: Thu, 28 May 2015 19:20:41 +0200 In-Reply-To: (Derek Atkins's message of "Thu, 28 May 2015 12:33:58 -0400") Message-ID: <87fv6gy5xy.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: Wyllys Ingersoll , "openpgp@ietf.org" Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 28 May 2015 17:27:03 -0000 On Thu, 28 May 2015 18:33, derek@ihtfp.com said: > I'm not sure we need to merge in 5581 and 6637. I think it's perfectly > reasonable to leave those as separate documents, unless you're expecting > to make them MTI? Well, 5581 has only the algorithm numbers for Camellia. These are just 3 lines and one new reference. We did the same for AES in rfc2440bis. I assumed that ECC will at least be a SHOULD algorithm and thus merging 6637 seems to be appropriate. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu May 28 10:51: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 05C841A86E6 for ; Thu, 28 May 2015 10:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 SFk7Y7M6LJ51 for ; Thu, 28 May 2015 10:51:47 -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 07A6E1A00BD for ; Thu, 28 May 2015 10:51:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 976A5E2039; Thu, 28 May 2015 13:51:45 -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 15186-04; Thu, 28 May 2015 13:51:42 -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 C808AE2038; Thu, 28 May 2015 13:51:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1432835502; bh=fxSd5qRHS7v3R8xisTZfPtjHVQWeuaZYFQkNrmhdGhY=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=qiIqp2Ir6RLxlEVsVRCdFX7BkAYkBlhshO6YXJ6H5UTMhUSjv7+RnG0V7O4dyVtsz +c8yDLRQedYdo82EJxV6APmItbQPJMlJBmk4Sy/WwjRdeDIWrnOEoIwqsWLxzzoY+1 s8SRWSsURJRYFObCa0SbsKzAxzMSulcP77FBSaA0= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4SHpgXk026514; Thu, 28 May 2015 13:51:42 -0400 From: Derek Atkins To: Derek Atkins References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> <87fv6gy5xy.fsf@vigenere.g10code.de> Date: Thu, 28 May 2015 13:51:42 -0400 In-Reply-To: <87fv6gy5xy.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 28 May 2015 19:20: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: Wyllys Ingersoll , "openpgp@ietf.org" Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 28 May 2015 17:51:48 -0000 Werner Koch writes: > On Thu, 28 May 2015 18:33, derek@ihtfp.com said: > >> I'm not sure we need to merge in 5581 and 6637. I think it's perfectly >> reasonable to leave those as separate documents, unless you're expecting >> to make them MTI? > > Well, 5581 has only the algorithm numbers for Camellia. These are just > 3 lines and one new reference. We did the same for AES in rfc2440bis. > > I assumed that ECC will at least be a SHOULD algorithm and thus merging > 6637 seems to be appropriate. I'm fine with that; just wanted to make sure we included them for a good reason. For example, I don't expect that we would include draft-atkins-openpgp-algebraic-eraser in 4880bis, although I do want to see it progress. > Shalom-Salam, > > Werner -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu May 28 11:26: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 B3D5C1A009E for ; Thu, 28 May 2015 11:26: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 IEVg1ZsJxws6 for ; Thu, 28 May 2015 11:26: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 705B01A0078 for ; Thu, 28 May 2015 11:26:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E30CBEFB; Thu, 28 May 2015 19:26:23 +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 p7TUsYAxoP7v; Thu, 28 May 2015 19:26:22 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06642BEF6; Thu, 28 May 2015 19:26:22 +0100 (IST) Message-ID: <55675DCB.2090302@cs.tcd.ie> Date: Thu, 28 May 2015 19:26:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Derek Atkins , Wyllys Ingersoll , "openpgp@ietf.org" References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> <87fv6gy5xy.fsf@vigenere.g10code.de> In-Reply-To: <87fv6gy5xy.fsf@vigenere.g10code.de> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 28 May 2015 18:26:25 -0000 On 28/05/15 18:20, Werner Koch wrote: > I assumed that ECC will at least be a SHOULD algorithm and thus merging > 6637 seems to be appropriate. I'd say most folks here are aware of it but just in case... It'd be good if the WG(-to-be) considered if they want to incorporate the work on new curves being done by CFRG. That might mean waiting a little longer as CFRG aren't done at that although they seem to be making good progress now. Wearing no hats, I think it'd be good to include the new curves in this work. Cheers, S. From nobody Thu May 28 15:29: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 2085A1AC3E5 for ; Thu, 28 May 2015 15:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpuC2XNdOwap for ; Thu, 28 May 2015 15:29:32 -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 20D801A914B for ; Thu, 28 May 2015 15:29:32 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so37647535lbb.3 for ; Thu, 28 May 2015 15:29: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=bNGAv8XGq+taFujd09h4fy1MUDDJi1AcpbSI3EHJxPQ=; b=uq3kZ94sfwC5rImgVlPvTMRFKm0/iNkTZB/2NgvukkqAmu2rNvVKkfwTm1Y6XPSK5+ PnzpxCg+dsxIM6342mqgm1LQYNFoRQkjOSkg6sD514GdAgaZfXjpTBltVjBkcqVdCReg lNwb0RrIEkHgCJr0vnkv+69yzwbkcNrCmTDy8vx/XjekIl9JTBLHQU2LWJKuu+9T2S/k b17FUuhnTSWq/A29f6Kvueb/6oR7RghYsWmHbUC6R3TPxdQ7vY+Ln9AVBvetVBNjDP8+ nBjd5HmFtVDjW5CxgQrKz83ZKx1rVH+JAu//qdxMf75v4JQ2VXatryne+6A7MgZgKpZ5 CFbg== MIME-Version: 1.0 X-Received: by 10.152.43.168 with SMTP id x8mr5003259lal.79.1432852170577; Thu, 28 May 2015 15:29:30 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 28 May 2015 15:29:30 -0700 (PDT) In-Reply-To: <55675DCB.2090302@cs.tcd.ie> References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> <87fv6gy5xy.fsf@vigenere.g10code.de> <55675DCB.2090302@cs.tcd.ie> Date: Thu, 28 May 2015 18:29:30 -0400 X-Google-Sender-Auth: 2I88DQzid_NfLC5SF9yM-XhAcwM Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c22a5ea49e6c05172be478 Archived-At: Cc: Wyllys Ingersoll , Derek Atkins , "openpgp@ietf.org" Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 28 May 2015 22:29:34 -0000 --001a11c22a5ea49e6c05172be478 Content-Type: text/plain; charset=UTF-8 On Thu, May 28, 2015 at 2:26 PM, Stephen Farrell wrote: > > > On 28/05/15 18:20, Werner Koch wrote: > > I assumed that ECC will at least be a SHOULD algorithm and thus merging > > 6637 seems to be appropriate. > > I'd say most folks here are aware of it but just in case... > > It'd be good if the WG(-to-be) considered if they want to > incorporate the work on new curves being done by CFRG. That > might mean waiting a little longer as CFRG aren't done at > that although they seem to be making good progress now. > > Wearing no hats, I think it'd be good to include the new > curves in this work. > Exactly what I was about to say. I don't actually care very much which ECC we do. What I care about is that instead of having fifty different variations and curlicues we have one high strength and one ridiculously high strength approach. And I want to use that same approach for S/MIME, TLS, SSH and OpenPGP. This provides many benefits. First off, it means that instead of tracking five separate sets of implementation experience, we have one. If someone comes up with a TLS attack we can look at OpenPGP and see if the same sort of thing might apply. TLS is going to get orders of magnitude more implementation experience than anything else so chances are we will have a solid implementation there long before we could gain experience on any other application. Another reason for the change is that then 'support for CFRG ECC' becomes shorthand for 'support for crypto vNext'. Checking protocol version numbers is quite tricky. Checking to see if they do an algorithm, much easier. Problem is that security comes from removing features that seemed like a good idea at the time. But that doesn't appear in marketing collateral. Support for new algorithms does. And finally, biggest problem with ECC has been that it is just too much new complexity for too little reward many of us. When I see crypto with a bazillion options, I see 'needs further work'. One of the main reasons RSA is so dominant is that there is one algorithm and the way to implement it has changed only three times in twenty years. --001a11c22a5ea49e6c05172be478 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 28, 2015 at 2:26 PM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:


On 28/05/15 18:20, Werner Koch wrote:
> I assumed that ECC will at least be a SHOULD algorithm and thus mergin= g
> 6637 seems to be appropriate.

I'd say most folks here are aware of it but just in case...

It'd be good if the WG(-to-be) considered if they want to
incorporate the work on new curves being done by CFRG. That
might mean waiting a little longer as CFRG aren't done at
that although they seem to be making good progress now.

Wearing no hats, I think it'd be good to include the new
curves in this work.

Exactly what I was= about to say.

I don't actually care very much= which ECC we do. What I care about is that instead of having fifty differe= nt variations and curlicues we have one high strength and one ridiculously = high strength approach. And I want to use that same approach for S/MIME, TL= S, SSH and OpenPGP.

This provides many benefits. F= irst off, it means that instead of tracking five separate sets of implement= ation experience, we have one. If someone comes up with a TLS attack we can= look at OpenPGP and see if the same sort of thing might apply. TLS is goin= g to get orders of magnitude more implementation experience than anything e= lse so chances are we will have a solid implementation there long before we= could gain experience on any other application.

A= nother reason for the change is that then 'support for CFRG ECC' be= comes shorthand for 'support for crypto vNext'. Checking protocol v= ersion numbers is quite tricky. Checking to see if they do an algorithm, mu= ch easier. Problem is that security comes from removing features that seeme= d like a good idea at the time. But that doesn't appear in marketing co= llateral. Support for new algorithms does.

And fin= ally, biggest problem with ECC has been that it is just too much new comple= xity for too little reward many of us. When I see crypto with a bazillion o= ptions, I see 'needs further work'. One of the main reasons RSA is = so dominant is that there is one algorithm and the way to implement it has = changed only three times in twenty years.
--001a11c22a5ea49e6c05172be478-- From nobody Fri May 29 05:37: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 904741A87EB for ; Fri, 29 May 2015 05:37:04 -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 xksP1bYS7pdK for ; Fri, 29 May 2015 05:37:02 -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 A73961A6F2A for ; Fri, 29 May 2015 05:37:02 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YyJX3-0006Wr-5M for ; Fri, 29 May 2015 14:37:01 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YyJSL-0002lR-PK; Fri, 29 May 2015 14:32:09 +0200 From: Werner Koch To: Stephen Farrell References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> <87fv6gy5xy.fsf@vigenere.g10code.de> <55675DCB.2090302@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 Mail-Followup-To: Stephen Farrell , Derek Atkins , Wyllys Ingersoll , "openpgp\@ietf.org" Date: Fri, 29 May 2015 14:32:09 +0200 In-Reply-To: <55675DCB.2090302@cs.tcd.ie> (Stephen Farrell's message of "Thu, 28 May 2015 19:26:19 +0100") Message-ID: <87zj4nwomu.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: Wyllys Ingersoll , Derek Atkins , "openpgp@ietf.org" Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 12:37:04 -0000 On Thu, 28 May 2015 20:26, stephen.farrell@cs.tcd.ie said: > It'd be good if the WG(-to-be) considered if they want to > incorporate the work on new curves being done by CFRG. That > might mean waiting a little longer as CFRG aren't done at This is actually a no-brainer. We can easily add new curves by adding their OIDs and adjust MUST/SHOULD/MAY keywords at any stage of the development. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri May 29 12:41: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 A95F81A1B9E for ; Fri, 29 May 2015 12:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 kcANPT9SteuU for ; Fri, 29 May 2015 12:41:52 -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 032C91A1B7B for ; Fri, 29 May 2015 12:41:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6F515E2039; Fri, 29 May 2015 15:41:50 -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 23969-07; Fri, 29 May 2015 15:41:48 -0400 (EDT) Received: from securerf.ihtfp.org (marriott-chateau-champlain-montreal.sites.intello.com [66.171.169.34]) (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 3AFEBE2035; Fri, 29 May 2015 15:41:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1432928508; bh=l+XUFubf84cn3gG8DtYNas3req5CIrxDFEvPfHHvnOU=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=XBbJtlDydYNvOfJcTUfaV6+ZwhS3CB4MTIsIdcu3nBpuqIRFp48fp+i9OKLwjNVJ6 brI2YmoCppXU8PKIRjfAU7fzBXKYiIQY5/x6q6+gmxaOTwNR3hDbZ2mQ8/MdUBS68H JE0LpfSkDw2ZjyYeh6pr4FIeZNR2xzv4MVbsE3xw= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t4TFctC6009258; Fri, 29 May 2015 11:38:55 -0400 From: Derek Atkins To: Stephen Farrell References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> <87fv6gy5xy.fsf@vigenere.g10code.de> <55675DCB.2090302@cs.tcd.ie> Date: Fri, 29 May 2015 11:38:55 -0400 In-Reply-To: <55675DCB.2090302@cs.tcd.ie> (Stephen Farrell's message of "Thu, 28 May 2015 19:26:19 +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: Wyllys Ingersoll , "openpgp@ietf.org" Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 19:41:53 -0000 Stephen Farrell writes: > On 28/05/15 18:20, Werner Koch wrote: >> I assumed that ECC will at least be a SHOULD algorithm and thus merging >> 6637 seems to be appropriate. > > I'd say most folks here are aware of it but just in case... > > It'd be good if the WG(-to-be) considered if they want to > incorporate the work on new curves being done by CFRG. That > might mean waiting a little longer as CFRG aren't done at > that although they seem to be making good progress now. > > Wearing no hats, I think it'd be good to include the new > curves in this work. There is already an I-D on Ed25519. Because it has a different form than the NIST curves it requires a different parameter. Is the intention to include that by value in RFC4880bis? (I'm certainly not opposed to the answer being "yes" -- I just want us to be clear that we're going to do that too in addition to 6637). > Cheers, > S. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri May 29 12:47: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 A57741A1B77 for ; Fri, 29 May 2015 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 1mZ3JASTQuCo for ; Fri, 29 May 2015 12:47:02 -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 168B71A01CB for ; Fri, 29 May 2015 12:47:02 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YyQFA-0001LP-IP for ; Fri, 29 May 2015 21:47:00 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YyQ9D-0003vX-9c for ; Fri, 29 May 2015 21:40:51 +0200 From: Werner Koch To: openpgp@ietf.org Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: openpgp@ietf.org Date: Fri, 29 May 2015 21:40:51 +0200 Message-ID: <87k2vrw4sc.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] rfc4880bis: Merged RFC-5581 and RFC-6637 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 19:47:11 -0000 Hi, I merged the Camellia and the ECC For OpenPGP RFCs into 4880bis. See Below is a diff of the major changes related to RFC-6637. I merged most stuff except for parts which IMHO do not make sense: For example IANA consideration to assign the algos and text explaining why ECC is a good idea. I am not sure whether the "Compatibility Profile" should go into 4880bis. But it has been in 6637 and thus we should keep it for now. Shalom-Salam, Werner ---------- rfc4880bis: Merge with RFC-6637 (ECC for OpenPGP) This patch adds the new algorithm numbers for ECDH and ECDSA and marks them as MUST implement. The bulk of RFC-6637 is added to the new sections Elliptic Curve Cryptography and Compatibility Profiles. The remaining stuff goes into the Security Considerations. diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd index 9ea7326..80c0a61 100644 --- a/misc/id/rfc4880bis/middle.mkd +++ b/misc/id/rfc4880bis/middle.mkd @@ -10,7 +10,8 @@ # {1} Introduction Message Format", which itself replaces RFC 1991, "PGP Message Exchange Formats" [](#RFC1991) [](#RFC2440). -This document obsoletes: RFC 5581 (Camellia cipher). +This document obsoletes: RFC 5581 (Camellia cipher) and RFC 6637 (ECC +for OpenPGP) ## {1.1} Terms @@ -635,6 +636,13 @@ ## {5.1} Public-Key Encrypted Session Key Packets (Tag 1) - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. + Algorithm-Specific Fields for ECDH encryption: + + - MPI of an EC point representing an ephemeral public key. + + - a one-octet size, followed by a symmetric key encoded using the + method described in [](#ec-dh-algorithm-ecdh). + The value "m" in the above formulas is derived from the session key as follows. First, the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption algorithm used to @@ -830,11 +838,11 @@ ### {5.2.2} Version 3 Signature Packet Format * Multiprecision integer (MPI) of RSA signature value m**d mod n. - Algorithm-Specific Fields for DSA signatures: + Algorithm-Specific Fields for DSA and ECDSA signatures: - * MPI of DSA value r. + * MPI of DSA or ECDSA value r. - * MPI of DSA value s. + * MPI of DSA or ECDSA value s. The signature calculation is based on a hash of the signed data, as described above. The details of the calculation are different for DSA @@ -1798,6 +1806,49 @@ ### {5.5.2} Public-Key Packet Formats - MPI of Elgamal public key value y (= g**x mod p where x is secret). + Algorithm-Specific Fields for ECDSA keys: + + - a variable-length field containing a curve OID, formatted + as follows: + + - a one-octet size of the following field; values 0 and + 0xFF are reserved for future extensions, + + - the octets representing a curve OID, defined in + section 11{FIXME}; + + - a MPI of an EC point representing a public key. + + Algorithm-Specific Fields for ECDH keys: + + - a variable-length field containing a curve OID, formatted + as follows: + + - a one-octet size of the following field; values 0 and + 0xFF are reserved for future extensions, + + - the octets representing a curve OID, defined in + Section 11{FIXME}; + + - a MPI of an EC point representing a public key; + + - a variable-length field containing KDF parameters, + formatted as follows: + + - a one-octet size of the following fields; values 0 + and 0xff are reserved for future extensions; + + - a one-octet value 1, reserved for future extensions; + + - a one-octet hash function ID used with a KDF; + + - a one-octet algorithm ID for the symmetric algorithm + used to wrap the symmetric key used for the message + encryption; see Section 8 for details. + +Observe that an ECDH public key is composed of the same sequence of +fields that define an ECDSA key, plus the KDF parameters field. + ### {5.5.3} Secret-Key Packet Formats The Secret-Key and Secret-Subkey packets contain all the data of the @@ -1856,6 +1907,12 @@ ### {5.5.3} Secret-Key Packet Formats - MPI of Elgamal secret exponent x. + Algorithm-Specific Fields for ECDH or ECDSA secret keys: + + - MPI of an integer representing the secret key, which is a + scalar of the public EC point. + + Secret MPI values can be encrypted using a passphrase. If a string- to-key specifier is given, that describes the algorithm for converting the passphrase to a key, else a simple MD5 hash of the passphrase is @@ -2693,20 +2750,54 @@ ## {9.1} Public-Key Algorithms 3 RSA Sign-Only [](#HAC) 16 Elgamal (Encrypt-Only) [](#ELGAMAL) [](#HAC) 17 DSA (Digital Signature Algorithm) [](#FIPS186) [](#HAC) - 18 Reserved for Elliptic Curve - 19 Reserved for ECDSA + 18 ECDH public key algorithm + 19 ECDSA public key algorithm [](#FIPS186-3) 20 Reserved (formerly Elgamal Encrypt or Sign) 21 Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 100--110 Private/Experimental algorithm -Implementations MUST implement DSA for signatures, and Elgamal for +Implementations MUST implement DSA and ECDSA for signatures, and +Elgamal and ECDH for encryption. Implementations SHOULD implement RSA keys (1). RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be -generated, but may be interpreted. See Section 13.5. See Section 13.8 -for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or Sign -(20), and X9.42 (21). Implementations MAY implement any other -algorithm. +generated, but may be interpreted. See Section 13.5. +See Section 13.8 for notes Elgamal Encrypt or Sign (20), and X9.42 (21). +Implementations MAY implement any other algorithm. + +A compatible specification of ECDSA is given in [](#RFC6090) as "KT-I +Signatures" and in [](#SEC1); ECDH is defined in [](#ec-dh-algorithm-ecdh) +this document. + +## ECC Curve OID + +The parameter curve OID is an array of octets that define a named +curve. The table below specifies the exact sequence of bytes for each +named curve referenced in this document: + + ------------ --- ----------------------- ------------- + ASN.1 Object OID Curve OID bytes in Curve name in + Identifier len hexadecimal [FIPS186-3] + representation + ------------ --- ----------------------- ------------- + 1.2.840.10045.3.1.7 8 2A 86 48 CE 3D 03 01 07 NIST curve P-256 + + 1.3.132.0.34 5 2B 81 04 00 22 NIST curve P-384 + + 1.3.132.0.35 5 2B 81 04 00 23 NIST curve P-521 + ------------------------------------------------------------------ + +The sequence of octets in the third column is the result of applying +the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier +with subsequent truncation. The truncation removes the two fields of +encoded Object Identifier. The first omitted field is one octet +representing the Object Identifier tag, and the second omitted field +is the length of the Object Identifier body. For example, the +complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A +86 48 CE 3D 03 01 07", from which the first entry in the table above +is constructed by omitting the first two octets. Only the truncated +sequence of octets is the valid representation of a curve OID. + ## {9.2} Symmetric-Key Algorithms @@ -3186,6 +3277,201 @@ ## {12.2} Key IDs and Fingerprints same way as for a primary key, including the 0x99 as the first octet (even though this is not a valid packet ID for a public subkey). +# Elliptic Curve Cryptography + +This section descripes algorithms and parameters used with Elliptic +Curve Cryptography (ECC) keys. A thorough introduction to ECC can be +found in [](#KOBLITZ). + +## Supported ECC Curves + +This document references three named prime field curves, defined in +[](#FIPS186-3) as "Curve P-256", "Curve P-384", and "Curve P-521". + +The named curves are referenced as a sequence of bytes in this +document, called throughout, curve OID. [](#ecc-curve-oid) describes +in detail how this sequence of bytes is formed. + +## ECC Conversion Primitives + +This document only defines the uncompressed point format. The point +is encoded in the Multiprecision Integer (MPI) format. The +content of the MPI is the following: + + B = 04 || x || y + +where x and y are coordinates of the point P = (x, y), each encoded in +the big-endian format and zero-padded to the adjusted underlying field +size. The adjusted underlying field size is the underlying field size +that is rounded up to the nearest 8-bit boundary. + +Therefore, the exact size of the MPI payload is 515 bits for "Curve +P-256", 771 for "Curve P-384", and 1059 for "Curve P-521". + +Even though the zero point, also called the point at infinity, may +occur as a result of arithmetic operations on points of an elliptic +curve, it SHALL NOT appear in data structures defined in this +document. + +This encoding is compatible with the definition given in [](#SEC1). + +If other conversion methods are defined in the future, a compliant +application MUST NOT use a new format when in doubt that any recipient +can support it. Consider, for example, that while both the public key +and the per-recipient ECDH data structure, respectively defined in +Sections 9{FIXME} and 10{FIXME}, contain an encoded point field, the +format changes to the field in Section 10{FIXME} only affect a given +recipient of a given message. + +## Key Derivation Function + +A key derivation function (KDF) is necessary to implement the EC +encryption. The Concatenation Key Derivation Function (Approved +Alternative 1) [](#SP800-56A) with the KDF hash function that is +SHA2-256 [](#FIPS180-3) or stronger is REQUIRED. See Section +12{FIXME} for the details regarding the choice of the hash function. + +For convenience, the synopsis of the encoding method is given below +with significant simplifications attributable to the restricted choice +of hash functions in this document. However, [](#SP800-56A) is the +normative source of the definition. + + // Implements KDF( X, oBits, Param ); + // Input: point X = (x,y) + // oBits - the desired size of output + // hBits - the size of output of hash function Hash + // Param - octets representing the parameters + // Assumes that oBits <= hBits + // Convert the point X to the octet string, see section 6{FIXME}: + // ZB' = 04 || x || y + // and extract the x portion from ZB' + ZB = x; + MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param ); + return oBits leftmost bits of MB. + +Note that ZB in the KDF description above is the compact +representation of X, defined in Section 4.2 of [](#RFC6090). + +## EC DH Algorithm (ECDH) + +The method is a combination of an ECC Diffie-Hellman method to +establish a shared secret, a key derivation method to process the +shared secret into a derived key, and a key wrapping method that uses +the derived key to protect a session key used to encrypt a message. + +The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [](#SP800-56A) +MUST be implemented with the following restrictions: the ECC CDH +primitive employed by this method is modified to always assume the +cofactor as 1, the KDF specified in Section 7 is used, and the KDF +parameters specified below are used. + +The KDF parameters are encoded as a concatenation of the following 5 +variable-length and fixed-length fields, compatible with the +definition of the OtherInfo bitstring [](#SP800-56A): + + - a variable-length field containing a curve OID, formatted as + follows: + + + a one-octet size of the following field + + + the octets representing a curve OID, defined in Section 11 + + - a one-octet public key algorithm ID defined in Section 5 + + - a variable-length field containing KDF parameters, identical to + the corresponding field in the ECDH public key, formatted as + follows: + + + a one-octet size of the following fields; values 0 and 0xff + are reserved for future extensions + + + a one-octet value 01, reserved for future extensions + + + a one-octet hash function ID used with the KDF + + + a one-octet algorithm ID for the symmetric algorithm used to + wrap the symmetric key for message encryption; see Section 8 + for details + + - 20 octets representing the UTF-8 encoding of the string + "Anonymous Sender ", which is the octet sequence + 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20 + + - 20 octets representing a recipient encryption subkey or a master + key fingerprint, identifying the key material that is needed for + the decryption. + +The size of the KDF parameters sequence, defined above, is either 54 +for the NIST curve P-256 or 51 for the curves P-384 and P-521. + +The key wrapping method is described in [](#RFC3394). KDF produces a +symmetric key that is used as a key-encryption key (KEK) as specified +in [](#RFC3394). Refer to Section 13{FIXME} for the details regarding the +choice of the KEK algorithm, which SHOULD be one of three AES +algorithms. Key wrapping and unwrapping is performed with the default +initial value of [](#RFC3394). + +The input to the key wrapping method is the value "m" derived from the +session key, as described in Section 5.1{FIXME}, "Public-Key +Encrypted Session Key Packets (Tag 1)", except that the PKCS #1.5 +padding step is omitted. The result is padded using the method +described in [](#PKCS5) to the 8-byte granularity. For example, the +following AES-256 session key, in which 32 octets are denoted from k0 +to k31, is composed to form the following 40 octet sequence: + + 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 + +The octets c0 and c1 above denote the checksum. This encoding allows +the sender to obfuscate the size of the symmetric encryption key used +to encrypt the data. For example, assuming that an AES algorithm is +used for the session key, the sender MAY use 21, 13, and 5 bytes of +padding for AES-128, AES-192, and AES-256, respectively, to provide +the same number of octets, 40 total, as an input to the key wrapping +method. + +The output of the method consists of two fields. The first field is +the MPI containing the ephemeral key used to establish the shared +secret. The second field is composed of the following two fields: + + - a one-octet encoding the size in octets of the result of the key + wrapping method; the value 255 is reserved for future extensions; + + - up to 254 octets representing the result of the key wrapping + method, applied to the 8-byte padded session key, as described + above. + +Note that for session key sizes 128, 192, and 256 bits, the size of +the result of the key wrapping method is, respectively, 32, 40, and 48 +octets, unless the size obfuscation is used. + +For convenience, the synopsis of the encoding method is given below; +however, this section, [](#SP800-56A), and [](#RFC3394) are the +normative sources of the definition. + + Obtain the authenticated recipient public key R + Generate an ephemeral key pair {v, V=vG} + Compute the shared point S = vR; + m = symm_alg_ID || session key || checksum || pkcs5_padding; + curve_OID_len = (byte)len(curve_OID); + Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 + || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous + Sender " || recipient_fingerprint; + Z_len = the key size for the KEK_alg_ID used with AESKeyWrap + Compute Z = KDF( S, Z_len, Param ); + Compute C = AESKeyWrap( Z, m ) as per [RFC3394] + VB = convert point V to the octet string + Output (MPI(VB) || len(C) || C). + +The decryption is the inverse of the method given. Note that the +recipient obtains the shared secret by calculating + + S = rV = rvG, where (r,R) is the recipient's key pair. + +Consistent with Section 5.13{FIXME}, "Sym. Encrypted Integrity +Protected Data Packet (Tag 18)", a Modification Detection Code (MDC) +MUST be used anytime the symmetric key is protected by ECDH. + + # {13} Notes on Algorithms ## {13.1} PKCS\#1 Encoding in OpenPGP @@ -3449,9 +3735,8 @@ ## {13.8} Reserved Algorithm Numbers algorithm. These are marked in Section 9.1, "Public-Key Algorithms", as "reserved for". -The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19), -and X9.42 (21), do not have the necessary parameters, parameter order, -or semantics defined. +The reserved public-key algorithm X9.42 (21) does not have the +necessary parameters, parameter order, or semantics defined. Previous versions of OpenPGP permitted Elgamal [](#ELGAMAL) signatures with a public-key identifier of 20. These are no longer permitted. An @@ -3636,7 +3921,7 @@ # {14} Security Considerations taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. While consensus about the strength of a given algorithm may evolve, NIST Special - Publication 800-57 [SP800-57] recommends the following list of + Publication 800-57 [](#SP800-57) recommends the following list of equivalent strengths: Asymmetric | Hash | Symmetric @@ -3750,6 +4035,156 @@ # {14} Security Considerations data is decrypted. There are many cases in cryptographic engineering where the implementer must use care and wisdom, and this is one. + - Refer to [](#FIPS186-3), B.4.1, for the method to generate a + uniformly distributed ECC private key. + + - The curves proposed in this document correspond to the symmetric + key sizes 128 bits, 192 bits, and 256 bits, as described in the + table below. This allows a compliant application to offer + balanced public key security, which is compatible with the + symmetric key strength for each AES algorithm defined here. + + The following table defines the hash and the symmetric encryption + algorithm that SHOULD be used with a given curve for ECDSA or ECDH. + A stronger hash algorithm or a symmetric key algorithm MAY be used + for a given ECC curve. However, note that the increase in the + strength of the hash algorithm or the symmetric key algorithm may + not increase the overall security offered by the given ECC key. + + Curve name | ECC | RSA | Hash size | Symmetric + | strength | strength, | | key size + | | informative | | + -----------+----------+-------------+-----------+----------- + NIST P-256 256 3072 256 128 + NIST P-384 384 7680 384 192 + NIST P-521 521 15360 512 256 + + Requirement levels indicated elsewhere in this document lead to the + following combinations of algorithms in the OpenPGP profile: MUST + implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement + NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve + P-384 / SHA2-384 / AES-256, among other allowed combinations. + + Consistent with the table above, the following table defines the KDF + hash algorithm and the AES KEK encryption algorithm that SHOULD be + used with a given curve for ECDH. A stronger KDF hash algorithm or + AES KEK algorithm MAY be used for a given ECC curve. + + Curve name | Recommended KDF | Recommended KEK + | hash algorithm | encryption algorithm + -----------+-----------------+----------------------- + NIST P-256 SHA2-256 AES-128 + NIST P-384 SHA2-384 AES-192 + NIST P-521 SHA2-512 AES-256 + + This document explicitly discourages the use of algorithms other + than AES as a KEK algorithm because backward compatibility of the + ECDH format is not a concern. The KEK algorithm is only used within + the scope of a Public-Key Encrypted Session Key Packet, which + represents an ECDH key recipient of a message. Compare this with + the algorithm used for the session key of the message, which MAY be + different from a KEK algorithm. + + Compliant applications SHOULD implement, advertise through key + preferences, and use the strongest algorithms specified in this + document. + + Note that the symmetric algorithm preference list may make it + impossible to use the balanced strength of symmetric key algorithms + for a corresponding public key. For example, the presence of the + symmetric key algorithm IDs and their order in the key preference + list affects the algorithm choices available to the encoding side, + which in turn may make the adherence to the table above infeasible. + Therefore, compliance with this specification is a concern + throughout the life of the key, starting immediately after the key + generation when the key preferences are first added to a key. It is + generally advisable to position a symmetric algorithm ID of strength + matching the public key at the head of the key preference list. + + Encryption to multiple recipients often results in an unordered + intersection subset. For example, if the first recipient's set is + {A, B} and the second's is {B, A}, the intersection is an unordered + set of two algorithms, A and B. In this case, a compliant + application SHOULD choose the stronger encryption algorithm. + + Resource constraints, such as limited computational power, is a + likely reason why an application might prefer to use the weakest + algorithm. On the other side of the spectrum are applications that + can implement every algorithm defined in this document. Most + applications are expected to fall into either of two categories. A + compliant application in the second, or strongest, category SHOULD + prefer AES-256 to AES-192. + + SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method. + + MDC MUST be used when a symmetric encryption key is protected by + ECDH. None of the ECC methods described in this document are + allowed with deprecated V3 keys. A compliant application MUST only + use iterated and salted S2K to protect private keys, as defined in + Section 3.7.1.3{FIXME}, "Iterated and Salted S2K". + + Side channel attacks are a concern when a compliant application's + use of the OpenPGP format can be modeled by a decryption or signing + oracle model, for example, when an application is a network service + performing decryption to unauthenticated remote users. ECC scalar + multiplication operations used in ECDSA and ECDH are vulnerable to + side channel attacks. Countermeasures can often be taken at the + higher protocol level, such as limiting the number of allowed + failures or time-blinding of the operations associated with each + network interface. Mitigations at the scalar multiplication level + seek to eliminate any measurable distinction between the ECC point + addition and doubling operations. + + +# Compatibility Profiles + +## OpenPGP ECC Profile + +A compliant application MUST implement NIST curve P-256, MAY implement +NIST curve P-384, and SHOULD implement NIST curve P-521, as defined in +Section 11. A compliant application MUST implement SHA2-256 and +SHOULD implement SHA2-384 and SHA2-512. A compliant application MUST +implement AES-128 and SHOULD implement AES-256. + +A compliant application SHOULD follow Section 13{FIXME} regarding the +choice of the following algorithms for each curve: + + - the KDF hash algorithm, + - the KEK algorithm, + - the message digest algorithm and the hash algorithm used in the + key certifications, + - the symmetric algorithm used for message encryption. + +It is recommended that the chosen symmetric algorithm for message +encryption be no less secure than the KEK algorithm. + +## Suite-B Profile + +A subset of algorithms allowed by this document can be used to achieve +[](#SuiteB) compatibility. The references to [](#SuiteB) in this +document are informative. This document is primarily concerned with +format specification, leaving additional security restrictions +unspecified, such as matching the assigned security level of +information to authorized recipients or interoperability concerns +arising from fewer allowed algorithms in [](#SuiteB) than allowed by +this document. + +## Security Strength at 192 Bits + +To achieve the security strength of 192 bits, [](#SuiteB) requires +NIST curve P-384, AES-256, and SHA2-384. The symmetric algorithm +restriction means that the algorithm of KEK used for key wrapping in +Section 8 and an OpenPGP session key used for message encryption must +be AES-256. The hash algorithm restriction means that the hash +algorithms of KDF and the OpenPGP message digest calculation must be +SHA-384. + +## Security Strength at 128 Bits + +The set of algorithms in Section 12.2.1{FIXME} is extended to allow NIST +curve P-256, AES-128, and SHA2-256. + + # {15} Implementation Nits This section is a collection of comments to help an implementer, -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri May 29 12:56: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 B97571A6FFC for ; Fri, 29 May 2015 12:56: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 5iH9S-BOp4j4 for ; Fri, 29 May 2015 12:56:40 -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 A5C891A1AFB for ; Fri, 29 May 2015 12:56:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4C6A6E2035 for ; Fri, 29 May 2015 15:56:38 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24255-07 for ; Fri, 29 May 2015 15:56:32 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id DAB7EE2038; Fri, 29 May 2015 15:56:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1432929392; bh=1IS8ePWLgY2WA1+T9vad+jfX0MkwIsG7aB2LJpJSNkY=; h=In-Reply-To:References:Date:Subject:From:To; b=RfXFgmNZj8YeAkt71lHvIfqwYIqnG/QcPZhJNhfODr09yIV61+7uACMLfCT9RW7Z3 nRuw+ZytDMJ3Ds0euhuRpuixq+1Wcncw1avQxUOEu5vNhQnR02wkGF7FW9oyNWw5ah EDYO47A1H1PlQOFh/Mgi0QengQzbB70QpNkY/2nM= Received: from 66.171.169.34 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 29 May 2015 15:56:32 -0400 Message-ID: <6d0cc6fe1608c255600640dd5b95f2d9.squirrel@mail2.ihtfp.org> In-Reply-To: <87k2vrw4sc.fsf@vigenere.g10code.de> References: <87k2vrw4sc.fsf@vigenere.g10code.de> Date: Fri, 29 May 2015 15:56:32 -0400 From: "Derek Atkins" To: openpgp@ietf.org 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: Subject: Re: [openpgp] rfc4880bis: Merged RFC-5581 and RFC-6637 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 19:56:44 -0000 I notice you did not add the text for Ed25519? Is that for a future update? -derek On Fri, May 29, 2015 3:40 pm, Werner Koch wrote: > Hi, > > I merged the Camellia and the ECC For OpenPGP RFCs into 4880bis. See > > > > Below is a diff of the major changes related to RFC-6637. I merged most > stuff except for parts which IMHO do not make sense: For example IANA > consideration to assign the algos and text explaining why ECC is a good > idea. > > I am not sure whether the "Compatibility Profile" should go into 4880bis. > But it has been in 6637 and thus we should keep it for now. > > > Shalom-Salam, > > Werner > > > ---------- > rfc4880bis: Merge with RFC-6637 (ECC for OpenPGP) > > This patch adds the new algorithm numbers for ECDH and ECDSA and marks > them as MUST implement. The bulk of RFC-6637 is added to the new > sections Elliptic Curve Cryptography and Compatibility Profiles. The > remaining stuff goes into the Security Considerations. > > diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd > index 9ea7326..80c0a61 100644 > --- a/misc/id/rfc4880bis/middle.mkd > +++ b/misc/id/rfc4880bis/middle.mkd > @@ -10,7 +10,8 @@ # {1} Introduction > Message Format", which itself replaces RFC 1991, "PGP Message Exchange > Formats" [](#RFC1991) [](#RFC2440). > > -This document obsoletes: RFC 5581 (Camellia cipher). > +This document obsoletes: RFC 5581 (Camellia cipher) and RFC 6637 (ECC > +for OpenPGP) > > > ## {1.1} Terms > @@ -635,6 +636,13 @@ ## {5.1} Public-Key Encrypted Session Key Packets > (Tag 1) > > - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. > > + Algorithm-Specific Fields for ECDH encryption: > + > + - MPI of an EC point representing an ephemeral public key. > + > + - a one-octet size, followed by a symmetric key encoded using the > + method described in [](#ec-dh-algorithm-ecdh). > + > The value "m" in the above formulas is derived from the session key as > follows. First, the session key is prefixed with a one-octet algorithm > identifier that specifies the symmetric encryption algorithm used to > @@ -830,11 +838,11 @@ ### {5.2.2} Version 3 Signature Packet Format > > * Multiprecision integer (MPI) of RSA signature value m**d mod n. > > - Algorithm-Specific Fields for DSA signatures: > + Algorithm-Specific Fields for DSA and ECDSA signatures: > > - * MPI of DSA value r. > + * MPI of DSA or ECDSA value r. > > - * MPI of DSA value s. > + * MPI of DSA or ECDSA value s. > > The signature calculation is based on a hash of the signed data, as > described above. The details of the calculation are different for DSA > @@ -1798,6 +1806,49 @@ ### {5.5.2} Public-Key Packet Formats > > - MPI of Elgamal public key value y (= g**x mod p where x is > secret). > > + Algorithm-Specific Fields for ECDSA keys: > + > + - a variable-length field containing a curve OID, formatted > + as follows: > + > + - a one-octet size of the following field; values 0 and > + 0xFF are reserved for future extensions, > + > + - the octets representing a curve OID, defined in > + section 11{FIXME}; > + > + - a MPI of an EC point representing a public key. > + > + Algorithm-Specific Fields for ECDH keys: > + > + - a variable-length field containing a curve OID, formatted > + as follows: > + > + - a one-octet size of the following field; values 0 and > + 0xFF are reserved for future extensions, > + > + - the octets representing a curve OID, defined in > + Section 11{FIXME}; > + > + - a MPI of an EC point representing a public key; > + > + - a variable-length field containing KDF parameters, > + formatted as follows: > + > + - a one-octet size of the following fields; values 0 > + and 0xff are reserved for future extensions; > + > + - a one-octet value 1, reserved for future extensions; > + > + - a one-octet hash function ID used with a KDF; > + > + - a one-octet algorithm ID for the symmetric algorithm > + used to wrap the symmetric key used for the message > + encryption; see Section 8 for details. > + > +Observe that an ECDH public key is composed of the same sequence of > +fields that define an ECDSA key, plus the KDF parameters field. > + > ### {5.5.3} Secret-Key Packet Formats > > The Secret-Key and Secret-Subkey packets contain all the data of the > @@ -1856,6 +1907,12 @@ ### {5.5.3} Secret-Key Packet Formats > > - MPI of Elgamal secret exponent x. > > + Algorithm-Specific Fields for ECDH or ECDSA secret keys: > + > + - MPI of an integer representing the secret key, which is a > + scalar of the public EC point. > + > + > Secret MPI values can be encrypted using a passphrase. If a string- > to-key specifier is given, that describes the algorithm for converting > the passphrase to a key, else a simple MD5 hash of the passphrase is > @@ -2693,20 +2750,54 @@ ## {9.1} Public-Key Algorithms > 3 RSA Sign-Only [](#HAC) > 16 Elgamal (Encrypt-Only) [](#ELGAMAL) [](#HAC) > 17 DSA (Digital Signature Algorithm) [](#FIPS186) [](#HAC) > - 18 Reserved for Elliptic Curve > - 19 Reserved for ECDSA > + 18 ECDH public key algorithm > + 19 ECDSA public key algorithm [](#FIPS186-3) > 20 Reserved (formerly Elgamal Encrypt or Sign) > 21 Reserved for Diffie-Hellman > (X9.42, as defined for IETF-S/MIME) > 100--110 Private/Experimental algorithm > > -Implementations MUST implement DSA for signatures, and Elgamal for > +Implementations MUST implement DSA and ECDSA for signatures, and > +Elgamal and ECDH for > encryption. Implementations SHOULD implement RSA keys (1). RSA > Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be > -generated, but may be interpreted. See Section 13.5. See Section 13.8 > -for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or Sign > -(20), and X9.42 (21). Implementations MAY implement any other > -algorithm. > +generated, but may be interpreted. See Section 13.5. > +See Section 13.8 for notes Elgamal Encrypt or Sign (20), and X9.42 (21). > +Implementations MAY implement any other algorithm. > + > +A compatible specification of ECDSA is given in [](#RFC6090) as "KT-I > +Signatures" and in [](#SEC1); ECDH is defined in > [](#ec-dh-algorithm-ecdh) > +this document. > + > +## ECC Curve OID > + > +The parameter curve OID is an array of octets that define a named > +curve. The table below specifies the exact sequence of bytes for each > +named curve referenced in this document: > + > + ------------ --- ----------------------- ------------- > + ASN.1 Object OID Curve OID bytes in Curve name in > + Identifier len hexadecimal [FIPS186-3] > + representation > + ------------ --- ----------------------- ------------- > + 1.2.840.10045.3.1.7 8 2A 86 48 CE 3D 03 01 07 NIST curve P-256 > + > + 1.3.132.0.34 5 2B 81 04 00 22 NIST curve P-384 > + > + 1.3.132.0.35 5 2B 81 04 00 23 NIST curve P-521 > + ------------------------------------------------------------------ > + > +The sequence of octets in the third column is the result of applying > +the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier > +with subsequent truncation. The truncation removes the two fields of > +encoded Object Identifier. The first omitted field is one octet > +representing the Object Identifier tag, and the second omitted field > +is the length of the Object Identifier body. For example, the > +complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A > +86 48 CE 3D 03 01 07", from which the first entry in the table above > +is constructed by omitting the first two octets. Only the truncated > +sequence of octets is the valid representation of a curve OID. > + > > ## {9.2} Symmetric-Key Algorithms > > @@ -3186,6 +3277,201 @@ ## {12.2} Key IDs and Fingerprints > same way as for a primary key, including the 0x99 as the first octet > (even though this is not a valid packet ID for a public subkey). > > +# Elliptic Curve Cryptography > + > +This section descripes algorithms and parameters used with Elliptic > +Curve Cryptography (ECC) keys. A thorough introduction to ECC can be > +found in [](#KOBLITZ). > + > +## Supported ECC Curves > + > +This document references three named prime field curves, defined in > +[](#FIPS186-3) as "Curve P-256", "Curve P-384", and "Curve P-521". > + > +The named curves are referenced as a sequence of bytes in this > +document, called throughout, curve OID. [](#ecc-curve-oid) describes > +in detail how this sequence of bytes is formed. > + > +## ECC Conversion Primitives > + > +This document only defines the uncompressed point format. The point > +is encoded in the Multiprecision Integer (MPI) format. The > +content of the MPI is the following: > + > + B = 04 || x || y > + > +where x and y are coordinates of the point P = (x, y), each encoded in > +the big-endian format and zero-padded to the adjusted underlying field > +size. The adjusted underlying field size is the underlying field size > +that is rounded up to the nearest 8-bit boundary. > + > +Therefore, the exact size of the MPI payload is 515 bits for "Curve > +P-256", 771 for "Curve P-384", and 1059 for "Curve P-521". > + > +Even though the zero point, also called the point at infinity, may > +occur as a result of arithmetic operations on points of an elliptic > +curve, it SHALL NOT appear in data structures defined in this > +document. > + > +This encoding is compatible with the definition given in [](#SEC1). > + > +If other conversion methods are defined in the future, a compliant > +application MUST NOT use a new format when in doubt that any recipient > +can support it. Consider, for example, that while both the public key > +and the per-recipient ECDH data structure, respectively defined in > +Sections 9{FIXME} and 10{FIXME}, contain an encoded point field, the > +format changes to the field in Section 10{FIXME} only affect a given > +recipient of a given message. > + > +## Key Derivation Function > + > +A key derivation function (KDF) is necessary to implement the EC > +encryption. The Concatenation Key Derivation Function (Approved > +Alternative 1) [](#SP800-56A) with the KDF hash function that is > +SHA2-256 [](#FIPS180-3) or stronger is REQUIRED. See Section > +12{FIXME} for the details regarding the choice of the hash function. > + > +For convenience, the synopsis of the encoding method is given below > +with significant simplifications attributable to the restricted choice > +of hash functions in this document. However, [](#SP800-56A) is the > +normative source of the definition. > + > + // Implements KDF( X, oBits, Param ); > + // Input: point X = (x,y) > + // oBits - the desired size of output > + // hBits - the size of output of hash function Hash > + // Param - octets representing the parameters > + // Assumes that oBits <= hBits > + // Convert the point X to the octet string, see section 6{FIXME}: > + // ZB' = 04 || x || y > + // and extract the x portion from ZB' > + ZB = x; > + MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param ); > + return oBits leftmost bits of MB. > + > +Note that ZB in the KDF description above is the compact > +representation of X, defined in Section 4.2 of [](#RFC6090). > + > +## EC DH Algorithm (ECDH) > + > +The method is a combination of an ECC Diffie-Hellman method to > +establish a shared secret, a key derivation method to process the > +shared secret into a derived key, and a key wrapping method that uses > +the derived key to protect a session key used to encrypt a message. > + > +The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [](#SP800-56A) > +MUST be implemented with the following restrictions: the ECC CDH > +primitive employed by this method is modified to always assume the > +cofactor as 1, the KDF specified in Section 7 is used, and the KDF > +parameters specified below are used. > + > +The KDF parameters are encoded as a concatenation of the following 5 > +variable-length and fixed-length fields, compatible with the > +definition of the OtherInfo bitstring [](#SP800-56A): > + > + - a variable-length field containing a curve OID, formatted as > + follows: > + > + + a one-octet size of the following field > + > + + the octets representing a curve OID, defined in Section 11 > + > + - a one-octet public key algorithm ID defined in Section 5 > + > + - a variable-length field containing KDF parameters, identical to > + the corresponding field in the ECDH public key, formatted as > + follows: > + > + + a one-octet size of the following fields; values 0 and 0xff > + are reserved for future extensions > + > + + a one-octet value 01, reserved for future extensions > + > + + a one-octet hash function ID used with the KDF > + > + + a one-octet algorithm ID for the symmetric algorithm used to > + wrap the symmetric key for message encryption; see Section 8 > + for details > + > + - 20 octets representing the UTF-8 encoding of the string > + "Anonymous Sender ", which is the octet sequence > + 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20 > + > + - 20 octets representing a recipient encryption subkey or a master > + key fingerprint, identifying the key material that is needed for > + the decryption. > + > +The size of the KDF parameters sequence, defined above, is either 54 > +for the NIST curve P-256 or 51 for the curves P-384 and P-521. > + > +The key wrapping method is described in [](#RFC3394). KDF produces a > +symmetric key that is used as a key-encryption key (KEK) as specified > +in [](#RFC3394). Refer to Section 13{FIXME} for the details regarding > the > +choice of the KEK algorithm, which SHOULD be one of three AES > +algorithms. Key wrapping and unwrapping is performed with the default > +initial value of [](#RFC3394). > + > +The input to the key wrapping method is the value "m" derived from the > +session key, as described in Section 5.1{FIXME}, "Public-Key > +Encrypted Session Key Packets (Tag 1)", except that the PKCS #1.5 > +padding step is omitted. The result is padded using the method > +described in [](#PKCS5) to the 8-byte granularity. For example, the > +following AES-256 session key, in which 32 octets are denoted from k0 > +to k31, is composed to form the following 40 octet sequence: > + > + 09 k0 k1 ... k31 c0 c1 05 05 05 05 05 > + > +The octets c0 and c1 above denote the checksum. This encoding allows > +the sender to obfuscate the size of the symmetric encryption key used > +to encrypt the data. For example, assuming that an AES algorithm is > +used for the session key, the sender MAY use 21, 13, and 5 bytes of > +padding for AES-128, AES-192, and AES-256, respectively, to provide > +the same number of octets, 40 total, as an input to the key wrapping > +method. > + > +The output of the method consists of two fields. The first field is > +the MPI containing the ephemeral key used to establish the shared > +secret. The second field is composed of the following two fields: > + > + - a one-octet encoding the size in octets of the result of the key > + wrapping method; the value 255 is reserved for future extensions; > + > + - up to 254 octets representing the result of the key wrapping > + method, applied to the 8-byte padded session key, as described > + above. > + > +Note that for session key sizes 128, 192, and 256 bits, the size of > +the result of the key wrapping method is, respectively, 32, 40, and 48 > +octets, unless the size obfuscation is used. > + > +For convenience, the synopsis of the encoding method is given below; > +however, this section, [](#SP800-56A), and [](#RFC3394) are the > +normative sources of the definition. > + > + Obtain the authenticated recipient public key R > + Generate an ephemeral key pair {v, V=vG} > + Compute the shared point S = vR; > + m = symm_alg_ID || session key || checksum || pkcs5_padding; > + curve_OID_len = (byte)len(curve_OID); > + Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 > + || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous > + Sender " || recipient_fingerprint; > + Z_len = the key size for the KEK_alg_ID used with AESKeyWrap > + Compute Z = KDF( S, Z_len, Param ); > + Compute C = AESKeyWrap( Z, m ) as per [RFC3394] > + VB = convert point V to the octet string > + Output (MPI(VB) || len(C) || C). > + > +The decryption is the inverse of the method given. Note that the > +recipient obtains the shared secret by calculating > + > + S = rV = rvG, where (r,R) is the recipient's key pair. > + > +Consistent with Section 5.13{FIXME}, "Sym. Encrypted Integrity > +Protected Data Packet (Tag 18)", a Modification Detection Code (MDC) > +MUST be used anytime the symmetric key is protected by ECDH. > + > + > # {13} Notes on Algorithms > > ## {13.1} PKCS\#1 Encoding in OpenPGP > @@ -3449,9 +3735,8 @@ ## {13.8} Reserved Algorithm Numbers > algorithm. These are marked in Section 9.1, "Public-Key Algorithms", > as "reserved for". > > -The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19), > -and X9.42 (21), do not have the necessary parameters, parameter order, > -or semantics defined. > +The reserved public-key algorithm X9.42 (21) does not have the > +necessary parameters, parameter order, or semantics defined. > > Previous versions of OpenPGP permitted Elgamal [](#ELGAMAL) signatures > with a public-key identifier of 20. These are no longer permitted. An > @@ -3636,7 +3921,7 @@ # {14} Security Considerations > taken that the weakest element of an OpenPGP message is still > sufficiently strong for the purpose at hand. While consensus about > the strength of a given algorithm may evolve, NIST Special > - Publication 800-57 [SP800-57] recommends the following list of > + Publication 800-57 [](#SP800-57) recommends the following list of > equivalent strengths: > > Asymmetric | Hash | Symmetric > @@ -3750,6 +4035,156 @@ # {14} Security Considerations > data is decrypted. There are many cases in cryptographic engineering > where the implementer must use care and wisdom, and this is one. > > + - Refer to [](#FIPS186-3), B.4.1, for the method to generate a > + uniformly distributed ECC private key. > + > + - The curves proposed in this document correspond to the symmetric > + key sizes 128 bits, 192 bits, and 256 bits, as described in the > + table below. This allows a compliant application to offer > + balanced public key security, which is compatible with the > + symmetric key strength for each AES algorithm defined here. > + > + The following table defines the hash and the symmetric encryption > + algorithm that SHOULD be used with a given curve for ECDSA or ECDH. > + A stronger hash algorithm or a symmetric key algorithm MAY be used > + for a given ECC curve. However, note that the increase in the > + strength of the hash algorithm or the symmetric key algorithm may > + not increase the overall security offered by the given ECC key. > + > + Curve name | ECC | RSA | Hash size | Symmetric > + | strength | strength, | | key size > + | | informative | | > + -----------+----------+-------------+-----------+----------- > + NIST P-256 256 3072 256 128 > + NIST P-384 384 7680 384 192 > + NIST P-521 521 15360 512 256 > + > + Requirement levels indicated elsewhere in this document lead to the > + following combinations of algorithms in the OpenPGP profile: MUST > + implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement > + NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve > + P-384 / SHA2-384 / AES-256, among other allowed combinations. > + > + Consistent with the table above, the following table defines the KDF > + hash algorithm and the AES KEK encryption algorithm that SHOULD be > + used with a given curve for ECDH. A stronger KDF hash algorithm or > + AES KEK algorithm MAY be used for a given ECC curve. > + > + Curve name | Recommended KDF | Recommended KEK > + | hash algorithm | encryption algorithm > + -----------+-----------------+----------------------- > + NIST P-256 SHA2-256 AES-128 > + NIST P-384 SHA2-384 AES-192 > + NIST P-521 SHA2-512 AES-256 > + > + This document explicitly discourages the use of algorithms other > + than AES as a KEK algorithm because backward compatibility of the > + ECDH format is not a concern. The KEK algorithm is only used within > + the scope of a Public-Key Encrypted Session Key Packet, which > + represents an ECDH key recipient of a message. Compare this with > + the algorithm used for the session key of the message, which MAY be > + different from a KEK algorithm. > + > + Compliant applications SHOULD implement, advertise through key > + preferences, and use the strongest algorithms specified in this > + document. > + > + Note that the symmetric algorithm preference list may make it > + impossible to use the balanced strength of symmetric key algorithms > + for a corresponding public key. For example, the presence of the > + symmetric key algorithm IDs and their order in the key preference > + list affects the algorithm choices available to the encoding side, > + which in turn may make the adherence to the table above infeasible. > + Therefore, compliance with this specification is a concern > + throughout the life of the key, starting immediately after the key > + generation when the key preferences are first added to a key. It is > + generally advisable to position a symmetric algorithm ID of strength > + matching the public key at the head of the key preference list. > + > + Encryption to multiple recipients often results in an unordered > + intersection subset. For example, if the first recipient's set is > + {A, B} and the second's is {B, A}, the intersection is an unordered > + set of two algorithms, A and B. In this case, a compliant > + application SHOULD choose the stronger encryption algorithm. > + > + Resource constraints, such as limited computational power, is a > + likely reason why an application might prefer to use the weakest > + algorithm. On the other side of the spectrum are applications that > + can implement every algorithm defined in this document. Most > + applications are expected to fall into either of two categories. A > + compliant application in the second, or strongest, category SHOULD > + prefer AES-256 to AES-192. > + > + SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method. > + > + MDC MUST be used when a symmetric encryption key is protected by > + ECDH. None of the ECC methods described in this document are > + allowed with deprecated V3 keys. A compliant application MUST only > + use iterated and salted S2K to protect private keys, as defined in > + Section 3.7.1.3{FIXME}, "Iterated and Salted S2K". > + > + Side channel attacks are a concern when a compliant application's > + use of the OpenPGP format can be modeled by a decryption or signing > + oracle model, for example, when an application is a network service > + performing decryption to unauthenticated remote users. ECC scalar > + multiplication operations used in ECDSA and ECDH are vulnerable to > + side channel attacks. Countermeasures can often be taken at the > + higher protocol level, such as limiting the number of allowed > + failures or time-blinding of the operations associated with each > + network interface. Mitigations at the scalar multiplication level > + seek to eliminate any measurable distinction between the ECC point > + addition and doubling operations. > + > + > +# Compatibility Profiles > + > +## OpenPGP ECC Profile > + > +A compliant application MUST implement NIST curve P-256, MAY implement > +NIST curve P-384, and SHOULD implement NIST curve P-521, as defined in > +Section 11. A compliant application MUST implement SHA2-256 and > +SHOULD implement SHA2-384 and SHA2-512. A compliant application MUST > +implement AES-128 and SHOULD implement AES-256. > + > +A compliant application SHOULD follow Section 13{FIXME} regarding the > +choice of the following algorithms for each curve: > + > + - the KDF hash algorithm, > + - the KEK algorithm, > + - the message digest algorithm and the hash algorithm used in the > + key certifications, > + - the symmetric algorithm used for message encryption. > + > +It is recommended that the chosen symmetric algorithm for message > +encryption be no less secure than the KEK algorithm. > + > +## Suite-B Profile > + > +A subset of algorithms allowed by this document can be used to achieve > +[](#SuiteB) compatibility. The references to [](#SuiteB) in this > +document are informative. This document is primarily concerned with > +format specification, leaving additional security restrictions > +unspecified, such as matching the assigned security level of > +information to authorized recipients or interoperability concerns > +arising from fewer allowed algorithms in [](#SuiteB) than allowed by > +this document. > + > +## Security Strength at 192 Bits > + > +To achieve the security strength of 192 bits, [](#SuiteB) requires > +NIST curve P-384, AES-256, and SHA2-384. The symmetric algorithm > +restriction means that the algorithm of KEK used for key wrapping in > +Section 8 and an OpenPGP session key used for message encryption must > +be AES-256. The hash algorithm restriction means that the hash > +algorithms of KDF and the OpenPGP message digest calculation must be > +SHA-384. > + > +## Security Strength at 128 Bits > + > +The set of algorithms in Section 12.2.1{FIXME} is extended to allow NIST > +curve P-256, AES-128, and SHA2-256. > + > + > # {15} Implementation Nits > > This section is a collection of comments to help an implementer, > > > > > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > 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 May 29 13:26: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 861D61A8836 for ; Fri, 29 May 2015 13:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbHDUcVvY8id for ; Fri, 29 May 2015 13:26:11 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403311A8780 for ; Fri, 29 May 2015 13:26:11 -0700 (PDT) Received: by labko7 with SMTP id ko7so60513750lab.2 for ; Fri, 29 May 2015 13:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fHa6SYvN+EKXI3KZ82pOUMkvuDPQLyz59fouSfg9ICM=; b=rrUDDmdGH9hCNDqjf/Ectvo7Yn0n/WVCLHjvK+ceZjyIUuMhwcZuvF1uIHVVxCTRev bXNsFCyqUHIP4pR5+9fs4nhAz4dETLgXYqWeXLCeU7ceauIRM0wz9f5CTSBfBEKqWooh k7saEBxMNTM83693Pg2CIGq5SB3dtP8BcJIf5dpICMn+0+jmW95yW1UTMimxsYer3dlb HnIrTwqfsMWYLOu0OzzSqeyYThuu8K0oxLjCJZSNZ1dHA/vY/pBu2y3u4vwOXPaFUozD amQf+zS/SkzV1ZiIRHomTgVRnb8kZtSDGHbGgO5d08IY/y8RaNrzQWEAWeE9+7zIyres 1yLA== MIME-Version: 1.0 X-Received: by 10.112.126.42 with SMTP id mv10mr2996969lbb.58.1432931169750; Fri, 29 May 2015 13:26:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 29 May 2015 13:26:09 -0700 (PDT) In-Reply-To: <6d0cc6fe1608c255600640dd5b95f2d9.squirrel@mail2.ihtfp.org> References: <87k2vrw4sc.fsf@vigenere.g10code.de> <6d0cc6fe1608c255600640dd5b95f2d9.squirrel@mail2.ihtfp.org> Date: Fri, 29 May 2015 16:26:09 -0400 X-Google-Sender-Auth: M_AfJK2z_8Ak5BwhvPdqAX0gn4c Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=001a11c36bc65c55a905173e49a5 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] rfc4880bis: Merged RFC-5581 and RFC-6637 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 20:26:12 -0000 --001a11c36bc65c55a905173e49a5 Content-Type: text/plain; charset=UTF-8 On Fri, May 29, 2015 at 3:56 PM, Derek Atkins wrote: > I notice you did not add the text for Ed25519? > Is that for a future update? > Please don't do Ed25519 right now. Let the CFRG folk finish first. Otherwise we will end up with two different versions. --001a11c36bc65c55a905173e49a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, May 29, 2015 at 3:56 PM, Derek Atkins <derek@ihtfp.com> wr= ote:
I notice you did not add the text fo= r Ed25519?
Is that for a future update?

Please don= 't do Ed25519 right now.

Let the CFRG folk fin= ish first.

Otherwise we will end up with two diffe= rent versions.=C2=A0
--001a11c36bc65c55a905173e49a5-- From nobody Fri May 29 13:56: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 8B1CA1B2D48 for ; Fri, 29 May 2015 13:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ULB_RLDpYiL for ; Fri, 29 May 2015 13:56:48 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F96D1B2D47 for ; Fri, 29 May 2015 13:56:47 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4TKuRqA012558 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 May 2015 22:56:28 +0200 From: Simon Josefsson To: Phillip Hallam-Baker References: <87k2vrw4sc.fsf@vigenere.g10code.de> <6d0cc6fe1608c255600640dd5b95f2d9.squirrel@mail2.ihtfp.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150529:openpgp@ietf.org::JV7SlLhp7ocTXv6L:qiN X-Hashcash: 1:22:150529:derek@ihtfp.com::19NauBUEvxrn3rnS:UEx9 X-Hashcash: 1:22:150529:phill@hallambaker.com::POcNhGeVMX0jqcxW:GtMD Date: Fri, 29 May 2015 22:56:26 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 29 May 2015 16:26:09 -0400") Message-ID: <87382fxfut.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: IETF OpenPGP , Derek Atkins Subject: Re: [openpgp] rfc4880bis: Merged RFC-5581 and RFC-6637 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 20:56:49 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker writes: > On Fri, May 29, 2015 at 3:56 PM, Derek Atkins wrote: > >> I notice you did not add the text for Ed25519? >> Is that for a future update? >> > > Please don't do Ed25519 right now. > > Let the CFRG folk finish first. > > Otherwise we will end up with two different versions. Different versions of what? Ed25519 is well defined and implemented already, as far as I understand. If CFRG recommends something other than Ed25519 (which is possible), that doesn't change that there is already momentum and deployed code for Ed25519 in OpenPGP. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVaNJ6AAoJEIYLf7sy+BGd5rkH/0Aw8r7G1zbrVxbfThlrN6h7 kORl12xjOUvoXXVQLQ1De+zcI6MtudqP+17uFQvMI40GecAJ1Dr/OQq8iquUV7F7 Hi0w7c1qcgWPOD+IGompfFPqFlxFkWrKTv83kXeyFluE3sRuvkCC1gnBdM7ODpWo ZOjT/1IxU5ru6E5rWZIlBwAolG7QuxHCj9gXFFz5lSDVTBjjV8W2SllNlwF5f5Ko qjlEL0n1f0QOnUSMQ3EbZqfEV1gYZJamAB8kQIJzlXgcKrh/tZumwn52mJOdZYn3 Hx9qGcpZm3cLLUlo3Ry6fJ2jd/lxjtOk20EXr42E8FtAs/m9RTzstdEFHIdxlus= =9EMv -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 29 14:04: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 1A1A41B2D5C for ; Fri, 29 May 2015 14:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mol4hsg4yxd for ; Fri, 29 May 2015 14:04:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ABC1B2D63 for ; Fri, 29 May 2015 14:04:38 -0700 (PDT) Received: from SN1PR05CA0036.namprd05.prod.outlook.com (25.163.68.174) by BLUPR05MB708.namprd05.prod.outlook.com (10.141.207.24) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 29 May 2015 21:04:20 +0000 Received: from BL2FFO11FD014.protection.gbl (2a01:111:f400:7c09::169) by SN1PR05CA0036.outlook.office365.com (2a01:111:e400:5197::46) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Fri, 29 May 2015 21:04:20 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=juniper.net; hallambaker.com; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Fri, 29 May 2015 21:04:19 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 29 May 2015 14:04:18 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t4TL4HD20553; Fri, 29 May 2015 14:04:17 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 69F3E11446; Fri, 29 May 2015 14:04:17 -0700 (PDT) To: Phillip Hallam-Baker In-Reply-To: References: <87k2vrw4sc.fsf@vigenere.g10code.de> <6d0cc6fe1608c255600640dd5b95f2d9.squirrel@mail2.ihtfp.org> Comments: In-reply-to: Phillip Hallam-Baker message dated "Fri, 29 May 2015 16:26:09 -0400." From: "Mark D. Baushke" Date: Fri, 29 May 2015 14:04:17 -0700 Message-ID: <14000.1432933457@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD014; 1:LuoLXiSMMNmr0ubfPfnPZGko4zYIvr7wvBjNAt/qs5mpl8/Sr9M9UlOebporPEyI5apx1Xs3QKPiQ2O4aHdyDMK3Uu6kqT14gpqh5mtaBIbG1FBe2VdmHT7jse3zPwfT9TPorKBIkvQGLPd0KGWgqa638DrXTCCqfaOWw1mG0dlkbv3ixs5FJBviIGdJ46f1phMQnN5cXAqoNXlgMIqxtFnm3Sbf27WZ+1iCKF8NhY96hEykpix0q5xvZooTeckvWM4Lv+aKjRt7rAZzK1qJag== X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(189002)(47776003)(81156007)(2950100001)(5001830100001)(77156002)(110136002)(5001960100002)(62966003)(189998001)(69596002)(5001860100001)(19580405001)(97736004)(92566002)(87936001)(64706001)(76176999)(4001540100001)(19580395003)(54356999)(6806004)(106466001)(76506005)(117636001)(53416004)(105596002)(68736005)(77096005)(50466002)(46102003)(50986999)(86362001)(48376002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB708; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB708; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BLUPR05MB708; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB708; X-Forefront-PRVS: 059185FE08 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2015 21:04:19.5172 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16]; Helo=[P-EMF02-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB708 Archived-At: Cc: IETF OpenPGP , Derek Atkins Subject: Re: [openpgp] rfc4880bis: Merged RFC-5581 and RFC-6637 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 21:04:45 -0000 Phillip Hallam-Baker writes: > Please don't do Ed25519 right now. > > Let the CFRG folk finish first. > > Otherwise we will end up with two different versions. +1 It may be desirable to have a family EdDSA of Edwards curves rather than just the Ed25519 entry. Let's wait to see the IEF CFRG finding. -- Mark From nobody Fri May 29 14:07: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 486791A88EC for ; Fri, 29 May 2015 14:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dju2RLkIncqQ for ; Fri, 29 May 2015 14:07:13 -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 475D11A88EB for ; Fri, 29 May 2015 14:07:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0930DBF19; Fri, 29 May 2015 22:07:12 +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 NQ6uOKQR8oM4; Fri, 29 May 2015 22:07:11 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.20.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DDCA4BF03; Fri, 29 May 2015 22:07:10 +0100 (IST) Message-ID: <5568D4FE.8010909@cs.tcd.ie> Date: Fri, 29 May 2015 22:07:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Derek Atkins References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> <87fv6gy5xy.fsf@vigenere.g10code.de> <55675DCB.2090302@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Wyllys Ingersoll , "openpgp@ietf.org" Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 29 May 2015 21:07:14 -0000 On 29/05/15 16:38, Derek Atkins wrote: > There is already an I-D on Ed25519. Because it has a different form > than the NIST curves it requires a different parameter. Is the > intention to include that by value in RFC4880bis? (I'm certainly not > opposed to the answer being "yes" -- I just want us to be clear that > we're going to do that too in addition to 6637). I hope we hold off a wee bit there - CFRG are just now discussing signature scheme issues and they might or might not land on precisely Ed25519. But so long as we recognise there might be a non-interoperable change then we're fine. S. From nobody Sat May 30 03:07: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 726B01A1B61 for ; Sat, 30 May 2015 03:07:06 -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 QYUnRP9jfeG6 for ; Sat, 30 May 2015 03:07:02 -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 AAC461A1B5A for ; Sat, 30 May 2015 03:07:02 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YydfR-0007gR-3X for ; Sat, 30 May 2015 12:07:01 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YyddP-0006K4-NR; Sat, 30 May 2015 12:04:55 +0200 From: Werner Koch To: "Derek Atkins" References: <87k2vrw4sc.fsf@vigenere.g10code.de> <6d0cc6fe1608c255600640dd5b95f2d9.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" , openpgp@ietf.org Date: Sat, 30 May 2015 12:04:55 +0200 In-Reply-To: <6d0cc6fe1608c255600640dd5b95f2d9.squirrel@mail2.ihtfp.org> (Derek Atkins's message of "Fri, 29 May 2015 15:56:32 -0400") Message-ID: <877frqwfco.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] rfc4880bis: Merged RFC-5581 and RFC-6637 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 30 May 2015 10:07:06 -0000 On Fri, 29 May 2015 21:56, derek@ihtfp.com said: > I notice you did not add the text for Ed25519? It is not an RFC thus it can't be added without discussion. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat May 30 03:07: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 BE9881A1B5A for ; Sat, 30 May 2015 03:07:06 -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 WScTeW36U6lD for ; Sat, 30 May 2015 03:07:04 -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 ADD531A1B5F for ; Sat, 30 May 2015 03:07:02 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YydfR-0007gN-0P for ; Sat, 30 May 2015 12:07:01 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1YydcT-0006Jg-Au; Sat, 30 May 2015 12:03:57 +0200 From: Werner Koch To: Derek Atkins References: <87iobodgwi.fsf@vigenere.g10code.de> <87pp5m1hxq.fsf@vigenere.g10code.de> <87fv6gy5xy.fsf@vigenere.g10code.de> <55675DCB.2090302@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 Mail-Followup-To: Derek Atkins , Stephen Farrell , Wyllys Ingersoll , "openpgp\@ietf.org" Date: Sat, 30 May 2015 12:03:56 +0200 In-Reply-To: (Derek Atkins's message of "Fri, 29 May 2015 11:38:55 -0400") Message-ID: <87bnh2wfeb.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" , Wyllys Ingersoll , Stephen Farrell Subject: Re: [openpgp] rfc4880bis basics X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 30 May 2015 10:07:06 -0000 On Fri, 29 May 2015 17:38, derek@ihtfp.com said: > There is already an I-D on Ed25519. Because it has a different form > than the NIST curves it requires a different parameter. Is the Well, the I-D is on EdDSA which is a different signature algorithm than ECDSA. This is the reason why we need another public key algorithm identifier. Although Ed25519 is currently the only defined curve for use with EdDSA we should keep algorithms and curves separate. > intention to include that by value in RFC4880bis? (I'm certainly not > opposed to the answer being "yes" -- I just want us to be clear that Obviously I would vote with yes, but it is not an issue right now. There are other things on out TODO list which I consider easier to decide and more important. For example a new "Issuer Fingerprint" signature subpacket to be used in favor of the "Issuer" signature subpacket (5.2.3.5). Even now, without having settled for a new fingerprint format we could already start defining that subpacket: It's length would be a sufficient indication on whether this is the old or new fingerprint format (I don't expect a new fingerprint format will stay at 20 octets). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat May 30 03:12: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 A05AC1A1B61 for ; Sat, 30 May 2015 03:12:04 -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 DC_BXF3ZPea6 for ; Sat, 30 May 2015 03:12:03 -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 16BA51A1B5A for ; Sat, 30 May 2015 03:12:03 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1YydkH-0007i0-IB for ; Sat, 30 May 2015 12:12:01 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yydi2-0006LM-KO; Sat, 30 May 2015 12:09:42 +0200 From: Werner Koch To: "Mark D. Baushke" References: <87k2vrw4sc.fsf@vigenere.g10code.de> <6d0cc6fe1608c255600640dd5b95f2d9.squirrel@mail2.ihtfp.org> <14000.1432933457@eng-mail01.juniper.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: "Mark D. Baushke" , Phillip Hallam-Baker , IETF OpenPGP , Derek Atkins Date: Sat, 30 May 2015 12:09:42 +0200 In-Reply-To: <14000.1432933457@eng-mail01.juniper.net> (Mark D. Baushke's message of "Fri, 29 May 2015 14:04:17 -0700") Message-ID: <87382ewf4p.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 , Derek Atkins , IETF OpenPGP Subject: Re: [openpgp] rfc4880bis: Merged RFC-5581 and RFC-6637 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 30 May 2015 10:12:04 -0000 On Fri, 29 May 2015 23:04, mdb@juniper.net said: > It may be desirable to have a family EdDSA of Edwards curves rather than > just the Ed25519 entry. Let's wait to see the IEF CFRG finding. My I-D already does this: draft-koch-eddsa-for-openpgp-02.txt: This document specifies how to use the EdDSA public key signature algorithm [ED25519] with the OpenPGP standard. It defines a new signature algorithm named EdDSA and specifies how to use the Ed25519 curve with EdDSA. This algorithm uses a custom point compression method. There are three main advantages of the EdDSA algorithm: It does not require the use of a unique random number for each signature, there are no padding or truncation issues as with ECDSA, and it is more resilient to side-channel attacks. It might be useful to replace the reference id [ED25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. Yang, "High-speed high-security signatures", Journal of Cryptographic Engineering Volume 2, Issue 2, pp. 77-89, September 2011, . to [EDDSA] for clarity. And we should push for Simon's EDDSA draft to become an RFC. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat May 30 20:28:23 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E641ACE0A for ; Sat, 30 May 2015 20:28:21 -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 3arvS9FVE-Wt for ; Sat, 30 May 2015 20:28:20 -0700 (PDT) Received: from smtp5.emailarray.com (smtp5.emailarray.com [65.39.216.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C7B1ACE03 for ; Sat, 30 May 2015 20:28:19 -0700 (PDT) Received: (qmail 90235 invoked by uid 89); 31 May 2015 03:28:18 -0000 Received: from unknown (HELO ?204.29.149.93?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp5.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 May 2015 03:28:18 -0000 From: "Christopher LILJENSTOLPE" To: "IETF OpenPGP" Date: Sat, 30 May 2015 20:28:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_9F73F590-D53A-4A36-8F81-3024D5CF823E_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.1r5084) X-PolarisMail-Flags: Archived-At: Cc: sec-ads@tools.ietf.org, Daniel Kahn Gillmor Subject: [openpgp] Proposed WG charter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 31 May 2015 03:28:22 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_9F73F590-D53A-4A36-8F81-3024D5CF823E_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, Here's a first cut of the charter. We'd like to get this process start= ed ASAP, so please make any comments, suggestions as soon as possible. It's also available as a gist https://gist.github.com/liljenstolpe/a4a45= 477d1b89ea45e09 Christopher An Open Specification for Pretty Good Privacy (openpgp) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Charter ------- Chairs: Christopher Liljenstolpe Daniel Kahn Gillmor Security Area Directors: Stephen Farrell Kathleen Moriarty Security Area Advisor: Stephen Farrell Mailing Lists: To Subscribe: https://www.ietf.org/mailman/listinfo/openpgp Archive: http://www.ietf.org/mail-archive/web/openpgp/ Description of Working Group ---------------------------- OpenPGP is an Internet standard that covers object encryption, object signing, and identity certification. These were defined by the first incarnation of the OpenPGP working group. The following is an excerpt from the charter of the original incarnation of the openpgp working group > The goal of the OpenPGP working group is to provide IETF standards > for the algorithms and formats of PGP processed objects as well as > providing the MIME framework for exchanging them via e-mail or other > transport protocols. The working group concluded this work and was closed in March of 2008. In the intervening period, there has been a rough consensus reached that the RFC that defined the IETF openpgp standard, RFC4880, is in need of revision. This incarnation of the working group is chartered to primarily produce a revision of RFC4880 to address issues that have been identified by the community since the working group was originally closed. The Working Group will perform the following work ------------------------------------------------- Revise RFC4880 Other work may be entertained by the working group as long as it does not interfere with the completion of the RFC4880 revision. As the revision of RFC4880 is primary goal of the working group, and other work will also not unduly delay the closure of the working group after the revision is finished (unless the working group is rechartered). Working Group Process --------------------- The working group will endeavor to complete most if not all of its work online on the working group's mailing list. We expect that the requirement for face-to-face sessions at IETF meetings to be minimal. Furthermore, the working group will accept no ID's as working group items unless there is a review by at least two un-interested parties of the ID as part of the acceptance process. Goals and Milestones -------------------- July 2016: Deliver an RFC 4880bis WG ID to the RFC editor -- = =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe --=_MailMate_9F73F590-D53A-4A36-8F81-3024D5CF823E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVan/SAAoJEGmx2Mt/+Iw/ykMIAIMrX3xFQRSrG63k+w4NCJs6 T1h9u48kpBxyf4BZA8qqk/5BUCFmlnkLykDHT7Aa+5PnH8yptzQWyRpXZIOOqkZP dYu5wlkUXvyg9771jhTYm+6AxwxwauIcnPCADokV9bIdcpW72u0MxjeUYSYB+me8 Yec5DNQvdyj0Ts5pIA+dyO8maoCiCMcGJGiKSROJeLsru5cifkY5d2KLSgplHFJd o01vajebZL148+4SiuMw7aQmLjnMt9zIrk8vRSWp9WsdiDAoxSTB5AWA/ZeAavhd lGUqBg1nK5LUA3vK4Xf6jzcE62X3E4tB6yQzWBjiq/WTZPmdUkHT6+l/cksn1mY= =je56 -----END PGP SIGNATURE----- --=_MailMate_9F73F590-D53A-4A36-8F81-3024D5CF823E_=-- From nobody Sun May 31 03:00: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 A4EE41A0015 for ; Sun, 31 May 2015 03:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Cc1R_2F_YZJQ for ; Sun, 31 May 2015 03:00:31 -0700 (PDT) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by ietfa.amsl.com (Postfix) with ESMTP id E4E7C1A0006 for ; Sun, 31 May 2015 03:00:30 -0700 (PDT) Received: from straylight.m.ringlet.net (unknown [91.211.191.230]) by nimbus.fccf.net (Postfix) with ESMTPSA id DF63E3C1 for ; Sun, 31 May 2015 13:00:27 +0300 (EEST) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 25401b6 by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Sun, 31 May 2015 13:00:26 +0300 Date: Sun, 31 May 2015 13:00:26 +0300 From: Peter Pentchev To: Christopher LILJENSTOLPE Message-ID: <20150531100026.GA3191@straylight.m.ringlet.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IETF OpenPGP , sec-ads@tools.ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Proposed WG charter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 31 May 2015 10:00:33 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 30, 2015 at 08:28:18PM -0700, Christopher LILJENSTOLPE wrote: > Greetings, >=20 > Here's a first cut of the charter. We'd like to get this process > started ASAP, so please make any comments, suggestions as soon as > possible. [snip] >=20 > The Working Group will perform the following work > ------------------------------------------------- >=20 > Revise RFC4880 >=20 > Other work may be entertained by the working group as long as it does > not interfere with the completion of the RFC4880 revision. As the > revision of RFC4880 is primary goal of the working group, and other > work... Just a very, very minor comment: is this supposed to be "any other work" instead of "and"? > ...will also not unduly delay the closure of the working group > after the revision is finished (unless the working group is > rechartered). G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVatutAAoJEGUe77AlJ98TAT4QAL1L2SC0Ugv5O2bPED6MIeEG ZpyDI0wF03llpBzqG9BYvZuWGVa6jqGdijG5dariBy+uJvfdObWx4OMWKmczStRB SxWOTWuxmujH1EbAqbfAzsmAGqmeFlmmN0Ok9TUQmcbIcx0I5GHrOkMtYYlY6Os4 BVOq7lj4Rz/rsQ2RsOBfg4HEYecps+/HFabULwhysxbJGBlzUy2qCnqQU4s1bDc4 R74H1owgVti/Nig45aB/G9uF07L1bEfIdHh2ww+tsfnqT0DEJtl8ITJFYD1uWDNs S5/89dYc1ggrzTbodWhl99XZT5DxzyglNzfSPxRgUo+dmZTkMdSYC8pZnQfowH7U d2eaoUwfWlz9Y+OQ4e44Wb3movP1oAwI17xFxPS5HxWNdUHJST4y4YSvepi+yQx0 D+M8VRbM+JLRba6y7sNPhAOXLudB0ZIMu3D1AQS1p38sJyMrTOGCvPgFaVDGaobQ 4ubgWrsvbGhEwuJnhwbmesuWf6x41PT414UtivO21Hw0/XOMK5c3Z1wNTv+36t/+ 4aZrriYk2ncYhZpfOj7kiq3LEGtHqL7ZzT6Qt18Jt7bzQU0DoLqR8AyKhLRM4T3b CeUsA6EhoMVHmag7D/G932Oz1RTClfM+QxdS+JRr6yxNfjSYDEQ7kdSZuw4zp98u rcYysAU63QcxaYgS9BNX =wt/2 -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From nobody Sun May 31 11:37: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 299731A883F for ; Sun, 31 May 2015 11:37:05 -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 bmm9RAUmfvg9 for ; Sun, 31 May 2015 11:37:03 -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 62B8F1A883E for ; Sun, 31 May 2015 11:37:03 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Yz86X-00065n-G6 for ; Sun, 31 May 2015 20:37:01 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1Yz83z-0003Fa-8k; Sun, 31 May 2015 20:34:23 +0200 From: Werner Koch To: "Christopher LILJENSTOLPE" 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: "Christopher LILJENSTOLPE" , "IETF OpenPGP" , sec-ads@tools.ietf.org, Daniel Kahn Gillmor Date: Sun, 31 May 2015 20:34:23 +0200 In-Reply-To: (Christopher LILJENSTOLPE's message of "Sat, 30 May 2015 20:28:18 -0700") Message-ID: <87h9qstx3k.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 , sec-ads@tools.ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Proposed WG charter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 31 May 2015 18:37:05 -0000 On Sun, 31 May 2015 05:28, ietf@cdl.asgaard.org said: > Here's a first cut of the charter. We'd like to get this > process started ASAP, so please make any comments, suggestions > as soon as possible. Fine with me. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.