From nobody Mon Sep 1 05:21: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 5B6B11A0278 for ; Mon, 1 Sep 2014 05:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDAENFxXTZBY for ; Mon, 1 Sep 2014 05:21:45 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76E71A0295 for ; Mon, 1 Sep 2014 05:21:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XOQcB-0004Ki-4X for ; Mon, 01 Sep 2014 14:21:43 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XOQVv-0004jZ-Dl; Mon, 01 Sep 2014 14:15:15 +0200 From: Werner Koch To: Derek Atkins 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, 01 Sep 2014 14:15:15 +0200 In-Reply-To: (Derek Atkins's message of "Thu, 28 Aug 2014 16:09:31 -0400") Message-ID: <87zjejo7u4.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/PpZf6PBwtGUgKar73lXAqBGpJsw Cc: openpgp@ietf.org Subject: Re: [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: Mon, 01 Sep 2014 12:21:47 -0000 On Thu, 28 Aug 2014 22:09, derek@ihtfp.com said: > 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. Is the intention that a user ID attribute shall in general be handled the same way as a user id packet? This would raise the question whether a certification is based on only or all the user id, the image, or any future sub packets. Given that you assume certain constrains on an implementation, the intended use would require only a self-signature. Can you clarify that in the draft? 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. I would suggest to use a different name. "vers" might be confused with the protocol or key version, what about "mver", "pver, or "pvers"? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Sep 1 06:13: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 3EF331A03E0 for ; Mon, 1 Sep 2014 06:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2J_2GV9plyy for ; Mon, 1 Sep 2014 06:13: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 883991A03DF for ; Mon, 1 Sep 2014 06:13:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C1D93E2031; Mon, 1 Sep 2014 09:13:32 -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 24057-04; Mon, 1 Sep 2014 09:13:30 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 4AB5EE2034; Mon, 1 Sep 2014 09:13:30 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 1 Sep 2014 09:13:30 -0400 Message-ID: In-Reply-To: <87zjejo7u4.fsf@vigenere.g10code.de> References: <87zjejo7u4.fsf@vigenere.g10code.de> Date: Mon, 1 Sep 2014 09:13:30 -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/PAmx8lbkcYD0fnjVYkypV1v9iB0 Cc: openpgp@ietf.org Subject: Re: [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: Mon, 01 Sep 2014 13:13:38 -0000 Hi, On Mon, September 1, 2014 8:15 am, Werner Koch wrote: > On Thu, 28 Aug 2014 22:09, derek@ihtfp.com said: > >> 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. > > Is the intention that a user ID attribute shall in general be handled > the same way as a user id packet? This would raise the question whether > a certification is based on only or all the user id, the image, or any > future sub packets. Given that you assume certain constrains on an > implementation, the intended use would require only a self-signature. > Can you clarify that in the draft? RFC4880 already says that that the User Attribute Packet should be treated the same as the User ID Packet and can be used in all the places that a User ID Packet can be used. I'm just trying to add a place where you could insert an actual "User ID" into the attribute packet so you don't need two signatures to have both an ID and Image (and other attributes). I don't think there is any confusion; a signature over the User Attribute Packet would be a signatue over the whole packet (meaning all subpackets in the attribute). However I can make this more clear. > 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. > > I would suggest to use a different name. "vers" might be confused with > the protocol or key version, what about "mver", "pver, or "pvers"? I'm not sure how it would get confused, but I'm not tied to "vers". I'll change it to pver. I'm also adding a bunch more. I'll submit a new draft tomorrow; today is a holiday to technically I'm not working ;) Thank you for your review sand comments. > > 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 Mon Sep 1 09:07:06 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 0D0951A02A3 for ; Mon, 1 Sep 2014 09:07:01 -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 18dZiAe8Y8cp for ; Mon, 1 Sep 2014 09:06:54 -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 94D811A02DC for ; Mon, 1 Sep 2014 09:06:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XOU7u-0007e6-PY for ; Mon, 01 Sep 2014 18:06:42 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XOU3I-0005Hq-Up; Mon, 01 Sep 2014 18:01:56 +0200 From: Werner Koch To: "Derek Atkins" References: <87zjejo7u4.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, 01 Sep 2014 18:01:56 +0200 In-Reply-To: (Derek Atkins's message of "Mon, 1 Sep 2014 09:13:30 -0400") Message-ID: <87mwajnxcb.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/Wpv_fWFlOnAHQbeuGMi4tKyxviY Cc: openpgp@ietf.org Subject: Re: [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: Mon, 01 Sep 2014 16:07:01 -0000 On Mon, 1 Sep 2014 15:13, derek@ihtfp.com said: > RFC4880 already says that that the User Attribute Packet should be treated > the same as the User ID Packet and can be used in all the places that a > User ID Packet can be used. I'm just trying to add a place where you Alright. I was in GnuPG and not in standard mode. GnuPG skips the attribute packets for trust computations because it would be surprising if your key is valid because someone signed you photo and you don't even see your photo on the command line. We may need to reconsider this if people start using the WoT based on your new user ID attribute. > I'm not sure how it would get confused, but I'm not tied to "vers". I'll For example, we have a "Version:" armor header and "vers" looks like some kind of abbreviation. Right, they have technically nothing in common but the notation will be listed and the armor headers may also be noticed by the user. No big deal, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Sep 2 10:27:25 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 48B1A1A8742 for ; Tue, 2 Sep 2014 10:27:18 -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 hFL-_olJ3NEr for ; Tue, 2 Sep 2014 10:27:17 -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 88C081A8752 for ; Tue, 2 Sep 2014 10:27:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 53B12E2034; Tue, 2 Sep 2014 13:27:12 -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 32130-03; Tue, 2 Sep 2014 13:27:10 -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 B546FE2031; Tue, 2 Sep 2014 13:27:10 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s82HRAXo015261; Tue, 2 Sep 2014 13:27:10 -0400 From: Derek Atkins To: Werner Koch References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> Date: Tue, 02 Sep 2014 13:27:10 -0400 In-Reply-To: <87mwajnxcb.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 01 Sep 2014 18:01:56 +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/7Mg_pqsA7xcfn40Ysp9bTCWD3i0 Cc: openpgp@ietf.org Subject: Re: [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: Tue, 02 Sep 2014 17:27:19 -0000 Hi, Werner Koch writes: > On Mon, 1 Sep 2014 15:13, derek@ihtfp.com said: > >> RFC4880 already says that that the User Attribute Packet should be treated >> the same as the User ID Packet and can be used in all the places that a >> User ID Packet can be used. I'm just trying to add a place where you > > Alright. I was in GnuPG and not in standard mode. GnuPG skips the > attribute packets for trust computations because it would be surprising > if your key is valid because someone signed you photo and you don't even > see your photo on the command line. We may need to reconsider this if > people start using the WoT based on your new user ID attribute. I added this text: Note that RFC 4880 already allows an User Attribute packet anywhere a User ID packet can be used. See RFC 4880 section 5.2.3.19 (Primary User ID) for more information on self-signatures over these kinds of packets. Any signature on a User Attribute packet covers all subpackets. Implementations MAY decide to trust the User ID Subpacket. >> I'm not sure how it would get confused, but I'm not tied to "vers". I'll > > For example, we have a "Version:" armor header and "vers" looks like > some kind of abbreviation. Right, they have technically nothing in > common but the notation will be listed and the armor headers may also be > noticed by the user. No big deal, though. Let me think more on this as I revise the draft. I'll get another copy out later today. > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Sep 2 12:44: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 747BD1A8875 for ; Tue, 2 Sep 2014 12:44:30 -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 jG8bRr80tDCa for ; Tue, 2 Sep 2014 12:44:27 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB14E1A886B for ; Tue, 2 Sep 2014 12:44:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 94BD4E2033; Tue, 2 Sep 2014 15:44:25 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32690-06; Tue, 2 Sep 2014 15:44:21 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id E00C3E2031; Tue, 2 Sep 2014 15:44:21 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s82JiLfh024022; Tue, 2 Sep 2014 15:44:21 -0400 From: Derek Atkins To: Werner Koch References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> Date: Tue, 02 Sep 2014 15:44:21 -0400 In-Reply-To: <87mwajnxcb.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 01 Sep 2014 18:01:56 +0200") 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/MXfLvDwadcLfHD4ew-uGUGZzXnw Cc: openpgp@ietf.org Subject: [openpgp] Updated Draft (was Re: 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: Tue, 02 Sep 2014 19:44:31 -0000 --=-=-= Content-Type: text/plain Hi, Attached please find the -01 version of this draft. This version: * changed 'vers' notation to 'pvers' * added some new notations (prodid, lot, qty, and hash) * added some text about signatures over the User (ID) Attribute (sub)packet per our conversation Please send me any additional comments. Thanks, -derek --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=draft-atkins-openpgp-device-certificates-01.txt Content-Description: device certificates Internet Engineering Task Force D. Atkins Internet-Draft SecureRF Corporation Updates: 4880 (if approved) September 02, 2014 Intended status: Standards Track Expires: March 06, 2015 OpenPGP Extensions for Device Certificates draft-atkins-openpgp-device-certificates-01 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 06, 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 06, 2015 [Page 1] Internet-Draft OpenPGP Device Certificates September 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 . . . . . . . . . . . . . . . . . 4 4. Device Certification Notations . . . . . . . . . . . . . . . 4 4.1. The 'manu' Notation . . . . . . . . . . . . . . . . . . . 4 4.2. The 'make' Notation . . . . . . . . . . . . . . . . . . . 5 4.3. The 'model' Notation . . . . . . . . . . . . . . . . . . 5 4.4. The 'prodid' Notation . . . . . . . . . . . . . . . . . . 5 4.5. The 'pvers' Notation . . . . . . . . . . . . . . . . . . 5 4.6. The 'lot' Notation . . . . . . . . . . . . . . . . . . . 5 4.7. The 'qty' Notation . . . . . . . . . . . . . . . . . . . 5 4.8. The 'loc' and 'dest' Notations . . . . . . . . . . . . . 5 4.9. The 'hash' Notation . . . . . . . . . . . . . . . . . . . 5 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. PGP User Attribute Types . . . . . . . . . . . . . . . . 6 6.2. Signature Notation Data Subpacket Types . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 Atkins Expires March 06, 2015 [Page 2] Internet-Draft OpenPGP Device Certificates September 2014 those use cases and make it easier to have device certificates using OpenPGP. 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. Atkins Expires March 06, 2015 [Page 3] Internet-Draft OpenPGP Device Certificates September 2014 3. User ID Attribute Subpacket 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. Note that RFC 4880 already allows an User Attribute packet anywhere a User ID packet can be used. See RFC 4880 section 5.2.3.19 (Primary User ID) for more information on self-signatures over these kinds of packets. Any signature on a User Attribute packet covers all subpackets. Implementations MAY decide to trust the User ID Subpacket. 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). Atkins Expires March 06, 2015 [Page 4] Internet-Draft OpenPGP Device Certificates September 2014 4.2. The 'make' Notation This notation defines the product make. It is a free form string. 4.3. The 'model' Notation This notation defines the product model name/number. It is a free form string. 4.4. The 'prodid' Notation This notation contains the product identifier. It is a free form string. 4.5. The 'pvers' 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.6. The 'lot' Notation This notation defines the product lot number (which is an indicator of the batch of product). It is a free form string. 4.7. The 'qty' Notation This notation defines the quantity of items in this package. It is a decimal integer representation with no punctuation, e.g. "10", "1000", "10000", etc. 4.8. 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). 4.9. The 'hash' Notation A 'hash' notation is a means to include external data in the contents of a signature without including the data itself. This is done by Atkins Expires March 06, 2015 [Page 5] Internet-Draft OpenPGP Device Certificates September 2014 hashing the external data separately and then including the data's name and hash in the signature via this notation. This is useful, for example, to have an external "manifest," "image," or other data that might not be vital to the signature itself but still needs to be protected and authenticated without requiring a second signature. The 'hash' notation has the following structure: o A single byte specifying the length of the name of the hashed data o A UTF-8 string of the name of the hashed data o A single byte specifying the hash algorithm (see RFC 4880 section 9.4) o The binary hash output of the hashed data using the specified algorithm. (The length of this data is implicit based on the algorithm specified). Due to its nature a 'hash' notation is not human readable and MUST NOT be marked as such when used. 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 6.2. Signature Notation Data Subpacket Types Atkins Expires March 06, 2015 [Page 6] Internet-Draft OpenPGP Device Certificates September 2014 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 | prodid | Product ID | This doc | | | | | Section 4.4 | +--------------+---------+--------------------------+---------------+ | Any String | pvers | Product Version | This doc | | | | | Section 4.5 | +--------------+---------+--------------------------+---------------+ | Any String | lot | Product Lot Number | This doc | | | | | Section 4.6 | +--------------+---------+--------------------------+---------------+ | Decimal | qty | Package Quantity | This doc | | Integer | | | Section 4.7 | | String | | | | +--------------+---------+--------------------------+---------------+ | A geo: URI | loc | Current Geo-location | This doc | | without the | | Latitude/Longitude | Section 4.8 | | "geo:" | | | | +--------------+---------+--------------------------+---------------+ | A geo: URI | dest | Destination Geo-location | This doc | | without the | | Latitude/Longitude | Section 4.8 | | "geo:" | | | | +--------------+---------+--------------------------+---------------+ | Hash | hash | The Hash of external | This doc | | Notation | | data | Section 4.9 | | data | | | | +--------------+---------+--------------------------+---------------+ Table 2: Device Certificate Notations 7. Security Considerations The Security Considerations of [RFC4880] apply. Atkins Expires March 06, 2015 [Page 7] Internet-Draft OpenPGP Device Certificates September 2014 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. 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. Atkins Expires March 06, 2015 [Page 8] Internet-Draft OpenPGP Device Certificates September 2014 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 [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 06, 2015 [Page 9] --=-=-= Content-Type: text/plain -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=-- From nobody Mon Sep 8 06:46: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 378461A87D1 for ; Mon, 8 Sep 2014 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h70YNoD4K6G8 for ; Mon, 8 Sep 2014 06:46:48 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7DB1A87D5 for ; Mon, 8 Sep 2014 06:46:47 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XQzHK-00019G-0n for ; Mon, 08 Sep 2014 15:46:46 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XQzEG-0001MH-Il; Mon, 08 Sep 2014 15:43:36 +0200 From: Werner Koch To: Derek Atkins References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.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, 08 Sep 2014 15:43:36 +0200 In-Reply-To: (Derek Atkins's message of "Tue, 02 Sep 2014 15:44:21 -0400") Message-ID: <8738c29qif.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/cukl2xu3M3GSTbc6eo4QFSkaKck Cc: openpgp@ietf.org Subject: Re: [openpgp] Updated Draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:46:50 -0000 On Tue, 2 Sep 2014 21:44, derek@ihtfp.com said: > This version: > > * changed 'vers' notation to 'pvers' > * added some new notations (prodid, lot, qty, and hash) > * added some text about signatures over the User (ID) Attribute > (sub)packet per our conversation Fine with me. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Sep 8 08:00:05 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 E083B1A8847 for ; Mon, 8 Sep 2014 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWBia6oTS5pU for ; Mon, 8 Sep 2014 08:00:00 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85EE1A8842 for ; Mon, 8 Sep 2014 08:00:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 40502E2033; Mon, 8 Sep 2014 10:59: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 07586-03; Mon, 8 Sep 2014 10:59: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 19E12E2031; Mon, 8 Sep 2014 10:59:57 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s88ExutZ021535; Mon, 8 Sep 2014 10:59:56 -0400 From: Derek Atkins To: Werner Koch References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> <8738c29qif.fsf@vigenere.g10code.de> Date: Mon, 08 Sep 2014 10:59:56 -0400 In-Reply-To: <8738c29qif.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 08 Sep 2014 15:43:36 +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/DUZDxV8sy5_kmYK1T3p04rGtkhs Cc: openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] Updated Draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 15:00:03 -0000 Werner Koch writes: > On Tue, 2 Sep 2014 21:44, derek@ihtfp.com said: > >> This version: >> >> * changed 'vers' notation to 'pvers' >> * added some new notations (prodid, lot, qty, and hash) >> * added some text about signatures over the User (ID) Attribute >> (sub)packet per our conversation > > Fine with me. Thanks! Now I'm just waiting for input from David Leon Gil who wanted to make some stylistic comments. I've got another draft that I'm ready to submit shortly on encoding Algebraic Eraser public keys. I'll send that out for review later today. Thanks!! > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Sep 9 06:34:11 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 1B8D41A02F0 for ; Tue, 9 Sep 2014 06:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1oXCCe8O3um for ; Tue, 9 Sep 2014 06:34:08 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F8C1A02BE for ; Tue, 9 Sep 2014 06:34:07 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so3040402wgh.20 for ; Tue, 09 Sep 2014 06:34:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=j4j4vnfuXhrl07TeJPrj1PWl5y47ilSezvOZT+oebA0=; b=QreH9gp/rcs0X29svkI0AfxjZ/nntH8PRJhCGVa2rWyUqS55monaV8hJrUr02+A20q 5qYaC4RVIxgzZ59JIBY+IMEz9WUsksWILCccrod5ISKp9JfYUwEckb0HqAvO3n5vkn/Z 6wgZpctVUJ+iUUj4NR6QnPw7upt85PB6a6KRxp9n/cJEibGvA495LRNeBHQUYT+Jdog3 ibrlsFbSqFDbqle4z/JG6UE70nUSpZ3M2uSwPnm3ZyAygpQGdI2OwmQgON1Zk2CD8Z/R 5k3lpd9XFZNF13uVjgusPyXC6MNjQbH0bW4+jUjWvOTV6aaUSuYuo6hC1SkyFvBo9xNI kkKg== X-Gm-Message-State: ALoCoQkI7hElxFyDAQ+OL/wexpa6SAavmjl7LGTV3OmALbq0zAAChDdT6UFVDD9AF8hXmgiBX7kX X-Received: by 10.194.236.132 with SMTP id uu4mr4600751wjc.108.1410269646579; Tue, 09 Sep 2014 06:34:06 -0700 (PDT) Received: from [192.168.1.114] (business-80-99-236-194.business.broadband.hu. [80.99.236.194]) by mx.google.com with ESMTPSA id ky3sm14928164wjb.39.2014.09.09.06.34.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Sep 2014 06:34:05 -0700 (PDT) Message-ID: <540F01CC.9080505@epointsystem.org> Date: Tue, 09 Sep 2014 15:34:04 +0200 From: "Daniel A. Nagy" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T6Wm7ihBTvMgeaRCk69LnfxPCaLB63HCw" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/FXBmrphZ9V4LqrHMDR71nSpfjIQ Subject: Re: [openpgp] Updated Draft (was Re: 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: Tue, 09 Sep 2014 13:34:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T6Wm7ihBTvMgeaRCk69LnfxPCaLB63HCw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Question: Does this specification allow for signature/certification keys without user ID and self-certification? I am a bit confused with the wording. Please indicate in your answer which section allows (or prohibits) such keys. Maybe, we could make it more explicit? Regards, Daniel On 09/02/2014 09:44 PM, Derek Atkins wrote: > Hi, >=20 > Attached please find the -01 version of this draft. >=20 > This version: >=20 > * changed 'vers' notation to 'pvers' > * added some new notations (prodid, lot, qty, and hash) > * added some text about signatures over the User (ID) Attribute > (sub)packet per our conversation >=20 > Please send me any additional comments. >=20 > Thanks, >=20 > -derek=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --T6Wm7ihBTvMgeaRCk69LnfxPCaLB63HCw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlQPAcwACgkQVjtq4DhBLAOg8wCePWKSRa+RT3la8DcoxEiMnUWq 2yAAn1khHmrxW/5tvXBZP6WmpgKKh+Hh =jFZx -----END PGP SIGNATURE----- --T6Wm7ihBTvMgeaRCk69LnfxPCaLB63HCw-- From nobody Tue Sep 9 07:30: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 79E1B1A6FD0 for ; Tue, 9 Sep 2014 07:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX73rmo-9_4T for ; Tue, 9 Sep 2014 07:30:19 -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 236821A6FB7 for ; Tue, 9 Sep 2014 07:30:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7209CE2033; Tue, 9 Sep 2014 10:30:09 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15323-04; Tue, 9 Sep 2014 10:30:04 -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 C9DBAE2031; Tue, 9 Sep 2014 10:30:04 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s89EU4UA007472; Tue, 9 Sep 2014 10:30:04 -0400 From: Derek Atkins To: "Daniel A. Nagy" References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> <540F01CC.9080505@epointsystem.org> Date: Tue, 09 Sep 2014 10:30:04 -0400 In-Reply-To: <540F01CC.9080505@epointsystem.org> (Daniel A. Nagy's message of "Tue, 09 Sep 2014 15:34:04 +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/HoBGiPkMe-dFE8qSMXQEaLFfQQk Cc: openpgp@ietf.org Subject: Re: [openpgp] Updated Draft (was Re: 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: Tue, 09 Sep 2014 14:30:25 -0000 "Daniel A. Nagy" writes: > Question: > > Does this specification allow for signature/certification keys without > user ID and self-certification? Yes, it is allowed. > I am a bit confused with the wording. > Please indicate in your answer which section allows (or prohibits) such > keys. Maybe, we could make it more explicit? Section 2 allows it through the definition of the "Augmented v4 device certificate". Wording suggestions to make it more clear are welcome. I suppose your confusion is my use of the word "can" throughout that section? > Regards, > > Daniel -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Sep 9 08:47: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 23FF71A6FF6 for ; Tue, 9 Sep 2014 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmqG2jv6SLAX for ; Tue, 9 Sep 2014 08:47:20 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4ACB1A6FE4 for ; Tue, 9 Sep 2014 08:47:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A4310E2034 for ; Tue, 9 Sep 2014 11:47:18 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 15728-08 for ; Tue, 9 Sep 2014 11:47:13 -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 DCE8DE2033 for ; Tue, 9 Sep 2014 11:47:13 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s89FlDk1013290; Tue, 9 Sep 2014 11:47:13 -0400 From: Derek Atkins To: openpgp@ietf.org Date: Tue, 09 Sep 2014 11:47:13 -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/uDLc0y_Mar-1MrFoGJ2yz70OPQo Subject: [openpgp] Draft review: Algebraic Eraser keys in 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, 09 Sep 2014 15:47:23 -0000 --=-=-= Content-Type: text/plain Hi, I just posted the attached draft specifying how to encode AEKAP Keys in OpenPGP. AEKAP is a Diffie-Hellman like protocol (so only supports encryption). Reviews and comments are requested. Thanks! -derek --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=draft-atkins-openpgp-algebraic-eraser-00.txt Content-Description: AEKAP in OpenPGP Internet Engineering Task Force D. Atkins Internet-Draft SecureRF Corporation Intended status: Standards Track September 09, 2014 Expires: March 13, 2015 Using Algebraic Eraser in OpenPGP draft-atkins-openpgp-albegraic-eraser-00 Abstract The Algebraic Eraser(TM) is an encryption engine that supports, among other configurations, a Diffie-Hellman-like key agreement protocol. This draft specifies how to encode, store, share, and use Algebraic Eraser Key Agreement Protocol keys in OpenPGP. 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 13, 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. Atkins Expires March 13, 2015 [Page 1] Internet-Draft Algebraic Eraser for OpenPGP September 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Algebraic Eraser . . . . . . . . . . . . . . . . . . . . 3 2.1. E-Multiplication . . . . . . . . . . . . . . . . . . . . 3 2.2. AEKAP Keyset Parameters . . . . . . . . . . . . . . . . . 3 2.3. Generating Key Pairs . . . . . . . . . . . . . . . . . . 4 3. Encoding of Public and Private Keys . . . . . . . . . . . . . 4 3.1. Encoding Bit-Strings . . . . . . . . . . . . . . . . . . 5 3.1.1. Encoding Techniques . . . . . . . . . . . . . . . . . 5 3.1.2. Multi-Byte Entries . . . . . . . . . . . . . . . . . 6 3.2. Encoding Public Keys . . . . . . . . . . . . . . . . . . 6 3.3. Encoding Private Keys . . . . . . . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 9 A.1. Sample key . . . . . . . . . . . . . . . . . . . . . . . 9 A.2. Sample key agreement . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The OpenPGP specification in [RFC4880] defines the use of RSA, Elgamal, and DSA public key algorithms. [RFC6637] adds support for Elliptic Curve Cryptography and specifies the ECDSA and ECDH algorithms. The Algebraic Eraser was first introduced in Key agreement, the Algebraic Eraser, and lightweight cryptography [AAGL] published by the American Mathematical Society in 2004. It describes "a new key agreement protocol suitable for implementation on low-cost platforms which constrain the use of computational resources." This document specifies how to encode, store, and use the Algebraic Eraser(TM) Key Agreement Protocol (AEKAP) in OpenPGP. 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]. Atkins Expires March 13, 2015 [Page 2] Internet-Draft Algebraic Eraser for OpenPGP September 2014 2. The Algebraic Eraser The Algebraic Eraser brings together the Braid Group, Matrices, and operations over small Finite Fields to produce an algorithm that executes linear in time with the increase in key size. A complete description of the Algebraic Eraser is available in [AAGL]. 2.1. E-Multiplication The Algebraic Eraser defines an operation called "E-Multiplication" upon which the algorithm is based (see [AAGL]). E-Multiplication (denoted herein by *) takes one matrix (M0) and permutation (S0) and operates on a second matrix (M1) and permutation (S1), resulting in another matrix (M2) and permutation (S2). In other words: (M0,S0) * (M1,S1) = (M2,S2). 2.2. AEKAP Keyset Parameters AEKAP Keyset Parameters are similar to Diffie-Hellman cyclic groups of prime order or ECC curves. Just as users must choose the same DH prime or ECC curve in order to communicate, similarly participants in the AEKAP must be using the same Keyset Parameters. The first basic set of parameters is the chosen Braid Group and Field Size, BnFq, where n is the number of strands in the chosen braid (also called the braid index) and q is the size of the field in use. The field size, q, must be a power of a prime. Generally it is 2^r (where r is a small integer) although this is not a requirement. For example, one might choose B10F8 or B16F32. This is like choosing how many bits to use when generating a prime for Diffie-Hellman. Once the BnFq space is chosen then the Keyset Parameters can be generated by a trusted third party (TTP). First they generate an n-by-n matrix (M) where each entry in the matrix is a member of the field Fq. Then the TTP generates at least two sets of braid conjugates, Ca and Cb, where each conjugate in Ca commutes with each conjugate in Cb. The conjugates are lists of "braid words", or "Artin generators" within the Bn braid group. The TTP generates La conjugates for set Ca and Lb conjugates for set Cb, where the numbers La and Lb MAY be different. The public Keyset Parameters are the Matrix and conjugate sets and must be available to generate keys that can communicate. These Keysets MAY be published and named, but MUST be numbered with an OID. For two users to execute the AEKAP they MUST generate keys from the same Keyset and they MUST choose from different conjugate sets within Atkins Expires March 13, 2015 [Page 3] Internet-Draft Algebraic Eraser for OpenPGP September 2014 that Keyset. I.e., for Alice and Bob to complete the AEKAP Alice must generate her key from Ca and Bob must generate his key from Cb. This document does not specify any particular Keyset Parameters that MUST be implemented. 2.3. Generating Key Pairs The Algebraic Eraser has a two-part Private Key and a two-part Public Key. The Public key is then generated from the two Private Keys. To generate the 1st private key you generate a random polynomial and apply that to the public matrix from the keyset within the keyset field. This results in an nxn matrix where each entry in the matrix is a member of the field Fq. The key search space for the 1st private key is 2^nr (where q=2^r). To generate the 2nd private key you choose a random set of conjugates (and inverses) and string them together. This results in a long string of Artin generators (and inverses). You MAY reduce the string if you so choose using the Dehornoy reduction [Dehornoy]. The search space of the 2nd private key is (2k)^l (where k is the number of published conjugates, and l the number of chosen conjugates and inverses). The Public Key is computed by an E-Multiplication of the 1st private key and the 2nd private key, where the 2nd private key is iteratively processed. Each Artin generator in the 2nd private key is associated to a specific Colored Burau (CB) matrix and permutation (see [AAGL]). The E-multiplication occurs after you substitute the T-values in the CB Matrix with the values in the existing permutation. The result (the public key) is an nxn matrix of Fq and another permutation. Note that the last row of the Public Key Matrix is all zero except for the last entry. When encoding the Public Key you SHOULD ignore those zeros. 3. Encoding of Public and Private Keys Each portion of a key can be reduced to a byte-string (or, more accurately, multiple byte strings). Each matrix can be encoded by stringing together each field element in each row and then stringing each row together. A permutation can be encoded by stringing together each element in the list. The conjugates are also encoded by stringing together each element. The following public key algorithm IDs are added to expand section 9.1 of [RFC4880], "Public-Key Algorithms": Atkins Expires March 13, 2015 [Page 4] Internet-Draft Algebraic Eraser for OpenPGP September 2014 +------+----------------------------+ | ID | Description of Algorithm | +------+----------------------------+ | TBD1 | AEKAP public key algorithm | +------+----------------------------+ Encoding of Public and Private keys MUST use the version 4 packet format (or newer). 3.1. Encoding Bit-Strings The Algebraic eraser uses matrices, fields, and braids that are denoted in bits, particular strings of bits. These objects need to be encoded into bit strings for storage and transmission. The most simplistic method of encoding is to take each field as a byte (or multi-byte word) and string them together. The following sections detail multiple (alternate) ways these bit strings can be encoded to possibly reduce the space used. 3.1.1. Encoding Techniques Depending on the number of bits used per element (which is defined by the braid index and field size), using different encodings of these strings may result in reducing storage space by dropping extra bits and combining elements. For example, when using the finite field F16 each entry can be encoded in exactly one nibble of four (4) bits, so you can easily combine two entries into a single 8-bit byte (called nibble- encoding). This technique could also be used for entries smaller than a nibble, although then you would still have extra (unused) bits. When using the nibble-encoding of an odd number of nibbles the encoding rules MUST specify whether the extra nibble is at the leading or trailing byte. Another encoding option is bit-stealing. This merges all bits together and then cuts it up into 8-bit bytes. For example if the entries are 5 bits each you might steal 3 bits from the second entry to merge into the first, then shift the remaining 2 bits of the second entry, combine with the next 5 bits from the third, and then steal one bit from the fourth entry, and so on, until you've reached the end. This could end up with unused bits at the end of the string. Yet another option is the reverse-bit-stealing, where you start at the end of the string and work your way to the front. This could leave you with unused bits a the front of the string. Atkins Expires March 13, 2015 [Page 5] Internet-Draft Algebraic Eraser for OpenPGP September 2014 Assume you require five (5) bits to encode your numbers, the following table shows how you could could use bit stealing and reverse bit stealing to encode them (where a, b, c, and d are the bits in the first, second, third, and fourth entries) +-----------------------+----------+----------+----------+----------+ | Full Bytes: | 000aaaaa | 000bbbbb | 000ccccc | 000ddddd | +-----------------------+----------+----------+----------+----------+ | Bit stealing: | aaaaabbb | bbcccccd | dddd0000 | | +-----------------------+----------+----------+----------+----------+ | Reverse bit stealing: | 0000aaaa | abbbbbcc | cccddddd | | +-----------------------+----------+----------+----------+----------+ Any unused bits MUST be left as zero (and MUST be checked to be zero). The actual encoding method MUST be defined by the Keyset parameter definition and may change from one keyset parameter to another. The row of zeros in the matrix SHOULD be assumed to "not exist". When using these encoding techniques you SHOULD just tack the last entry of the final row onto the end of the list of entries of the rest of the matrix. This could result in an odd number of entries depending on your n and q choices potentially requiring passing at the start or end of the bit string. 3.1.2. Multi-Byte Entries In the case of entries wider than 8 bits (e.g. a Field parameter greater than 256), the bits are combined in network byte order. However they can still be merged together using the same encoding algorithms from Section 3.1.1 in the case of entries that are not 8-bit multiples. For example, a 12-bit field (F4096) could be combined a nibble at a time, or a 10-bit field (F1024) could use bit- stealing. 3.2. Encoding Public Keys The following algorithm specific packets are added to Section 5.5.2 of [RFC4880], "Public-Key Packet Formats", to support AEKAP: o a variable length field containing a keyset parameter OID, formatted as follows (see [RFC6637] for a full description of the OID encoding method): * a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, Atkins Expires March 13, 2015 [Page 6] Internet-Draft Algebraic Eraser for OpenPGP September 2014 * octets representing a keyset parameter OID o one byte denoting from which set of conjugates in the keyset this key was generated (e.g. the Alice set or the Bob set) o MPI of the public key matrix o MPI of the public key permutation 3.3. Encoding Private Keys The following algorithm specific packets are added to Section 5.5.3 of [RFC4880], "Secret-Key Packet Formats", to support AEKAP: o MPI of the 1st private key (matrix) o MPI of the 2nd private key (conjugate string) 4. Acknowledgements The term "Algebraic Eraser" is a trademark of SecureRF Corporation and is used herein with permission. The author would like to thank Paul Gunnells and Dorian Goldfeld for their tireless efforts to review this document, suggest improvements, and explain to me how to improve my description of how AE works. 5. 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 3. +------+----------------------------+-----------+ | ID | Algorithm | Reference | +------+----------------------------+-----------+ | TBD1 | AEKAP 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.] 6. Security Considerations Atkins Expires March 13, 2015 [Page 7] Internet-Draft Algebraic Eraser for OpenPGP September 2014 The security considerations of [RFC4880] apply accordingly. AEKAP will generate the same session key when used with the same two public/private key pairs. The authors of AE generally recommend that at least one party use an ephemeral key pair in order to prevent the same session key being generated every time. AEKAP is an encryption-only algorithm, therefore it cannot self- certify a key. To have an AEKAP master key you MUST implement [I-D.atkins-openpgp-device-certificates]. When using the generated session key, you MUST only use the bits included in the protocol. You should MUST NOT use any always-zero bits, including those in the last row of the matrix. 7. References 7.1. Normative References [AAGL] Anshel, I., Anshel, M., Goldfeld, D., and S. Lemieux, "Key agreement, the Algebraic Eraser, and lightweight cryptography", 2004, . [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. 7.2. Informative References [Dehornoy] Dehornoy, P., "A fast method for comparing braids", Advances in Mathematics 123, 1997, . [I-D.atkins-openpgp-device-certificates] Atkins, D., "OpenPGP Extensions for Device Certificates", draft-atkins-openpgp-device-certificates-00 (work in progress), August 2014. Atkins Expires March 13, 2015 [Page 8] Internet-Draft Algebraic Eraser for OpenPGP September 2014 Appendix A. Test Vectors To help implementing this specification a non-normative example is provided. This example assumes: o the algorithm id for AEKAP will be 22 o the keyset OID 1.3.6.1.4.1.44196.1.0.0, which defines: * the braid/field as B10F8 * the public key packing is nibble-packed with trailing zeros * the 2nd private key is not bit-packed; it uses bit 7 to define "inverse" and bits 3-0 to define the Artin generator. and gets encoded with length 11 and the following hex bytes: 2B 06 01 04 01 82 D9 24 01 00 00 A.1. Sample key The secret key used for this example is: 1st Private Key Matrix: 4 2 7 4 1 2 7 7 3 5 1 1 5 4 0 5 0 0 3 1 2 7 5 3 4 0 6 0 0 4 6 1 0 7 4 7 7 4 1 1 1 1 7 6 6 2 4 6 5 7 7 5 4 1 7 3 7 5 0 7 1 6 0 7 3 6 4 2 5 6 7 2 3 6 6 6 4 2 7 7 3 7 5 2 2 2 0 7 5 2 6 2nd Private key (in hex): 060481820304050384840506028304050682838485810203048506878807880984 858384828384858383838485068708070809868788888887880586078809080987 880788090809878809030485850384848583838483848506070809878809060506 070809878788860788090687080983040506070809030405060708090203840506 070405060708838484858583848384858586870687080102030405060708098586 878888858586838485858182828282828181828203048586878809080907080607 080984858586860283040586868601820304858586878787870808098102038485 860102030405860708878787878787088181828384858687080607070606060706 070809090607880988090687880907088787080986878809090607080987888687 Atkins Expires March 13, 2015 [Page 9] Internet-Draft Algebraic Eraser for OpenPGP September 2014 878888078806078809868788888886878788888787888807880987880607880909 068708070809098686878807078809090987888686878809880988090906878807 880906878888078806060687880987080808080708098687880909888788090987 880607060607070788090809878809060708098787888686868787878809880909 090607080906878809888888090987880909078809878807880909098788090708 098687880607880908098788888888880909878886078888090607080986878886 868787888809090809878888090607080987888806878809870809868788090607 080987878809880907080987068708090708098686878788888686868686860788 880987880987870687888788860788068788078886078806878888078809868787 878788078806078886070707070788098708080986868607088787870886870886 878708090707088687878787878787080806070886868708090906070809868788 078809090809870809870809870809868788060788090906878809090707880986 878888888788090807080907860788090987080808090908080808080987880707 860707880909098788090986878888880909868788090981828384858687880906 070506050606078607070707048304858607070782038485860781028384850606 070707080809098401828384050607880909040506870881828384858687088708 080102030485060701020384050607080802020101020202020283848586870182 838485868708038485860706070809888809098788098687880485860788090905 060708090708868708098182838485868788078809878807880987880788090403 040303040405068708080985868788090607080806070583040303030304058602 03040584058683048582038485010203040485860582838483840201 The key was created on 2014-09-08 15:24:20 from the tag conjugates (type 1), and thus the fingerprint of the OpenPGP key is: 176D 1360 FBB7 036C C281 8696 8741 94EC A3DF FA7E and the entire public key packet is: 98 4a 04 54 0e 02 64 16 0b 2b 06 01 04 01 82 d9 24 01 00 00 01 01 6e 26 44 05 46 10 02 50 43 37 56 66 37 42 40 10 72 06 14 44 16 67 13 02 70 73 11 00 30 27 47 21 75 35 76 13 13 31 00 60 52 75 24 50 57 23 60 00 25 12 35 76 a8 94 A.2. Sample key agreement The key agreement is created using the sample key against a second (reader) public key. The reader public key has the following data: Matrix (in nibbled-packed hex with trailing zeros): 24 14 13 22 14 67 30 02 20 23 11 26 26 51 20 11 67 40 56 57 60 77 01 04 66 56 71 35 21 27 57 00 55 75 16 40 07 75 05 12 31 35 75 45 66 40 Atkins Expires March 13, 2015 [Page 10] Internet-Draft Algebraic Eraser for OpenPGP September 2014 Permutation (in nibble-packed hex): 32 14 56 78 9a Which results in the following shared secret: Matrix: 4 0 6 5 2 3 0 5 6 0 6 5 5 0 2 0 1 7 5 5 2 0 2 1 1 1 2 7 2 0 4 0 1 2 5 6 6 6 1 2 5 0 1 0 7 4 3 3 3 4 5 1 2 5 3 3 5 5 7 1 1 0 7 1 6 3 4 0 2 1 2 7 5 4 6 7 1 4 7 4 7 1 5 5 3 6 1 4 1 6 5 Permutation (decimal): 3 2 1 5 7 6 10 8 9 4 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 13, 2015 [Page 11] --=-=-= Content-Type: text/plain -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=-- From nobody Tue Sep 9 12:06:01 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 BE1ED1A010F for ; Tue, 9 Sep 2014 12:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8d9scq7_GXJ for ; Tue, 9 Sep 2014 12:05:37 -0700 (PDT) Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CD51A00DD for ; Tue, 9 Sep 2014 12:05:25 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id CA60941F6F for ; Tue, 9 Sep 2014 21:05:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) (using TLS with cipher AES256-GCM-SHA384) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTPS id Huz7HGgymjfu for ; Tue, 9 Sep 2014 21:05:20 +0200 (CEST) Message-ID: <540F501C.7080109@dominikschuermann.de> Date: Tue, 09 Sep 2014 21:08:12 +0200 From: Dominik Schuermann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CJtHiFhBsVGjOUx3F3nTMiU8HqvTLoXu1" Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/sj9wcX0jqjt0_l95oh7r3Mc3jAk Subject: Re: [openpgp] Draft review: Algebraic Eraser keys in 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, 09 Sep 2014 19:05:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CJtHiFhBsVGjOUx3F3nTMiU8HqvTLoXu1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, does AEKAP really qualify to be chosen as an extension to OpenPGP? The outcome of my short literature research shows that there are just a very small group of mathematicians working on the theoretic backgrounds for these kind of braid based crypto. Funnily, I had a short introduction by a mathematics professor some semesters ago, but it sounded far away from practical secure implementations. Here are some papers linked: http://lists.randombit.net/pipermail/cryptography/2012-May/002898.html I don't want to sound offensive, just wondering why you chose to write a draft about this. Regards Dominik On 09/09/2014 05:47 PM, Derek Atkins wrote: > Hi, >=20 > I just posted the attached draft specifying how to encode AEKAP Keys in= > OpenPGP. AEKAP is a Diffie-Hellman like protocol (so only supports > encryption). Reviews and comments are requested. >=20 > Thanks! >=20 > -derek >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --CJtHiFhBsVGjOUx3F3nTMiU8HqvTLoXu1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJUD1AcAAoJEHGMBwEAASKC3JkH/j1plXNLnVMbhSkKGhzRT3yv ZUBpQeG03YfTXf3NtPEI983kinqv+duFE/DYu99zCK9M9RW7hZiO8P5mQLUnoj5A wcVSmI1VdUeLTMl0CJRYWH6RTAge/vfYADGLpD2nuojCyXPn1ZyK+aWFFVs2SAd+ G8GPDiOxTy+7nWDshmulXadwE9ngfxoOa2KF5GnadfxoYHfhu3i+nlOz+EVSsRLp TLAG//DEqcWE6bgWR+8bv51XhrP9kC5RuDkEMmQG7AocN8rZIO1Qv7I7sTGdjxl9 nI+rx62CAD2/glWZiWLwPr2bOTaALf7y/BuGRH9LERVSHh+aZ3LUAw31i8aK7WM= =nrs5 -----END PGP SIGNATURE----- --CJtHiFhBsVGjOUx3F3nTMiU8HqvTLoXu1-- From nobody Tue Sep 9 12:21:51 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 619B01A0197 for ; Tue, 9 Sep 2014 12:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM3dkM-bmhMz for ; Tue, 9 Sep 2014 12:21:46 -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 3A1911A0191 for ; Tue, 9 Sep 2014 12:21:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id BAA23E2031; Tue, 9 Sep 2014 15:21:44 -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 16989-01; Tue, 9 Sep 2014 15:21:42 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 550EBE2033; Tue, 9 Sep 2014 15:21:42 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 9 Sep 2014 15:21:42 -0400 Message-ID: In-Reply-To: <540F501C.7080109@dominikschuermann.de> References: <540F501C.7080109@dominikschuermann.de> Date: Tue, 9 Sep 2014 15:21:42 -0400 From: "Derek Atkins" To: "Dominik Schuermann" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/2shCB0TtWGbOMoxR1JejXoaoTIE Cc: openpgp@ietf.org Subject: Re: [openpgp] Draft review: Algebraic Eraser keys in 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, 09 Sep 2014 19:21:50 -0000 Hi, On Tue, September 9, 2014 3:08 pm, Dominik Schuermann wrote: > Hi, > > does AEKAP really qualify to be chosen as an extension to OpenPGP? The > outcome of my short literature research shows that there are just a very > small group of mathematicians working on the theoretic backgrounds for > these kind of braid based crypto. Funnily, I had a short introduction by > a mathematics professor some semesters ago, but it sounded far away from > practical secure implementations. Here are some papers linked: > http://lists.randombit.net/pipermail/cryptography/2012-May/002898.html > > I don't want to sound offensive, just wondering why you chose to write a > draft about this. No offence taken, but we do have a practical, secure implementation. (Of course it all depends on your definition of "practical" and "secure"). I'm writing a draft because I have an actual deployment of AEKAP and want to be able to use the OpenPGP format to ship around AEKAP keys. As for qualification, we (meaning the OpenPGP WG) have never really turned away a request to add a new cipher in the past so long as someone actually wanted to use it. I actually want to use it :) I'll also point out that the analysis on the cryptography list is someone inaccurate.. There are multiple braid group problems, and indeed the single conjugacy search problem is easily solvable, however AEKAP is based on the simultaneous conjugacy search problem, which has not been shown to be solvable in polynomial time. Thanks, > Regards > Dominik -derek > On 09/09/2014 05:47 PM, Derek Atkins wrote: >> Hi, >> >> I just posted the attached draft specifying how to encode AEKAP Keys in >> OpenPGP. AEKAP is a Diffie-Hellman like protocol (so only supports >> encryption). Reviews and comments are requested. >> >> Thanks! >> >> -derek >> >> >> >> >> >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >> > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Sep 10 07:07:23 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 08CA61A0277 for ; Wed, 10 Sep 2014 07:07:19 -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 uIEjWoKg13_Y for ; Wed, 10 Sep 2014 07:07:14 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358121A00E9 for ; Wed, 10 Sep 2014 07:07:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id EC3CDE2033; Wed, 10 Sep 2014 10:07:12 -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 23120-07; Wed, 10 Sep 2014 10:07:08 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id E4A16E2031; Wed, 10 Sep 2014 10:07:07 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s8AE77Pn029467; Wed, 10 Sep 2014 10:07:07 -0400 From: Derek Atkins To: Derek Atkins References: Date: Wed, 10 Sep 2014 10:07:07 -0400 In-Reply-To: (Derek Atkins's message of "Tue, 09 Sep 2014 11:47:13 -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/G9EDhHRcZ7mnlfYSAdcOBOwEWlo Cc: openpgp@ietf.org Subject: [openpgp] (updated) Re: Draft review: Algebraic Eraser keys in 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, 10 Sep 2014 14:07:19 -0000 --=-=-= Content-Type: text/plain Per responses that I received off-list, here is the -01 version of this draft. The main changes made: 1) Change the suggested protocol number from 22 to 23 so as to avoid conflict with Ed25519 2) Change the AAGL reference to a different URL that's not behind a paywall, and add another Informational reference regarding AEKAP. Any additional comments, suggestions, or clarifications are welcome. Thanks, -derek --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=draft-atkins-openpgp-algebraic-eraser-01.txt Content-Description: AEKAP in OpenPGP 01 Internet Engineering Task Force D. Atkins Internet-Draft SecureRF Corporation Intended status: Standards Track September 10, 2014 Expires: March 14, 2015 Using Algebraic Eraser in OpenPGP draft-atkins-openpgp-algebraic-eraser-01 Abstract The Algebraic Eraser(TM) is an encryption engine that supports, among other configurations, a Diffie-Hellman-like key agreement protocol. This draft specifies how to encode, store, share, and use Algebraic Eraser Key Agreement Protocol keys in OpenPGP. 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 14, 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. Atkins Expires March 14, 2015 [Page 1] Internet-Draft Algebraic Eraser for OpenPGP September 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Algebraic Eraser . . . . . . . . . . . . . . . . . . . . 2 2.1. E-Multiplication . . . . . . . . . . . . . . . . . . . . 3 2.2. AEKAP Keyset Parameters . . . . . . . . . . . . . . . . . 3 2.3. Generating Key Pairs . . . . . . . . . . . . . . . . . . 4 3. Encoding of Public and Private Keys . . . . . . . . . . . . . 4 3.1. Encoding Bit-Strings . . . . . . . . . . . . . . . . . . 5 3.1.1. Encoding Techniques . . . . . . . . . . . . . . . . . 5 3.1.2. Multi-Byte Entries . . . . . . . . . . . . . . . . . 6 3.2. Encoding Public Keys . . . . . . . . . . . . . . . . . . 6 3.3. Encoding Private Keys . . . . . . . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 9 A.1. Sample key . . . . . . . . . . . . . . . . . . . . . . . 9 A.2. Sample key agreement . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The OpenPGP specification in [RFC4880] defines the use of RSA, Elgamal, and DSA public key algorithms. [RFC6637] adds support for Elliptic Curve Cryptography and specifies the ECDSA and ECDH algorithms. The Algebraic Eraser was first introduced in Key agreement, the Algebraic Eraser, and lightweight cryptography [AAGL] published by the American Mathematical Society in 2004. It describes "a new key agreement protocol suitable for implementation on low-cost platforms which constrain the use of computational resources." It is further compared to other algorithims in [AEIntro]. This document specifies how to encode, store, and use the Algebraic Eraser(TM) Key Agreement Protocol (AEKAP) in OpenPGP. 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. The Algebraic Eraser Atkins Expires March 14, 2015 [Page 2] Internet-Draft Algebraic Eraser for OpenPGP September 2014 The Algebraic Eraser brings together the Braid Group, Matrices, and operations over small Finite Fields to produce an algorithm that executes linear in time with the increase in key size. A complete description of the Algebraic Eraser is available in [AAGL]. 2.1. E-Multiplication The Algebraic Eraser defines an operation called "E-Multiplication" upon which the algorithm is based (see [AAGL]). E-Multiplication (denoted herein by *) takes one matrix (M0) and permutation (S0) and operates on a second matrix (M1) and permutation (S1), resulting in another matrix (M2) and permutation (S2). In other words: (M0,S0) * (M1,S1) = (M2,S2). 2.2. AEKAP Keyset Parameters AEKAP Keyset Parameters are similar to Diffie-Hellman cyclic groups of prime order or ECC curves. Just as users must choose the same DH prime or ECC curve in order to communicate, similarly participants in the AEKAP must be using the same Keyset Parameters. The first basic set of parameters is the chosen Braid Group and Field Size, BnFq, where n is the number of strands in the chosen braid (also called the braid index) and q is the size of the field in use. The field size, q, must be a power of a prime. Generally it is 2^r (where r is a small integer) although this is not a requirement. For example, one might choose B10F8 or B16F32. This is like choosing how many bits to use when generating a prime for Diffie-Hellman. Once the BnFq space is chosen then the Keyset Parameters can be generated by a trusted third party (TTP). First they generate an n-by-n matrix (M) where each entry in the matrix is a member of the field Fq. Then the TTP generates at least two sets of braid conjugates, Ca and Cb, where each conjugate in Ca commutes with each conjugate in Cb. The conjugates are lists of "braid words", or "Artin generators" within the Bn braid group. The TTP generates La conjugates for set Ca and Lb conjugates for set Cb, where the numbers La and Lb MAY be different. The public Keyset Parameters are the Matrix and conjugate sets and must be available to generate keys that can communicate. These Keysets MAY be published and named, but MUST be numbered with an OID. For two users to execute the AEKAP they MUST generate keys from the same Keyset and they MUST choose from different conjugate sets within that Keyset. I.e., for Alice and Bob to complete the AEKAP Alice must generate her key from Ca and Bob must generate his key from Cb. Atkins Expires March 14, 2015 [Page 3] Internet-Draft Algebraic Eraser for OpenPGP September 2014 This document does not specify any particular Keyset Parameters that MUST be implemented. 2.3. Generating Key Pairs The Algebraic Eraser has a two-part Private Key and a two-part Public Key. The Public key is then generated from the two Private Keys. To generate the 1st private key you generate a random polynomial and apply that to the public matrix from the keyset within the keyset field. This results in an nxn matrix where each entry in the matrix is a member of the field Fq. The key search space for the 1st private key is 2^nr (where q=2^r). To generate the 2nd private key you choose a random set of conjugates (and inverses) and string them together. This results in a long string of Artin generators (and inverses). You MAY reduce the string if you so choose using the Dehornoy reduction [Dehornoy]. The search space of the 2nd private key is (2k)^l (where k is the number of published conjugates, and l the number of chosen conjugates and inverses). The Public Key is computed by an E-Multiplication of the 1st private key and the 2nd private key, where the 2nd private key is iteratively processed. Each Artin generator in the 2nd private key is associated to a specific Colored Burau (CB) matrix and permutation (see [AAGL]). The E-multiplication occurs after you substitute the T-values in the CB Matrix with the values in the existing permutation. The result (the public key) is an nxn matrix of Fq and another permutation. Note that the last row of the Public Key Matrix is all zero except for the last entry. When encoding the Public Key you SHOULD ignore those zeros. 3. Encoding of Public and Private Keys Each portion of a key can be reduced to a byte-string (or, more accurately, multiple byte strings). Each matrix can be encoded by stringing together each field element in each row and then stringing each row together. A permutation can be encoded by stringing together each element in the list. The conjugates are also encoded by stringing together each element. The following public key algorithm IDs are added to expand section 9.1 of [RFC4880], "Public-Key Algorithms": +------+----------------------------+ | ID | Description of Algorithm | Atkins Expires March 14, 2015 [Page 4] Internet-Draft Algebraic Eraser for OpenPGP September 2014 +------+----------------------------+ | TBD1 | AEKAP public key algorithm | +------+----------------------------+ Encoding of Public and Private keys MUST use the version 4 packet format (or newer). 3.1. Encoding Bit-Strings The Algebraic eraser uses matrices, fields, and braids that are denoted in bits, particular strings of bits. These objects need to be encoded into bit strings for storage and transmission. The most simplistic method of encoding is to take each field as a byte (or multi-byte word) and string them together. The following sections detail multiple (alternate) ways these bit strings can be encoded to possibly reduce the space used. 3.1.1. Encoding Techniques Depending on the number of bits used per element (which is defined by the braid index and field size), using different encodings of these strings may result in reducing storage space by dropping extra bits and combining elements. For example, when using the finite field F16 each entry can be encoded in exactly one nibble of four (4) bits, so you can easily combine two entries into a single 8-bit byte (called nibble- encoding). This technique could also be used for entries smaller than a nibble, although then you would still have extra (unused) bits. When using the nibble-encoding of an odd number of nibbles the encoding rules MUST specify whether the extra nibble is at the leading or trailing byte. Another encoding option is bit-stealing. This merges all bits together and then cuts it up into 8-bit bytes. For example if the entries are 5 bits each you might steal 3 bits from the second entry to merge into the first, then shift the remaining 2 bits of the second entry, combine with the next 5 bits from the third, and then steal one bit from the fourth entry, and so on, until you've reached the end. This could end up with unused bits at the end of the string. Yet another option is the reverse-bit-stealing, where you start at the end of the string and work your way to the front. This could leave you with unused bits a the front of the string. Atkins Expires March 14, 2015 [Page 5] Internet-Draft Algebraic Eraser for OpenPGP September 2014 Assume you require five (5) bits to encode your numbers, the following table shows how you could could use bit stealing and reverse bit stealing to encode them (where a, b, c, and d are the bits in the first, second, third, and fourth entries) +-----------------------+----------+----------+----------+----------+ | Full Bytes: | 000aaaaa | 000bbbbb | 000ccccc | 000ddddd | +-----------------------+----------+----------+----------+----------+ | Bit stealing: | aaaaabbb | bbcccccd | dddd0000 | | +-----------------------+----------+----------+----------+----------+ | Reverse bit stealing: | 0000aaaa | abbbbbcc | cccddddd | | +-----------------------+----------+----------+----------+----------+ Any unused bits MUST be left as zero (and MUST be checked to be zero). The actual encoding method MUST be defined by the Keyset parameter definition and may change from one keyset parameter to another. The row of zeros in the matrix SHOULD be assumed to "not exist". When using these encoding techniques you SHOULD just tack the last entry of the final row onto the end of the list of entries of the rest of the matrix. This could result in an odd number of entries depending on your n and q choices potentially requiring passing at the start or end of the bit string. 3.1.2. Multi-Byte Entries In the case of entries wider than 8 bits (e.g. a Field parameter greater than 256), the bits are combined in network byte order. However they can still be merged together using the same encoding algorithms from Section 3.1.1 in the case of entries that are not 8-bit multiples. For example, a 12-bit field (F4096) could be combined a nibble at a time, or a 10-bit field (F1024) could use bit- stealing. 3.2. Encoding Public Keys The following algorithm specific packets are added to Section 5.5.2 of [RFC4880], "Public-Key Packet Formats", to support AEKAP: o a variable length field containing a keyset parameter OID, formatted as follows (see [RFC6637] for a full description of the OID encoding method): * a one-octet size of the following field; values 0 and 0xFF are reserved for future extensions, Atkins Expires March 14, 2015 [Page 6] Internet-Draft Algebraic Eraser for OpenPGP September 2014 * octets representing a keyset parameter OID o one byte denoting from which set of conjugates in the keyset this key was generated (e.g. the Alice set or the Bob set) o MPI of the public key matrix o MPI of the public key permutation 3.3. Encoding Private Keys The following algorithm specific packets are added to Section 5.5.3 of [RFC4880], "Secret-Key Packet Formats", to support AEKAP: o MPI of the 1st private key (matrix) o MPI of the 2nd private key (conjugate string) 4. Acknowledgements The term "Algebraic Eraser" is a trademark of SecureRF Corporation and is used herein with permission. The author would like to thank Paul Gunnells and Dorian Goldfeld for their tireless efforts to review this document, suggest improvements, and explain to me how to improve my description of how AE works. Big thanks also to Werner Koch and Vedaal for their comments and suggestions. 5. 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 3. +------+----------------------------+-----------+ | ID | Algorithm | Reference | +------+----------------------------+-----------+ | TBD1 | AEKAP 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, but we request the selection of 23.] Atkins Expires March 14, 2015 [Page 7] Internet-Draft Algebraic Eraser for OpenPGP September 2014 6. Security Considerations The security considerations of [RFC4880] apply accordingly. AEKAP will generate the same session key when used with the same two public/private key pairs. The authors of AE generally recommend that at least one party use an ephemeral key pair in order to prevent the same session key being generated every time. AEKAP is an encryption-only algorithm, therefore it cannot self- certify a key. To have an AEKAP master key you MUST implement [I-D.atkins-openpgp-device-certificates]. When using the generated session key, you MUST only use the bits included in the protocol. You should MUST NOT use any always-zero bits, including those in the last row of the matrix. 7. References 7.1. Normative References [AAGL] Anshel, I., Anshel, M., Goldfeld, D., and S. Lemieux, "Key agreement, the Algebraic Eraser, and lightweight cryptography", Contemporary Mathematics 418, 2004, . [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. 7.2. Informative References [AEIntro] SecureRF Corporation, SRF., "An Introduction to Cryptographic Security Methods and Their Role in Securing Low Resource Computing Devices", 2011, . Atkins Expires March 14, 2015 [Page 8] Internet-Draft Algebraic Eraser for OpenPGP September 2014 [Dehornoy] Dehornoy, P., "A fast method for comparing braids", Advances in Mathematics 123, 1997, . [I-D.atkins-openpgp-device-certificates] Atkins, D., "OpenPGP Extensions for Device Certificates", draft-atkins-openpgp-device-certificates-00 (work in progress), August 2014. Appendix A. Test Vectors To help implementing this specification a non-normative example is provided. This example assumes: o the algorithm id for AEKAP will be 23 o the keyset OID 1.3.6.1.4.1.44196.1.0.0, which defines: * the braid/field as B10F8 * the public key packing is nibble-packed with trailing zeros * the 2nd private key is not bit-packed; it uses bit 7 to define "inverse" and bits 3-0 to define the Artin generator. and gets encoded with length 11 and the following hex bytes: 2B 06 01 04 01 82 D9 24 01 00 00 A.1. Sample key The secret key used for this example is: 1st Private Key Matrix: 4 2 7 4 1 2 7 7 3 5 1 1 5 4 0 5 0 0 3 1 2 7 5 3 4 0 6 0 0 4 6 1 0 7 4 7 7 4 1 1 1 1 7 6 6 2 4 6 5 7 7 5 4 1 7 3 7 5 0 7 1 6 0 7 3 6 4 2 5 6 7 2 3 6 6 6 4 2 7 7 3 7 5 2 2 2 0 7 5 2 6 2nd Private key (in hex): Atkins Expires March 14, 2015 [Page 9] Internet-Draft Algebraic Eraser for OpenPGP September 2014 060481820304050384840506028304050682838485810203048506878807880984 858384828384858383838485068708070809868788888887880586078809080987 880788090809878809030485850384848583838483848506070809878809060506 070809878788860788090687080983040506070809030405060708090203840506 070405060708838484858583848384858586870687080102030405060708098586 878888858586838485858182828282828181828203048586878809080907080607 080984858586860283040586868601820304858586878787870808098102038485 860102030405860708878787878787088181828384858687080607070606060706 070809090607880988090687880907088787080986878809090607080987888687 878888078806078809868788888886878788888787888807880987880607880909 068708070809098686878807078809090987888686878809880988090906878807 880906878888078806060687880987080808080708098687880909888788090987 880607060607070788090809878809060708098787888686868787878809880909 090607080906878809888888090987880909078809878807880909098788090708 098687880607880908098788888888880909878886078888090607080986878886 868787888809090809878888090607080987888806878809870809868788090607 080987878809880907080987068708090708098686878788888686868686860788 880987880987870687888788860788068788078886078806878888078809868787 878788078806078886070707070788098708080986868607088787870886870886 878708090707088687878787878787080806070886868708090906070809868788 078809090809870809870809870809868788060788090906878809090707880986 878888888788090807080907860788090987080808090908080808080987880707 860707880909098788090986878888880909868788090981828384858687880906 070506050606078607070707048304858607070782038485860781028384850606 070707080809098401828384050607880909040506870881828384858687088708 080102030485060701020384050607080802020101020202020283848586870182 838485868708038485860706070809888809098788098687880485860788090905 060708090708868708098182838485868788078809878807880987880788090403 040303040405068708080985868788090607080806070583040303030304058602 03040584058683048582038485010203040485860582838483840201 The key was created on 2014-09-09 16:35:36 from the tag conjugates (type 1), and thus the fingerprint of the OpenPGP key is: 8020 A772 BA18 EA47 3501 B8CE EABE 1082 56BB 5D64 and the entire public key packet is: 98 4a 04 54 0f 64 98 17 0b 2b 06 01 04 01 82 d9 24 01 00 00 01 01 6e 26 44 05 46 10 02 50 43 37 56 66 37 42 40 10 72 06 14 44 16 67 13 02 70 73 11 00 30 27 47 21 75 35 76 13 13 31 00 60 52 75 24 50 57 23 60 00 25 12 35 76 a8 94 A.2. Sample key agreement Atkins Expires March 14, 2015 [Page 10] Internet-Draft Algebraic Eraser for OpenPGP September 2014 The key agreement is created using the sample key against a second (reader) public key. The reader public key has the following data: Matrix (in nibbled-packed hex with trailing zeros): 24 14 13 22 14 67 30 02 20 23 11 26 26 51 20 11 67 40 56 57 60 77 01 04 66 56 71 35 21 27 57 00 55 75 16 40 07 75 05 12 31 35 75 45 66 40 Permutation (in nibble-packed hex): 32 14 56 78 9a Which results in the following shared secret: Matrix: 4 0 6 5 2 3 0 5 6 0 6 5 5 0 2 0 1 7 5 5 2 0 2 1 1 1 2 7 2 0 4 0 1 2 5 6 6 6 1 2 5 0 1 0 7 4 3 3 3 4 5 1 2 5 3 3 5 5 7 1 1 0 7 1 6 3 4 0 2 1 2 7 5 4 6 7 1 4 7 4 7 1 5 5 3 6 1 4 1 6 5 Permutation (decimal): 3 2 1 5 7 6 10 8 9 4 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 14, 2015 [Page 11] --=-=-= Content-Type: text/plain -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --=-=-=-- From nobody Fri Sep 12 05:37: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 A222F1A04B9 for ; Fri, 12 Sep 2014 05:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA9Wz6pbUZhU for ; Fri, 12 Sep 2014 05:37:37 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65121A0298 for ; Fri, 12 Sep 2014 05:37:36 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id n3so533993wiv.7 for ; Fri, 12 Sep 2014 05:37:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LyxYkS5PSKZr8w/JhSfS+BHjOkYFLNl15FMc3TKwvEI=; b=IpBj038QP3YnfQvEf0O9S/Dzoq8f3TCjM1/7OMmv1aMSyeOrfkB7wRcAfXmDY8HL43 zuAvXE1QmidISMpVMEmNb0O/vR/Vt6zA1ok/DwdBmVtl60pHv8p2g/Hgcz9Sss0WV+rC DFkLly0iuvqYydKDpuVkzEMOPK5LQo3TY4OSXiGvBgwiA06Ga5kJY6jNZxVPB/2c+Voi ZNTN3KYwF10KJjhpWhY+fSMm1GrPShxS6wp4tekvWOFHPIUbE3Cy/ZdfOgjinlopO5Ee Uwf1m6LubRPwHFwvd4dcmfs2/5V+lpTIrGVLLamX8dT1rCsWhBr8+wDEg4/UxRk+4s2f zMXQ== X-Gm-Message-State: ALoCoQlCmPv43/2iOVh7jSfaRn5iW65fLNpD2QhqR+jXoKhhM2ZNveutHUMJWlqS3LEynEC+eP/Z X-Received: by 10.180.76.209 with SMTP id m17mr2002746wiw.78.1410525449930; Fri, 12 Sep 2014 05:37:29 -0700 (PDT) Received: from [192.168.1.114] (business-80-99-236-194.business.broadband.hu. [80.99.236.194]) by mx.google.com with ESMTPSA id u8sm1641822wia.24.2014.09.12.05.37.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 05:37:29 -0700 (PDT) Message-ID: <5412E907.2040005@epointsystem.org> Date: Fri, 12 Sep 2014 14:37:27 +0200 From: "Daniel A. Nagy" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Derek Atkins References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> <540F01CC.9080505@epointsystem.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/H84P5pPBvc73iadj0dTLJGjwd_Q Cc: openpgp@ietf.org Subject: Re: [openpgp] Updated Draft (was Re: 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: Fri, 12 Sep 2014 12:37:38 -0000 Thank you! On 09/09/2014 04:30 PM, Derek Atkins wrote: > "Daniel A. Nagy" writes: > >> Question: >> >> Does this specification allow for signature/certification keys without >> user ID and self-certification? > > Yes, it is allowed. > >> I am a bit confused with the wording. >> Please indicate in your answer which section allows (or prohibits) such >> keys. Maybe, we could make it more explicit? > > Section 2 allows it through the definition of the "Augmented v4 device > certificate". Wording suggestions to make it more clear are welcome. I > suppose your confusion is my use of the word "can" throughout that > section? I got confused by this: "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. ... It MAY accept public keys without an accompanying signature." Basically, it says that signature-capable primary keys without certification are not really proper, but sufficiently liberal implementation may still accept them. Now, the only thing a self-certification directly on the key proves is that the public key is not bogus; it does, indeed, have a private counterpart, right? Regards, Daniel From nobody Fri Sep 12 06:18: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 CAA281A06E2 for ; Fri, 12 Sep 2014 06:18:00 -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 duETUDELAzCM for ; Fri, 12 Sep 2014 06:17:58 -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 EA3E41A0720 for ; Fri, 12 Sep 2014 06:17:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 6B45EE2031; Fri, 12 Sep 2014 09:17:09 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06193-08; Fri, 12 Sep 2014 09:17:07 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 32666E2033; Fri, 12 Sep 2014 09:17:07 -0400 (EDT) Received: from 192.168.248.220 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 12 Sep 2014 09:17:07 -0400 Message-ID: <24be5640d9da98c2866c2d8cde06fcad.squirrel@mail2.ihtfp.org> In-Reply-To: <5412E907.2040005@epointsystem.org> References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> <540F01CC.9080505@epointsystem.org> <5412E907.2040005@epointsystem.org> Date: Fri, 12 Sep 2014 09:17:07 -0400 From: "Derek Atkins" To: "Daniel A. Nagy" 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/eOUqX5I6ySp1Il7ztehyyJEBTsk Cc: openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] Updated Draft (was Re: 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: Fri, 12 Sep 2014 13:18:01 -0000 Hi, On Fri, September 12, 2014 8:37 am, Daniel A. Nagy wrote: > Thank you! > > On 09/09/2014 04:30 PM, Derek Atkins wrote: >> "Daniel A. Nagy" writes: >> >>> Question: >>> >>> Does this specification allow for signature/certification keys without >>> user ID and self-certification? >> >> Yes, it is allowed. >> >>> I am a bit confused with the wording. >>> Please indicate in your answer which section allows (or prohibits) such >>> keys. Maybe, we could make it more explicit? >> >> Section 2 allows it through the definition of the "Augmented v4 device >> certificate". Wording suggestions to make it more clear are welcome. I >> suppose your confusion is my use of the word "can" throughout that >> section? > > I got confused by this: > > "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. > ... > It MAY accept public keys without an > accompanying signature." > > Basically, it says that signature-capable primary keys without > certification are not really proper, but sufficiently liberal > implementation may still accept them. Correct. Do I need to reword that or add something to make that more clear? > Now, the only thing a self-certification directly on the key proves is > that the public key is not bogus; it does, indeed, have a private > counterpart, right? That and a self-assertion of any particular notations in the signature. > Regards, > > Daniel Thanks, -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Sep 15 01:55: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 4AF811A0240 for ; Mon, 15 Sep 2014 01:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HamKJmHIsYo3 for ; Mon, 15 Sep 2014 01:55:50 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D7B1A02BD for ; Mon, 15 Sep 2014 01:55:49 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so3727641wib.8 for ; Mon, 15 Sep 2014 01:55:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=stVNSADa1Vo4CCsNQ+BOMzqPQx5R9QSmLxpZwopOgeA=; b=ILZ8eFBSvzkIrYWAkFl2Fvt2lppfSGoyXjPM1H6ThC/rK3SorChLG+RBxlUL8trAmI 7kYUvE3Ko3o03nW/pEFanxn9BTJQ1abeUx5Xp+23e1/A9cAOmMV1N33lpd/B9SDK2deE fIKFFXBas4+mF5ZJhxTTUFGYqwXSgzzQ0sxGjxZobfY+l7s12pFBal4eKy9AcoZIi++N 5FejQ1Rj0yTEp0D/bdQPIFNgX3l0LiCef/QcOCoXgtfZrlSjQwTrG1WWUvOEYL0YO10d Be6K9nxDaWtzsh+ZYBLjakrB4Xkj5oVuZQirqCokWOKc0U4mTj2njNpQZqIf8cMgXvcd rkeg== X-Gm-Message-State: ALoCoQnzrjkpxqlrOCW9dj2b+QFIT1A0NzZcAjP44p8SL4ktgd3cEGdlUNomH2uhGEPaKj2PZgAs X-Received: by 10.180.87.231 with SMTP id bb7mr21958254wib.63.1410771345798; Mon, 15 Sep 2014 01:55:45 -0700 (PDT) Received: from [192.168.1.139] (business-80-99-236-194.business.broadband.hu. [80.99.236.194]) by mx.google.com with ESMTPSA id cj7sm14003556wjc.37.2014.09.15.01.55.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Sep 2014 01:55:45 -0700 (PDT) Message-ID: <5416A98B.3090803@epointsystem.org> Date: Mon, 15 Sep 2014 10:55:39 +0200 From: "Daniel A. Nagy" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Derek Atkins References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> <540F01CC.9080505@epointsystem.org> <5412E907.2040005@epointsystem.org> <24be5640d9da98c2866c2d8cde06fcad.squirrel@mail2.ihtfp.org> In-Reply-To: <24be5640d9da98c2866c2d8cde06fcad.squirrel@mail2.ihtfp.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/xMoUks_Gc6dP0gkgdl7OO8hFpSg Cc: openpgp@ietf.org Subject: Re: [openpgp] Updated Draft (was Re: 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: Mon, 15 Sep 2014 08:55:51 -0000 Hi, On 09/12/2014 03:17 PM, Derek Atkins wrote: >> I got confused by this: >> >> "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. >> ... >> It MAY accept public keys without an >> accompanying signature." >> >> Basically, it says that signature-capable primary keys without >> certification are not really proper, but sufficiently liberal >> implementation may still accept them. > > Correct. Do I need to reword that or add something to make that more clear? Not necessarily. Perhaps reordering the sentences (and changing referring pronouns accordingly) so that these two statements would be right after one another would make it easier to understand. >> Now, the only thing a self-certification directly on the key proves is >> that the public key is not bogus; it does, indeed, have a private >> counterpart, right? > > That and a self-assertion of any particular notations in the signature. Right. Thanks! From nobody Mon Sep 15 08:18:11 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 C4C211A038B for ; Mon, 15 Sep 2014 08:18:06 -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 lm3StgU-v7ty for ; Mon, 15 Sep 2014 08:18:05 -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 0C2991A01E2 for ; Mon, 15 Sep 2014 08:18:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C2142E2033; Mon, 15 Sep 2014 11:18:03 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25928-02; Mon, 15 Sep 2014 11:18:02 -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 DCC45E2031; Mon, 15 Sep 2014 11:18:01 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s8FFI0fV027976; Mon, 15 Sep 2014 11:18:00 -0400 From: Derek Atkins To: Tom Ritter References: Date: Mon, 15 Sep 2014 11:18:00 -0400 In-Reply-To: (Tom Ritter's message of "Sat, 13 Sep 2014 22:18:40 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/0NpAPyjFJXWwjU3t2aQnBtG428M Cc: openpgp@ietf.org, Derek Atkins Subject: Re: [openpgp] (updated) Re: Draft review: Algebraic Eraser keys in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 15:18:06 -0000 Hi, Tom Ritter writes: > I see a few (TM)'s in the document. I'm not going to say you should > standardize it if it's patented, but I would like to know the IPR > status of the stuff covered in the document. As required by IETF policy, IPR notifications will be made appropriately. > Thanks, > -tom -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Sep 15 08:46: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 50D641A6F6E for ; Mon, 15 Sep 2014 08:46:00 -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 9TXVCjwf8HmK for ; Mon, 15 Sep 2014 08:45:56 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE4D1A6FC0 for ; Mon, 15 Sep 2014 08:36:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id E8454E2033; Mon, 15 Sep 2014 11:36: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 25919-10; Mon, 15 Sep 2014 11:36:22 -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 9B20EE2031; Mon, 15 Sep 2014 11:36:22 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s8FFaM5o028628; Mon, 15 Sep 2014 11:36:22 -0400 From: Derek Atkins To: "Daniel A. Nagy" References: <87zjejo7u4.fsf@vigenere.g10code.de> <87mwajnxcb.fsf@vigenere.g10code.de> <540F01CC.9080505@epointsystem.org> <5412E907.2040005@epointsystem.org> <24be5640d9da98c2866c2d8cde06fcad.squirrel@mail2.ihtfp.org> <5416A98B.3090803@epointsystem.org> Date: Mon, 15 Sep 2014 11:36:22 -0400 In-Reply-To: <5416A98B.3090803@epointsystem.org> (Daniel A. Nagy's message of "Mon, 15 Sep 2014 10:55:39 +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/qy9j_YHA_o1C0UiqOSdm6XKV0y0 Cc: openpgp@ietf.org Subject: Re: [openpgp] Updated Draft (was Re: 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: Mon, 15 Sep 2014 15:46:00 -0000 Hi, "Daniel A. Nagy" writes: > Hi, > > On 09/12/2014 03:17 PM, Derek Atkins wrote: >>> I got confused by this: >>> >>> "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. >>> ... >>> It MAY accept public keys without an >>> accompanying signature." >>> >>> Basically, it says that signature-capable primary keys without >>> certification are not really proper, but sufficiently liberal >>> implementation may still accept them. >> >> Correct. Do I need to reword that or add something to make that more clear? > > Not necessarily. Perhaps reordering the sentences (and changing > referring pronouns accordingly) so that these two statements would be > right after one another would make it easier to understand. How about if I split it up into two paragraphs and reorder/reword a bit: 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. Implementations MUST accept encryption-only primary keys without a signature. It also MUST allow importing any key accompanied either by a certification signature or a signature on itself. It MAY accept signature-capable primary keys without an accompanying signature. >>> Now, the only thing a self-certification directly on the key proves is >>> that the public key is not bogus; it does, indeed, have a private >>> counterpart, right? >> >> That and a self-assertion of any particular notations in the signature. > > Right. Thanks! -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant