From nobody Fri Aug 1 10:43:47 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4E1B2883 for ; Fri, 1 Aug 2014 10:43:45 -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 VxnnroBLYf_9 for ; Fri, 1 Aug 2014 10:43:42 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1001A028A for ; Fri, 1 Aug 2014 10:43:42 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so6371804ier.41 for ; Fri, 01 Aug 2014 10:43:41 -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=WqWTtFQMgPghp1zaNI0qf+p6ZtmdiYqeQ8i80OSDaq4=; b=Ri9O71VEGkpVsjWQeIaMxuUSIj7h6UhCg+AIp/939g8GnWc3iq/W6NDw3sL6jxp9bm qGYKqw9VDaCKu8R23qiyo3MzvcAX8dklhvuGWfKoHGrwdJIgWb0EvXm6lvQrvGERk2GW okF4FgMqz0pedNrczgCoCjTelf4KMxGhLIrXvFcYpbrGgz+veoSDSP60Z3ILh0W4THKJ 4AbdYu7XfDxapCtIXEU7bghWG5lppoZ+HrjeEm/HzxmjKGY/gAA1tUiFW7InuqWpl5PD fhVXwTp82OQeZrK+y0gXgfinqd5DrbOPRWuA/mpAkWlGITLHxKBOEbZZcgbgeWKG988e /P+g== X-Received: by 10.42.23.16 with SMTP id q16mr9477183icb.0.1406915021523; Fri, 01 Aug 2014 10:43:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.225 with HTTP; Fri, 1 Aug 2014 10:43:21 -0700 (PDT) From: David Leon Gil Date: Fri, 1 Aug 2014 13:43:21 -0400 Message-ID: To: openpgp@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/vDS1CMcQj5da6JCpr7dpz9XPrVA Subject: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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 Aug 2014 17:43:45 -0000 A quick note re exportable public keys. Apparently the SKS keyservers will accept(?) ECDH or ELG-E primary public keys: See, e.g., http://pool.sks-keyservers.net/pks/lookup?op=get&search=0x13A7A60EF2AC27BC or http://pool.sks-keyservers.net/pks/lookup?op=get&search=0xE7E4C6E20CF902B7 (But there are only 6 examples of these in total... Does anyone know what software can use them?) This seems like a sensible deviation from the RFC to me; the benefits of signing an ECDH or ELG-E key intended solely for (somewhat) deniable encryption are minimal. - David From nobody Mon Aug 4 02:56:33 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D029F1B2998 for ; Mon, 4 Aug 2014 02:56:31 -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 KnED8Seva4lD for ; Mon, 4 Aug 2014 02:56:29 -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 984A21B2948 for ; Mon, 4 Aug 2014 02:56:29 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XEF0F-0001jd-Fm for ; Mon, 04 Aug 2014 11:56:27 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XEEuT-0000Fo-6c; Mon, 04 Aug 2014 11:50:29 +0200 From: Werner Koch To: David Leon Gil References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 04 Aug 2014 11:50:29 +0200 In-Reply-To: (David Leon Gil's message of "Fri, 1 Aug 2014 13:43:21 -0400") Message-ID: <87mwbkh9cq.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: http://mailarchive.ietf.org/arch/msg/openpgp/AUmjUe6W6k3OAGg3OVBfYp6VbpY Cc: openpgp@ietf.org Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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 Aug 2014 09:56:32 -0000 On Fri, 1 Aug 2014 19:43, coruus@gmail.com said: > (But there are only 6 examples of these in total... Does anyone know > what software can use them?) No software can use those keys becuase they are not capabable of signing. They are rejected ("no user Id" because the self-signature does not check out). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ibobbitt@custodes.info Mon Aug 4 10:06:52 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CB11A0045 for ; Mon, 4 Aug 2014 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 F3nxQub-s2_B for ; Mon, 4 Aug 2014 10:06:47 -0700 (PDT) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326621A0030 for ; Mon, 4 Aug 2014 10:06:47 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 79so4270931ykr.22 for ; Mon, 04 Aug 2014 10:06:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=sJP18WiQ6lz68VRp9YZTOKhSvTmc+vHy5cCF7usU9RQ=; b=PTaHMuVmhFPycBaBNW8XTUd/PnqxszzTMz7aOwkQnBcml58SPc78LtAussEKg7Aw7V Nb6HKMO435DsXO+JeCjRcVj5SFIDv360qofjqNkoCzAg9MnztfBcoyXM2gj3c4f7Y8Dz ix+35DRciVJGSqaoclIPGrWiIpntdJme2t6OTRokASNwy81d8w9PQrRxz2Zt6Rho3vfC mZvJWjYj9rEOmtmpdJZ47akEHLaentkQsksPELdyjqDq3516qwq/kg4oPx5ikZJNH91m tzL6esaTowyEy0yGFeeTlTbh5pWA/I9fBUEcJAP6IRSygDBT7NkOG/utG4Xn1ijv9sXM IveQ== X-Gm-Message-State: ALoCoQmgjzLyVL4G4s3P+VJBlkTMvGDAvIWFUAbDQdGXyQNvC3yicH/WxfKXYdk9TgUrCXEBDg7W MIME-Version: 1.0 X-Received: by 10.236.111.2 with SMTP id v2mr41202962yhg.39.1407172006424; Mon, 04 Aug 2014 10:06:46 -0700 (PDT) Sender: ibobbitt@custodes.info Received: by 10.170.132.133 with HTTP; Mon, 4 Aug 2014 10:06:46 -0700 (PDT) In-Reply-To: <87mwbkh9cq.fsf@vigenere.g10code.de> References: <87mwbkh9cq.fsf@vigenere.g10code.de> Date: Mon, 4 Aug 2014 13:06:46 -0400 X-Google-Sender-Auth: 0Feec3xc00UPcd20VMcbdcj0ye8 Message-ID: From: Ian Bobbitt To: openpgp@ietf.org Content-Type: multipart/alternative; boundary=001a1133469894cea404ffd0c365 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/ga3RNx05Gkmma3c5L_2z8ZrsqcY Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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 Aug 2014 17:08:28 -0000 --001a1133469894cea404ffd0c365 Content-Type: text/plain; charset=UTF-8 I'm not so sure I would say "no software" can use them. They're odd in that they're a bare Public-Key Packet, but that doesn't mean they're unusable. For example, the first example is a secp256r1 public key for ECDH with point 54913208749856979301715917236679182042233113041563426424642991739197245983353452579573506780881803740193710199307901035821397170740305648420195074480633099 and SHA256 and 128 bit AES for KDF, as described in RFC6637. There may exist software that is using the OpenPGP format for exchanging keys without generating what most software would expect. On Mon, Aug 4, 2014 at 5:50 AM, Werner Koch wrote: > On Fri, 1 Aug 2014 19:43, coruus@gmail.com said: > > > (But there are only 6 examples of these in total... Does anyone know > > what software can use them?) > > No software can use those keys becuase they are not capabable of > signing. They are rejected ("no user Id" because the self-signature > does not check out). > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1133469894cea404ffd0c365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not so sure I would say "no software" can use them. The= y're odd in that they're a bare Public-Key Packet, but that doesn&#= 39;t mean they're unusable.

For ex= ample, the first example is a=C2=A0secp256r1 public key for ECDH with point=C2=A0549132087498569793017159172366791820422331130415634264246429917391= 972459833534525795735067808818037401937101993079010358213971707403056484201= 95074480633099 and=C2=A0SHA256 and 128 bit=C2=A0AES for KDF,=C2=A0as describe= d in RFC6637.

There may exist software that is using the= OpenPGP format for exchanging keys without generating what most software w= ould expect.


On Mon,= Aug 4, 2014 at 5:50 AM, Werner Koch <wk@gnupg.org> wrote:
On Fri, =C2=A01 Aug 2014 19:43, coruus@gmail.com said:

> (But there are only 6 examples of these in total... Does anyone know > what software can use them?)

No software can use those keys becuase they are not capabable of
signing. =C2=A0They are rejected ("no user Id" because the self-s= ignature
does not check out).


Shalom-Salam,

=C2=A0 =C2=A0Werner


--
Die Gedanken sind frei. =C2=A0Ausnahmen regelt ein Bundesgesetz.

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

--001a1133469894cea404ffd0c365-- From nobody Mon Aug 4 13:06:33 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC401A01E7 for ; Mon, 4 Aug 2014 13:06:31 -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 koS1hO3n_-Z8 for ; Mon, 4 Aug 2014 13:06:29 -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 8E4A11A01C8 for ; Mon, 4 Aug 2014 13:06:29 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XEOWa-0001d3-02 for ; Mon, 04 Aug 2014 22:06:28 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XEOUS-0001mH-J2; Mon, 04 Aug 2014 22:04:16 +0200 From: Werner Koch To: Ian Bobbitt References: <87mwbkh9cq.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=1E42B367; url=finger:wk@g10code.com Date: Mon, 04 Aug 2014 22:04:16 +0200 In-Reply-To: (Ian Bobbitt's message of "Mon, 4 Aug 2014 13:06:46 -0400") Message-ID: <87zjfkdnsv.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: http://mailarchive.ietf.org/arch/msg/openpgp/lfTC-bPvWpGnbo4r-WyNonwaV3M Cc: openpgp@ietf.org Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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 Aug 2014 20:06:32 -0000 On Mon, 4 Aug 2014 19:06, ian@icb.im said: > I'm not so sure I would say "no software" can use them. They're odd in that > they're a bare Public-Key Packet, but that doesn't mean they're unusable. I won't call that an OpenPGP packet. It is not OpenPGP compatible: RFC4880, 12.1 Key Structures: In a V4 key, the primary key MUST be a key capable of certification. along with 5.5.2 Public-Key Packet Formats: OpenPGP implementations MUST create keys with version 4 format. V3 keys are deprecated; an implementation MUST NOT generate a V3 key, but MAY accept it. v3 keys have severe weaknesses for example they rely on MD5. ECDH is not capabale of signing/certifying. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Aug 6 15:34:03 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339D11A0336 for ; Wed, 6 Aug 2014 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewtV6qGpdXAD for ; Wed, 6 Aug 2014 15:34:00 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541EC1A0037 for ; Wed, 6 Aug 2014 15:34:00 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rl12so3578014iec.24 for ; Wed, 06 Aug 2014 15:33:59 -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=WCprpZR3FcsiyHpsEXiZ4GoN6UlIj5o3w576uqmyIu8=; b=a0cSe87JDWpt30zcUnyjGMQ3iSBS7mP3o9SBaPGhobOsqXzdd61DYGjrZRbAnGLpmN 0+cFTocd5bj0e5anXZfRCJsadAwXlOXse9m/kaAIxr2ikPnAfM6SDgizWvIc1bxcb9Vl FBQW+TNY9EjxVZ0PMQVdc/Hvw3N4LvgHEfQZ2k9inHOTRZRP61UmMbFk60uGSZsznDy+ FlnBExVHeejByj/G0oPxX+IcZnoLBRxXlXOhCm8ENPvWMz+FIauWUM0ds9tC5KfGSZ30 +0kn81lE1KzL7Gy53aEYdi6bbzF7CqSTii9tUdEQdTP/AoP8zeF3KJY8FlDsDrlPr2Fx t3lA== MIME-Version: 1.0 X-Received: by 10.42.23.16 with SMTP id q16mr19792992icb.0.1407364439666; Wed, 06 Aug 2014 15:33:59 -0700 (PDT) Received: by 10.107.130.225 with HTTP; Wed, 6 Aug 2014 15:33:59 -0700 (PDT) Date: Wed, 6 Aug 2014 18:33:59 -0400 Message-ID: From: David Leon Gil To: openpgp@ietf.org, Werner Koch Content-Type: multipart/alternative; boundary=20cf301cbf387ef5c804fffd917f Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/TW5fhQaH3i-idiKp-AdaQD0a-38 Subject: [openpgp] Making keysteak from 0xdeadbeef X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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 Aug 2014 22:34:02 -0000 --20cf301cbf387ef5c804fffd917f Content-Type: text/plain; charset=UTF-8 > From: Werner Koch > To: David Shaw > Cc: IETF OpenPGP Working Group > Date: Fri, 18 Feb 2011 09:22:40 +0100 > In-reply-to: > (David Shaw's message of "Thu, 17 Feb 2011 14:12:20 -0500") > References: > On Thu, 17 Feb 2011 20:12, dshaw at jabberwocky.com said: > > Disabling v3 import and an option to enable such imports seems to be > justified and is easy to implement. > Any progress on this? I thought that part of the recent keyserver filter patch set was supposed to prevent this when retrieving keys from keyservers, generally. Thought I'd note on this list, for the record, that I have a proof-of-concept keyserver-in-the-middle that 0xdeadbeefs on demand for testing against: https://github.com/coruus/cooperpair/tree/master/keysteak Seems to still work on latest released GnuPG. -dlg --20cf301cbf387ef5c804fffd917f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From: Werner Koch <wk at gnupg.org>
To: Dav= id Shaw <dshaw at j= abberwocky.com>
Cc: IETF OpenPGP Working Group <ietf-openpgp at imc.org>
Date: Fri, 18 Feb 2011 = 09:22:40 +0100
In-reply-to: <D8E81788-AF18-448F-BA39-56185C1F0= 672 at jabberwocky.com= > (David Shaw's message of "Thu, 17 Feb 2011 14:12:20 -0500= ")
References: <D8E81788-AF18-448F-BA39-56185C1F0672 at jabberwocky.com>
On= Thu, 17 Feb 2011 20:12, dshaw at jabberwocky.com said:
=C2=A0
Disabling= v3 import and an option to enable such imports seems to be
justi= fied and is easy to implement.

Any progress on this?=C2=A0

=
I thought that part of the recent keyserver filter patch set was= supposed to prevent this when retrieving keys from keyservers,=C2=A0genera= lly.

Thought=C2=A0I'd note on this list, for the record,= =C2=A0that I have=C2=A0a proof-of-concept keyserver-in-the-middle that 0xde= adbeefs on demand for testing against:

https://github.com/coruus/cooperpair/tree/master/= keysteak


Seems to sti= ll work on latest released GnuPG.


-dlg

--20cf301cbf387ef5c804fffd917f-- From nobody Sun Aug 10 12:16:47 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8618E1A073E for ; Sun, 10 Aug 2014 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.75 X-Spam-Level: *** X-Spam-Status: No, score=3.75 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 3JCHNloK4YSC for ; Sun, 10 Aug 2014 10:57:55 -0700 (PDT) Received: from smtp1.goneo.de (smtp1.goneo.de [85.220.129.30]) (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 D0FC01A06B2 for ; Sun, 10 Aug 2014 10:57:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp1.goneo.de (Postfix) with ESMTP id 0B62C23F1AC for ; Sun, 10 Aug 2014 19:57:51 +0200 (CEST) X-Virus-Scanned: by goneo Received: from smtp1.goneo.de ([127.0.0.1]) by localhost (smtp1.goneo.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6HQFDhRagvb for ; Sun, 10 Aug 2014 19:57:50 +0200 (CEST) Received: from [192.168.178.32] (aftr-88-217-180-159.dynamic.mnet-online.de [88.217.180.159]) by smtp1.goneo.de (Postfix) with ESMTPSA id 1DBDB23F1A0 for ; Sun, 10 Aug 2014 19:57:49 +0200 (CEST) Message-ID: <1407693468.1416.36.camel@chstpc-2.fritz.box> From: Christian Stadelmann To: openpgp@ietf.org Date: Sun, 10 Aug 2014 19:57:48 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-3.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/wexilsAY1U1AQ4Ja7164eLhpJeE X-Mailman-Approved-At: Sun, 10 Aug 2014 12:16:45 -0700 Subject: [openpgp] =?utf-8?q?SHA-2_support_should_be_mandatory_=E2=80=93_c?= =?utf-8?q?hange_defaults?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 10 Aug 2014 17:57:56 -0000 Hi Disclaimer: I'm not much familiar with the RFC process I recently found that many mails encrypted by Enigmail/GnuPG are using SHA-1 as hashing algorithm. So I asked the Enigmail guys to use SHA-2 instead [1]. They said no arguing not to change any GnuPG defaults. The GnuPG guys don't want to set SHA-2 as default [2] since RFC4880 [3] only states that SHA-1 must be implemented. Since SHA-2 support is not mandatory they won't make it default. There are several known attacks against SHA-1 reducing its effective security (without breaking it). Since SHA-2 is widely deployed for about 10 years I think it is time to move on and make SHA-2 default. I don't know whether any plans are around to specify a Revision 2 of the OpenPGP standard but if they are, this should be part of it. Are there any chances to change it? And if there are such changes would it be possible to make these changes too: 1. Add SHA-3 support 2. Make AES-256 the default (mandatory) symmetric-key algorithm instead of TripleDES (which is quite weak anyway) 3. Replace DSA as default public-key algorithm (since it relies on good random which is often not available/ensured) by RSA. 4. Algorithm Preferences / RSA: change minimum RSA key size to 2048 There was a related discussion on this some 5 years ago [4]. [1] http://sourceforge.net/p/enigmail/forum/feature_requests/thread/e1810d6b/ [2] https://bugs.g10code.com/gnupg/issue1679 [3] https://tools.ietf.org/html/rfc4880#section-9.4 [4] https://www.ietf.org/mail-archive/web/openpgp/current/msg00239.html Regards Christian Stadelmann From nobody Sun Aug 10 17:40:22 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0991A00A2 for ; Sun, 10 Aug 2014 17:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq7tSy3C9Sq9 for ; Sun, 10 Aug 2014 17:40:17 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33111A0084 for ; Sun, 10 Aug 2014 17:40:17 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id fp1so9793364pdb.19 for ; Sun, 10 Aug 2014 17:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:openpgp :crypto-challenge:crypto-hint:user-agent; bh=aUPXUmKiLdbkIb59wViQW9WmTFLI5zx9YM9MoipZsnQ=; b=VqIiNxxGCJhN/qwfDGWN7/Da7cIgR93zLAgvyCn8HxNJj60V1MtzZLEkhu13u2dSeZ Cmm/cn/OocDW/Xta24hSMIkLfZD5A0vnf6CCmQ/Utxsa4XACVTlK5wtaKl6YF21PpjXh IkDo08jwfvL/rC40RruLZRGogezzXV8y0Fsv+OplzZ6Xlz6TL1Pk7vdlO8IIFn8J8OtQ mmNrRmp+uUdfvYibhBeMIf5q+bsZBHl644N0r6hH8QwJGV2g+F+/s1l2ja+sjWyOvqOL xUEyXUm/yxhex7ivLEYpySpdw8jPnypgQRitVK3ABXhqDJ1fQ0UXWKLiKaQ0EAsZrPXe HrRA== X-Received: by 10.66.184.42 with SMTP id er10mr38530396pac.62.1407717617155; Sun, 10 Aug 2014 17:40:17 -0700 (PDT) Received: from irc.ae7.st (pinyin.ae7.st. [166.70.136.40]) by mx.google.com with ESMTPSA id qb2sm9551750pbb.0.2014.08.10.17.40.15 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 10 Aug 2014 17:40:16 -0700 (PDT) Date: Sun, 10 Aug 2014 18:40:13 -0600 From: Aaron Toponce To: Christian Stadelmann Message-ID: <20140811004012.GN4006@irc.ae7.st> References: <1407693468.1416.36.camel@chstpc-2.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tqN4RWvJTb9VNux/" Content-Disposition: inline In-Reply-To: <1407693468.1416.36.camel@chstpc-2.fritz.box> X-Hashcash: 1:20:140811:chris.privat@genodeftest.de::WKJ6m3EwgiN0FK5z:2L6F X-Hashcash: 1:20:140811:openpgp@ietf.org::kDhj5LsOyCkdjIT/:0KUU X-Hashcash: 1:20:140811:aaron.toponce@gmail.com::Pdq7Oif6RQyimg2U:XCX OpenPGP: id=8086060F; url=http://ae7.st/s/pgp; preference=signencrypt Crypto-Challenge: iVBORw0KGgoAAAANSUhEUgAAAFwAAABcAQMAAADZIUAbAAAABlBMVEX///8A AABVwtN+AAAAS0lEQVQ4jbXSUQoAIAhEwYXuf2NhS1O6QM+EnH4qUfoaK2bBcJysnUUVWY lGput3JGxPD1H00byAQ17r20YW8QaChXr2UHgiUHyNDSRgxkgDsThDAAAAAElFTkSuQmCC Crypto-Hint: image/png User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/p63pbltMftpjIGayGxolXNA71Hs Cc: openpgp@ietf.org Subject: Re: [openpgp] =?utf-8?q?SHA-2_support_should_be_mandatory_=E2=80=93_c?= =?utf-8?q?hange_defaults?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 11 Aug 2014 00:40:19 -0000 --tqN4RWvJTb9VNux/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 10, 2014 at 07:57:48PM +0200, Christian Stadelmann wrote: > There are several known attacks against SHA-1 reducing its effective > security (without breaking it). Since SHA-2 is widely deployed for about > 10 years I think it is time to move on and make SHA-2 default. First off, I'm not a cryptographer, but this is my understanding of what it would take to break SHA-1 on a PGP signature. I'm assuming that the attacks you are referring to are collision attacks, because there is no practical second preimage attack on SHA-1 [1], or even = MD5 for that matter [2]. Second preimage attacks differ from collision attacks subt= ly. In a collision attack, the plaintexts p1 and p2 are not specified, but chosen randomly. With second preimage attacks, plaintext p1 is known, so plaintext= p2 must be found such that hash(p1) =3D=3D hash(p2) [3]. 1. http://stackoverflow.com/a/2774744 2. https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability 3. https://en.wikipedia.org/wiki/Preimage_attack Also, I'm assuming you don't understand how PGP signatures work. With PGP signatures, a plaintext message is first cryptographically hashed, then encrypted with the sender's private key. So to mount a feasible attack on a= PGP signature, you would need to: 1- Produce the exact cryptagraphic hash from a different public key, or 2- Find a hash collision with differing text In the first case, you would be breaking RSA, El Gamal, etc. In the second,= you would be mounting a second preimage attack on the hash function. Both cases= are not practical, or even remotely close to becoming practical in the foreseea= ble future. Finally, even though it's not default, you can change your gpg.conf(5) to u= se a specific hashing algorithm that your signing key supports, such as SHA1, SHA224, SHA256, SHA384, SHA512, RIPEMD160, etc. It's trivial to make the change, and while I don't know about Enigmal specifically, Mutt will honor = the change. I'm guessing that there may be some historical baggage that prevents making SHA-2 or SHA-3 the default for OpenPGP in the near term, such as breaking o= lder PGP userspace implementations. Also, SHA-1 outperforms SHA-2 [4]. I would advocate moving to SHA-3 if performance was a factor, as the authors claim = 12.5 cycles per byte [5], versus 15.8 with SHA-256 and 17.7 with SHA-512 (even though SHA-1 still out performs SHA-3) [4]. 4. http://www.cryptopp.com/benchmarks.html 5. http://keccak.noekeon.org/Keccak-implementation-3.2.pdf Thanks, --=20 =2E o . o . o . . o o . . . o . =2E . o . o o o . o . o o . . o o o o . o . . o o o o . o o o --tqN4RWvJTb9VNux/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: http://ae7.st/s/pgp iQEcBAABCgAGBQJT6BDsAAoJEM55Ebf8BAiPGhIH/AwFy3AlrMNMbzIwxa1UMliF WFZK/1dA4euekAYyd4X4IvB6RcnU9h2+bSMt1r2SS2aWl8hX22G5q3JWPl496wzq 4OzPThx634uAC0yp9aDZR1qKDY+SGpgL3CpBx1TdYLmSyo4flbOwsomTvxjCd3wp ReE3ZLCqaXTPC4efYrFeWkBnINbnFXhrOLGQDJUVZ5YsZ7TWBh8vnCJsvx22/cRm UbbcsV175ED6Uyzntb96qD7o50jWlMD2DEs7VBCf4cScF8hcvV9zqc1kVJhhAnez pRsIUEpTEJPNE1/BazTexWW98Z8Xc6Asw6zKIN0M+zj2YF5HuOtcaFZ00r6z0RQ= =NSyz -----END PGP SIGNATURE----- --tqN4RWvJTb9VNux/-- From nobody Sun Aug 10 21:21:14 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77EF1A02D4 for ; Sun, 10 Aug 2014 21:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgXxpfjW22lR for ; Sun, 10 Aug 2014 21:21:09 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D811A02D0 for ; Sun, 10 Aug 2014 21:21:09 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rd18so9304807iec.28 for ; Sun, 10 Aug 2014 21:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iuheqSIQj3EQ6niuC70aZ4UwWxt2EGeNu2edNunlaEo=; b=iKFPJ81kZahDVh+EynhLqCOxSa7Q00Nxre4eUY8WlNtLf8wXlSAvRoDigUVnEtyvfC XXYHZgFT6HmEm4KyimfHhY/elbHbuxX9GOBRzshjOGMgN95q7Z/vm4dnUrjXqRqEvW+6 E/poxpNPJe+b8Rn8LYS82Mcc98vCXwuopHQ8fF9fZE0o3/ARDKm/ovPt25Ktcqqdc1ME 0cSr654sdsY3hQphFtaBcoMPRcOIiNDUrJiAzfxPSZjQ6D7dD2UWWFTM1XGDVdsYM8Kn na8FUgm8VRH/nxp4KQA1GzwtX5zTtHsbdsvZN5IGcaODCUd7u3T68b9mMukjObKs4/mb Vphg== MIME-Version: 1.0 X-Received: by 10.50.43.167 with SMTP id x7mr26398927igl.36.1407730868665; Sun, 10 Aug 2014 21:21:08 -0700 (PDT) Received: by 10.107.130.225 with HTTP; Sun, 10 Aug 2014 21:21:08 -0700 (PDT) In-Reply-To: <20140811004012.GN4006@irc.ae7.st> References: <1407693468.1416.36.camel@chstpc-2.fritz.box> <20140811004012.GN4006@irc.ae7.st> Date: Mon, 11 Aug 2014 00:21:08 -0400 Message-ID: From: David Leon Gil To: Aaron Toponce Content-Type: multipart/alternative; boundary=089e011602b25dd386050052e228 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/8WiszCFxzvypoyLK1ZbiRaRHANo Cc: Christian Stadelmann , "openpgp@ietf.org" Subject: Re: [openpgp] =?utf-8?q?SHA-2_support_should_be_mandatory_=E2=80=93_c?= =?utf-8?q?hange_defaults?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 11 Aug 2014 04:21:11 -0000 --089e011602b25dd386050052e228 Content-Type: text/plain; charset=UTF-8 On Sunday, August 10, 2014, Aaron Toponce wrote: > On Sun, Aug 10, 2014 at 07:57:48PM +0200, Christian Stadelmann wrote: > > There are several known attacks against SHA-1 reducing its effective > > security (without breaking it). Since SHA-2 is widely deployed for about > > 10 years I think it is time to move on and make SHA-2 default. > Christian is correct (except for the not breaking SHA-1 part). The collision attacks on SHA-1 are serious and are computationally feasible (but still too expensive for academic cryptographers). I'd suggest reading Marc Steven's thesis: https://marc-stevens.nl/research/papers/PhD%20Thesis%20Marc%20Stevens%20-%20Attacks%20on%20Hash%20Functions%20and%20Applications.pdf Note that chosen-prefix collision attacks, in particular, can accomplish almost everything a 2nd preimage attack on a hash can. Again, Stevens provides useful details. Also, I'm assuming you don't understand how PGP signatures work. OpenPGP does not use any signature algorithms which are 'collision-resistant'. So, if the hash algorithm is weak, so are the signatures. For RSA signatures, the situation is even worse; there is no proof that PKCS1v1_5 signatures have any specific security strength against forgery.[*] ECDSA signatures are the only OpenPGP-specified signature algorithm with a good security proof. Google's E2E extension is well-written and generates ECC keys exclusively (but can verify RSA signatures); I recommend it highly. (But it is in beta right now.) even though it's not default, you can change your gpg.conf(5) to use a > specific hashing algorithm In particular, set the following preferences in GnuPG: digest-algo SHA512 cipher-algo AES256 The man page incorrectly warns against using them, and advises that you use the 'personal-' variants instead. These effectively do nothing. If any downstream package maintainers are reading this, email me, and I'll be delighted to open an issue to include a modern gpg.conf skeleton in your package. (I'm presently preparing an annotated version with detailed justifications for various option settings.) I'm guessing that there may be some historical baggage that prevents making > SHA-2 or SHA-3 the default for OpenPGP in the near term, such as breaking > older > PGP userspace implementations. Does *anyone* on this list use an OpenPGP implementation that does not support SHA-2 and AES? (And, if so, can you estimate how many users are in a similar position?) -dlg [*] In particular, even though we can estimate the cost of *factoring* an RSA key, the cost of *forging* a signature may be much lower. This cost may well be lower than the cost of a collision attack on the hash. See, e.g., Coron et al.'s work on ISO 9796-2 signatures, if you aren't clear on the distinction: https://eprint.iacr.org/2009/203.pdf --089e011602b25dd386050052e228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, August 10, 2014, Aaron Toponce <aaron.toponce@gmail.com> wrote:
On Sun, Aug 10, 2014 at 07:57:48PM +0200, Christian Stadelmann wrote:
> There are several known attacks against SHA-1 reducing its effective > security (without breaking it). Since SHA-2 is widely deployed for abo= ut
> 10 years I think it is time to move on and make SHA-2 default.

Christian is correct (except for the not break= ing SHA-1 part).=C2=A0The collision attacks on SHA-1 are=C2=A0serious and= =C2=A0are computationally feasible (but still=C2=A0too expensive for academ= ic cryptographers). I'd suggest reading Marc Steven's thesis:=C2=A0= https= ://marc-stevens.nl/research/papers/PhD%20Thesis%20Marc%20Stevens%20-%20Atta= cks%20on%20Hash%20Functions%20and%20Applications.pdf
=C2=A0
Note that=C2=A0chosen-prefix collision attacks, in pa= rticular, can accomplish almost everything a 2nd preimage attack on a hash= =C2=A0can. Again, Stevens provides useful details.

Also, I'm assuming you don't understand how PGP signatures work.=C2= =A0

OpenPGP does not use any signature algo= rithms which are 'collision-resistant'. So, if the hash algorithm= =C2=A0is weak, so are the signatures.

For RSA signatures, the situation is even worse; there = is no proof that=C2=A0PKCS1v1_5 signatures have any specific security=C2=A0= strength against forgery.[*]=C2=A0

ECDSA signature= s are the only OpenPGP-specified signature=C2=A0algorithm with=C2=A0a good = security proof. Google's=C2=A0E2E extension is well-written and=C2=A0ge= nerates ECC keys exclusively (but can verify RSA signatures); I recommend i= t highly. (But it is in beta right now.)

even though it's no= t default, you can change your gpg.conf(5) to use a
specific hashing algorithm

In particular, s= et the following preferences in GnuPG:=C2=A0

diges= t-algo SHA512
cipher-algo AES256

The man= page incorrectly warns against using them, and advises that you use the &#= 39;personal-' variants instead. These effectively do nothing.

If any=C2=A0downstream=C2=A0package maintainers are rea= ding this,=C2=A0email me, and I'll be delighted=C2=A0to open an issue t= o include=C2=A0a modern gpg.conf skeleton=C2=A0in your=C2=A0package. (I'= ;m presently preparing an annotated version with detailed justifications fo= r various option settings.)

I'm guessing that there may be some historical baggage that prevents ma= king
SHA-2 or SHA-3 the default for OpenPGP in the near term, such as breaking o= lder
PGP userspace implementations.
<= /blockquote>

Does *anyone* on this list use an OpenPGP= =C2=A0implementation that does not support SHA-2 and AES? (And, if so, can = you estimate how many users are in a similar position?)

-dlg

[*]=C2=A0In particular, e= ven though we can estimate the cost of *factoring* an RSA key, the cost of = *forging* a signature may be much lower. This cost may well be lower than t= he cost of a collision attack on the hash.=C2=A0See, e.g.,=C2=A0Coron et al= .'s work on ISO 9796-2 signatures, if you aren't clear on the disti= nction:=C2=A0https://eprin= t.iacr.org/2009/203.pdf
--089e011602b25dd386050052e228-- From nobody Sun Aug 10 23:27:21 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BAE1A0322 for ; Sun, 10 Aug 2014 23:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae3a-cxFkz0K for ; Sun, 10 Aug 2014 23:27:18 -0700 (PDT) Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2001:4f8:3:36:211:85ff:fe63:a549]) by ietfa.amsl.com (Postfix) with ESMTP id CDA821A031B for ; Sun, 10 Aug 2014 23:27:18 -0700 (PDT) Received: from [192.168.1.103] (ip72-219-202-206.dc.dc.cox.net [72.219.202.206]) (Authenticated sender: rjh-sixdemonbag) by shards.monkeyblade.net (Postfix) with ESMTPSA id AB7A15864A2 for ; Sun, 10 Aug 2014 23:27:16 -0700 (PDT) Message-ID: <53E86241.4080608@sixdemonbag.org> Date: Mon, 11 Aug 2014 02:27:13 -0400 From: "Robert J. Hansen" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <1407693468.1416.36.camel@chstpc-2.fritz.box> In-Reply-To: <1407693468.1416.36.camel@chstpc-2.fritz.box> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (shards.monkeyblade.net [149.20.54.216]); Sun, 10 Aug 2014 23:27:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/eRlFETsjNgzh48vglrBIfkcsYNU Subject: Re: [openpgp] =?windows-1252?q?SHA-2_support_should_be_mandatory_=96_?= =?windows-1252?q?change_defaults?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 11 Aug 2014 06:27:19 -0000 > There are several known attacks against SHA-1 reducing its effective > security (without breaking it). The question is whether these attacks reduce SHA-1's effectiveness as it is used in OpenPGP, and if so, to what extent. (My belief is they do, but not to the extent doomsayers fear.) > 2. Make AES-256 the default (mandatory) symmetric-key algorithm > instead of TripleDES (which is quite weak anyway) The best attack on 3DES requires 315 yottabytes (!!) of memory just to reduce it to complexity 2**112. For any reasonable assumption about computing power, 3DES is as solid as a rock and offers an effective key length comparable to more modern ciphers. There are many reasons to dislike 3DES. It's slow, ungainly, hard to implement correctly, has a relatively small block size, and so on... but "quite weak" is not one of them. I would not mind replacing 3DES as the mandatory symmetric cipher, but there needs to be better justification than this. > 3. Replace DSA as default public-key algorithm (since it relies on > good random which is often not available/ensured) by RSA. A good PRNG is required for the overwhelming majority of OpenPGP uses. (I mean, sure, technically you could send everything unencrypted and unsigned in an OpenPGP packet, but...) If you don't have a good PRNG then pretty much the entire protocol falls apart, so I don't understand why it's important to make RSA the default key selection because it's less dependent on having a good PRNG. What am I missing here? I have nothing against making RSA the default, but again, we need better justification. From nobody Mon Aug 11 01:16:37 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DF71A0362 for ; Mon, 11 Aug 2014 01:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z36_C2ZzLfmk for ; Mon, 11 Aug 2014 01:16:33 -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 787191A035F for ; Mon, 11 Aug 2014 01:16:33 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XGkmN-0005eK-PY for ; Mon, 11 Aug 2014 10:16:31 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XGkhj-0007Df-K8; Mon, 11 Aug 2014 10:11:43 +0200 From: Werner Koch To: Christian Stadelmann References: <1407693468.1416.36.camel@chstpc-2.fritz.box> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 11 Aug 2014 10:11:43 +0200 In-Reply-To: <1407693468.1416.36.camel@chstpc-2.fritz.box> (Christian Stadelmann's message of "Sun, 10 Aug 2014 19:57:48 +0200") Message-ID: <87egwnsaww.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: http://mailarchive.ietf.org/arch/msg/openpgp/1cG3K0JrEPtjJzhqTsjowM2YYr8 Cc: openpgp@ietf.org Subject: Re: [openpgp] =?utf-8?q?SHA-2_support_should_be_mandatory_=E2=80=93_c?= =?utf-8?q?hange_defaults?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 11 Aug 2014 08:16:35 -0000 On Sun, 10 Aug 2014 19:57, chris.privat@genodeftest.de said: > 3. Replace DSA as default public-key algorithm (since it relies on good > random which is often not available/ensured) by RSA. You mean the random K value commonly used for signatures? GnuPG has replaced that by the RFC-6979 method. I don't know how other implementations handles this. Anyway, I assume that it is now common understanding that a v5 key format will suggest the use of ECC algorithms using modern curves. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Aug 11 05:37:02 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A458E1A065F for ; Mon, 11 Aug 2014 05:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0zdmwzn_RSG for ; Mon, 11 Aug 2014 05:36:58 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA1F1A0647 for ; Mon, 11 Aug 2014 05:36:58 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so10647664pdb.41 for ; Mon, 11 Aug 2014 05:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:openpgp :crypto-challenge:crypto-hint:user-agent; bh=YJ4PceKH01iiR9qtVlvuUsYiO0L8PyVT8mk1Kr8HU00=; b=suu61vMuIqqtGTL/ow4hb1qqSU4SXX/87/HVPDfnlxlEfRZu1HvLhRVteMCkXHoQO2 4WSDUW3ypOd0nBKX68KCSrAspN8glszRfL+GnfNGnShihZIGHwaadLG8j132v95Y7iD7 4vbvYckKEDpBaMd9Pgd0tN9EM54XtLNqYDz4Niye3zD9Yzt+6kS62Df1XFGBXJyeUz83 UI0vSazyd5yMo9OoCqkmyz9OVWw/b7enLQ4AyGO2Nn0yfqBs8Kgzw8YcRfAU1vTN0Dkf qhbGQHdaYSuRUnUmo/vKaTWWmKN5NvaGSQGPxGeAwHKJg4XN5JwsVivswlq0tjDqzV1o ZhBA== X-Received: by 10.69.20.11 with SMTP id gy11mr41816364pbd.28.1407760618032; Mon, 11 Aug 2014 05:36:58 -0700 (PDT) Received: from irc.ae7.st (pinyin.ae7.st. [166.70.136.40]) by mx.google.com with ESMTPSA id ct1sm17353017pdb.59.2014.08.11.05.36.56 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 11 Aug 2014 05:36:57 -0700 (PDT) Date: Mon, 11 Aug 2014 06:36:54 -0600 From: Aaron Toponce To: openpgp@ietf.org Message-ID: <20140811123652.GP4006@irc.ae7.st> References: <1407693468.1416.36.camel@chstpc-2.fritz.box> <87egwnsaww.fsf@vigenere.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HAv5+T9jbwMPl6Kw" Content-Disposition: inline In-Reply-To: <87egwnsaww.fsf@vigenere.g10code.de> X-Hashcash: 1:20:140811:openpgp@ietf.org::woRhnr0L8Rr9IYA5:ROM X-Hashcash: 1:20:140811:aaron.toponce@gmail.com::ztaLuodkvW4rui5B:2DZ5 OpenPGP: id=8086060F; url=http://ae7.st/s/pgp; preference=signencrypt Crypto-Challenge: iVBORw0KGgoAAAANSUhEUgAAAFwAAABcAQMAAADZIUAbAAAABlBMVEX///8A AABVwtN+AAAAS0lEQVQ4jbXSUQoAIAhEwYXuf2NhS1O6QM+EnH4qUfoaK2bBcJysnUUVWY lGput3JGxPD1H00byAQ17r20YW8QaChXr2UHgiUHyNDSRgxkgDsThDAAAAAElFTkSuQmCC Crypto-Hint: image/png User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/MzjLMekyxpH50-dpGYhfbildIF4 Subject: Re: [openpgp] =?utf-8?q?SHA-2_support_should_be_mandatory_=E2=80=93_c?= =?utf-8?q?hange_defaults?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 11 Aug 2014 12:36:59 -0000 --HAv5+T9jbwMPl6Kw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 11, 2014 at 10:11:43AM +0200, Werner Koch wrote: > On Sun, 10 Aug 2014 19:57, chris.privat@genodeftest.de said: >=20 > > 3. Replace DSA as default public-key algorithm (since it relies on good > > random which is often not available/ensured) by RSA. >=20 > You mean the random K value commonly used for signatures? GnuPG has > replaced that by the RFC-6979 method. I don't know how other > implementations handles this. Just to clarify for those on the list (I'm not sure of the technical competencies of most on the list), RFC 6979 as I understand it specifies a "deterministic DSA". This is calculated by first creating an HMAC_DRBG(k,c) value, where 'k' is a randomly generated key, and 'c' is a counter. Provided the hashing algorithm is cryptographically secure, even though the output is determined, its output is indistinguishable from true random, and it will be uniformly chosen. This output is now the "random k" for DSA that Werner ref= ers to. --=20 =2E o . o . o . . o o . . . o . =2E . o . o o o . o . o o . . o o o o . o . . o o o o . o o o --HAv5+T9jbwMPl6Kw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: http://ae7.st/s/pgp iQEcBAABCgAGBQJT6LjkAAoJEM55Ebf8BAiPj0MH/jGJW5Bf8KvSc7nuSR2vmqof eKqjdddf+1UWjlp455HiSUKD1UlbMcD9K/uXoBTT/S8MEqg4jFV3NMh++Eev6GWr RO28V2YK6QA/nbCZntzlvvVO1L+3GLM6E6xz6VODd4mS08yULqIhz6AnWqg0htbv X4PxXHsgMgmyJB4IjSxzCCyvKiL3MxahUeCmJQXqHBGM0VBntsCVkdFLq+i07Ihu t/LVjqU1s1qZHLezQFjBF0DlGogL+HwDihK4JjhBOLQCQ+AAJvMI8/sCQQb2824D TRbgEwf7SfGmRFithL0mFzMP/uxC5k8gWkXFOzWp6aO+4nsxtR9d4l20S+EBsuQ= =+ldK -----END PGP SIGNATURE----- --HAv5+T9jbwMPl6Kw-- From nobody Tue Aug 12 12:24:16 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCFB1A0702 for ; Tue, 12 Aug 2014 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e-FctIqeZDC for ; Tue, 12 Aug 2014 11:57: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 664DB1A0706 for ; Tue, 12 Aug 2014 11:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CD9CCE2033; Tue, 12 Aug 2014 14:56:59 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32560-01; Tue, 12 Aug 2014 14:56:57 -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 E372CE2031; Tue, 12 Aug 2014 14:56:57 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s7CIuvDR017569; Tue, 12 Aug 2014 14:56:57 -0400 From: Derek Atkins To: Werner Koch References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> Date: Tue, 12 Aug 2014 14:56:57 -0400 In-Reply-To: <87zjfkdnsv.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 04 Aug 2014 22:04:16 +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: http://mailarchive.ietf.org/arch/msg/openpgp/lAsPM6jv5BVSHMZHtuen0uaCk5A X-Mailman-Approved-At: Tue, 12 Aug 2014 12:24:14 -0700 Cc: openpgp@ietf.org, Ian Bobbitt Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 12 Aug 2014 18:57:04 -0000 Werner Koch writes: > On Mon, 4 Aug 2014 19:06, ian@icb.im said: >> I'm not so sure I would say "no software" can use them. They're odd in that >> they're a bare Public-Key Packet, but that doesn't mean they're unusable. > > I won't call that an OpenPGP packet. It is not OpenPGP compatible: > > RFC4880, 12.1 Key Structures: > > In a V4 key, the primary key MUST be a key capable of certification. > > along with 5.5.2 Public-Key Packet Formats: > > OpenPGP implementations MUST create keys with version 4 format. V3 > keys are deprecated; an implementation MUST NOT generate a V3 key, > but MAY accept it. > > v3 keys have severe weaknesses for example they rely on MD5. ECDH is > not capabale of signing/certifying. For what it's worth I have a use-case for bare Public Key Packets with direct signatures, without a user-id packet or a self-signature. I plan to write up an I-D that will loosen the restrictions in 4880 to allow this use-case. Note that this use-case is not for email. Indeed, these keys are not even user keys; they are "device keys". In my use case I'd like to use RFC4880-style signatures for certifying those device keys. Hopefully there is some support for this loosening? > Shalom-Salam, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 13 01:31:38 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDA51A00E0 for ; Wed, 13 Aug 2014 01:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjifNj0-yKVj for ; Wed, 13 Aug 2014 01:31:34 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07B11A0077 for ; Wed, 13 Aug 2014 01:31:33 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XHTy0-0005Kj-1K for ; Wed, 13 Aug 2014 10:31:32 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XHTuC-0005G7-Ar; Wed, 13 Aug 2014 10:27:36 +0200 From: Werner Koch To: Derek Atkins References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.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=1E42B367; url=finger:wk@g10code.com Date: Wed, 13 Aug 2014 10:27:36 +0200 In-Reply-To: (Derek Atkins's message of "Tue, 12 Aug 2014 14:56:57 -0400") Message-ID: <871tskn69z.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: http://mailarchive.ietf.org/arch/msg/openpgp/qPkNWK0vgZc18P6CCN-9NY-9n1w Cc: openpgp@ietf.org, Ian Bobbitt Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 08:31:37 -0000 On Tue, 12 Aug 2014 20:56, derek@ihtfp.com said: > Note that this use-case is not for email. Indeed, these keys are not > even user keys; they are "device keys". In my use case I'd like to use > RFC4880-style signatures for certifying those device keys. > > Hopefully there is some support for this loosening? You mean a feature to create v3 keys? RFC4880 is quite specific about creating v3 keys: OpenPGP implementations MUST create keys with version 4 format. V3 keys are deprecated; an implementation MUST NOT generate a V3 key, but MAY accept it. Regarding signatres, v3 signatures SHOULD not be used and thus it is possible to implement them. In 11.1 transferable key is defined as - One Public-Key packet - Zero or more revocation signatures - One or more User ID packets [...] in 12.1 (Key structures) a v3 key is defined as RSA Public Key [Revocation Self Signature] User ID [Signature ...] [User ID [Signature ...] ...] and a v4 key as Primary-Key [Revocation Self Signature] [Direct Key Signature...] User ID [Signature ...] [User ID [Signature ...] ...] Thus a strict interpretation requires a user id packet. A direct key signature is only possible with a v4 key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Aug 13 05:45:40 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD2C1A0021 for ; Wed, 13 Aug 2014 05:45:39 -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 5Bz5IBCTHGVx for ; Wed, 13 Aug 2014 05:45: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 1528D1A000E for ; Wed, 13 Aug 2014 05:45:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E0205E2031; Wed, 13 Aug 2014 08:45:29 -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 04753-10; Wed, 13 Aug 2014 08:45:27 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 6298CE2033; Wed, 13 Aug 2014 08:45:27 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 13 Aug 2014 08:45:27 -0400 Message-ID: <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> In-Reply-To: <871tskn69z.fsf@vigenere.g10code.de> References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> Date: Wed, 13 Aug 2014 08:45:27 -0400 From: "Derek Atkins" To: "Werner Koch" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/QCwpfnpDvJ7JtcG3dFvPApMKe9w Cc: Ian Bobbitt , openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 12:45:39 -0000 Hi, On Wed, August 13, 2014 4:27 am, Werner Koch wrote: > On Tue, 12 Aug 2014 20:56, derek@ihtfp.com said: > >> Note that this use-case is not for email. Indeed, these keys are not >> even user keys; they are "device keys". In my use case I'd like to use >> RFC4880-style signatures for certifying those device keys. >> >> Hopefully there is some support for this loosening? > > You mean a feature to create v3 keys? No. Not at all. [snip] > in 12.1 (Key structures) [snip] a v4 key as > > Primary-Key > [Revocation Self Signature] > [Direct Key Signature...] > User ID [Signature ...] > [User ID [Signature ...] ...] > > Thus a strict interpretation requires a user id packet. A direct key > signature is only possible with a v4 key. Exactly. My proposal would be a new I-D that would loosen this restriction and define a new-style v4+ key as: Primary-Key [Revocation Self Signature] [Direct Key Signature...] [User ID [Signature ...] ...] .... (rest elided) I'll note that 12.1 goes on to say: In a V4 key, the primary key MUST be a key capable of certification. The subkeys may be keys of any other type. There may be other and in my proposed I-D I would remove this restriction as well. Assuming there is desire for this functionality. Like I said, *I* have a use case for this, and if I do I can assume others do too. Am I more clear on what I intend? Any comments on this? > Shalom-Salam, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 13 06:36:39 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3D11A017A for ; Wed, 13 Aug 2014 06:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTY02PV48wHY for ; Wed, 13 Aug 2014 06:36:34 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA5C1A0178 for ; Wed, 13 Aug 2014 06:36:34 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XHYjB-0002L9-4A for ; Wed, 13 Aug 2014 15:36:33 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XHYdB-00063I-5f; Wed, 13 Aug 2014 15:30:21 +0200 From: Werner Koch To: "Derek Atkins" References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.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=1E42B367; url=finger:wk@g10code.com Date: Wed, 13 Aug 2014 15:30:21 +0200 In-Reply-To: <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> (Derek Atkins's message of "Wed, 13 Aug 2014 08:45:27 -0400") Message-ID: <8761hwikk2.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: http://mailarchive.ietf.org/arch/msg/openpgp/HbviBjln5ldeGAXPBuwxxTPhfWU Cc: openpgp@ietf.org, Ian Bobbitt Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 13:36:37 -0000 On Wed, 13 Aug 2014 14:45, derek@ihtfp.com said: > Exactly. My proposal would be a new I-D that would loosen this > restriction and define a new-style v4+ key as: > > Primary-Key > [Revocation Self Signature] > [Direct Key Signature...] > [User ID [Signature ...] ...] > .... (rest elided) That would be easy to implement. > Am I more clear on what I intend? Any comments on this? Yes. no. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Aug 13 07:03:08 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1203D1A0270 for ; Wed, 13 Aug 2014 07:03:05 -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 hugrDZXzO0K3 for ; Wed, 13 Aug 2014 07:03:04 -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 C46351A0316 for ; Wed, 13 Aug 2014 07:03:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3726AE2031; Wed, 13 Aug 2014 10:03:02 -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 05527-01; Wed, 13 Aug 2014 10:02:59 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 21E08E2033; Wed, 13 Aug 2014 10:02:59 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 13 Aug 2014 10:02:59 -0400 Message-ID: In-Reply-To: <8761hwikk2.fsf@vigenere.g10code.de> References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> <8761hwikk2.fsf@vigenere.g10code.de> Date: Wed, 13 Aug 2014 10:02:59 -0400 From: "Derek Atkins" To: "Werner Koch" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/vopFhxWLE8oJkxPtLnqgZVZtwfI Cc: Ian Bobbitt , openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 14:03:05 -0000 On Wed, August 13, 2014 9:30 am, Werner Koch wrote: > On Wed, 13 Aug 2014 14:45, derek@ihtfp.com said: > >> Exactly. My proposal would be a new I-D that would loosen this >> restriction and define a new-style v4+ key as: >> >> Primary-Key >> [Revocation Self Signature] >> [Direct Key Signature...] >> [User ID [Signature ...] ...] >> .... (rest elided) > > That would be easy to implement. That was my intention :) >> Am I more clear on what I intend? Any comments on this? > > Yes. no. Great! I'll work on the text and get it uploaded for comments. Thanks, > > Shalom-Salam, > > Werner -derek > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 13 07:07:27 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8181F1A02F0 for ; Wed, 13 Aug 2014 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 b15ilqVK7II1 for ; Wed, 13 Aug 2014 07:07:22 -0700 (PDT) Received: from ethos.braverock.com (braverock.com [173.15.14.25]) (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 D69211A031F for ; Wed, 13 Aug 2014 07:07:17 -0700 (PDT) Received: from [10.10.100.199] ([38.104.228.126]) (authenticated bits=0) by ethos.braverock.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id s7DE75tg018774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 13 Aug 2014 09:07:11 -0500 Message-ID: <53EB7137.4030602@braverock.com> Date: Wed, 13 Aug 2014 09:07:51 -0500 From: "Brian G. Peterson" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> <8761hwikk2.fsf@vigenere.g10code.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/a4_hkuzFzqZy4dI-6J3NSt9jICY Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 14:07:24 -0000 On 08/13/2014 09:02 AM, Derek Atkins wrote: >>> On Wed, August 13, 2014 9:30 am, Werner Koch wrote: >> >>Am I more clear on what I intend? Any comments on this? >> >>> Yes. no. >> > Great! I'll work on the text and get it uploaded for comments. I believe Werner's point was that the RFC will not change to support your use case. The old key and signature formats are obsolete, and should be abandoned. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock From nobody Wed Aug 13 07:27:53 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE1A1A040D for ; Wed, 13 Aug 2014 07:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXAVJbvcGUXI for ; Wed, 13 Aug 2014 07:27:51 -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 1ED501A03D1 for ; Wed, 13 Aug 2014 07:27:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A4F6CE2031; Wed, 13 Aug 2014 10:27:49 -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 05527-09; Wed, 13 Aug 2014 10:27:46 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 83C9EE2033; Wed, 13 Aug 2014 10:27:46 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 13 Aug 2014 10:27:46 -0400 Message-ID: <577ab0e4ed6764aeca8f21088b5c8b16.squirrel@mail2.ihtfp.org> In-Reply-To: <53EB7137.4030602@braverock.com> References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> <8761hwikk2.fsf@vigenere.g10code.de> <53EB7137.4030602@braverock.com> Date: Wed, 13 Aug 2014 10:27:46 -0400 From: "Derek Atkins" To: "Brian G. Peterson" 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: http://mailarchive.ietf.org/arch/msg/openpgp/Jfqsd-EdthYsHc9GTgPgnyuN2eY Cc: openpgp@ietf.org Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 14:27:52 -0000 On Wed, August 13, 2014 10:07 am, Brian G. Peterson wrote: > > > On 08/13/2014 09:02 AM, Derek Atkins wrote: >>>> On Wed, August 13, 2014 9:30 am, Werner Koch wrote: >>> >>>Am I more clear on what I intend? Any comments on this? >>> >>>> Yes. no. > >> >> Great! I'll work on the text and get it uploaded for comments. > > I believe Werner's point was that the RFC will not change to support > your use case. The old key and signature formats are obsolete, and > should be abandoned. Then you didn't read my complete reply to Werner. I am not suggesting going back to the old key and signature (v3) formats. I agree they should be abandoned. I am suggesting a *NEW* I-D (which will hopefully be progressed into an RFC) that would extend RFC4880 and loosen the v4 key restrictions in section 12.1 that require a UserID+Self-Signature on a Primary Key. And Werner's reply to my suggestion (which you conveniently removed) was that it would be easily implementable. So, any other comments? Thanks, > Regards, > > Brian -derek > -- > Brian G. Peterson > http://braverock.com/brian/ > Ph: 773-459-4973 > IM: bgpbraverock > > _______________________________________________ > 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 Wed Aug 13 09:02:09 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919FD1A08AE for ; Wed, 13 Aug 2014 09:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is2-vEszHYO8 for ; Wed, 13 Aug 2014 09:02:04 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B5D1A087D for ; Wed, 13 Aug 2014 09:01:48 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id l13so10660034iga.16 for ; Wed, 13 Aug 2014 09:01: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 :cc:content-type; bh=ohQY1cuZxVGlF0wP76dKENy7ywaZP04SzckLVgUC840=; b=XAVfEzS0oy/5HEw+GzWWuIinX1inFIvsYFudfrTgNltRSBkcjH3IDSb0cIDVjBPHWb Fn1hWjcmYvacaK+moFdLb9pJWDGBNjYXsCKBe+mnjBFphx93bZD5PJH5/uCKOxwlFm5p mmsNfM+y0J6I2uif3GZd0gUUQV6ATzSBvj1MdVUr9TBw1ytAXhWuVkfLIBuK3ZCWpwSZ +6WsSE/K683B7AOs0UtlKWMFLKq3IinXGIpWxdwti3RcH2HqG3kXR2a3jkxLWr0FwKXm j0v/O6XX7V0JrwVNzxN49HXqaIcNtlKFUC8zbRM+a1+MjvKC6nf00ODWtdOrNhxAXgxk mz9w== MIME-Version: 1.0 X-Received: by 10.50.30.72 with SMTP id q8mr49973560igh.14.1407945707689; Wed, 13 Aug 2014 09:01:47 -0700 (PDT) Received: by 10.107.130.225 with HTTP; Wed, 13 Aug 2014 09:01:47 -0700 (PDT) In-Reply-To: <577ab0e4ed6764aeca8f21088b5c8b16.squirrel@mail2.ihtfp.org> References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> <8761hwikk2.fsf@vigenere.g10code.de> <53EB7137.4030602@braverock.com> <577ab0e4ed6764aeca8f21088b5c8b16.squirrel@mail2.ihtfp.org> Date: Wed, 13 Aug 2014 12:01:47 -0400 Message-ID: From: David Leon Gil To: Derek Atkins Content-Type: multipart/alternative; boundary=047d7bd6c016c5903a050084e708 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/W6y_j-r3zdtiT0dVXCZCTuZJxBQ Cc: "openpgp@ietf.org" Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 16:02:06 -0000 --047d7bd6c016c5903a050084e708 Content-Type: text/plain; charset=UTF-8 On Wednesday, August 13, 2014, Derek Atkins wrote: > > I am suggesting a *NEW* I-D (which will hopefully be progressed into an > RFC) that would extend RFC4880 and loosen the v4 key restrictions in > section 12.1 that require a UserID+Self-Signature on a Primary Key. > > So, any other comments? > I support the proposal so far as it concerns *encryption* keys as primary keys; I'd prefer if the MUST support were limited to ECDH keys. I don't really see much point in permitting *signing* keys without a proof-of-possession. (If the key isn't able to sign a PoP, what can it do?) --047d7bd6c016c5903a050084e708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, August 13, 2014, Derek Atkins <derek@ihtfp.com> wrote:
I am suggesting a *NEW* I-D (which will hopefully be progressed into an
RFC) that would extend RFC4880 and loosen the v4 key restrictions in
section 12.1 that require a UserID+Self-Signature on a Primary Key. =C2=A0<= br>
So, any other comments?

I support the proposal so far as it concer= ns *encryption* keys as primary keys; I'd prefer if the MUST=C2=A0suppo= rt=C2=A0were limited to ECDH keys.

I don't really s= ee much point in=C2=A0permitting=C2=A0*signing* keys without a proof-of-pos= session. (If the key isn't able to=C2=A0sign a PoP, what can it do?) --047d7bd6c016c5903a050084e708-- From nobody Wed Aug 13 09:09:29 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F374F1A08D3 for ; Wed, 13 Aug 2014 09:09:27 -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 Ba2wjh-lsI40 for ; Wed, 13 Aug 2014 09:09:25 -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 6306A1A08CE for ; Wed, 13 Aug 2014 09:09:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 790DEE2031; Wed, 13 Aug 2014 12:09:23 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06279-04; Wed, 13 Aug 2014 12:09:21 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 52D72E203A; Wed, 13 Aug 2014 12:09:21 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 13 Aug 2014 12:09:21 -0400 Message-ID: <6ff293bc7e0225fc4aa7d6bc741ed5f1.squirrel@mail2.ihtfp.org> In-Reply-To: References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> <8761hwikk2.fsf@vigenere.g10code.de> <53EB7137.4030602@braverock.com> <577ab0e4ed6764aeca8f21088b5c8b16.squirrel@mail2.ihtfp.org> Date: Wed, 13 Aug 2014 12:09:21 -0400 From: "Derek Atkins" To: "David Leon Gil" 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: http://mailarchive.ietf.org/arch/msg/openpgp/fZ8Z9BobUAzdiMStkL4QgxQOxv4 Cc: "openpgp@ietf.org" , Derek Atkins Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 13 Aug 2014 16:09:28 -0000 On Wed, August 13, 2014 12:01 pm, David Leon Gil wrote: > On Wednesday, August 13, 2014, Derek Atkins wrote: > >> >> I am suggesting a *NEW* I-D (which will hopefully be progressed into an >> RFC) that would extend RFC4880 and loosen the v4 key restrictions in >> section 12.1 that require a UserID+Self-Signature on a Primary Key. >> >> So, any other comments? >> > > I support the proposal so far as it concerns *encryption* keys as primary > keys; I'd prefer if the MUST support were limited to ECDH keys. > > I don't really see much point in permitting *signing* keys without a > proof-of-possession. (If the key isn't able to sign a PoP, what can it > do?) While I consider this a reasonable restriction, in my use case there is no need for self-certification. Devices don't have self-identities, only the keys; identities are supplied by third parties. However I am willing to make it a "SHOULD Self-Certify" for a key that is capable of signatures to make it clear that in the general case you should still self-sign when you can. Does that work for you? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Aug 13 20:04:42 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7DC1A0754 for ; Wed, 13 Aug 2014 20:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_wwlKvo_RpJ for ; Wed, 13 Aug 2014 20:04:39 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 722F91A0746 for ; Wed, 13 Aug 2014 20:04:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 181D65974949; Wed, 13 Aug 2014 20:04:39 -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 LGH6eD4DEzpG; Wed, 13 Aug 2014 20:04:34 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 0A6F75974934; Wed, 13 Aug 2014 20:04:31 -0700 (PDT) Received: from [172.19.131.141] ([12.130.116.5]) by keys.merrymeet.com (PGP Universal service); Wed, 13 Aug 2014 20:04:34 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 13 Aug 2014 20:04:34 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jon Callas In-Reply-To: <1407693468.1416.36.camel@chstpc-2.fritz.box> Date: Wed, 13 Aug 2014 20:04:29 -0700 Message-Id: References: <1407693468.1416.36.camel@chstpc-2.fritz.box> To: Christian Stadelmann X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/Fs6sR-Fy7H61JmRTPc1bzr8hsPQ Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] =?windows-1252?q?SHA-2_support_should_be_mandatory_=96_?= =?windows-1252?q?change_defaults?= X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 14 Aug 2014 03:04:40 -0000 To add in my two cents to this, I'm going to channel an old Security AD, = Jeff Schiller. There's a huge difference between Mandatory To Implement (a MUST) and = Mandatory to Use. As perhaps the best example, the X.509 RFCs list DSA as the MUST = algorithm, but it's not clear that there are as many real-world DSA = certificates as I have fingers. Or noses. Everyone uses RSA or ECC. Thus, I agree with what you're saying, that implementations really need = to stop using SHA-1, except by some explicit override, and maybe not = even then. In PGP, we stopped using SHA-1 by default back in 2004 when = Wang's attacks came out. We moved right to SHA-256, and just started = marking all keys as wanting SHA-256 or better. Similarly, PGP started guiding people early on to longer RSA keys. You = could make one if you wanted, but you had to go into advanced key = creation etc. Also similarly, it had opinions about symmetric algorithms = and these were in the defaults. You don't need to change any documents, you need to get software to = change. Now, there are plenty of other things that could be useful. I might, for = example, do an individual draft for SHA3, or even SHA-512/z in a few = relevant values of z. As for DSA, there's no reason you can't use any of a number of protected = DSAs. Werner noted that GnuPG uses RFC-6979 to protect it. PGP always = used a keyed hash, where the key was the DSA private key to improve the = nonce. If you wonder why PGP didn't use an HMAC, it's because in those = days there was no HMAC. These days, HMAC is Simply What Is Done. In short -- it's a lot easier to fix software than documents. Remember, = (again, channeling Schiller) standards exist for interoperability. Jon From nobody Sat Aug 16 17:09:21 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCC41A04DC for ; Sat, 16 Aug 2014 17:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAkDqVjC3h9B for ; Sat, 16 Aug 2014 17:09:18 -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 441081A04C2 for ; Sat, 16 Aug 2014 17:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id F0E30E2033 for ; Sat, 16 Aug 2014 20:09:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30417-07 for ; Sat, 16 Aug 2014 20:09:15 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 22A9AE2031 for ; Sat, 16 Aug 2014 20:09:15 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s7H09EIo022755; Sat, 16 Aug 2014 20:09:14 -0400 From: Derek Atkins To: openpgp@ietf.org Date: Sat, 16 Aug 2014 20:09:14 -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: http://mailarchive.ietf.org/arch/msg/openpgp/J2xfuALm3U7en_CWbYyZTVSzPRU Subject: [openpgp] OpenPGP Notation Registry: what is the "Type" field? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 17 Aug 2014 00:09:20 -0000 Hi, I'm looking to register some notations with IANA and trying to figure out what the "Type" is supposed to be used for. Is that the "description" of the tag? Or is it supposed to be how to interpret the data string? Alas, RFC 4880 doesn't actually say what the type is supposed to be, and I don't remember myself. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Aug 16 17:24:27 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9981A0503 for ; Sat, 16 Aug 2014 17:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 tj3MqjQk5sEu for ; Sat, 16 Aug 2014 17:24:26 -0700 (PDT) Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42481A0502 for ; Sat, 16 Aug 2014 17:24:25 -0700 (PDT) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id s7H0ONfN001754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Aug 2014 20:24:24 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Shaw In-Reply-To: Date: Sat, 16 Aug 2014 20:24:23 -0400 Content-Transfer-Encoding: 7bit Message-Id: <92092698-FFC9-4284-B2E0-869769219D80@jabberwocky.com> References: To: Derek Atkins X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/RsIV3TQJhOCxlv8OEkGIX8j_GU0 Cc: openpgp@ietf.org Subject: Re: [openpgp] OpenPGP Notation Registry: what is the "Type" field? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 17 Aug 2014 00:24:27 -0000 On Aug 16, 2014, at 8:09 PM, Derek Atkins wrote: > Hi, > > I'm looking to register some notations with IANA and trying to figure > out what the "Type" is supposed to be used for. Is that the > "description" of the tag? Or is it supposed to be how to interpret the > data string? Alas, RFC 4880 doesn't actually say what the type is > supposed to be, and I don't remember myself. My understanding is that the type is indeed a description of the notation. David From nobody Sat Aug 16 17:37:45 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601E91A052E for ; Sat, 16 Aug 2014 17:37:41 -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 CIBnat4Ekb4e for ; Sat, 16 Aug 2014 17:37:40 -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 BA00B1A0390 for ; Sat, 16 Aug 2014 17:37:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 78843E2031; Sat, 16 Aug 2014 20:37:39 -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 30744-02; Sat, 16 Aug 2014 20:37:36 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id DBE13E2033; Sat, 16 Aug 2014 20:37:36 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Sat, 16 Aug 2014 20:37:36 -0400 Message-ID: In-Reply-To: <92092698-FFC9-4284-B2E0-869769219D80@jabberwocky.com> References: <92092698-FFC9-4284-B2E0-869769219D80@jabberwocky.com> Date: Sat, 16 Aug 2014 20:37:36 -0400 From: "Derek Atkins" To: "David Shaw" 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: http://mailarchive.ietf.org/arch/msg/openpgp/4yMThA5B64z3LQMdDoI8Um5B24I Cc: openpgp@ietf.org Subject: Re: [openpgp] OpenPGP Notation Registry: what is the "Type" field? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 17 Aug 2014 00:37:41 -0000 On Sat, August 16, 2014 8:24 pm, David Shaw wrote: > On Aug 16, 2014, at 8:09 PM, Derek Atkins wrote: > >> Hi, >> >> I'm looking to register some notations with IANA and trying to figure >> out what the "Type" is supposed to be used for. Is that the >> "description" of the tag? Or is it supposed to be how to interpret the >> data string? Alas, RFC 4880 doesn't actually say what the type is >> supposed to be, and I don't remember myself. > > My understanding is that the type is indeed a description of the notation. Thanks, David! That's what I thought, too, but wanted to make sure. Still working on the first of two I-Ds I plan to submit. :) > David -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Aug 19 13:06:41 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705651A0B78 for ; Tue, 19 Aug 2014 13:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVlNF7GA7_tS for ; Tue, 19 Aug 2014 13:06:37 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B621A0B7B for ; Tue, 19 Aug 2014 13:06:37 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XJpfw-0003I8-4x for ; Tue, 19 Aug 2014 22:06:36 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XJpdq-0002hu-Gy; Tue, 19 Aug 2014 22:04:26 +0200 From: Werner Koch To: openpgp@ietf.org Mail-Followup-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=1E42B367; url=finger:wk@g10code.com Date: Tue, 19 Aug 2014 22:04:26 +0200 Message-ID: <874mx88cvp.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: http://mailarchive.ietf.org/arch/msg/openpgp/ewSY_i2uQAawKMW5rB4TpcA0jBQ Cc: gnupg-devel@gnupg.org Subject: [openpgp] EdDSA/Ed25519 I-D for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 20:06:40 -0000 Hi, I just submitted an I-D for use of Ed25519 in OpenPGP: http://www.ietf.org/id/draft-koch-eddsa-for-openpgp-00.txt I include a version without page breaks below. Salam-Shalom, Werner ==== Network Working Group W. Koch Internet-Draft g10 Code Intended status: Standards Track August 19, 2014 Expires: February 20, 2015 EdDSA for OpenPGP draft-koch-eddsa-for-openpgp-00 Abstract This specification extends OpenPGP with the EdDSA public key algorithm and describes the use of curve Ed25519. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 20, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Supported Curves 3. Point Format 4. Encoding of Public and Private Keys 5. Message Encoding 6. Curve OID 7. Security Considerations 8. IANA Considerations 9. Acknowledgments 10. Normative References Appendix A. Test vectors A.1. Sample key A.2. Sample signature Author's Address 1. Introduction The OpenPGP specification in [RFC4880] defines the RSA, Elgamal, and DSA public key algorithms. [RFC6637] adds support for Elliptic Curve Cryptography and specifies the ECDSA and ECDH algorithms. Due to patent reasons no point compression was defined. 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Supported Curves This document references the Curve "Ed25519" which is the Edwards form of "Curve25519" and specified in the same paper as the "EdDSA" algorithm ([ED25519]). Other curves may be used by using a specific OID for the curve and its EdDSA parameters. The following public key algorithm IDs are added to expand section 9.1 of [RFC4880], "Public-Key Algorithms": +-------+-----------------------------+ | ID | Description of Algorithm | +-------+-----------------------------+ | TBD1 | EdDSA public key algorithm | +-------+-----------------------------+ Compliant applications MUST support EdDSA with the curve Ed25519. Applications MAY support other curves as long as a dedicated OID for that curve is used. 3. Point Format The EdDSA algorithm defines a specific point compression format. To indicate the use of this compression format and to make sure that the key can be represented in the Multiprecision Internet (MPI) format of [RFC4880] the octet string specifying the point is prefixed with the octet 0x40. This encoding is an extension of the encoding given in [RFC6637] which uses 0x04 to indicate an uncompressed point. For example, the length of a public key for the curve Ed25519 is 263 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the native value of the public key. 4. Encoding of Public and Private Keys The following algorithm specific packets are added to Section 5.5.2 of [RFC4880], "Public-Key Packet Formats", to support EdDSA. Algorithm-Specific Fields for EdDSA keys: o 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, * octets representing a curve OID, defined in Section 6. o MPI of an EC point representing a public key Q as described under Point Format above. The following algorithm specific packets are added to Section 5.5.3 of [RFC4880], "Secret-Key Packet Formats", to support EdDSA. Algorithm-Specific Fields for EdDSA keys: o an MPI of an integer representing the secret key, which is a scalar of the public EC point. The version 4 packet format MUST be used. 5. Message Encoding Section 5.2.3 of [RFC4880], "Version 4 Signature Packet Format" specifies formats. To support EdDSA no change is required, the MPIs representing the R and S value are encoded as MPIs in the same way as done for the DSA and ECDSA algorithms; in particular the Algorithm- Specific Fields for an EdDSA signature are: - MPI of EdDSA value r. - MPI of EdDSA value s. Note that the compressed version of R and S as specified for EdDSA ([ED25519]) is used. The version 3 signature format MUST NOT be used with EdDSA. Although that algorithm allows arbitrary data as input, its use with OpenPGP requires that a digest of the message is used as input. See section 5.2.4 of [RFC4880], "Computing Signatures" for details. Truncation of the resulting digest is never applied; the resulting digest value is used verbatim as input to the EdDSA algorithm. 6. Curve OID The EdDSA key parameter curve OID is an array of octets that defines a named curve. The table below specifies the exact sequence of bytes for each named curve referenced in this document: +------------------------+------+------------------------+----------+ | OID | Len | Encoding in hex format | Name | +------------------------+------+------------------------+----------+ | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 | | | | 0F 01 | | +------------------------+------+------------------------+----------+ See [RFC6637] for a description of the OID encoding given in the second and third columns. 7. Security Considerations The security considerations of [RFC4880] apply accordingly. The use of EdDSA with the Ed25519 curve is believed to be as strong as other curves of the same size. However, a proper implementation of this algorithm avoids most security problems due to wrong usage. The algorithm does not require a unique random number for each signature created by the same key. 8. IANA Considerations IANA is requested to assign an algorithm number from the OpenPGP Public-Key Algorithms range, or the "namespace" in the terminology of [RFC5226], that was created by [RFC4880]. See section 2. +-------+-----------------------------+------------+ | ID | Algorithm | Reference | +-------+-----------------------------+------------+ | TBD1 | EdDSA public key algorithm | This doc | +-------+-----------------------------+------------+ [Notes to RFC-Editor: Please remove the table above on publication. It is desirable not to reuse old or reserved algorithms because some existing tools might print a wrong description. A higher number is also an indication for a newer algorithm. As of now 22 is the next free number.] 9. Acknowledgments The author would like to acknowledge the help of the individuals who kindly voiced their opinions on the IETF OpenPGP and GnuPG mailing lists, in particular, the help of Andrey Jivsov, Jon Callas, and NIIBE Yutaka. 10. Normative References [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in OpenPGP", RFC 6637, June 2012. Appendix A. Test vectors To help implementing this specification a non-normative example is given. This example assumes that the algorithm id for EdDSA will be 22. A.1. Sample key The secret key used for this example is: D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2 Note that this is the raw secret key as used as input to the EdDSA signing operation. The key was created on 2014-08-19 14:28:27 and thus the fingerprint of the OpenPGP key is: C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A The algorithm specific input parameters without the MPI length headers are: oid: 2b06010401da470f01 q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406 The entire public key packet is thus 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e 43 ee 3b 24 06 A.2. Sample signature The signature is created using the sample key over the input data "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash function is m: 4f70656e504750040016080006050255f95f9504ff0000000c using the SHA-256 hash algorithm yields this digest d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 which is fed into the EdDSA signature function and yields this signature: r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366 s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404 Note that the MPI encoding rules require that the value of S needs to be prefixed with a 0x00 octet. The entire signature packet is thus 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00 d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04 Author's Address Werner Koch g10 Code Email: wk@gnupg.org URI: https://g10code.com -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Aug 20 15:24:42 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A691A894D for ; Wed, 20 Aug 2014 15:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 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, URI_HEX=1.122] 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 XFyYlWiep3Nd for ; Wed, 20 Aug 2014 15:24:39 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0221A8935 for ; Wed, 20 Aug 2014 15:24:39 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so11991853igb.4 for ; Wed, 20 Aug 2014 15:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qf1LK2HoMhd60LlyHvTdNg+kZzKfNEQJjOCat8AAthQ=; b=ZNhG8hNU1Xf6uMbwYWORw6gIBt4ni9qBYDp4XUys8dbwLYkLha1Szylh/ahoaYrqzO UFVEC0Dta9J9kGfuyJPPFCNuIRu4cfdb5+itCl+9OsTx8f5ptZz1Awb8wrFOMsxsKdL0 XLAgjbkOIT5k8u0pn9+GCzIf6cSw1cKZ29J69qDejh1gks1Nocr5C4XmTFSlHLWz6BX9 XxMDV57V8Ur4VrgNMSAH7fthZFYE7tPoB1j7uIXSfej+RbnfCDvhsNdyfliK8b7dttbO 28rmnq5uTV+Hy/1Q52GkVYcWRUGAR/ITqJiALECIQNDxuGHQBghS6377/lbz+c3FLYWU ALSg== X-Received: by 10.42.23.16 with SMTP id q16mr293607icb.0.1408573478966; Wed, 20 Aug 2014 15:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.225 with HTTP; Wed, 20 Aug 2014 15:24:18 -0700 (PDT) In-Reply-To: <874mx88cvp.fsf@vigenere.g10code.de> References: <874mx88cvp.fsf@vigenere.g10code.de> From: David Leon Gil Date: Wed, 20 Aug 2014 18:24:18 -0400 Message-ID: To: "openpgp@ietf.org" , Werner Koch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/x3aqFEpo2Dp1CCcorEr1uexO_H8 Cc: "gnupg-devel@gnupg.org" Subject: Re: [openpgp] EdDSA/Ed25519 I-D for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 22:24:40 -0000 On Tue, Aug 19, 2014 at 4:04 PM, Werner Koch wrote: > I just submitted an I-D for use of Ed25519 in OpenPGP: This is terrific! > 2. Supported Curves > > Other curves may be used by using a specific OID for the curve and > its EdDSA parameters. See infra. You should list EdDSA parameters that need to be encoded into the OID. > 3. Point Format Are MPIs -- and the 0x40 prefix -- necessary? The curve OID already determines the length the octet string. Similarly for encoding the signature; it poses significant interoperability concerns to deviate from the existing encoding used by Ed25519 implementations. > Although that algorithm allows arbitrary data as input, its use with > OpenPGP requires that a digest of the message is used as input. See > section 5.2.4 of [RFC4880], "Computing Signatures" for details. > Truncation of the resulting digest is never applied; the resulting > digest value is used verbatim as input to the EdDSA algorithm. This is confusing. EdDSA is defined to operate on messages of arbitrary length; hashing the message is part of the EdDSA algorithm. To quote: EdDSA has seven parameters: - an integer _b_ =E2=89=A5 10; - a cryptographic hash function _H_ producing **2b-bit output**; - a prime power _q_ congruent to 1 modulo 4; - a (_b_=E2=88=921)-bit encoding of elements of the finite field _Fq_; - a non-square element _d_ of _Fq_; - a prime _L_ between 2^_b_=E2=88=924 and 2^_b_=E2=88=923 satisfying an= extra constraint [. . .]; - [and a point _B_] Ed25519-SHA2-512 is widely implemented. No other hash functions currently specified for use with OpenPGP provide long enough output to be used with Curve25519. > 10. Normative References > > [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, http://ed25519.cr.yp.to/ed25519-20110926.pdf From nobody Wed Aug 20 17:32:26 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7CB1A0021 for ; Wed, 20 Aug 2014 17:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, 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 Erikri5il-O1 for ; Wed, 20 Aug 2014 17:32:22 -0700 (PDT) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEB81A0649 for ; Wed, 20 Aug 2014 17:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID; bh=TwxJ8iC0Q0xPV1Ydgw7sLFnUNtxbx5bK3oW4gzTjx8Q=; b=EFIe/h8FtwLr3Y7pyNYWBMw2CxvboPmimS3NTHdFudLrjzfQa5AVqfRUM6Seexi1w+FC3nBa7CiuYcbRwsbaJ9ZIC3aLFgkMDedq84hmUUKya3KTSyeidUYCDl7UTjyEHQFI5EqqDsxy1O1qsdX1mn3O5NMbqKMvM16M7jGard1iXWPOpkKjmu3YLg/8ofqnmr96mEOA/dP60zCBpq8jNmlSa0C/fJuxUNsuECFEbJM+7ryk2g3iCx6VIgWWBRW6IkS4cEHoPR/pe3YMY8d9ARGjycBJz8fUOAJJxJR/Y4Kx8CJCIZ2jWkeqFBjl/XO+Ijqg7B5Hz1UX9HBdyiKa4A==; Received: from 223.17.156.59.ap.dti.ne.jp ([59.156.17.223] helo=[192.168.2.105]) by akagi.fsij.org with esmtpsa (SSL3.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XKGHq-0007OS-LZ; Thu, 21 Aug 2014 09:31:31 +0900 Message-ID: <1408581133.1630.1.camel@cfw2.gniibe.org> From: NIIBE Yutaka To: Werner Koch Date: Thu, 21 Aug 2014 09:32:13 +0900 In-Reply-To: <874mx88cvp.fsf@vigenere.g10code.de> References: <874mx88cvp.fsf@vigenere.g10code.de> Organization: Free Software Initiative of Japan Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/kufAv2F3jmbXmaOGcJ0jLFkVk4Q Cc: gnupg-devel@gnupg.org, openpgp@ietf.org Subject: Re: [openpgp] EdDSA/Ed25519 I-D for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 00:32:24 -0000 On 2014-08-19 at 22:04 +0200, Werner Koch wrote: > I just submitted an I-D for use of Ed25519 in OpenPGP: > > http://www.ietf.org/id/draft-koch-eddsa-for-openpgp-00.txt Great. I have a question if you plan to submit another I-D for Curve25519 in OpenPGP. Well, I think that when people say "Curve25519", it refers two different things: the Montgomery curve itself or the ECDH computation with the curve. In the paragraph above, I mean ECDH computation. Specifically,,, > 6. Curve OID > > The EdDSA key parameter curve OID is an array of octets that defines > a named curve. The table below specifies the exact sequence of bytes > for each named curve referenced in this document: > > +------------------------+------+------------------------+----------+ > | OID | Len | Encoding in hex format | Name | > +------------------------+------+------------------------+----------+ > | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 | > | | | 0F 01 | | > +------------------------+------+------------------------+----------+ Do you intend to use this OID of Ed25519 for ECDH, too? Or do we use another OID of Curve25519 (the Montgomery curve) for ECDH, to specify Curve25519 (ECDH computation)? -- From nobody Wed Aug 20 23:51:44 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B31A06D2 for ; Wed, 20 Aug 2014 23:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ekvZqMiaj_e for ; Wed, 20 Aug 2014 23:51:38 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADF91A068A for ; Wed, 20 Aug 2014 23:51:38 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XKMDg-0000ND-BM for ; Thu, 21 Aug 2014 08:51:36 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XKMAv-0007nh-8L; Thu, 21 Aug 2014 08:48:45 +0200 From: Werner Koch To: NIIBE Yutaka References: <874mx88cvp.fsf@vigenere.g10code.de> <1408581133.1630.1.camel@cfw2.gniibe.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Mail-Followup-To: NIIBE Yutaka , gnupg-devel@gnupg.org, openpgp@ietf.org Date: Thu, 21 Aug 2014 08:48:44 +0200 In-Reply-To: <1408581133.1630.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 21 Aug 2014 09:32:13 +0900") Message-ID: <87iolm5odv.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: http://mailarchive.ietf.org/arch/msg/openpgp/udKKCNC-0K1DLWxY384859lYm-g Cc: gnupg-devel@gnupg.org, openpgp@ietf.org Subject: Re: [openpgp] EdDSA/Ed25519 I-D for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 06:51:42 -0000 On Thu, 21 Aug 2014 02:32, gniibe@fsij.org said: > I have a question if you plan to submit another I-D for Curve25519 in > OpenPGP. I would like to do that but the problem I face is that there is no suitable specification for the original Curve25519. Ed25519 is well defined and the printed and online paper should be sufficient as a normative reference. However an I-D for Curve25519 [1] has recently been published. Thus it may soon be possible to describe how to use it in OpenPGP. In particular on how to use only the X coordinate. > Do you intend to use this OID of Ed25519 for ECDH, too? No, that is for Ed25519. > Or do we use another OID of Curve25519 (the Montgomery curve) for > ECDH, to specify Curve25519 (ECDH computation)? For the Montgomery curve Peter Gutman assigned 1.3.6.1.4.1.3029.1.5.1 arlier this year. Shalom-Salam, Werner [1] http://tools.ietf.org/id/draft-turner-thecurve25519function-01.txt -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Aug 21 00:26:41 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C221A046D for ; Thu, 21 Aug 2014 00:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.778 X-Spam-Level: X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URI_HEX=1.122] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts2h-oci2kJ9 for ; Thu, 21 Aug 2014 00:26:39 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0478E1A00D8 for ; Thu, 21 Aug 2014 00:26:39 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XKMlZ-0000qn-A2 for ; Thu, 21 Aug 2014 09:26:37 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XKMhw-0007uC-AK; Thu, 21 Aug 2014 09:22:52 +0200 From: Werner Koch To: David Leon Gil References: <874mx88cvp.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=1E42B367; url=finger:wk@g10code.com Mail-Followup-To: David Leon Gil , "openpgp\@ietf.org" , "gnupg-devel\@gnupg.org" Date: Thu, 21 Aug 2014 09:22:52 +0200 In-Reply-To: (David Leon Gil's message of "Wed, 20 Aug 2014 18:24:18 -0400") Message-ID: <87egwa5msz.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: http://mailarchive.ietf.org/arch/msg/openpgp/GzZ5WJgJg5SRawdGhgcwoGejVKM Cc: "gnupg-devel@gnupg.org" , "openpgp@ietf.org" Subject: Re: [openpgp] EdDSA/Ed25519 I-D for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 07:26:40 -0000 On Thu, 21 Aug 2014 00:24, coruus@gmail.com said: > See infra. You should list EdDSA parameters that need to be encoded > into the OID. Not required. That is specified in the Ed25519 paper. > This is confusing. EdDSA is defined to operate on messages of > arbitrary length; hashing the message is part of the EdDSA algorithm. Right but that can't be used in OpenPGP. Recall that there is a preference system which goes along with encrypted messages and that we have specific requirements of what needs to be hashed. Messing up the well established OpenPGP layered structure won't do any good. Further, to implement EdDSA on a smartcard it is required that the card does the hashing. Now imagine what happens if you try to sign a 100 MB message: You can go out for lunch and come back to realize that it will take another hour to finish. > Ed25519-SHA2-512 is widely implemented. No other hash functions > currently specified for use with OpenPGP provide long enough output to > be used with Curve25519. We are talking about the EdDSA algorithm which required the Edwards form of Curve25519. The internal use of a 64 byte digest is required by the way EdDSA works. Using a SHA-256 hash as data to be signed matches this nicely but if you don't like it you may sign any other hash. > http://ed25519.cr.yp.to/ed25519-20110926.pdf Web pages are not suitable as a normative reference. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Aug 21 06:32:41 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A031A02DC for ; Thu, 21 Aug 2014 06:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 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, URI_HEX=1.122] 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 lxrBvYRdrI7o for ; Thu, 21 Aug 2014 06:32:37 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699DC1A02D8 for ; Thu, 21 Aug 2014 06:32:37 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so4686931iec.29 for ; Thu, 21 Aug 2014 06:32:36 -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:cc:content-type; bh=u0iD1JyZi80tsy+5EQ6uphjjUlY7nxMmuk9dy0OrDWs=; b=jFc2VBt3DDCqBoq3JGmUEm5AuHQazWzH/em6bNFhlr3RLVqInmR17flQ4FNlLH1/lF 6GClQ0U1PklUxzK0VSnCb1+i5Rff+tixPhwtzItmHd2wtSEQHfPEEbifNDsjPRi/kboy 3T8bFjCpTtdu+1F5TQbvxqTRQVLeS0g7HUjop48dqaZV/Rs7XA2HK3SQPO5SmyILXupJ 0WOmjvfrB6EnLcboa4MVzfI1qNu/lWJau13hWsRDUqck7ndjGSGWMu/GDtPi6zP3cpxI IicQDmbpg9BiCWhzjJDRo5sToDndMw8jfvPnoHBk6drDeImIAf8KyZ/hJy17W501TU96 OLmw== X-Received: by 10.50.25.41 with SMTP id z9mr4323130igf.0.1408627956861; Thu, 21 Aug 2014 06:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.225 with HTTP; Thu, 21 Aug 2014 06:32:16 -0700 (PDT) From: David Leon Gil Date: Thu, 21 Aug 2014 09:32:16 -0400 Message-ID: To: "openpgp@ietf.org" , Werner Koch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/R2JpyRbgjU6b_SDU7CbvOMgQi0I Cc: "D. J. Bernstein" Subject: Re: [openpgp] EdDSA/Ed25519 I-D for OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 13:32:38 -0000 On Thu, Aug 21, 2014 at 3:22 AM, Werner Koch wrote: > On Thu, 21 Aug 2014 00:24, coruus@gmail.com said: >> This is confusing. EdDSA is defined to operate on messages of >> arbitrary length; hashing the message is part of the EdDSA algorithm. > > Right but that can't be used in OpenPGP. Recall that there is a > preference system which goes along with encrypted messages and that we > have specific requirements of what needs to be hashed. Messing up the > well established OpenPGP layered structure won't do any good. Compatibility with implementations that don't implement Ed25519 should not be a priority. > We are talking about the EdDSA algorithm which required the Edwards form > of Curve25519. The internal use of a 64 byte digest is required by the > way EdDSA works. Using a SHA-256 hash as data to be signed matches this > nicely but if you don't like it you may sign any other hash. So, to be clear: You are proposing that *hashes* of OpenPGP messages be what is hashed by Ed25519. Could you provide a reference with concrete security results for this construction? (It is no longer a collision-resistant signature scheme, at the very least.) (This is not how OpenPGP ECDSA works.) >> http://ed25519.cr.yp.to/ed25519-20110926.pdf > > Web pages are not suitable as a normative reference. Included for reader's convenience. - David From nobody Thu Aug 21 08:37:49 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDD01A6F07 for ; Thu, 21 Aug 2014 08:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoqn5JNohI3C for ; Thu, 21 Aug 2014 08:37:43 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C531A03F0 for ; Thu, 21 Aug 2014 08:37:42 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so13057934igc.12 for ; Thu, 21 Aug 2014 08:37:42 -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=n+Dz7QeY0+Crw2obK+rxhLysyfVJVecSNaYNk3W+p1o=; b=OY+5vL8NQzR7As8do4icwP5Ki7hm84nXvns8+1Fl3mdZZixJMvbaHupRXt+B1gckYr pydZgbou6nN6ud8zhm+9IkNAeaFAuf+3F1fXjtHQ3eCYel5rDTGipC15K7VQ8UxP26co RGHxVjTYDd/EvvVP8Qqqo6jXx3MiDGOV7TSpsDiuMR+0js1+5azptQaZd96E7EqR/1+f K10Tlt7pACeLqgwG+NI/ZbHxqUrqQr1MgUb4ndN6+w9lY4MmV3DcSDbH5mtNkF3NoH3m Ck8vjO+pFAz0HQRZteOdy1YKxsLPFWRA8EviRBSbUNbzhnPIAuVqvj4Of1MjZoOIotyQ ZDCA== MIME-Version: 1.0 X-Received: by 10.42.58.210 with SMTP id j18mr4368617ich.2.1408635462320; Thu, 21 Aug 2014 08:37:42 -0700 (PDT) Received: by 10.107.130.225 with HTTP; Thu, 21 Aug 2014 08:37:42 -0700 (PDT) In-Reply-To: <6ff293bc7e0225fc4aa7d6bc741ed5f1.squirrel@mail2.ihtfp.org> References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> <8761hwikk2.fsf@vigenere.g10code.de> <53EB7137.4030602@braverock.com> <577ab0e4ed6764aeca8f21088b5c8b16.squirrel@mail2.ihtfp.org> <6ff293bc7e0225fc4aa7d6bc741ed5f1.squirrel@mail2.ihtfp.org> Date: Thu, 21 Aug 2014 11:37:42 -0400 Message-ID: From: David Leon Gil To: Derek Atkins , "openpgp@ietf.org" Content-Type: multipart/alternative; boundary=20cf30334b49598aaa0501258016 Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/ZbmD2q0H7SPO71lujD0AMMNu21c Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 21 Aug 2014 15:37:45 -0000 --20cf30334b49598aaa0501258016 Content-Type: text/plain; charset=UTF-8 Sorry, I wasn't entirely clear; for this case a certification signature would be nonsensical. But a direct key signature would. Perhaps: > A key capable of making signatures SHOULD be accompanied by either a certification signature or a signature directly on the key. An implementation MUST allow importing a key accompanied either by a certification signature or a signature on itself. It MAY accept public keys without an accompanying signature. And then a must accept for encryption-only primary keys sans signature. On Wednesday, August 13, 2014, Derek Atkins wrote: > > On Wed, August 13, 2014 12:01 pm, David Leon Gil wrote: > > On Wednesday, August 13, 2014, Derek Atkins > wrote: > > > >> > >> I am suggesting a *NEW* I-D (which will hopefully be progressed into an > >> RFC) that would extend RFC4880 and loosen the v4 key restrictions in > >> section 12.1 that require a UserID+Self-Signature on a Primary Key. > >> > >> So, any other comments? > >> > > > > I support the proposal so far as it concerns *encryption* keys as primary > > keys; I'd prefer if the MUST support were limited to ECDH keys. > > > > I don't really see much point in permitting *signing* keys without a > > proof-of-possession. (If the key isn't able to sign a PoP, what can it > > do?) > > While I consider this a reasonable restriction, in my use case there is no > need for self-certification. Devices don't have self-identities, only the > keys; identities are supplied by third parties. However I am willing to > make it a "SHOULD Self-Certify" for a key that is capable of signatures to > make it clear that in the general case you should still self-sign when you > can. > > Does that work for you? > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > --20cf30334b49598aaa0501258016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I wasn't entirely clear; for this case a certification signature= would be nonsensical. But a direct key signature would.=C2=A0Perhaps:
=
=C2=A0 =C2=A0 =C2=A0>=C2=A0A key capable of making signat= ures SHOULD be accompanied by either a certification=C2=A0signature or a si= gnature directly on the key. An implementation MUST allow importing=C2=A0a = key accompanied either=C2=A0by a certification signature or a signature on = itself. It MAY accept public keys without an accompanying=C2=A0signature.

And then a must accept=C2=A0for encryption-only primary keys= sans signature.

On Wednesday, August 13, 201= 4, Derek Atkins <derek@ihtfp.com&= gt; wrote:

On Wed, August 13, 2014 12:01 pm, David Leon Gil wrote:
> On Wednesday, August 13, 2014, Derek Atkins <derek@i= htfp.com> wrote:
>
>>
>> I am suggesting a *NEW* I-D (which will hopefully be progressed in= to an
>> RFC) that would extend RFC4880 and loosen the v4 key restrictions = in
>> section 12.1 that require a UserID+Self-Signature on a Primary Key= .
>>
>> So, any other comments?
>>
>
> I support the proposal so far as it concerns *encryption* keys as prim= ary
> keys; I'd prefer if the MUST support were limited to ECDH keys. >
> I don't really see much point in permitting *signing* keys without= a
> proof-of-possession. (If the key isn't able to sign a PoP, what ca= n it
> do?)

While I consider this a reasonable restriction, in my use case there is no<= br> need for self-certification.=C2=A0 Devices don't have self-identities, = only the
keys; identities are supplied by third parties.=C2=A0 However I am willing = to
make it a "SHOULD Self-Certify" for a key that is capable of sign= atures to
make it clear that in the general case you should still self-sign when you<= br> can.

Does that work for you?

-derek
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.com=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant

--20cf30334b49598aaa0501258016-- From nobody Thu Aug 21 13:47:49 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55601A8A05 for ; Thu, 21 Aug 2014 13:47:48 -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 M0N43llP4mdL for ; Thu, 21 Aug 2014 13:47: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 282021A8A1F for ; Thu, 21 Aug 2014 13:47:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0030FE2033; Thu, 21 Aug 2014 16:47: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 18202-06; Thu, 21 Aug 2014 16:47:44 -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 1F17CE2031; Thu, 21 Aug 2014 16:47:44 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s7LKlhqI029567; Thu, 21 Aug 2014 16:47:43 -0400 From: Derek Atkins To: David Leon Gil References: <87mwbkh9cq.fsf@vigenere.g10code.de> <87zjfkdnsv.fsf@vigenere.g10code.de> <871tskn69z.fsf@vigenere.g10code.de> <0ce6dcb465129426f8e19cc64ad3853f.squirrel@mail2.ihtfp.org> <8761hwikk2.fsf@vigenere.g10code.de> <53EB7137.4030602@braverock.com> <577ab0e4ed6764aeca8f21088b5c8b16.squirrel@mail2.ihtfp.org> <6ff293bc7e0225fc4aa7d6bc741ed5f1.squirrel@mail2.ihtfp.org> Date: Thu, 21 Aug 2014 16:47:43 -0400 In-Reply-To: (David Leon Gil's message of "Thu, 21 Aug 2014 11:37:42 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/CuFm4S2LYBflmcegXf7eLBb0J2w Cc: "openpgp@ietf.org" Subject: Re: [openpgp] ECDH and ELG-E primary keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 21 Aug 2014 20:47:49 -0000 David Leon Gil writes: > Sorry, I wasn't entirely clear; for this case a certification signature w= ould > be nonsensical. But a direct key signature would.=C2=A0Perhaps: > > =C2=A0 =C2=A0 =C2=A0>=C2=A0A key capable of making signatures SHOULD be a= ccompanied by either a > certification=C2=A0signature or a signature directly on the key. An imple= mentation > MUST allow importing=C2=A0a key accompanied either=C2=A0by a certificatio= n signature or > a signature on itself. It MAY accept public keys without an > accompanying=C2=A0signature. > > And then a must accept=C2=A0for encryption-only primary keys sans signatu= re. Okay, I think I get the gist of this and I'll incorporate it into my draft, which I plan to submit (hopefully) tomorrow. Please read the draft once it's posted and make sure I got it right? Thanks for your feedback. -derek --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Thu Aug 28 13:09:45 2014 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4145F1A014C for ; Thu, 28 Aug 2014 13:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.11 X-Spam-Level: *** X-Spam-Status: No, score=3.11 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_DOMAIN=2.3, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ4q2YndjDM2 for ; Thu, 28 Aug 2014 13:09:35 -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 31F491A0175 for ; Thu, 28 Aug 2014 13:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0A2AEE2031 for ; Thu, 28 Aug 2014 16:09:34 -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 01516-03 for ; Thu, 28 Aug 2014 16:09:31 -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 625A9E200A for ; Thu, 28 Aug 2014 16:09:31 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s7SK9Vuk026122; Thu, 28 Aug 2014 16:09:31 -0400 From: Derek Atkins To: openpgp@ietf.org Date: Thu, 28 Aug 2014 16:09:31 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/tqK6RaprYeay_eS-lPM3Ul70W08 Subject: [openpgp] OpenPGP extension to allow for Primary Encrypt-only Keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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 Aug 2014 20:09:39 -0000 --=-=-= Content-Type: text/plain Hi, I just posted an internet draft to loosen the RFC4880 restriction that requires self-certification on primary keys (among other things). The primary goal of this draft is to allow "third-party" certification of (potentially encryption-only) device keys, so in addition to allowing encrypt-only primary keys it also attempts to register some notation data for the certification parts. Another thing it does is add a new "User ID Attribute" type to the User Attributes list so that you could use a single signature to certify both an "ID" and an image together. I've attached the document for your review. This document should already have taken into account the converations we had a couple weeks ago about ECDSA and ECDH keys. Please send me your comments and reviews, Thanks! -derek --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=draft-atkins-openpgp-device-certificates-00.txt Content-Description: draft-atkins-openpgp-device-certificates-00.txt Internet Engineering Task Force D. Atkins Internet-Draft SecureRF Corporation Updates: 4880 (if approved) August 28, 2014 Intended status: Standards Track Expires: March 01, 2015 OpenPGP Extensions for Device Certificates draft-atkins-openpgp-device-certificates-00 Abstract The OpenPGP Message Formats defined in RFC 4880 specify packet formats and methods for combining those packets to form messages and certificates. However RFC 4880 made an architectural decision that keys are owned by users and must be self-certified. New use cases have emerged where that is not the case. There is a desire to have certificates that are not tied to a user (e.g. device certificates) and may only have encryption keys so may not even be self certifiable. This draft specifies extensions to (and updates) RFC 4880 that loosen the definitions of certificates in order to enable userless certificates without self-certifications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 01, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Atkins Expires March 01, 2015 [Page 1] Internet-Draft OpenPGP Device Certificates August 2014 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Device Certificate Format . . . . . . . . . . . . . . . . . . 3 3. User ID Attribute Subpacket . . . . . . . . . . . . . . . . . 3 4. Device Certification Notations . . . . . . . . . . . . . . . 4 4.1. The 'manu' Notation . . . . . . . . . . . . . . . . . . . 4 4.2. The 'make' Notation . . . . . . . . . . . . . . . . . . . 4 4.3. The 'model' Notation . . . . . . . . . . . . . . . . . . 5 4.4. The 'vers' Notation . . . . . . . . . . . . . . . . . . . 5 4.5. The 'loc' and 'dest' Notations . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6.1. PGP User Attribute Types . . . . . . . . . . . . . . . . 5 6.2. Signature Notation Data Subpacket Types . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction OpenPGP [RFC4880] defines a standard, compact format for, among other things, sharing keys and signature certificates. Unfortunately the specification is user-focused, assuming that there are people sitting at the ends and creating and managing those keys. New use cases have come up where that is not the case and the endpoint for these keys are devices, not users. Yet we still want to be able to certify these device keys. Since the publication of RFC 4880, new use cases have emerged that don't fit into the existing standard models. For example, the Internet of Things have introduced devices that need to certify device-level encryption keys but cannot self-certify and have no user associated. This draft suggests extensions to RFC 4880 that enable those use cases and make it easier to have device certificates using OpenPGP. Atkins Expires March 01, 2015 [Page 2] Internet-Draft OpenPGP Device Certificates August 2014 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Device Certificate Format RFC 4880 section 12.1 defines a v4 Public Key Format as a sequence of packets starting with a Primary Key and then a sequence of packets and subpackets that add Revocations, User IDs, and Signatures. The description in RFC 4880 requires a User ID. Implementors of this specification can loosen that requirement such that an augmented V4 device certificate looks like the following sequence (no longer requiring a User ID packet): Primary-Key [Revocation Self Signature] [Direct Key Signature...] [User ID [Signature ...] ...] [User Attribute [Signature ...] ...] [[Subkey [Binding-Signature-Revocation] Primary-Key-Binding-Signature] ...] Note that RFC 4880 section 11.1 defines this same sequence in text for transferable public keys. Implementors of this specification can change that definition from "One or more User ID packets" to "Zero or more User ID packets". Moreover, one more relaxation from section 12.1. RFC 4880 states that "In a V4 key, the primary key MUST be a key capable of certification." Implementors of this specification can loosen that restriction as well, such that in V4 augmented key, the primary key MAY be a key capable of certification. A primary key capable of making signatures SHOULD be accompanied by either a certification signature (on a User ID or User Attribute) or a signature directly on the key. An implementation MUST allow importing a key accompanied either by a certification signature or a signature on itself. It MAY accept public keys without an accompanying signature. Implementations MUST accept encryption-only primary keys without a signature. 3. User ID Attribute Subpacket Atkins Expires March 01, 2015 [Page 3] Internet-Draft OpenPGP Device Certificates August 2014 Section 5.12 of RFC 4880 defines the User Attribute Packet which can be used in lieu of a User ID Packet. Whereas the User ID Packet only allows a single UTF-8 string content, the User Attribute Packet allows the addition of multiple attributes in subtype packets. Unfortunately RFC 4880 only defined a single Attribute Subpacket, the Image Attribute. This means that you need two signatures if you want to have an ID and an image. To solve that problem for device certificates we define a new User Attribute Subpacket, the User ID Attribute Subpacket, type #[IANA -- assignment TBD1]. A User ID Attribute subpacket, just like a User ID packet, consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. For devices, it may be the device identifier. The packet length in the header specifies the length of the User ID. 4. Device Certification Notations OpenPGP defines a signature notation data packet that allows implementors and users to add extra data to signatures. RFC 4880 defined a registry for a global namespace and requires using name@dom.ain domain-name notations otherwise. Many of the devices targeted by this specification have limited storage capability, so it behooves an implementor to limit the extraneous storage. These notation can be important when you have a third-party device certification. That third party might want to add extra data about the device to its signature certification. In order to keep the certificate smaller we define a set of notations that MAY be used when signing a device certificate. 4.1. The 'manu' Notation The "manu" notation is a string that declares the device manufacturer's name. The certifier key is asserting this string (which may or may not be related to the User ID of the certifier's key). 4.2. The 'make' Notation This notation defines the product make. It is a free form string. Atkins Expires March 01, 2015 [Page 4] Internet-Draft OpenPGP Device Certificates August 2014 4.3. The 'model' Notation This notation defines the product model name/number. It is a free form string. 4.4. The 'vers' Notation This notation defines the product version number (which could be a release number, year, or some other identifier to differentiate different versions of the same make/model). It is a free form string. 4.5. The 'loc' and 'dest' Notations The "loc" and 'dest' notations declare a GeoLocation as defined by RFC 5870 [RFC5870] but without the leading "geo:" header. For example, if you had a GeoLocation URI of "geo:13.4125,103.8667" you would encode that in these notations as "13.4125,103.8667". The 'loc' notation is meant to encode the geo location where the signature was made. The 'dest' notation is meant to encode the geo location where the device is "destined" (i.e., a "destination" for the device). 5. Acknowledgements A big thank you to Werner Koch, David Shaw, Jon Callas, and David Leon Gil for their input on the concepts and text of this document. 6. IANA Considerations This document requests IANA to register several items within the OpenPGP parameters (or the "name space" in the terminology of [RFC5226]) created by [RFC4880]. 6.1. PGP User Attribute Types This specification asks IANA to register a PGP User Attribute Type: +-------+-----------+--------------------+ | Value | Attribute | Reference | +-------+-----------+--------------------+ | TBD1 | User ID | This Doc Section 3 | +-------+-----------+--------------------+ Table 1: User Attribute Types Atkins Expires March 01, 2015 [Page 5] Internet-Draft OpenPGP Device Certificates August 2014 6.2. Signature Notation Data Subpacket Types This specification asks IANA to register a set of OpenPGP Signature Notation Data Subpacket Types defined in Section 4. The following table is a summary of the requested registrations. +---------------+-------+----------------------------+--------------+ | Allowed | Name | Type | Reference | | Values | | | | +---------------+-------+----------------------------+--------------+ | Any String | manu | Manufacturer Name | This doc | | | | | Section 4.1 | | Any String | make | Product Make | This doc | | | | | Section 4.2 | | Any String | model | Product Model | This doc | | | | | Section 4.3 | | Any String | vers | Product Version | This doc | | | | | Section 4.4 | | A geo: URI | loc | Current Geo-location | This doc | | without the | | Latitude/Longitude | Section 4.5 | | "geo:" | | | | | A geo: URI | dest | Destination Geo-location | This doc | | without the | | Latitude/Longitude | Section 4.5 | | "geo:" | | | | +---------------+-------+----------------------------+--------------+ Table 2: Device Certificate Notations 7. Security Considerations OpenPGP was designed with security in mind, with many smart, intelligent people spending a lot of time thinking about the ramifications of their decisions. Removing the requirement for self- certifying User ID (and User Attribute) packets on a key means that someone could surreptitiously add an unwanted ID to a key and sign it. If enough "trusted" people sign that surreptitious identity then other people might believe it. The attack could wind up sending encrypted mail destined for alice to some other target, bob, because someone added "alice" to bob's key without bob's consent. In the case of device certificates the device itself does not have any consent. It is given an identity by the device manufacturer and the manufacturer can insert that ID on the device certificate, signing it with the manufacturer's key. If another people wants to label the device by another name, they can do so. There is no harm in multiple IDs, because the verification is all done based on who has signed those IDs. Atkins Expires March 01, 2015 [Page 6] Internet-Draft OpenPGP Device Certificates August 2014 When a key can self-sign, it is still suggested to self-certify IDs, even if it no longer required by this modification to OpenPGP. This at least signals to recipients of keys that yes, the owner of this key asserts that this identity belongs to herself. Note, however, that mallet could still assert that he is 'alice' and could even self-certify that. So the attack is not truly different. Moreover, in the case of device certificates, it's more the manufacturer than the device that wants to assert an identity (even if the device could self-certify). There is no signaling whether a key is using this new, looser- requirement key format. An attacker could therefore just remove the self-signature off a published key. However one would hope that wide publication would result in another copy still having that signature and it being returned quickly. However, the lack of signaling also means that a user with an application following RFC 4880 directly would see a key following this specification as "broken" and may not accept it. On a different note, including the "geo" notation could leak information about where a signer is located. However it is just an assertion (albeit a signed assertion) so there is no verifiable truth to the location information released. Similarly, all the rest of the signature notations are pure assertions, so they should be taken with the trustworthiness of the signer. Combining the User ID with the User Attribute means that an ID and image would not be separable. For a person this is probably not good, but for a device it's unlikely the image will change so it makes sense to combine the ID and image into a single signed packet with a single signature. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 8.2. Informative References Atkins Expires March 01, 2015 [Page 7] Internet-Draft OpenPGP Device Certificates August 2014 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010. Author's Address Derek Atkins SecureRF Corporation 100 Beard Sawmill Rd, Suite 350 Shelton, CT 06484 US Phone: +1 617 623 3745 Email: datkins@securerf.com, derek@ihtfp.com Atkins Expires March 01, 2015 [Page 8] --=-=-= Content-Type: text/plain -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=--