From nobody Wed Jul 1 12:35:20 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C181A9054 for ; Wed, 1 Jul 2015 12:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iBPQUcheY_X for ; Wed, 1 Jul 2015 12:35:07 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0558F1B2B38 for ; Wed, 1 Jul 2015 12:35:00 -0700 (PDT) Received: by lbbpo10 with SMTP id po10so19097916lbb.3 for ; Wed, 01 Jul 2015 12:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=L27egwFY2cjVumRSdMRBYM3ygkOuIDM3JYcnFQAVTsk=; b=byGJMW+QTxbddDj4lF4tMmwXymEgxctrh9QbeViLaWnuCgxHh6st8TpRBamXfBOZ1y zKOeqL2xCrUgMDQmJhjbWElh7BnBnDdGxYBSJ4hg91XMOBB15a2NoJI6XFxnX5Q8uRa7 d4gz487/47nEodRn2ZPUDQQfM1z9ESqeoLlTbmLG9zXitWLw9+v48vgGu/hZjU5hhtiY IzKvWN3osjYq8D9ZUJAl33pXLVur9fz551NkyqDHM2zkICoQcEALerT1vdwTHpMvOyS/ rFMN1Ir1+lpqznA6DIRi5+lTwbxL9OnJilLCR5aTjgr5X+zFNJ1imo6sHeYJX4IKnh91 VDeA== MIME-Version: 1.0 X-Received: by 10.112.40.99 with SMTP id w3mr14626066lbk.55.1435779298477; Wed, 01 Jul 2015 12:34:58 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 1 Jul 2015 12:34:58 -0700 (PDT) Date: Wed, 1 Jul 2015 15:34:58 -0400 X-Google-Sender-Auth: Q5bArcE0sVxntmUxdwsbMfAcVnQ Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: multipart/alternative; boundary=001a11336f960fce090519d56bec Archived-At: Subject: [openpgp] Agenda for Prague? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 19:35:12 -0000 --001a11336f960fce090519d56bec Content-Type: text/plain; charset=UTF-8 We have a time slot but I haven't seen a call for agenda items yet. I would like to propose OpenPGP uses UDF for next gen fingerprints. I define a fingerprint as being a cryptographic digest formatted for human interpretation. Since humans are going to have to interact with these we should make sure we adopt Murphy's advice[1] and design them in such a fashion that using an OpenPGP fingerprint with SSH or vice versa does not lead to tears. The draft is written to be application neutral but this is probably the best place to standardize it. https://tools.ietf.org/html/draft-hallambaker-udf-00 [1] Ed Murphy was not the first to propose the law but the reason his name got attached to it was he used it as justification for designing connectors so that they cannot be inserted the wrong way. --001a11336f960fce090519d56bec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have a time slot but I haven't seen a call for agen= da items yet.

I would like to propose OpenPGP uses UDF f= or next gen fingerprints. I define a fingerprint as being a cryptographic d= igest formatted for human interpretation.=C2=A0

Si= nce humans are going to have to interact with these we should make sure we = adopt Murphy's advice[1] and design them in such a fashion that using a= n OpenPGP fingerprint with SSH or vice versa does not lead to tears.
<= div>
The draft is written to be application neutral but this = is probably the best place to standardize it.



[1] Ed Murphy was not the first to propose the l= aw but the reason his name got attached to it was he used it as justificati= on for designing connectors so that they cannot be inserted the wrong way.<= /div>
--001a11336f960fce090519d56bec-- From nobody Wed Jul 15 07:05:11 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6216A1A9154 for ; Wed, 15 Jul 2015 07:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNGbnwYBa3X9 for ; Wed, 15 Jul 2015 07:05:08 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 599621A9149 for ; Wed, 15 Jul 2015 07:05:08 -0700 (PDT) Received: from p5081366d.dip0.t-ipconnect.de ([80.129.54.109] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZFNJ1-0006iI-Fu for openpgp@ietf.org; Wed, 15 Jul 2015 14:05:03 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZFNIz-0001jO-9O for openpgp@ietf.org; Wed, 15 Jul 2015 16:05:03 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZFNIy-00076H-5G for openpgp@ietf.org; Wed, 15 Jul 2015 16:05:00 +0200 Date: Wed, 15 Jul 2015 16:05:00 +0200 Message-ID: <87bnfdldo3.wl-neal@walfield.org> From: "Neal H. Walfield" To: IETF OpenPGP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 14:05:10 -0000 Hi, Encrypted mailing lists are currently difficult to do securely and easily. Either they trade security for usability by reencrypting mail or they trade usability for security by requiring each poster to keep a local list of subscribers up to date. I think many cases can be easily accommodated at the OpenPGP level. My proposal is relatively informal. This is because: I haven't actually implemented it yet; I would like some feedback on the idea before pursuing it further; and, I don't have any experience writing RFCs. If the community agrees that the approach is reasonable, I'll be happy to draft a more formal specification / patch for 4880bis. The basic idea is to publish the list of subscribes as an OpenPGP message. Concretely: To create a mailing list, the mailing list administrator generates a new key pair in the usual way. Associated with the key pair is a list of encryption keys (Public-Key Packet, tag 6, or Public-Subkey Packet, tag 14). Each key may optionally be preceded by a user id (User ID packet, tag 13). This list is stored in a signature subpacket with a new subpacket type. The list may be encrypted to hide the subscriber list. In this case, the list will be encrypted to the set of authorized posters (which may or may not be the same as the set of subscribers). The session key is encrypted for each poster and is saved in a public-key encrypted session key packet as usual. Since it is useful to hide the list of posters, as an extension to the public-key encrypted session key packet specification, if the first 6 octets of the key id are 0 and the last two are not, then the last two octets specify the last two octets of the key's id. I call these are "practically hidden key ids". They are practically hidden, because 16-bits does not provide enough information to identify a key (it's trivial to create a collision unlike with a 64-bit id) and thus plausible deniability is ensured. The 16-bits are useful, because there are potentially thousands of posters to a mailing list and if the public-key encrypted session key packets all have hidden key ids, it could take a long time to find the appropriate packet. The 16-bits are a simple filter that reduces decryption time by a factor of 2^16. Keyservers / export commands should only include the most recent valid version of this packet. The key may contain two optional uids. The first uid contains an email address that forwards the email to all of the mailing list's subscribers. This user id has the following comment: "mailing list". If there is no valid user id with the comment "mailing list" then the MUA should send the email to all of the UIDs listed in the encryption key list. The second uid contains the email address of the list's owner. It should have the following comment: "mailing list: owner". When encrypting, the implementation should make sure that the key is fresh. It could do this by automatically downloading the key from a key server or, if the key hasn't been updated in the last 24 hours, by issuing a warning. Thanks! :) Neal From nobody Wed Jul 15 07:22:00 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F56B1A9173 for ; Wed, 15 Jul 2015 07:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IygBHMhtsLF6 for ; Wed, 15 Jul 2015 07:21:58 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id AF59B1A914F for ; Wed, 15 Jul 2015 07:21:58 -0700 (PDT) Received: from p5081366d.dip0.t-ipconnect.de ([80.129.54.109] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZFNZK-0006tC-VI for openpgp@ietf.org; Wed, 15 Jul 2015 14:21:55 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZFNZJ-0001kj-VV for openpgp@ietf.org; Wed, 15 Jul 2015 16:21:55 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZFNZI-00078G-5H for openpgp@ietf.org; Wed, 15 Jul 2015 16:21:52 +0200 Date: Wed, 15 Jul 2015 16:21:52 +0200 Message-ID: <87a8uxlcvz.wl-neal@walfield.org> From: "Neal H. Walfield" To: IETF OpenPGP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: [openpgp] Unuploadable Keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 14:21:59 -0000 Hi, OpenPGP has support for local signatures. It would be nice to have something similar for keys as well. The motivation for this feature is: some people have keys that they don't want to have widely distributed and training others to respect this is very difficult. Concretely, it should be possible to mark a key as not exportable to a keyserver or to provide a list of key servers (perhaps described using regular expressions as per Section 8 of RFC 4880) to which it may be exported. This could be implemented as a new signature subpacket. When the key is exported (e.g., using gpg2 --export KEYID), a warning should be issued that the key is not intended for public distribution. I realize that this proposal is very informal. However, I'd like to hear if something like this is interesting for RFC 4880bis. If so, I'd be happy to try and come up with some more formal. Thanks! :) Neal From nobody Thu Jul 16 08:59:50 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA1E1A90B9 for ; Thu, 16 Jul 2015 08:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8tAjPboNa_o for ; Thu, 16 Jul 2015 08:59:39 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987921A9071 for ; Thu, 16 Jul 2015 08:59:38 -0700 (PDT) Received: by lblf12 with SMTP id f12so46402765lbl.2 for ; Thu, 16 Jul 2015 08:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=QTg+bb/W/iXuUDE/e3E4g8PS5g2uuDPVfuuaOmh+Og8=; b=SkkRW1UzLTyuKcwUCsrL9gbEcxQm1W8aSBGoB4yB8G/uT/vOa1YVfWxfPKat5soyuk BB7L/j77wYf9iMPYLW6e24XdUIreSSxj+P86M6ZaUEsREDUSXmmE2dSulCvR6Uw9snts 1zVApnKby07mZ/UC1fEhkFG7NETax5l8UVPtpVIFZdJkHyIuSJn89lZfO0lumTlTECti X+UhxZ3zuuHA8qwdXScg//cxCG/WQ58XpeaFADysn9+P+9Whk8ZWHweTRLkL8sSHLHjr fFF4Ni1TAD9msrYGp+JbWXvc6EZKCyElTJuwdVLzGAhKLr6WjWKh9ZkWPalW0KzfDiGX W7NQ== MIME-Version: 1.0 X-Received: by 10.112.167.202 with SMTP id zq10mr9776326lbb.118.1437062377136; Thu, 16 Jul 2015 08:59:37 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 16 Jul 2015 08:59:37 -0700 (PDT) Date: Thu, 16 Jul 2015 11:59:37 -0400 X-Google-Sender-Auth: 4JmThZqR8obzHcHV3fdLasCv9mg Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: multipart/alternative; boundary=001a11c269c28268f6051b0028ce Archived-At: Subject: [openpgp] Crypto on Rails X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 15:59:40 -0000 --001a11c269c28268f6051b0028ce Content-Type: text/plain; charset=UTF-8 I haven't actually used Ruby on Rails to build anything. But I have frequently adopted the Rails approach of eliminating all the unnecessary interface code between system X and system Y by insisting that the structures are represented in as close to the same form on both systems, forbidding pointless variations that only create unnecessary corner cases. Over the past few weeks I have been trying the same approach in crypto and the results are pretty interesting. Insisting that every name of a static object be the digest fingerprint of the object referenced has allowed me to remove about ten thousand lines of code. In JOSE for example, we have a 'kid' property for the Key Identifier. This can be anything the programmer likes: * Fingerprint of a certificate * Fingerprint of a Key * PGP fingerprint * Random friendly name Conventions can vary at the sender and receiver. What this means is that the identifiers in different apps have subtly different semantics. In some instances an identifier is unique to a key, in others it is unique to an account. Sometimes a name is authentically bound to something, other times it isn't. In short, there is variation without value but introducing considerable scope for confusion, error and misinterpretation. If we can introduce a fingerprint format that can be used on any type of input data without semantic substitution attacks, we can make interfacing OpenPGP to other types of cryptosystem a lot easier and simplify the implementation and deployment of all types of crypto system. --001a11c269c28268f6051b0028ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I haven't actually used Ruby on Rails to build anythin= g. But I have frequently adopted the Rails approach of eliminating all the = unnecessary interface code between system X and system Y by insisting that = the structures are represented in as close to the same form on both systems= , forbidding pointless variations that only create unnecessary corner cases= .

Over the past few weeks I have been trying the same ap= proach in crypto and the results are pretty interesting. Insisting that eve= ry name of a static object be the digest fingerprint of the object referenc= ed has allowed me to remove about ten thousand lines of code.

In JOSE for example, we have a 'kid' pro= perty for the Key Identifier. This can be anything the programmer likes:

* Fingerprint of a certificate
* Fingerpri= nt of a Key
* PGP fingerprint
* Random friendly name

Conventions can vary at the sender and receiver. Wha= t this means is that the identifiers in different apps have subtly differen= t semantics. In some instances an identifier is unique to a key, in others = it is unique to an account. Sometimes a name is authentically bound to some= thing, other times it isn't.

In short, there i= s variation without value but introducing considerable scope for confusion,= error and misinterpretation.


If we= can introduce a fingerprint format that can be used on any type of input d= ata without semantic substitution attacks, we can make interfacing OpenPGP = to other types of cryptosystem a lot easier and simplify the implementation= and deployment of all types of crypto system.
--001a11c269c28268f6051b0028ce-- From nobody Thu Jul 16 18:42:47 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7971B2E0F for ; Thu, 16 Jul 2015 18:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbVmAK7OI0xv for ; Thu, 16 Jul 2015 18:42:44 -0700 (PDT) Received: from smtp1.emailarray.com (smtp1.emailarray.com [65.39.216.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E331B2DCF for ; Thu, 16 Jul 2015 18:42:43 -0700 (PDT) Received: (qmail 24795 invoked by uid 89); 17 Jul 2015 01:42:42 -0000 Received: from unknown (HELO ?172.24.10.72?) (Y2RsQGFzZ2FhcmQub3JnQDE5OC4xNDcuMjI2LjY=) (POLARISLOCAL) by smtp1.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Jul 2015 01:42:42 -0000 From: "Christopher LILJENSTOLPE" To: "IETF OpenPGP" Date: Thu, 16 Jul 2015 18:42:38 -0700 Message-ID: <55640434-0612-431F-B6A5-3527648D0A38@cdl.asgaard.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_85FF41CF-1E2F-4AA2-A2D8-C44AAD3191BD_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: sec-ads@tools.ietf.org, Daniel Kahn Gillmor Subject: [openpgp] Draft Agenda posted X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 01:42:46 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_85FF41CF-1E2F-4AA2-A2D8-C44AAD3191BD_= Content-Type: multipart/mixed; boundary="=_MailMate_70615F58-1453-40D3-8A3D-8417B52A2E59_=" --=_MailMate_70615F58-1453-40D3-8A3D-8417B52A2E59_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, I have gone ahead and posted a DRAFT agenda for the meeting in Prague. = I will not be able to make it, but will be attending remotely. The agend= a is copied at the bottom of this e-mail. I've set aside 10 minutes for Daniel, myself, and our esteemed ADs to ta= lk about how we see this work moving forward. I've then set aside 10 min= utes for discussion or presentations on each of the four areas that we id= entified as areas we want to revise in the 4880bis document. Finally, th= ere's 30 minutes for open mic discussion (or to absorb some amount of ove= r-run in the previous section). What we really need to do is see if it makes sense for us to actually me= et, even though we have the room. Thererfore, PLEASE let us know if you = want a speaking slot in this meeting, and if so, what you want to discuss= =2E = If we don't have substantial talks, I'm not sure it makes sense to meet,= we should be able to hash out those document components online (which we= will start doing concurrently). Let us know ASAP, please. Christopher -- = =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe --=_MailMate_70615F58-1453-40D3-8A3D-8417B52A2E59_= Content-Disposition: attachment; filename=agenda.txt Content-Transfer-Encoding: quoted-printable Agenda OpenPGP (openpgp) Meeting: IETF 93, Prague Location: Congress Hall I Date: 24 July 2015 Time: 09:00 - 11:30 Chairs: Daniel Kahn Gillmor Christopher Liljenstolpe - Agenda Bashing, Blue Sheets, Scribe, etc. (10 min) - Review of Working Group scope and timetable, Chairs (10 minutes) - Discussion of suggested components of RFC4880bis Potential inclusion of elliptic curves recommended by the Crypto F= orum = Research Group (CFRG) (10 minutes) A symmetric encryption mechanism that offers modern message integrit= y = protection (e.g. AEAD) (10 minutes) Revision of mandatory-to-implement algorithm selection and deprecati= on = of weak algorithms (10 minutes) An updated public-key fingerprint mechanism (10 minutes) - Open Mic (30 min) --=_MailMate_70615F58-1453-40D3-8A3D-8417B52A2E59_=-- --=_MailMate_85FF41CF-1E2F-4AA2-A2D8-C44AAD3191BD_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVqF2OAAoJEGmx2Mt/+Iw/YzoIAJWZcU2A72h4HsltyUjaYsyF NFZzRXFEvS+7ZsouBMeFjY5dUvfwEEhcFvsBTeRjFNg7ViVAvQkDt5/ISr/vIS7f Pcp1z2EOjavbKLjP4WtbzT6lEuVb36Zz0KF5rXdiM2V1SbrQMp/J1Wg7cb9kmPNm Umhl58OA9Ea/aGAm06trdbIZSrFH1DUNQ9XemcpWxuJTYfGQgFiBzOnbOhq8TnuZ jh3ioMakZ8xA/hn2ChgK5FCefYOuYtIJoTnPUiYYPQDvMLbCEpqtoh50aG38hPMk WdjSPJa8BuYAQSsay7/JEh4WQ62g0f25gjQ9YbrhhaUMK2xlhAR8qsMLySbdGzc= =/BvD -----END PGP SIGNATURE----- --=_MailMate_85FF41CF-1E2F-4AA2-A2D8-C44AAD3191BD_=-- From nobody Thu Jul 16 18:49:53 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527971B2EBA for ; Thu, 16 Jul 2015 18:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnBXwRWAXPJg for ; Thu, 16 Jul 2015 18:49:50 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B591B2EB5 for ; Thu, 16 Jul 2015 18:49:50 -0700 (PDT) Received: by lagw2 with SMTP id w2so53385536lag.3 for ; Thu, 16 Jul 2015 18:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=J+PiMjvA0JrY67pP3fzKEQvVWPaG25cgg1idpTCyX/E=; b=dRbYerl7Xxum++vGciacXQBt/jYsXduLGjGKzFjERN7UK18gxDY4MOhVJgyjPVwghX 2xeuIukKfJH78I4PutRU7dMVOW8vpBAH1R0xXMKXX1Y7YcxxNGjUOG5foMn39PGSKrlq D4s0lsJoejXS2+KkW4mG2EHFsDwvrrkjEflRuJMPIhC4/Be3hZKd/6EEkwAQ21HKPalI Rz9b1A9CQB1j80cUHKxvVgYy2777MsgQHaciQ6qyLOed/GCI+6o+4eC2BUpzap/Oah3U 1XNR9WLC33N8qNwJW1un+tcmdQMiwGQEIWWEo8FpED/mAuEcZEZHSHpW1GEf8litnwYr XF1g== MIME-Version: 1.0 X-Received: by 10.112.172.4 with SMTP id ay4mr12361722lbc.124.1437097788589; Thu, 16 Jul 2015 18:49:48 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 16 Jul 2015 18:49:48 -0700 (PDT) In-Reply-To: <55640434-0612-431F-B6A5-3527648D0A38@cdl.asgaard.org> References: <55640434-0612-431F-B6A5-3527648D0A38@cdl.asgaard.org> Date: Thu, 16 Jul 2015 21:49:48 -0400 X-Google-Sender-Auth: ZIveccb89fsgCzRHnpQu553852U Message-ID: From: Phillip Hallam-Baker To: Christopher LILJENSTOLPE Content-Type: multipart/alternative; boundary=001a11c345a8324ca2051b086748 Archived-At: Cc: IETF OpenPGP , sec-ads@tools.ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Draft Agenda posted X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 01:49:52 -0000 --001a11c345a8324ca2051b086748 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do we actually need to discuss the CFRG curves right now? I am almost certain that OpenPGP should use the curves and so should S/MIME. But we won't know for sure until after there is a signature proposal on the table. I am equally certain that OpenPGP should be able to use the CFRG curves in pretty much the same way as the other EC algorithms already implemented modulo some possible details that won't be knowable till after CFRG readout occurs. Anyone disagree? What would there be to discuss? On Thu, Jul 16, 2015 at 9:42 PM, Christopher LILJENSTOLPE < ietf@cdl.asgaard.org> wrote: > Greetings, > > I have gone ahead and posted a DRAFT agenda for the meeting in > Prague. I will not be able to make it, but will be attending remotely. > The agenda is copied at the bottom of this e-mail. > > I've set aside 10 minutes for Daniel, myself, and our esteemed AD= s > to talk about how we see this work moving forward. I've then set aside 1= 0 > minutes for discussion or presentations on each of the four areas that we > identified as areas we want to revise in the 4880bis document. Finally, > there's 30 minutes for open mic discussion (or to absorb some amount of > over-run in the previous section). > > What we really need to do is see if it makes sense for us to > actually meet, even though we have the room. Thererfore, PLEASE let us > know if you want a speaking slot in this meeting, and if so, what you wan= t > to discuss. > > If we don't have substantial talks, I'm not sure it makes sense t= o > meet, we should be able to hash out those document components online (whi= ch > we will start doing concurrently). > > Let us know ASAP, please. > > Christopher > > > -- > =E6=9D=8E=E6=9F=AF=E7=9D=BF > Avt tace, avt loqvere meliora silentio > Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc > Current vCard here: http://www.asgaard.org/cdl/cdl.vcf > keybase: https://keybase.io/liljenstolpe > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > > --001a11c345a8324ca2051b086748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Do we actually need to discuss the CFRG curves right now?<= div>
I am almost certain that OpenPGP should use the curves a= nd so should S/MIME. But we won't know for sure until after there is a = signature proposal on the table.

I am equally cert= ain that OpenPGP should be able to use the CFRG curves in pretty much the s= ame way as the other EC algorithms already implemented modulo some possible= details that won't be knowable till after CFRG readout occurs.

Anyone disagree? What would there be to discuss?

On Thu, Jul 16= , 2015 at 9:42 PM, Christopher LILJENSTOLPE <ietf@cdl.asgaard.org= > wrote:
Greetings,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have gone ahead and posted a DRAFT agenda for= the meeting in Prague.=C2=A0 I will not be able to make it, but will be at= tending remotely.=C2=A0 The agenda is copied at the bottom of this e-mail.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've set aside 10 minutes for Daniel, mysel= f, and our esteemed ADs to talk about how we see this work moving forward.= =C2=A0 I've then set aside 10 minutes for discussion or presentations o= n each of the four areas that we identified as areas we want to revise in t= he 4880bis document.=C2=A0 Finally, there's 30 minutes for open mic dis= cussion (or to absorb some amount of over-run in the previous section).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 What we really need to do is see if it makes se= nse for us to actually meet, even though we have the room.=C2=A0 Thererfore= , PLEASE let us know if you want a speaking slot in this meeting, and if so= , what you want to discuss.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If we don't have substantial talks, I'm= not sure it makes sense to meet, we should be able to hash out those docum= ent components online (which we will start doing concurrently).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Let us know ASAP, please.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Christopher


--
=E6=9D=8E=E6=9F=AF=E7=9D=BF
Avt tace, avt loqvere meliora silentio
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf
keybase: https://keybase.io/liljenstolpe
_______= ________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp


--001a11c345a8324ca2051b086748-- From nobody Fri Jul 17 08:42:48 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABECF1A0381 for ; Fri, 17 Jul 2015 08:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWPsQK1KqvKX for ; Fri, 17 Jul 2015 08:42: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 28DA51A0372 for ; Fri, 17 Jul 2015 08:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 00BB5E2036; Fri, 17 Jul 2015 11:42: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 29157-07; Fri, 17 Jul 2015 11:42:42 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id CF0B9E2035; Fri, 17 Jul 2015 11:42:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1437147761; bh=NSfz/g/TR8XR20buDsSXJHzqzxZICf8ayv1UiiG8KRo=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=lt51+sdUqFxQot+uht3AhwsbMg7iRDb2ixzfKrxWVRvYfrujcjEHrZaBhJoFJLCYG fngFI3DHsqZ4JDrueJ0fAt/I43f4CAOzEkl7zmyuKNNmdTGGJs/LbZSpDy7635sJ5T LyfGUczhJRY5zqwUjA+RE+AhGDXLMfnkgY2vquUQ= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t6HFgfBo025992; Fri, 17 Jul 2015 11:42:41 -0400 From: Derek Atkins To: "Christopher LILJENSTOLPE" References: <55640434-0612-431F-B6A5-3527648D0A38@cdl.asgaard.org> Date: Fri, 17 Jul 2015 11:42:41 -0400 In-Reply-To: <55640434-0612-431F-B6A5-3527648D0A38@cdl.asgaard.org> (Christopher LILJENSTOLPE's message of "Thu, 16 Jul 2015 18:42:38 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , sec-ads@tools.ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Draft Agenda posted X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 15:42:47 -0000 Hi, I'm afraid I will not be in Prague and most likely will not be awake at 3-5am EDT to "dial in" during the meeting. :( -derek "Christopher LILJENSTOLPE" writes: > Greetings, > > I have gone ahead and posted a DRAFT agenda for the meeting in > Prague. I will not be able to make it, but will be attending > remotely. The agenda is copied at the bottom of this e-mail. > > I've set aside 10 minutes for Daniel, myself, and our esteemed > ADs to talk about how we see this work moving forward. I've then set > aside 10 minutes for discussion or presentations on each of the four > areas that we identified as areas we want to revise in the 4880bis > document. Finally, there's 30 minutes for open mic discussion (or to > absorb some amount of over-run in the previous section). > > What we really need to do is see if it makes sense for us to > actually meet, even though we have the room. Thererfore, PLEASE let > us know if you want a speaking slot in this meeting, and if so, what > you want to discuss. > > If we don't have substantial talks, I'm not sure it makes > sense to meet, we should be able to hash out those document components > online (which we will start doing concurrently). > > Let us know ASAP, please. > > Christopher -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 17 10:53:38 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F621ACDB9 for ; Fri, 17 Jul 2015 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgu9IdEUFRsz for ; Fri, 17 Jul 2015 10:53:36 -0700 (PDT) Received: from seditious.adversary.org (seditious.adversary.org [59.167.194.34]) by ietfa.amsl.com (Postfix) with ESMTP id 346881ACD56 for ; Fri, 17 Jul 2015 10:53:35 -0700 (PDT) Received: from localhost (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id E81D011C017D; Sat, 18 Jul 2015 03:53:32 +1000 (EST) X-Virus-Scanned: amavisd-new at adversary.org Received: from seditious.adversary.org ([127.0.0.1]) by localhost (seditious.adversary.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mOWT_Aymu_b7; Sat, 18 Jul 2015 03:53:02 +1000 (EST) Received: from nefarious.adversary.org (seditious.adversary.org [127.0.0.1]) by seditious.adversary.org (Postfix) with ESMTP id 56B6911C0179; Sat, 18 Jul 2015 03:52:49 +1000 (EST) Message-ID: <55A940E5.2000701@adversary.org> Date: Sat, 18 Jul 2015 03:52:37 +1000 From: Ben McGinnes User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Derek Atkins , Christopher LILJENSTOLPE References: <55640434-0612-431F-B6A5-3527648D0A38@cdl.asgaard.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WHKnCKaPBvKr8enkr1JbT7n5Dwl2AQVSi" Archived-At: Cc: IETF OpenPGP , sec-ads@tools.ietf.org, Daniel Kahn Gillmor Subject: Re: [openpgp] Draft Agenda posted X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 17:53:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WHKnCKaPBvKr8enkr1JbT7n5Dwl2AQVSi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18/07/2015 1:42 am, Derek Atkins wrote: > Hi, >=20 > I'm afraid I will not be in Prague and most likely will not be awake at= > 3-5am EDT to "dial in" during the meeting. :( I'm in a similar position to Derek, though not for time/sleep. That's the night before the PPAU Party Congress and Murphy's Law dictates I'll be either dealing with a crisis or tweaking my Treasurer's report for some overlooked thing. No doubt you'll all manage fine, though. Regards, Ben --WHKnCKaPBvKr8enkr1JbT7n5Dwl2AQVSi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJVqUDmAAoJEH/y03E1x1U86pAMALwcUrten90Z9v2wmVfQG2+Q U2gbFqclOBmJDj9J/4Ux/W8HfC7F+HUMLybviBBE34pScm9ubPiuu+kOzHVRFpss qIt1YpxsvpCVUD6XAaqYzZdTvdj/G6UNYcQ4hiorFxaWEROo4bd/P2cvmMspIqJX tQIHiBznRH62hH9dCUioUtWrNNlI+X5lfAZnGhmnBL1YJ7wCXGA06imxd9Gr+OUG DrhSMd8q1BjNb2u0Yc+o7peosOHXTtcIRIf4fwdbFF+D3CkAKsIQRv0VvuBMAw2V uLe3ttpsATD+jdnf7KyG6/bBww0u6+Qw784ifsYKs1P2QlBNVkSEOhMIZlfhBueC mtv+XCSPWGDF0VSoSliJYu25U7Gt4GI3kjcHV+yBBPqhblz+4LPd+Ujho3gxchb0 I288aSJalvJg2/urQyXRsXCbYPJhcZ6suUU7g+Lpm2KXMVwGBtX2F5+TWzBDmeSm tPzySlqiUkeEvjL8mLdGWQpWmhOP0nYJJ/iKaW5ZWw== =c6OF -----END PGP SIGNATURE----- --WHKnCKaPBvKr8enkr1JbT7n5Dwl2AQVSi-- From nobody Sat Jul 18 15:08:53 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557421A1A02 for ; Sat, 18 Jul 2015 15:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4206wcQ_ltQ for ; Sat, 18 Jul 2015 15:08:50 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id E9EE61A0382 for ; Sat, 18 Jul 2015 15:08:49 -0700 (PDT) Received: from [97.40.194.69] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZGaHn-0002LU-L8; Sat, 18 Jul 2015 18:08:48 -0400 Date: Sat, 18 Jul 2015 15:09:03 -0700 From: Bill Frantz To: "Neal H. Walfield" X-Priority: 3 In-Reply-To: <87bnfdldo3.wl-neal@walfield.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79f80d01279162d7b7a6eddc24e243c98f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 97.40.194.69 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 22:08:51 -0000 On 7/15/15 at 7:05 AM, neal@walfield.org (Neal H. Walfield) wrote: >Encrypted mailing lists are currently difficult to do securely and >easily. Either they trade security for usability by reencrypting mail >or they trade usability for security by requiring each poster to keep >a local list of subscribers up to date. A long time ago I was a member of an encrypted mailing list that=20 used PGP. Every member of the list had a copy of the private PGP=20 key (and its password). Messages to the list were encrypted=20 using the public key and all the legitimate list members could=20 decrypt using their copy of the private key. It worked quite well. When someone was dropped from the list,=20 new keys were needed and had to be distributed, which was a=20 disadvantage, but practically resulted in somewhat regular key changes. There may be better solutions, but this one worked with=20 unmodified PGP. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"After all, if the conventional wisdom was=20 working, the 408-356-8506 | rate of systems being compromised would be=20 going down, www.pwpconsult.com | wouldn't it?" -- Marcus Ranum From nobody Sat Jul 18 15:55:02 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD841A1ABE for ; Sat, 18 Jul 2015 15:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ioEFeNnl5WG for ; Sat, 18 Jul 2015 15:54:58 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8C1A1ABC for ; Sat, 18 Jul 2015 15:54:58 -0700 (PDT) Received: from p5ddf8f05.dip0.t-ipconnect.de ([93.223.143.5] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZGb0N-000213-Qg; Sat, 18 Jul 2015 22:54:51 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZGb0L-00070a-Pg; Sun, 19 Jul 2015 00:54:51 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZGb0K-0004PX-Oe; Sun, 19 Jul 2015 00:54:48 +0200 Date: Sun, 19 Jul 2015 00:54:48 +0200 Message-ID: <874ml1krev.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bill Frantz In-Reply-To: References: <87bnfdldo3.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 22:55:00 -0000 Hi, Thanks for your thoughts, I appreciate them. At Sat, 18 Jul 2015 15:09:03 -0700, Bill Frantz wrote: > > On 7/15/15 at 7:05 AM, neal@walfield.org (Neal H. Walfield) wrote: > > > Encrypted mailing lists are currently difficult to do securely and > > easily. Either they trade security for usability by reencrypting mail > > or they trade usability for security by requiring each poster to keep > > a local list of subscribers up to date. > > A long time ago I was a member of an encrypted mailing list that used > PGP. Every member of the list had a copy of the private PGP key (and > its password). Messages to the list were encrypted using the public > key and all the legitimate list members could decrypt using their copy > of the private key. > > It worked quite well. When someone was dropped from the list, new keys > were needed and had to be distributed, which was a disadvantage, but > practically resulted in somewhat regular key changes. > > There may be better solutions, but this one worked with unmodified > PGP. Yes, I think this is a reasonable solution, but it's not easy to use. The solution I propose is easy to use and it largely backwards compatible. - Only posters need to understand the new format; subscribers just decrypt as usual. - If a poster encrypts using the mailing list's key, the admin can always decrypt and reencrypt. Depending on the security requirements, this can be completely or partially automated. Thanks! Neal From nobody Sat Jul 18 19:29:03 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9169D1A1A0B for ; Sat, 18 Jul 2015 19:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FshF50Prg-o2 for ; Sat, 18 Jul 2015 19:29:00 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D211A1A00 for ; Sat, 18 Jul 2015 19:29:00 -0700 (PDT) Received: by lahh5 with SMTP id h5so79376270lah.2 for ; Sat, 18 Jul 2015 19:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4A9A4HDGzqkUDNh9yOPFufkiG65qpu/4tbB8vRf24rc=; b=rXRq1KXTqOLHvtDzr212eN5RwbRGV2jmnPcrqDlZIFm1MI3kl9QOJUC2XssUChOwiN XBHPCp2KVM/4SJF22fwv1DI0fc3/Kbg1+q4dvemG6UFSdZgqRnwXcR2SU/hmdyX0V1XU iCJunw43XGiX78ctD/CYRqrNTDxVfHRX8kWd6CGFSDOKYY1FdP7WyB+60EHW8PbDyVOJ k+IuZcOPQEr0P4NcAdp36xmEAX5WTSvH3j6HJhananJbiR4/uQOdRPeibpfKvHNq8Cac ovLhZXD/Q5/ehnCjPK1JhS66CV4ow4e9XqiZfpm8pB9KdAmZxhM93ijO97il4Ki1ssOQ 37hQ== MIME-Version: 1.0 X-Received: by 10.112.164.35 with SMTP id yn3mr21052898lbb.91.1437272938580; Sat, 18 Jul 2015 19:28:58 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 18 Jul 2015 19:28:58 -0700 (PDT) In-Reply-To: <874ml1krev.wl-neal@walfield.org> References: <87bnfdldo3.wl-neal@walfield.org> <874ml1krev.wl-neal@walfield.org> Date: Sat, 18 Jul 2015 22:28:58 -0400 X-Google-Sender-Auth: IljZnMMVAHWN-zVFAAaHSrijdIY Message-ID: From: Phillip Hallam-Baker To: "Neal H. Walfield" Content-Type: multipart/alternative; boundary=001a11c33530f31225051b312ee3 Archived-At: Cc: IETF OpenPGP , Bill Frantz Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 02:29:01 -0000 --001a11c33530f31225051b312ee3 Content-Type: text/plain; charset=UTF-8 I don't think this is a good time to do mailing lists in OpenPGP. A mailing list is essentially a form of multi-access drop box. There is a list of people who can write to the drop box and a list of people who can read. The only thing that distinguishes a mailing list from a drop box is the way the data is organized. But I think it much easier to organize the contents of a shared drop box to be a mailing list than to try to do anything on top of SMTP, let alone add security. The OpenPGP bit is fine, its the SMTP bit that is the problem. There are two basic ways a dropbox type scheme can be made to work with standard public key * There is a shared public key and everyone knows the private key. This is changed each time a person drops off the list. * Each person has an individual public key pair and the mailing list is encrypted and sent out to each of them. --001a11c33530f31225051b312ee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think this is a goo= d time to do mailing lists in OpenPGP. A mailing list is essentially a form= of multi-access drop box. There is a list of people who can write to the d= rop box and a list of people who can read.
=
The only thing that distinguishes a ma= iling list from a drop box is the way the data is organized. But I think it= much easier to organize the contents of a shared drop box to be a mailing = list than to try to do anything on top of SMTP, let alone add security. The= OpenPGP bit is fine, its the SMTP bit that is the problem.=C2=A0

There are two b= asic ways a dropbox type scheme can be made to work with standard public ke= y

* Th= ere is a shared public key and everyone knows the private key. This is chan= ged each time a person drops off the list.
=
* Each person has an individual public= key pair and the mailing list is encrypted and sent out to each of them.

=C2=A0<= /div>


--001a11c33530f31225051b312ee3-- From nobody Sun Jul 19 01:49:04 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003E51A8A4B for ; Sun, 19 Jul 2015 01:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FqAMCgUmT1i for ; Sun, 19 Jul 2015 01:49:01 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A4F1A8A42 for ; Sun, 19 Jul 2015 01:49:00 -0700 (PDT) Received: from latte.josefsson.org (m176-71-60-165.cust.tele2.se [176.71.60.165]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6J8mMlS010597 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 19 Jul 2015 10:48:24 +0200 From: Simon Josefsson To: Phillip Hallam-Baker References: <55640434-0612-431F-B6A5-3527648D0A38@cdl.asgaard.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150719:phill@hallambaker.com::anGM1sJJdEYUMmyq:0+oX X-Hashcash: 1:22:150719:ietf@cdl.asgaard.org::AKfBJ4FgBQM6ExNo:BaGR X-Hashcash: 1:22:150719:sec-ads@tools.ietf.org::nvWkDEW0jE48KVpz:9b6J X-Hashcash: 1:22:150719:openpgp@ietf.org::+9R8dnJDcttC0CZ7:Stku X-Hashcash: 1:22:150719:dkg@fifthhorseman.net::A6ZEfv9/6X1RsVCj:OQ8T Date: Sun, 19 Jul 2015 10:48:20 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 16 Jul 2015 21:49:48 -0400") Message-ID: <87615gttwr.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Daniel Kahn Gillmor , IETF OpenPGP , sec-ads@tools.ietf.org, Christopher LILJENSTOLPE Subject: Re: [openpgp] Draft Agenda posted X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 08:49:03 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker writes: > Do we actually need to discuss the CFRG curves right now? > > I am almost certain that OpenPGP should use the curves and so should > S/MIME. But we won't know for sure until after there is a signature > proposal on the table. > > I am equally certain that OpenPGP should be able to use the CFRG curves in > pretty much the same way as the other EC algorithms already implemented > modulo some possible details that won't be knowable till after CFRG readout > occurs. > > Anyone disagree? What would there be to discuss? There is: https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-02 It is already implemented, and I believe there is interest in seeing it reviewed, approved and published. I suggest the chairs ask whether to adopt this draft as a WG item. I'm not sure other discussions are useful, as I agree with you it is not clear what question to ask the participants. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVq2RUAAoJEIYLf7sy+BGdTAwH/0RCICTCCKs6Xiov41pyDq3y GjJoHxLXrdXME1t0nmaJGiBu1Lz2d45ndCGItIF7KtXlY21O8kSMkj39H36phLIn BaYIwe8hLTRzPTFQmXm3yqKR4k9dtw7zNjcrx5rMiB0aPKY+Aodv8rbK35rF3qEA WJGTEkWTv8GKuk1iDoTk0jHJModt8N/GDPS981C5tA2FnRtP5Oj6Tcm/Kp/4nfGg AT4CcOoWyHvronC2iRDw8m5J0r3ezwIwbU4ifke55p3cRCC+kIRyjaRPbjFVdTyA YsCgnS1+iYMJif9POVnmydulQ7dDFk+Zd2ZyqJA6Vi/R5v2HpR9vtvkNTg4jXyg= =8/Ge -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 19 06:39:15 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E4F1ACEFC for ; Sun, 19 Jul 2015 06:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKk5pjDv9QQg for ; Sun, 19 Jul 2015 06:39:13 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id E31021ACEFB for ; Sun, 19 Jul 2015 06:39:12 -0700 (PDT) Received: from [97.40.193.192] (helo=Williams-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZGoo9-0005AR-NT; Sun, 19 Jul 2015 09:39:10 -0400 Date: Sun, 19 Jul 2015 06:39:09 -0700 From: Bill Frantz To: Phillip Hallam-Baker X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79f963f2f32e2d3f15aecd2c27663d0581350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 97.40.193.192 Archived-At: Cc: IETF OpenPGP , "Neal H. Walfield" Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 13:39:14 -0000 On 7/18/15 at 7:28 PM, phill@hallambaker.com (Phillip=20 Hallam-Baker) wrote: >There are two basic ways a dropbox type scheme can be made to work with >standard public key > >* There is a shared public key and everyone knows the private key. This is >changed each time a person drops off the list. This approach will probably scale to reasonable levels. When it=20 gets to when you are sending out new keys several times a day,=20 then batching the drops may be a viable solution. >* Each person has an individual public key pair and the mailing list is >encrypted and sent out to each of them. This approach has real scaling problems. Assume the mailing list=20 software does the encryption. When you get a large list, then=20 the CPU load of encrypting the symmetric key to each member will=20 be quite high. The alternative seems to be to have the sender do=20 the encryption, but then every list member needs to have every=20 other's public key and a smart phone may be completely overwhelmed. So the question is, how large a list do we need to support? The=20 practical high water mark may come with a large organization=20 that needs a mailing list for all its members. The internal=20 mailing list of a corporation with 100,000 employees may be a=20 good example. Of course, a secret which that many people know=20 isn't very secret. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | "The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself." - FDR | 16345=20 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos,=20 CA 95032 From nobody Sun Jul 19 06:54:14 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF61ACF60 for ; Sun, 19 Jul 2015 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4GvugryrUSJ for ; Sun, 19 Jul 2015 06:54:11 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A30C1ACEF6 for ; Sun, 19 Jul 2015 06:54:11 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so82332531lbb.0 for ; Sun, 19 Jul 2015 06:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ef5s4zNdzADHIdSwR5WLtvXzB8U7shnnNVpkEk0yITk=; b=dUyhL+BIYzRfbpg0CxRDge14i3Z7hEAqZwVQhsAhO1XpE7+Zjjz2U/UzWxbxd0Xs13 BTnXQUAQD+qVQiDyCx9++v2Y2rJE88dwWAZKIbjo+wxW5MN/GLvMHhLGCyUbBCH59oY/ jE7WrVZjCT1avPEFItfa8crnlj5eL/3q7/Ks+bsNeQLe2hCnLnr0WXTwzHPoq5nkj88v Cqd+mDSMCIWS5p6VbNWRhEnG+8zrbipB72/dxX0tcrww+/IRMHakZrl7etHLhgt99Q9v 8lmYTotjKjrVExrKo83ecJE8/aSOxUEh0Jt/IhUOvsW5TEDYi/LY0yEaVnu3GEWGQty7 Fsxg== MIME-Version: 1.0 X-Received: by 10.112.123.179 with SMTP id mb19mr23728882lbb.55.1437314049711; Sun, 19 Jul 2015 06:54:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sun, 19 Jul 2015 06:54:09 -0700 (PDT) In-Reply-To: References: Date: Sun, 19 Jul 2015 09:54:09 -0400 X-Google-Sender-Auth: 6M6rrYci7aiLbgTzC_vbMfaQAS8 Message-ID: From: Phillip Hallam-Baker To: Bill Frantz Content-Type: multipart/alternative; boundary=047d7bfd04765d25bf051b3ac125 Archived-At: Cc: IETF OpenPGP , "Neal H. Walfield" Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 13:54:13 -0000 --047d7bfd04765d25bf051b3ac125 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 19, 2015 at 9:39 AM, Bill Frantz wrote: > On 7/18/15 at 7:28 PM, phill@hallambaker.com (Phillip Hallam-Baker) wrote: > > There are two basic ways a dropbox type scheme can be made to work with >> standard public key >> >> * There is a shared public key and everyone knows the private key. This is >> changed each time a person drops off the list. >> > > This approach will probably scale to reasonable levels. When it gets to > when you are sending out new keys several times a day, then batching the > drops may be a viable solution. At some point though, the process of dropping the new keys becomes equivalent to a cloud service with knowledge of the content and we lose end to end. > > * Each person has an individual public key pair and the mailing list is >> encrypted and sent out to each of them. >> > > This approach has real scaling problems. Assume the mailing list software > does the encryption. When you get a large list, then the CPU load of > encrypting the symmetric key to each member will be quite high. The > alternative seems to be to have the sender do the encryption, but then > every list member needs to have every other's public key and a smart phone > may be completely overwhelmed. > > So the question is, how large a list do we need to support? The practical > high water mark may come with a large organization that needs a mailing > list for all its members. The internal mailing list of a corporation with > 100,000 employees may be a good example. Of course, a secret which that > many people know isn't very secret. > 100,000 subscribers does not need to be end to end. There is no security advantage, there is a huge cost. --047d7bfd04765d25bf051b3ac125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jul 19, 2015 at 9:39 AM, Bill Frantz <frantz@pwpconsult.co= m> wrote:
= On 7/18/15 at 7:28 PM, phill@hallambaker.com (Phillip Hallam-Baker) wrote:

There are two basic ways a dropbox type scheme can be made to work with
standard public key

* There is a shared public key and everyone knows the private key. This is<= br> changed each time a person drops off the list.

 This approach will probably scale to reasonable levels. When it gets to whe= n you are sending out new keys several times a day, then batching the drops= may be a viable solution.

At some point th= ough, the process of dropping the new keys becomes equivalent to a cloud se= rvice with knowledge of the content and we lose end to end.

<= /div>
=C2=A0

* Each person has an individual public key pair and the mailing list is
encrypted and sent out to each of them.

 This approach has real scaling problems. Assume the mailing list software d= oes the encryption. When you get a large list, then the CPU load of encrypt= ing the symmetric key to each member will be quite high. The alternative se= ems to be to have the sender do the encryption, but then every list member = needs to have every other's public key and a smart phone may be complet= ely overwhelmed.

So the question is, how large a list do we need to support? The practical h= igh water mark may come with a large organization that needs a mailing list= for all its members. The internal mailing list of a corporation with 100,0= 00 employees may be a good example. Of course, a secret which that many peo= ple know isn't very secret.

100,000= subscribers does not need to be end to end. There is no security advantage= , there is a huge cost.
=C2=A0
--047d7bfd04765d25bf051b3ac125-- From nobody Mon Jul 20 03:03:12 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE901A1AD0 for ; Mon, 20 Jul 2015 03:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTl3wjKJHrdC for ; Mon, 20 Jul 2015 03:02:56 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4971A1AC1 for ; Mon, 20 Jul 2015 03:02:56 -0700 (PDT) Received: from p50813dfc.dip0.t-ipconnect.de ([80.129.61.252] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZH7uI-00045r-HD; Mon, 20 Jul 2015 10:02:46 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZH7uG-0000io-9b; Mon, 20 Jul 2015 12:02:46 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZH7uF-00062f-8u; Mon, 20 Jul 2015 12:02:43 +0200 Date: Mon, 20 Jul 2015 12:02:42 +0200 Message-ID: <871tg3kuyl.wl-neal@walfield.org> From: "Neal H. Walfield" To: Phillip Hallam-Baker In-Reply-To: References: <87bnfdldo3.wl-neal@walfield.org> <874ml1krev.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP , Bill Frantz Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:03:02 -0000 Hi Phillip, Thanks for the feedback. At Sat, 18 Jul 2015 22:28:58 -0400, Phillip Hallam-Baker wrote: > I don't think this is a good time to do mailing lists in OpenPGP. If now is not a good time to add mailing list support to OpenPGP, then I'll retract my proposal. What is the reason that now is not a good time to discuss this issue? Do you think this should wait until after 4880bis is finished and we should then recharter? > A mailing list is essentially a form of multi-access drop box. There > is a list of people who can write to the drop box and a list of > people who can read. > The only thing that distinguishes a mailing list from a drop box is > the way the data is organized. But I think it much easier to organize > the contents of a shared drop box to be a mailing list than to try to > do anything on top of SMTP, let alone add security. The OpenPGP bit is > fine, its the SMTP bit that is the problem. I don't understand this. Isn't a mailing list normally on top of SMTP? When you say that the OpenPGP bit is fine, but that the SMTP bit is the problem, what do you mean? Are you arguing that we should abandon SMTP altogether and use some other transport? I think this will be a hard fight and not one that the OpenPGP WG should take on. The reality is that people are trying to do secure mailing lists over SMTP and it is currently hard. > There are two basic ways a dropbox type scheme can be made to work > with standard public key > > * There is a shared public key and everyone knows the private key. > This is changed each time a person drops off the list. I think this is fine for small, technically apt groups, but I don't this is scales or is suitable for more casual use. Alternatively, I may just not be aware of all of the tools that make this easy. If so, I'd appreciate some pointers. > * Each person has an individual public key pair and the mailing list > is encrypted and sent out to each of them. There are two possibilities here. First, the mailing list software reencrypts the message. This means that the plaintext is handled on the server and that either the private key material is directly on the server or it is on a smartcard permanently attached to the server. In the former case, the key material can be stolen and in the later case, an attacker can send out fake messages until the break-in is discovered. This implies absolute trust in the provider. These issues limit the applicability of this solution. The other possibility is that each poster encrypts to all recipients. This works, but has horrible management issues. In particular, the posters need to synchronize the list of subscribers and keys. This is not easy. There is another management problem as well, which is less obvious. The mailing list participants might want the list of recipients to be hidden. In GnuPG, this is done using the --hidden-recipient option. In this case, the public-key encrypted session key packets don't contain the recipients' keyids. Making sure all posters remember to use this option is hard. This is also not scalable: the recipients will need to decrypt (on average) half of the public-key encrypted session key packets before they find the packet for them. My proposal solves these problems. There is no reencryption. Distribution takes advantage of existing infrastructure, namely, key servers. The packet format includes mailing list options and provides an optimization so that normally only a few public-key encrypted session key packets need to be decrypted when hiding the recipients. My proposal is also largely backwards compatible with existing OpenPGP implementations. In particular, it is completely backwards compatible for recipients and requires the mailing list administrator to reencrypt posts from posters if they are not using a compliant OpenPGP implementation. Now, my proposal is not perfect. In particular, posters still need to encrypt the session key for all of the subscribers, which can take a while if the list is large. But, this represents a security trade-off and users can decide if this cost justifies the added security relative to the convenience of a reencryption gateway. Thanks, Neal From nobody Mon Jul 20 03:13:09 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086DE1A1AFC for ; Mon, 20 Jul 2015 03:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMPV3ZNefu21 for ; Mon, 20 Jul 2015 03:13:07 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id BD0491A1AF6 for ; Mon, 20 Jul 2015 03:13:07 -0700 (PDT) Received: from p50813dfc.dip0.t-ipconnect.de ([80.129.61.252] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZH84B-0004C5-NI; Mon, 20 Jul 2015 10:12:59 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZH84A-0000jZ-Nj; Mon, 20 Jul 2015 12:13:00 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZH849-00063O-NL; Mon, 20 Jul 2015 12:12:57 +0200 Date: Mon, 20 Jul 2015 12:12:57 +0200 Message-ID: <87zj2rjfx2.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bill Frantz In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:13:09 -0000 At Sun, 19 Jul 2015 06:39:09 -0700, Bill Frantz wrote: > On 7/18/15 at 7:28 PM, phill@hallambaker.com (Phillip Hallam-Baker) > wrote: > So the question is, how large a list do we need to support? The > practical high water mark may come with a large organization that > needs a mailing list for all its members. The internal mailing list of > a corporation with 100,000 employees may be a good example. Of course, > a secret which that many people know isn't very secret. I think this is a very good point. But, once you get to mailing lists with that many subscribers, I think the mode of operation changes. In particular, the number of posts per unit time is probably very small and there are probably only a small number of authorized posters. These posters are probably not posting from their phones, but sending messages that were partially composed by the PR department. As such, computational cost is probably not a concern. I think a solution that scales to thousands of subscribers is probably more than adequate. Neal From nobody Mon Jul 20 03:14:31 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D7F1A1B0D for ; Mon, 20 Jul 2015 03:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD7p5U3GHQCc for ; Mon, 20 Jul 2015 03:14:28 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE441A1AFF for ; Mon, 20 Jul 2015 03:14:27 -0700 (PDT) Received: from p50813dfc.dip0.t-ipconnect.de ([80.129.61.252] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZH85U-0004Cb-6k; Mon, 20 Jul 2015 10:14:20 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZH85T-0000js-3S; Mon, 20 Jul 2015 12:14:20 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZH85S-00063U-31; Mon, 20 Jul 2015 12:14:18 +0200 Date: Mon, 20 Jul 2015 12:14:18 +0200 Message-ID: <87y4ibjfut.wl-neal@walfield.org> From: "Neal H. Walfield" To: Phillip Hallam-Baker In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP , Bill Frantz Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:14:29 -0000 At Sun, 19 Jul 2015 09:54:09 -0400, Phillip Hallam-Baker wrote: > > > On Sun, Jul 19, 2015 at 9:39 AM, Bill Frantz > wrote: > > On 7/18/15 at 7:28 PM, phill@hallambaker.com (Phillip > Hallam-Baker) wrote: > > There are two basic ways a dropbox type scheme can be made to > work with > standard public key > > * There is a shared public key and everyone knows the private > key. This is > changed each time a person drops off the list. > > > This approach will probably scale to reasonable levels. When it > gets to when you are sending out new keys several times a day, > then batching the drops may be a viable solution. > > At some point though, the process of dropping the new keys becomes > equivalent to a cloud service with knowledge of the content and we > lose end to end. Can you elaborate on this? If the drops are encrypted to all of the posters why does the server know the content? Thanks, Neal From nobody Mon Jul 20 03:36:51 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF39B1A1BBC for ; Mon, 20 Jul 2015 03:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9G5cJybKrYk for ; Mon, 20 Jul 2015 03:36:50 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id EAF8E1A21B2 for ; Mon, 20 Jul 2015 03:27:15 -0700 (PDT) Received: from p50813dfc.dip0.t-ipconnect.de ([80.129.61.252] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZH8Hw-0004Im-0w for openpgp@ietf.org; Mon, 20 Jul 2015 10:27:12 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZH8Hv-0000kx-5B for openpgp@ietf.org; Mon, 20 Jul 2015 12:27:12 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZH8Hu-00064I-5e for openpgp@ietf.org; Mon, 20 Jul 2015 12:27:10 +0200 Date: Mon, 20 Jul 2015 12:27:10 +0200 Message-ID: <87wpxvjf9d.wl-neal@walfield.org> From: "Neal H. Walfield" To: IETF OpenPGP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 10:36:51 -0000 Hi, Section 5.2.3.23 describes the reason-for-revocation subpacket. One reason is that the key has been superseded. Unfortunately, there is no standard, machine-readable way to indicate what the new key is. I propose that the description field be augmented to include optional email style headers. Further, we specify the following header to specify the new key: Superceded-by: fingerprint Finally, we add that if this extension is used, the whole message should be signed by the new key (to show that the user controls both keys). This amendment has the advantage that it is completely backwards compatible with existing implementations. Thoughts? Thanks, Neal From nobody Mon Jul 20 08:15:30 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECD01A899B for ; Mon, 20 Jul 2015 08:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 PkuoBxeUZh-w for ; Mon, 20 Jul 2015 08:15:28 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A851A8AA1 for ; Mon, 20 Jul 2015 08:15:20 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZHCmk-0004Kr-O8 for ; Mon, 20 Jul 2015 17:15:18 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZHClm-0000jB-D4; Mon, 20 Jul 2015 17:14:18 +0200 From: Werner Koch To: "Neal H. Walfield" References: <87wpxvjf9d.wl-neal@walfield.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: "Neal H. Walfield" , IETF OpenPGP Date: Mon, 20 Jul 2015 17:14:18 +0200 In-Reply-To: <87wpxvjf9d.wl-neal@walfield.org> (Neal H. Walfield's message of "Mon, 20 Jul 2015 12:27:10 +0200") Message-ID: <87d1zmlv3p.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 15:15:30 -0000 On Mon, 20 Jul 2015 12:27, neal@walfield.org said: > I propose that the description field be augmented to include optional > email style headers. Further, we specify the following header to > specify the new key: > > Superceded-by: fingerprint I think it is better to have a signature subpacket or notation data to the same effect. This has the advantage that it can also be used with a non-revoked key or data signature to declare a plan to supercede a key in the near future. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Jul 20 13:03:13 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841DE1B3134 for ; Mon, 20 Jul 2015 13:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up7FjfD5znnL for ; Mon, 20 Jul 2015 13:03:11 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD851B2C8C for ; Mon, 20 Jul 2015 13:03:11 -0700 (PDT) Received: from p50813dfc.dip0.t-ipconnect.de ([80.129.61.252] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZHHHG-0008Be-G6 for openpgp@ietf.org; Mon, 20 Jul 2015 20:03:06 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZHHHF-0001UZ-8S; Mon, 20 Jul 2015 22:03:06 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZHHHE-0006lb-83; Mon, 20 Jul 2015 22:03:04 +0200 Date: Mon, 20 Jul 2015 22:03:04 +0200 Message-ID: <87twsyk35z.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Neal H. Walfield" , IETF OpenPGP In-Reply-To: <87d1zmlv3p.fsf@vigenere.g10code.de> References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 20:03:12 -0000 Hi Werner, At Mon, 20 Jul 2015 17:14:18 +0200, Werner Koch wrote: > > On Mon, 20 Jul 2015 12:27, neal@walfield.org said: > > > I propose that the description field be augmented to include optional > > email style headers. Further, we specify the following header to > > specify the new key: > > > > Superceded-by: fingerprint > > I think it is better to have a signature subpacket or notation data to > the same effect. This has the advantage that it can also be used with a > non-revoked key or data signature to declare a plan to supercede a key > in the near future. This is a good point. Either approach that you propose seems reasonable to me. Thanks, Neal From nobody Tue Jul 21 05:08:25 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6D91A1A52 for ; Tue, 21 Jul 2015 05:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j93Uy482GE0Z for ; Tue, 21 Jul 2015 05:08:23 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3611A1A4E for ; Tue, 21 Jul 2015 05:08:23 -0700 (PDT) Received: from p5ddf95bf.dip0.t-ipconnect.de ([93.223.149.191] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZHWLK-0006Ki-Jy for openpgp@ietf.org; Tue, 21 Jul 2015 12:08:18 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZHWLK-0002Vr-2Q for openpgp@ietf.org; Tue, 21 Jul 2015 14:08:18 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZHWLJ-0007xS-1l for openpgp@ietf.org; Tue, 21 Jul 2015 14:08:17 +0200 Date: Tue, 21 Jul 2015 14:08:16 +0200 Message-ID: <87pp3lk91r.wl-neal@walfield.org> From: "Neal H. Walfield" To: IETF OpenPGP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:08:24 -0000 Hi, Simon pointed out to me in another context that the user id (section 5.11 of RFC 4880) is not always in RFC 2822 name-addr format, but is sometimes simply a hostname. I think we should expand the recommendation in that section to cover this usage. Thanks, Neal From nobody Tue Jul 21 05:35:27 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D11A0406 for ; Tue, 21 Jul 2015 05:35: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 cJLMI3_7RC8M for ; Tue, 21 Jul 2015 05:35:21 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBBD1A1B17 for ; Tue, 21 Jul 2015 05:35:20 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZHWlT-0005yg-8m for ; Tue, 21 Jul 2015 14:35:19 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZHWij-0003ly-Qf; Tue, 21 Jul 2015 14:32:29 +0200 From: Werner Koch To: "Neal H. Walfield" References: <87pp3lk91r.wl-neal@walfield.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: "Neal H. Walfield" , IETF OpenPGP Date: Tue, 21 Jul 2015 14:32:29 +0200 In-Reply-To: <87pp3lk91r.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 21 Jul 2015 14:08:16 +0200") Message-ID: <87pp3lhesi.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:35:25 -0000 On Tue, 21 Jul 2015 14:08, neal@walfield.org said: > Hi, > > Simon pointed out to me in another context that the user id (section > 5.11 of RFC 4880) is not always in RFC 2822 name-addr format, but is > sometimes simply a hostname. I think we should expand the > recommendation in that section to cover this usage. The name-addr convention has served us well for more than 20 years and I see no reason to explicitly recommend the use of just a hostname. I see no problem which will be solved by this. In case the hostname shall be used similar to a a user id (e.g. for DNS lookup), it is easier to use a pseudo mail address like hostmaster@foo.example.org. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Jul 21 10:04:32 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738B31ACD86 for ; Tue, 21 Jul 2015 10:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgshYAMT9K2E for ; Tue, 21 Jul 2015 10:04:30 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id E9E831B2F88 for ; Tue, 21 Jul 2015 10:04:29 -0700 (PDT) Received: from p5ddf95bf.dip0.t-ipconnect.de ([93.223.149.191] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZHaxt-0000Ai-BD for openpgp@ietf.org; Tue, 21 Jul 2015 17:04:25 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZHaxs-0002tA-7q; Tue, 21 Jul 2015 19:04:25 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZHaxr-0008ED-4C; Tue, 21 Jul 2015 19:04:23 +0200 Date: Tue, 21 Jul 2015 19:04:22 +0200 Message-ID: <87oaj5jvc9.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Neal H. Walfield" , IETF OpenPGP In-Reply-To: <87pp3lhesi.fsf@vigenere.g10code.de> References: <87pp3lk91r.wl-neal@walfield.org> <87pp3lhesi.fsf@vigenere.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Subject: Re: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 17:04:31 -0000 Hi, At Tue, 21 Jul 2015 14:32:29 +0200, Werner Koch wrote: > > Simon pointed out to me in another context that the user id (section > > 5.11 of RFC 4880) is not always in RFC 2822 name-addr format, but is > > sometimes simply a hostname. I think we should expand the > > recommendation in that section to cover this usage. > > The name-addr convention has served us well for more than 20 years and I > see no reason to explicitly recommend the use of just a hostname. I see > no problem which will be solved by this. In case the hostname shall be > used similar to a a user id (e.g. for DNS lookup), it is easier to use a > pseudo mail address like hostmaster@foo.example.org. I'm not making a recommendation about what should be done, but suggesting we update the RFC to reflect current practice. Neal From nobody Tue Jul 21 14:11:46 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9592C1B30A0 for ; Tue, 21 Jul 2015 14:11:45 -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 aNich8CaMsOd for ; Tue, 21 Jul 2015 14:11:43 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9062A1B309D for ; Tue, 21 Jul 2015 14:11:43 -0700 (PDT) Received: from fifthhorseman.net (31.208.broadband18.iol.cz [109.81.208.31]) by che.mayfirst.org (Postfix) with ESMTPSA id 6593CF984; Tue, 21 Jul 2015 17:11:42 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C8F29202F9; Tue, 21 Jul 2015 23:11:40 +0200 (CEST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , IETF OpenPGP In-Reply-To: <87a8uxlcvz.wl-neal@walfield.org> References: <87a8uxlcvz.wl-neal@walfield.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 21 Jul 2015 23:11:40 +0200 Message-ID: <87615dkygj.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Unuploadable 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, 21 Jul 2015 21:11:45 -0000 Hi Neal-- On Wed 2015-07-15 16:21:52 +0200, Neal H. Walfield wrote: > OpenPGP has support for local signatures. It would be nice to have > something similar for keys as well. The motivation for this feature > is: some people have keys that they don't want to have widely > distributed and training others to respect this is very difficult. > > Concretely, it should be possible to mark a key as not exportable to a > keyserver or to provide a list of key servers (perhaps described using > regular expressions as per Section 8 of RFC 4880) to which it may be > exported. > > This could be implemented as a new signature subpacket. > > When the key is exported (e.g., using gpg2 --export KEYID), a > warning should be issued that the key is not intended for public > distribution. I like this idea, though i'm not sure how useful it is as currently proposed. You could craft an OpenPGP certificate with all its self-sigs marked non-exportable, and that should have roughly the same effect for other users of GnuPG. You'd have to use --import-options import-local to import it at all, or else it would have no valid self-sigs, which GnuPG should reject as a poorly-formed certificate. However, this arrangement (or your signature subpacket proposal) has a set of problems that make it far from ideal protection, especially in the face of potentially adversarial users: 0) Any existing key (one with a self-sig that does *not* have this feature set) can't add this feature in a reliable way -- a new self-sig can just be stripped out of the certificate and the remaining certificate (with the previous self-sig) will be back to being "exportable". 1) The keyservers would need to respect the value and decline to accept or propagate such keys. SKS currently doesn't even respect the non-exportable flag for non-self-sigs (https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20), let alone verify the cryptographic validity of signatures. 2) GnuPG doesn't currently let you make non-exportable self-sigs, as far as i can tell (i just tested 2.1.6 with gpg2 --expert --lsign; maybe this is a bug in gpg, though) 3) anyone can just post the key publicly in a non-keyserver way (e.g. to the web) if they really want to do so. So the question is whether having this as an advisory mechanism (not a perfect bulwark against adversarial publication) is worthwhile. If it is worthwhole, would this interpretation of non-exportable self-sigs be a sufficient mechanism? This is certainly something worth considering clarifying in rfc4880, whether it's introduced as a separate subpacket, or a clearer recommendation of how to treat non-exportable subpackets in a self-sig. --dkg From nobody Tue Jul 21 14:15:54 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24A41B30A5 for ; Tue, 21 Jul 2015 14:15:52 -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 3iucs8HH04Ih for ; Tue, 21 Jul 2015 14:15:51 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 76A271B30A1 for ; Tue, 21 Jul 2015 14:15:51 -0700 (PDT) Received: from fifthhorseman.net (31.208.broadband18.iol.cz [109.81.208.31]) by che.mayfirst.org (Postfix) with ESMTPSA id 09A92F984; Tue, 21 Jul 2015 17:15:50 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id D3A8D202E8; Tue, 21 Jul 2015 23:15:48 +0200 (CEST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , IETF OpenPGP In-Reply-To: <87oaj5jvc9.wl-neal@walfield.org> References: <87pp3lk91r.wl-neal@walfield.org> <87pp3lhesi.fsf@vigenere.g10code.de> <87oaj5jvc9.wl-neal@walfield.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 21 Jul 2015 23:15:48 +0200 Message-ID: <87380hky9n.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 21:15:52 -0000 On Tue 2015-07-21 19:04:22 +0200, Neal H. Walfield wrote: > At Tue, 21 Jul 2015 14:32:29 +0200, > Werner Koch wrote: >> > Simon pointed out to me in another context that the user id (section >> > 5.11 of RFC 4880) is not always in RFC 2822 name-addr format, but is >> > sometimes simply a hostname. I think we should expand the >> > recommendation in that section to cover this usage. >> >> The name-addr convention has served us well for more than 20 years and I >> see no reason to explicitly recommend the use of just a hostname. I see >> no problem which will be solved by this. In case the hostname shall be >> used similar to a a user id (e.g. for DNS lookup), it is easier to use a >> pseudo mail address like hostmaster@foo.example.org. > > I'm not making a recommendation about what should be done, but > suggesting we update the RFC to reflect current practice. Can you point to existing examples of this usage (by fingerprint, maybe)? In the monkeysphere project we use the User ID for servicenames like ssh://example.com or https://example.com but not raw hostnames. I don't think i've seen many raw hostnames, though. --dkg From nobody Tue Jul 21 16:13:23 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693A1AC401 for ; Tue, 21 Jul 2015 16:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAGIayoD18kH for ; Tue, 21 Jul 2015 16:13:20 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id DFB251AC3FC for ; Tue, 21 Jul 2015 16:13:19 -0700 (PDT) Received: from fifthhorseman.net (31.208.broadband18.iol.cz [109.81.208.31]) by che.mayfirst.org (Postfix) with ESMTPSA id 9AC71F984; Tue, 21 Jul 2015 19:13:18 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EE8F8200E6; Wed, 22 Jul 2015 01:13:16 +0200 (CEST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , IETF OpenPGP In-Reply-To: <87twsyk35z.wl-neal@walfield.org> References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 22 Jul 2015 01:13:16 +0200 Message-ID: <87y4i9je9f.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 23:13:21 -0000 On Mon 2015-07-20 22:03:04 +0200, Neal H. Walfield wrote: > At Mon, 20 Jul 2015 17:14:18 +0200, Werner Koch wrote: >> On Mon, 20 Jul 2015 12:27, neal@walfield.org said: >> >> > I propose that the description field be augmented to include optional >> > email style headers. Further, we specify the following header to >> > specify the new key: >> > >> > Superceded-by: fingerprint >> >> I think it is better to have a signature subpacket or notation data to >> the same effect. This has the advantage that it can also be used with a >> non-revoked key or data signature to declare a plan to supercede a key >> in the near future. > > This is a good point. Either approach that you propose seems > reasonable to me. This is a great idea. Can you suggest a patch to the 4880bis draft that Werner started? --dkg From nobody Tue Jul 21 16:30:42 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988341A897F for ; Tue, 21 Jul 2015 16:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT0EBp569vsb for ; Tue, 21 Jul 2015 16:30:39 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 981091A87AB for ; Tue, 21 Jul 2015 16:30:39 -0700 (PDT) Received: from fifthhorseman.net (31.208.broadband18.iol.cz [109.81.208.31]) by che.mayfirst.org (Postfix) with ESMTPSA id 052E1F984; Tue, 21 Jul 2015 19:30:37 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6F9152033D; Wed, 22 Jul 2015 01:30:36 +0200 (CEST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , Phillip Hallam-Baker In-Reply-To: <871tg3kuyl.wl-neal@walfield.org> References: <87bnfdldo3.wl-neal@walfield.org> <874ml1krev.wl-neal@walfield.org> <871tg3kuyl.wl-neal@walfield.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 22 Jul 2015 01:30:36 +0200 Message-ID: <87twsxjdgj.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , Bill Frantz Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 23:30:41 -0000 On Mon 2015-07-20 12:02:42 +0200, Neal H. Walfield wrote: > There are two possibilities here. > > First, the mailing list software reencrypts the message. This means > that the plaintext is handled on the server and that either the > private key material is directly on the server or it is on a smartcard > permanently attached to the server. In the former case, the key > material can be stolen and in the later case, an attacker can send out > fake messages until the break-in is discovered. This implies absolute > trust in the provider. These issues limit the applicability of this > solution. I think the goal of an attacker in most scenarios isn't key recovery, but cleartext recovery. an attack on the remailer service doesn't need access to the key even if it's on a smartcard, they just want to compromise the server enough to read the messages after the server decrypts and before it encrypts. > The other possibility is that each poster encrypts to all recipients. > This works, but has horrible management issues. In particular, the > posters need to synchronize the list of subscribers and keys. This is > not easy. There is another management problem as well, which is less > obvious. The mailing list participants might want the list of > recipients to be hidden. In GnuPG, this is done using the > --hidden-recipient option. In this case, the public-key encrypted > session key packets don't contain the recipients' keyids. Making sure > all posters remember to use this option is hard. This is also not > scalable: the recipients will need to decrypt (on average) half of the > public-key encrypted session key packets before they find the packet > for them. This approach is clunky, and i agree that your approach is superior to it for key management. however, both of these approaches also leak the size of the subscriber list (as well as historical join and leave dates) in the public keyring. if they're re-using their normal encryption-capable subkeys (or if they have User IDs attached) then anyone who has access to the list's OpenPGP certificate is going to know who all of the subscribers are. There is a third approach, though, which is that used by PSELS: http://sels.ncsa.illinois.edu/about.html http://www.ncsa.illinois.edu/People/hkhurana/ICICS.pdf I haven't seen anyone re-tread this idea to use more modern crypto, but i think it might work. The idea is (roughly, from memory) that you're using some sort of discrete-log-based encryption key (e.g. el gamal, encryption-capable ECC), and the list has a public key. All correspondence to the list is encrypted to the list's public key. The (human, offline) mailing list manager knows a secret key for the list, and when a new subscriber joins, the manager issues the new subscriber a personalized secret key that has a specific randomized offset from the list's secret key, and tells the list server the subscriber's address, public key, and their offset from the list's key. The (automated) mailing list server doesn't know the list's secret material, but it knows the offset between all subscribers' public keys and the encryption key, and modifies the message so that the subscriber can decrypt it. unsubscribe happens by removing the address and the offset from the mailing list server. End users send encrypted mail exactly as they currently do, and the automated server never sees the cleartext. one chokepoint in this system is certainly the mailing list manager, who has access to the secret key material; but this is no different from your proposal, where whoever has access to the list's primary key has the same powers. In the PSELS approach, if any subscriber can collude with the list server, i think they can jointly reassemble the list's secret key, which is an additional risk, i think. though any subscriber on their own already has the content of all the messages, so i'm not sure how important the risk is. Of course, none of this avoids the problem of a large "private" list actually having the security of the weakest link in the group :/ --dkg From nobody Wed Jul 22 00:32:45 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F91E1B2D10 for ; Wed, 22 Jul 2015 00:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC-3GIAXbE9x for ; Wed, 22 Jul 2015 00:32:39 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A021B2BFD for ; Wed, 22 Jul 2015 00:32:39 -0700 (PDT) Received: by laah7 with SMTP id h7so1239897laa.0 for ; Wed, 22 Jul 2015 00:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TeFinu/tyW75aVnXWDrUd1MXF10Gm4h9pW/56dlkXfs=; b=gh27eZJmWZGZjV1Un8VMzHm5JXGvOU4LLZDgmXdISCtJJ6Iy1s+Y1NA/fVJm8+REv/ +gZX4Skp1sFcsAb8Y6og603wly0ghqCfzCSy9a4KV6szRJ6yVHZ/MIPIt3zhLPWds2On 5jTxboqKzWV8jUIdPpq2P4/OoArIPIsPT47ot3wBX/7cojGydId/QkyaKe7tEmZ7Vbbi HiALLHDgHIdYbwl4DhGRYNrekWPzeqqmX+d1Nat+MUWywmMFTwiOrYQ1tLzVha31NI31 XhPomw9UATGUWNHiZOQUzq3pk8HUkSWa46MPGRW8+CXDcDk0uq1BvPAgip7kOFnYhiYX BKtg== MIME-Version: 1.0 X-Received: by 10.112.126.42 with SMTP id mv10mr1043566lbb.58.1437550357728; Wed, 22 Jul 2015 00:32:37 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 22 Jul 2015 00:32:37 -0700 (PDT) In-Reply-To: <87twsxjdgj.fsf@alice.fifthhorseman.net> References: <87bnfdldo3.wl-neal@walfield.org> <874ml1krev.wl-neal@walfield.org> <871tg3kuyl.wl-neal@walfield.org> <87twsxjdgj.fsf@alice.fifthhorseman.net> Date: Wed, 22 Jul 2015 09:32:37 +0200 X-Google-Sender-Auth: HM5wfs8lSaA_4oSL84fc8NG3k4k Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a11c36bc66b5434051b71c62f Archived-At: Cc: IETF OpenPGP , "Neal H. Walfield" , Bill Frantz Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.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, 22 Jul 2015 07:32:42 -0000 --001a11c36bc66b5434051b71c62f Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 1:30 AM, Daniel Kahn Gillmor wrote: > On Mon 2015-07-20 12:02:42 +0200, Neal H. Walfield wrote: > > There are two possibilities here. > > > > First, the mailing list software reencrypts the message. This means > > that the plaintext is handled on the server and that either the > > private key material is directly on the server or it is on a smartcard > > permanently attached to the server. In the former case, the key > > material can be stolen and in the later case, an attacker can send out > > fake messages until the break-in is discovered. This implies absolute > > trust in the provider. These issues limit the applicability of this > > solution. > > I think the goal of an attacker in most scenarios isn't key recovery, > but cleartext recovery. an attack on the remailer service doesn't need > access to the key even if it's on a smartcard, they just want to > compromise the server enough to read the messages after the server > decrypts and before it encrypts. > > > The other possibility is that each poster encrypts to all recipients. > > This works, but has horrible management issues. In particular, the > > posters need to synchronize the list of subscribers and keys. This is > > not easy. There is another management problem as well, which is less > > obvious. The mailing list participants might want the list of > > recipients to be hidden. In GnuPG, this is done using the > > --hidden-recipient option. In this case, the public-key encrypted > > session key packets don't contain the recipients' keyids. Making sure > > all posters remember to use this option is hard. This is also not > > scalable: the recipients will need to decrypt (on average) half of the > > public-key encrypted session key packets before they find the packet > > for them. > > This approach is clunky, and i agree that your approach is superior to > it for key management. however, both of these approaches also leak the > size of the subscriber list (as well as historical join and leave dates) > in the public keyring. if they're re-using their normal > encryption-capable subkeys (or if they have User IDs attached) then > anyone who has access to the list's OpenPGP certificate is going to know > who all of the subscribers are. > > > > There is a third approach, though, which is that used by PSELS: > > http://sels.ncsa.illinois.edu/about.html > http://www.ncsa.illinois.edu/People/hkhurana/ICICS.pdf > > I haven't seen anyone re-tread this idea to use more modern crypto, but > i think it might work. > > The idea is (roughly, from memory) that you're using some sort of > discrete-log-based encryption key (e.g. el gamal, encryption-capable > ECC), and the list has a public key. All correspondence to the list is > encrypted to the list's public key. > > The (human, offline) mailing list manager knows a secret key for the > list, and when a new subscriber joins, the manager issues the new > subscriber a personalized secret key that has a specific randomized > offset from the list's secret key, and tells the list server the > subscriber's address, public key, and their offset from the list's key. > > The (automated) mailing list server doesn't know the list's secret > material, but it knows the offset between all subscribers' public keys > and the encryption key, and modifies the message so that the subscriber > can decrypt it. > > unsubscribe happens by removing the address and the offset from the > mailing list server. End users send encrypted mail exactly as they > currently do, and the automated server never sees the cleartext. > > one chokepoint in this system is certainly the mailing list manager, who > has access to the secret key material; but this is no different from > your proposal, where whoever has access to the list's primary key has > the same powers. > > In the PSELS approach, if any subscriber can collude with the list > server, i think they can jointly reassemble the list's secret key, which > is an additional risk, i think. though any subscriber on their own > already has the content of all the messages, so i'm not sure how > important the risk is. > I was playing with a similar approach, it translates fine into any DH system in any group (and you want to do DH in a group...). This is another consequence of the DH key multiplication capability I will be presenting an application of in CFRG later today. DH is actually a much more interesting cipher system than RSA as far as 'exotic' approaches go. If we have a Right private key R and a Left private key L, we can derive a Joint key J as follows: J = R+L e^J = e^R . e^L Further, if we perform the computations in a finite group it can be shown that knowledge of e^R and e^L does not provide any information about J unless knowledge of e^R discloses R (in which case DH is broken in that group anyway). The thing is that this is only a way to avoid the need to store the private key for the mailing list on the system. Everything else is completely unchanged. The end users can use their regular DH key. This is a very very useful property and one that the folk doing PERC should probably be looking at. It isn't one that has any impact on OpenPGP (or S/MIME) because it can be implemented regardless of the base spec. The only constraint being that the mailing list members use a DH based key. --001a11c36bc66b5434051b71c62f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 22, 2015 at 1:30 AM, Daniel Kahn Gillmor = <dkg@fifthhor= seman.net> wrote:
On Mon 2015-07-20 12:02:42 +0200, Neal H. Walfield wrote:
> There are two possibilities here.
>
> First, the mailing list software reencrypts the message.=C2=A0 This me= ans
> that the plaintext is handled on the server and that either the
> private key material is directly on the server or it is on a smartcard=
> permanently attached to the server.=C2=A0 In the former case, the key<= br> > material can be stolen and in the later case, an attacker can send out=
> fake messages until the break-in is discovered.=C2=A0 This implies abs= olute
> trust in the provider.=C2=A0 These issues limit the applicability of t= his
> solution.

I think the goal of an attacker in most scenarios isn't key reco= very,
but cleartext recovery.=C2=A0 an attack on the remailer service doesn't= need
access to the key even if it's on a smartcard, they just want to
compromise the server enough to read the messages after the server
decrypts and before it encrypts.

> The other possibility is that each poster encrypts to all recipients.<= br> > This works, but has horrible management issues.=C2=A0 In particular, t= he
> posters need to synchronize the list of subscribers and keys.=C2=A0 Th= is is
> not easy.=C2=A0 There is another management problem as well, which is = less
> obvious.=C2=A0 The mailing list participants might want the list of > recipients to be hidden.=C2=A0 In GnuPG, this is done using the
> --hidden-recipient option.=C2=A0 In this case, the public-key encrypte= d
> session key packets don't contain the recipients' keyids.=C2= =A0 Making sure
> all posters remember to use this option is hard.=C2=A0 This is also no= t
> scalable: the recipients will need to decrypt (on average) half of the=
> public-key encrypted session key packets before they find the packet > for them.

This approach is clunky, and i agree that your approach is superior = to
it for key management.=C2=A0 however, both of these approaches also leak th= e
size of the subscriber list (as well as historical join and leave dates) in the public keyring.=C2=A0 if they're re-using their normal
encryption-capable subkeys (or if they have User IDs attached) then
anyone who has access to the list's OpenPGP certificate is going to kno= w
who all of the subscribers are.



There is a third approach, though, which is that used by PSELS:

=C2=A0 =C2=A0 =C2=A0 =C2=A0http://sels.ncsa.illinois.edu/abo= ut.html
=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ncsa.ill= inois.edu/People/hkhurana/ICICS.pdf

I haven't seen anyone re-tread this idea to use more modern crypto, but=
i think it might work.

The idea is (roughly, from memory) that you're using some sort of
discrete-log-based encryption key (e.g. el gamal, encryption-capable
ECC), and the list has a public key.=C2=A0 All correspondence to the list i= s
encrypted to the list's public key.

The (human, offline) mailing list manager knows a secret key for the
list, and when a new subscriber joins, the manager issues the new
subscriber a personalized secret key that has a specific randomized
offset from the list's secret key, and tells the list server the
subscriber's address, public key, and their offset from the list's = key.

The (automated) mailing list server doesn't know the list's secret<= br> material, but it knows the offset between all subscribers' public keys<= br> and the encryption key, and modifies the message so that the subscriber
can decrypt it.

unsubscribe happens by removing the address and the offset from the
mailing list server.=C2=A0 End users send encrypted mail exactly as they currently do, and the automated server never sees the cleartext.

one chokepoint in this system is certainly the mailing list manager, who has access to the secret key material; but this is no different from
your proposal, where whoever has access to the list's primary key has the same powers.

In the PSELS approach, if any subscriber can collude with the list
server, i think they can jointly reassemble the list's secret key, whic= h
is an additional risk, i think.=C2=A0 though any subscriber on their own already has the content of all the messages, so i'm not sure how
important the risk is.

I was playing wi= th a similar approach, it translates fine into any DH system in any group (= and you want to do DH in a group...).

This is anot= her consequence of the DH key multiplication capability I will be presentin= g an application of in CFRG later today. DH is actually a much more interes= ting cipher system than RSA as far as 'exotic' approaches go.
=

If we have a Right private key R and a Left private key= L, we can derive a Joint key J as follows:

J =3D = R+L
e^J =3D e^R . e^L

Further, if we per= form the computations in a finite group it can be shown that knowledge of e= ^R and e^L does not provide any information about J unless knowledge of e^R= discloses R (in which case DH is broken in that group anyway).
<= br>

The thing is that this is only a way to avoid = the need to store the private key for the mailing list on the system. Every= thing else is completely unchanged. The end users can use their regular DH = key.

This is a very very useful property and one t= hat the folk doing PERC should probably be looking at.

=
It isn't one that has any impact on OpenPGP (or S/MIME) because it= can be implemented regardless of the base spec. The only constraint being = that the mailing list members use a DH based key.

=

--001a11c36bc66b5434051b71c62f-- From nobody Thu Jul 23 02:15:26 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3894D1A010D for ; Thu, 23 Jul 2015 02:15: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 Y3KUaHajnPxk for ; Thu, 23 Jul 2015 02:15:23 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB651A1B5D for ; Thu, 23 Jul 2015 02:15:23 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZICb3-0004UL-5p for ; Thu, 23 Jul 2015 11:15:21 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZICY8-0001KA-Dm; Thu, 23 Jul 2015 11:12:20 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Daniel Kahn Gillmor , "Neal H. Walfield" , IETF OpenPGP Date: Thu, 23 Jul 2015 11:12:20 +0200 In-Reply-To: <87615dkygj.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 21 Jul 2015 23:11:40 +0200") Message-ID: <87bnf3ck5n.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , "Neal H. Walfield" Subject: Re: [openpgp] Unuploadable Keys X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:15:25 -0000 On Tue, 21 Jul 2015 23:11, dkg@fifthhorseman.net said: > So the question is whether having this as an advisory mechanism (not a > perfect bulwark against adversarial publication) is worthwhile. If it I would really like to see such a standard flag. For whatever reasons some people do not like to have there keys on a keyserver and only make them available by other means. Such a flag would also help with testing to avoid accidental uploads of a key. This can be implemented with a new flag value for the key server preferences. The only defined 0x80 flag is not really useful because there is no definition on now a keyserver can check that an update request comes from the key holder. A new 0x40 = Do not send or refresh from a keyserver could be used for this. Of course it is still possible to export (e.g. "gpg --export") them and send them to a keyserver with other tools but it makes administyration (e.g. "gpg --refresh-keys") easier. An additional flag 0x20 = Do not use any public service to send or refresh this key could be used in the same way for DNS or other network based lookups. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Jul 23 19:25:59 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDAA1A039C for ; Thu, 23 Jul 2015 19:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48cgbJX99d8M for ; Thu, 23 Jul 2015 19:25:53 -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 46D381A8A7C for ; Thu, 23 Jul 2015 19:25:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 05992E2038; Thu, 23 Jul 2015 22:25:52 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16324-02; Thu, 23 Jul 2015 22:25:50 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-204.IHTFP.ORG [192.168.248.204]) (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 D90E4E2039; Thu, 23 Jul 2015 22:25:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1437704749; bh=4nv3DDP53z/HKZ/hZtr5v+fQSAHeNSOSYLwUljUT5/c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=KvTg9LH5jKD2OtWqY1IT6HzgjSyZc6bQEd6uX1W9NSDRn4i+9+BAlmI2Mwp67mOXV HVWP98X2net0o7kXTcpOWeg2Vq4T7FQChehA3ZczKC4r4oCygZH0u2q7TcoxhXiI/f YOkbQHUWgnN3ulLkr//OejcUvZ7azSLi0QMfVlA8= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t6O0FdDT032070; Thu, 23 Jul 2015 20:15:39 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87pp3lk91r.wl-neal@walfield.org> <87pp3lhesi.fsf@vigenere.g10code.de> <87oaj5jvc9.wl-neal@walfield.org> <87380hky9n.fsf@alice.fifthhorseman.net> Date: Thu, 23 Jul 2015 20:15:39 -0400 In-Reply-To: <87380hky9n.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 21 Jul 2015 23:15:48 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: IETF OpenPGP , "Neal H. Walfield" Subject: Re: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 02:25:57 -0000 Daniel Kahn Gillmor writes: > On Tue 2015-07-21 19:04:22 +0200, Neal H. Walfield wrote: >> At Tue, 21 Jul 2015 14:32:29 +0200, >> Werner Koch wrote: >>> > Simon pointed out to me in another context that the user id (section >>> > 5.11 of RFC 4880) is not always in RFC 2822 name-addr format, but is >>> > sometimes simply a hostname. I think we should expand the >>> > recommendation in that section to cover this usage. >>> >>> The name-addr convention has served us well for more than 20 years and I >>> see no reason to explicitly recommend the use of just a hostname. I see >>> no problem which will be solved by this. In case the hostname shall be >>> used similar to a a user id (e.g. for DNS lookup), it is easier to use a >>> pseudo mail address like hostmaster@foo.example.org. >> >> I'm not making a recommendation about what should be done, but >> suggesting we update the RFC to reflect current practice. > > Can you point to existing examples of this usage (by fingerprint, > maybe)? In my deployment of PGP signatures we're using only FQDNs in the UserID field in many cases (because they keys are tied to an entity and not a person). I'll note that RFC4880 does not specify the contents of the UserID field, only saying that by convention it's an email address but not actually REQUIRING it. I would oppose text that requires an email address in the ID field. > In the monkeysphere project we use the User ID for servicenames like > ssh://example.com or https://example.com but not raw hostnames. I don't > think i've seen many raw hostnames, though. We have a closed system, so we're not using the public keyservers.. > --dkg -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 24 03:10:13 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72ADD1A1B8A for ; Fri, 24 Jul 2015 03:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljq89cYK6VjE for ; Fri, 24 Jul 2015 03:10:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183711A1B60 for ; Fri, 24 Jul 2015 03:10:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C4D04BE58 for ; Fri, 24 Jul 2015 11:10:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mg3FtfhOA57 for ; Fri, 24 Jul 2015 11:10:08 +0100 (IST) Received: from [31.133.179.222] (dhcp-b3de.meeting.ietf.org [31.133.179.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 638D2BE59 for ; Fri, 24 Jul 2015 11:10:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437732606; bh=MSvggaJ1yEdtTTJgZFsQTT5sYqfolPkAI1j/N2j1Ce0=; h=Date:From:To:Subject:From; b=0xv8oTujrEocP9ZnAro/EiCdTmVQjYAddLWduGeQ1pJjPB+CXZEcYZDygoHkqDX9M iZbo/wYX1qYhTjAOnDURGn6FY971F6dPzNK+mcxojHP0iite6CdJhxIJO85+MOl+Yw tKH9uB4xP6tgtKJ9rt4BPi9xiaxk94ZfUlqnqIGo= Message-ID: <55B20EFD.9080800@cs.tcd.ie> Date: Fri, 24 Jul 2015 11:10:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "openpgp@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [openpgp] IESG conflict review check... X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:10:12 -0000 Hiya, This is a boring process thing, feel free to ignore. The IETF produces about 90% of all RFCs. The IRTF, IAB and the independent submissions editor (ISE [1]) can also produce non-IETF-stream RFCs. When the ISE figures a document is almost ready to publish as an independent submission stream RFC, they have to ask the IESG if their publishing would cause any conflict with IETF work. That process is documented in RFC 5742 [2]. Note that a "conflict" here means that the publication of this would get in the way of the WG. If you have any other comments on the document please send those to the ISE and author(s). The IESG has been asked to do a 5742 conflict review [3] of a document that describes an application of PGP so I thought I'd check here. So the question is if the WG think there is any conflict between this specification [4] and the work of this WG. IMO the answer is no (having quickly scanned the document). Please let me know if I'm wrong. Silence is a fine non-answer here if I'm not wrong. Thanks, S. [1] https://rfc-editor.org/indsubs.html [2] https://tools.ietf.org/html/rfc5742 [3] https://datatracker.ietf.org/doc/conflict-review-davin-eesst/ [4] https://datatracker.ietf.org/doc/draft-davin-eesst/ From nobody Fri Jul 24 03:40:39 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B108F1A8AD9 for ; Fri, 24 Jul 2015 03:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8FqxmCkdIQV for ; Fri, 24 Jul 2015 03:40:33 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6031A8A92 for ; Fri, 24 Jul 2015 03:40:32 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so12528871lbb.1 for ; Fri, 24 Jul 2015 03:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=k8dHDK+xjy+rIfWIaoqQ7v4/8pox+2THU4NSWBIRf4A=; b=oV4togsJ3yV39474FktFZN3nSwHYID0ZAHNIfGbNefAmVtk1S/JZ+z98LuetIcteMG go2rVZ/YMOzDPA//q9K2uYxFHBDrQqTNG5YCNZDC+ISj+hvwYHTyzNLUqDcwHUeHzXKZ fHs7AWuejK7FUEEeoGuZGyKK+lIe5qkih+QxJp5xxIAtqxC2NP11C9UqkUdezshpjOOG jH+tp/rg3HtgxcnMjmBtcbtKTOitUzPMf1+aiZSp+CW3LB1tnI20CvTxVy9fbEq7d/gQ eUQabbHZIgAaJg5v6PtEKIaYX7ySX5syS7lfrtLS2oDPFHRVxEwXX++0tunkumA+o/oB /1Dw== MIME-Version: 1.0 X-Received: by 10.152.178.229 with SMTP id db5mr13231687lac.55.1437734431236; Fri, 24 Jul 2015 03:40:31 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 24 Jul 2015 03:40:31 -0700 (PDT) Date: Fri, 24 Jul 2015 12:40:31 +0200 X-Google-Sender-Auth: X1skiZ4Qti9Aov0fXk1PwdVnETs Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: multipart/alternative; boundary=001a113415ea0e2762051b9ca203 Archived-At: Subject: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:40:34 -0000 --001a113415ea0e2762051b9ca203 Content-Type: text/plain; charset=UTF-8 To clarify the point I was attempting to make at the mic. 1) The draft is approaching IETF last call. People working on OpenPGP should review it now. 2) If people find it does not meet OpenPGP needs, they should say so and have no qualms about objecting. It is much more important that there be a spec people use than that the document progress quickly. If people want their drafts to progress quickly they should do that by getting buy in from the community they purport to be serving. 3) It is quite possible that it is better that there be no DANE for PGP RFC either at this stage or ever. DANE is trying to do three different things. It is trying to be a key discovery service, a security policy publication mechanism and a way of validating keys using the DNSSEC. This was a task that really demanded a high level of systems thinking if it is going to succeed. All such advice was rejected. People have been attempting to put email address related records into the DNS since the first drafts of the spec and none has taken off. It might well be that the best way to take advantage of the opportunities DNSSEC affords would be to make changes at the OpenPGP end rather than the DNS end. I remain convinced that the interface between a DNS based PKI and any other PKI should be approached as a cross-certification type activity and the hand over between DNSSEC and whatever other PKI is to be used should be a single 'certificate' (or key signing or whatever you want to call it). So the way that I would approach using DNSSEC to validate a key for ' alice@example.com' would be to introduce a record in the DNS with the semantics 'X is authorized to sign for *@example.com'. I would not attempt to fill the DNS with keys for Alice, Billybob, Carol, Doug, Ethelred and co. It is not working for TLS and I don't think it will work for OpenPGP or S/MIME. I do not find the idea of relying on the DNS for my keys remotely comforting and would not want to rely on such a record directly. The DNS has no persistence to it. Give me the MIT keyserver any day. What would interest me is if I could take a DNSSEC trust chain and intern it in a blockchain. At that point the whole process becomes transparent and I have a key I can place quite a bit of reliance on. The above might sound a bit handwavy because it is. But I can demonstrate the claims mathematically in terms of work factor. If the work factor for introducing a bogus key is $100 at time t and we intern the key (and chain) in a blockchain at time t, then the work factor becomes > $GDP(USA) after time t. --001a113415ea0e2762051b9ca203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To clarify the point I was attempting to make at the mic.<= div>
1) The draft is approaching IETF last call. People worki= ng on OpenPGP should review it now.

2) If people f= ind it does not meet OpenPGP needs, they should say so and have no qualms a= bout objecting. It is much more important that there be a spec people use t= han that the document progress quickly.=C2=A0

If p= eople want their drafts to progress quickly they should do that by getting = buy in from the community they purport to be serving.

<= div>3) It is quite possible that it is better that there be no DANE for PGP= RFC either at this stage or ever.

DANE is trying = to do three different things. It is trying to be a key discovery service, a= security policy publication mechanism and a way of validating keys using t= he DNSSEC. This was a task that really demanded a high level of systems thi= nking if it is going to succeed. All such advice was rejected.
People have been attempting to put email address related recor= ds into the DNS since the first drafts of the spec and none has taken off.<= /div>

It might well be that the best way to take advanta= ge of the opportunities DNSSEC affords would be to make changes at the Open= PGP end rather than the DNS end.

I remain convince= d that the interface between a DNS based PKI and any other PKI should be ap= proached as a cross-certification type activity and the hand over between D= NSSEC and whatever other PKI is to be used should be a single 'certific= ate' (or key signing or whatever you want to call it).

So the way that I would approach using DNSSEC to validate a key fo= r 'alice@example.com' woul= d be to introduce a record in the DNS with the semantics 'X is authoriz= ed to sign for *@example.com'. I wou= ld not attempt to fill the DNS with keys for Alice, Billybob, Carol, Doug, = Ethelred and co. It is not working for TLS and I don't think it will wo= rk for OpenPGP or S/MIME.

I do not find the idea o= f relying on the DNS for my keys remotely comforting and would not want to = rely on such a record directly. The DNS has no persistence to it. Give me t= he MIT keyserver any day.

What would interest me i= s if I could take a DNSSEC trust chain and intern it in a blockchain. At th= at point the whole process becomes transparent and I have a key I can place= quite a bit of reliance on.


The ab= ove might sound a bit handwavy because it is. But I can demonstrate the cla= ims mathematically in terms of work factor. If the work factor for introduc= ing a bogus key is $100 at time t and we intern the key (and chain) in a bl= ockchain at time t, then the work factor becomes > $GDP(USA) after time = t.
--001a113415ea0e2762051b9ca203-- From nobody Fri Jul 24 03:57:00 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D0A1A86FD for ; Fri, 24 Jul 2015 03:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJXKNrAgu8mW for ; Fri, 24 Jul 2015 03:56:56 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0461A1A15 for ; Fri, 24 Jul 2015 03:56:56 -0700 (PDT) Received: from fifthhorseman.net (dhcp-a2cb.meeting.ietf.org [31.133.162.203]) by che.mayfirst.org (Postfix) with ESMTPSA id 4F99CF984; Fri, 24 Jul 2015 06:56:54 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0733B2033D; Fri, 24 Jul 2015 12:56:53 +0200 (CEST) From: Daniel Kahn Gillmor To: Stephen Farrell , "openpgp\@ietf.org" In-Reply-To: <55B20EFD.9080800@cs.tcd.ie> References: <55B20EFD.9080800@cs.tcd.ie> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 24 Jul 2015 12:56:52 +0200 Message-ID: <87io99hlhn.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] IESG conflict review check... X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 10:56:58 -0000 On Fri 2015-07-24 12:10:05 +0200, Stephen Farrell wrote: > The IESG has been asked to do a 5742 conflict review [3] > of a document that describes an application of PGP so > I thought I'd check here. > > So the question is if the WG think there is any conflict > between this specification [4] and the work of this WG. > > IMO the answer is no (having quickly scanned the document). i also agree that the answer is "no" -- I do not think this spec conflicts with the work of the WG. It's basically saying "use OpenPGP to sign and/or encrypt the transcript before sending, with a specific mime structure". we're not aiming to get in the way of that. > [4] https://datatracker.ietf.org/doc/draft-davin-eesst/ the ascii art here is kind of "wow". --dkg From nobody Fri Jul 24 05:30:35 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320631A00A0 for ; Fri, 24 Jul 2015 05:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmwSXyKIfIda for ; Fri, 24 Jul 2015 05:30:31 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AD71A00DF for ; Fri, 24 Jul 2015 05:30:22 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZIc7I-0004eR-T4 for ; Fri, 24 Jul 2015 14:30:20 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZIc32-0005ea-Pl; Fri, 24 Jul 2015 14:25:56 +0200 From: Werner Koch To: Phillip Hallam-Baker References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Phillip Hallam-Baker , IETF OpenPGP Date: Fri, 24 Jul 2015 14:25:56 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Fri, 24 Jul 2015 12:40:31 +0200") Message-ID: <87si8dagiz.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 12:30:34 -0000 On Fri, 24 Jul 2015 12:40, phill@hallambaker.com said: > 2) If people find it does not meet OpenPGP needs, they should say so and > have no qualms about objecting. It is much more important that there be a > spec people use than that the document progress quickly. I was a bit disappointed by the process: I learned about the I-D too late and was surprised that it started out at the OpenPGP WG mailing list (2 years ago?) with just a few messages and then continued at the DANE list without having notified the OpenPGP list. IIRC, I send some thoughts on this to the GnuPG list but people told me that it is too late for changes to the I-D - so I gave up. Here are some thoughts, anyway: - Why a new DNS record despite that the CERT type has PGP support for 9 years now (RFC-4398). The argument for a new record is that this makes parsing easier because there is no need to loop over the record's sub-types. I do not consider it a valid argument because there is a need to loop anyway because there may be several DANE records for the same key. Adding an extra loop over the sub-types is a non-brainer and the selection logic to find the best matching record will be the same. The CERT record is more flexible because it also allows the use of an indirect specification via fingerprint. DANE however could use the straight PGP record and would be done. GnuPG has support for such CERT records including a script to create them also for about 9 years. It is not widely used because most users have no way to add records to their zone - that is the same problem for DANE of course. - The use of SHA-224 (really, see below) to map addresses to valid DNS characters is pure overkill. The shorter SHA-1 is sufficient for this. Counter argument is that SHA-1 shall be phased out. I have not looked up that IETF statement but I hope it states the "use of SHA-1 for cryptographic purposes". For example rsync(1) still uses MD5 which is sound for its purpose (SHA-1 would be better due to hardware support but that is another story). Actually it is using SHA-256 truncated to the size of SHA-224. Why not using SHA-224 (which has a different IV)? That is surprising for any implementer. - The I-D says about the local-part of the mail address: ... it is turned into lowercase and hashed using the SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets ... Lowercasing UTF-8 characters is not easy and a likely reasons for interoperability problems. It would be better to only require lowercasing ASCII characters and keep characters > 127 as they are. - There is no hint in the RFC on how to find a key to verify a signature. This can't be done via a mail address but requires the fingerprint (or as of today the key-id). - How shall a key be retrieved or updated after a mail account has been closed? It should be possible to verify signatures at all times. Thus another non DNS service to keep the key available needs to be setup too (e.g. a keyserver). That service is also required to allow dissemination of revocation certificates. IPGP records could be kept as long as the mail address has not been re-assigned. - Implementation nit: The I-D states: The lookup result MUST pass DNSSEC validation; if validation reaches any state other than "Secure", the verification MUST be treated as a failure. As an implementer I see no way to do this without adding a full fledged DNSSEC resolver. > People have been attempting to put email address related records into the > DNS since the first drafts of the spec and none has taken off. That is a general problem. You need the support from the mail providers. > I do not find the idea of relying on the DNS for my keys remotely > comforting and would not want to rely on such a record directly. The DNS > has no persistence to it. Give me the MIT keyserver any day. When intending to send a mail the first time the DNS is pretty useful because it creates an association between mail address and key. Thus you can pick the right key and the recipient won't be annoyed by encrypted mails they can't decrypt because the keyservers carry several "faked" keys for their mail address. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Jul 24 05:39:17 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C691A026A for ; Fri, 24 Jul 2015 05:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyeSOR7AMvhh for ; Fri, 24 Jul 2015 05:39:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25D51A0235 for ; Fri, 24 Jul 2015 05:39:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5EE3BE9A; Fri, 24 Jul 2015 13:39:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHEutJ01oFuj; Fri, 24 Jul 2015 13:39:09 +0100 (IST) Received: from [31.133.179.222] (dhcp-b3de.meeting.ietf.org [31.133.179.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D33CBBE49; Fri, 24 Jul 2015 13:39:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437741549; bh=Xjr3tGO3TB3WCt8Evve4nJsNIT7VuWVzJEszlO/ct4g=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OumI0Iw1g3JaHskoeFhAzQObYgnLtUeJV+QRUi/D2/gcWJgpEs31A9zhlkMGLgGeu o627ZalsEigfclTIzAk96h8i5yJj4QyoYm1NY+kUQqM/XBO1KXUIGkE5bNcCiRHanP MJz+R8XslxeQ/mDtozBTSdWIt25nBoAS27++pc18= Message-ID: <55B231EB.6000703@cs.tcd.ie> Date: Fri, 24 Jul 2015 13:39:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , IETF OpenPGP References: In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 12:39:15 -0000 On 24/07/15 11:40, Phillip Hallam-Baker wrote: > To clarify the point I was attempting to make at the mic. Sure. I'll do the same(ish:-) The draft in question is [1] and has been a work item for the DANE WG for a year or so. Please do read and comment on the draft - if there are PGP things in there that need fixing we should get those fixed. Such comments for now are best sent to dane@ietf.org. If you want to comment on the charter of the DANE WG please do so on ietf@ietf.org (or chat with me). Just as with this WG, the DANE charter was subject to IETF last call already. Cheers, S. [1] https://tools.ietf.org/html/draft-ietf-dane-openpgpkey > > 1) The draft is approaching IETF last call. People working on OpenPGP > should review it now. > > 2) If people find it does not meet OpenPGP needs, they should say so and > have no qualms about objecting. It is much more important that there be a > spec people use than that the document progress quickly. > > If people want their drafts to progress quickly they should do that by > getting buy in from the community they purport to be serving. > > 3) It is quite possible that it is better that there be no DANE for PGP RFC > either at this stage or ever. > > DANE is trying to do three different things. It is trying to be a key > discovery service, a security policy publication mechanism and a way of > validating keys using the DNSSEC. This was a task that really demanded a > high level of systems thinking if it is going to succeed. All such advice > was rejected. > > People have been attempting to put email address related records into the > DNS since the first drafts of the spec and none has taken off. > > It might well be that the best way to take advantage of the opportunities > DNSSEC affords would be to make changes at the OpenPGP end rather than the > DNS end. > > I remain convinced that the interface between a DNS based PKI and any other > PKI should be approached as a cross-certification type activity and the > hand over between DNSSEC and whatever other PKI is to be used should be a > single 'certificate' (or key signing or whatever you want to call it). > > So the way that I would approach using DNSSEC to validate a key for ' > alice@example.com' would be to introduce a record in the DNS with the > semantics 'X is authorized to sign for *@example.com'. I would not attempt > to fill the DNS with keys for Alice, Billybob, Carol, Doug, Ethelred and > co. It is not working for TLS and I don't think it will work for OpenPGP or > S/MIME. > > I do not find the idea of relying on the DNS for my keys remotely > comforting and would not want to rely on such a record directly. The DNS > has no persistence to it. Give me the MIT keyserver any day. > > What would interest me is if I could take a DNSSEC trust chain and intern > it in a blockchain. At that point the whole process becomes transparent and > I have a key I can place quite a bit of reliance on. > > > The above might sound a bit handwavy because it is. But I can demonstrate > the claims mathematically in terms of work factor. If the work factor for > introducing a bogus key is $100 at time t and we intern the key (and chain) > in a blockchain at time t, then the work factor becomes > $GDP(USA) after > time t. > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Fri Jul 24 07:16:59 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FD51A92B1 for ; Fri, 24 Jul 2015 07:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBOtj4BADMDZ for ; Fri, 24 Jul 2015 07:16:57 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121361A923D for ; Fri, 24 Jul 2015 07:16:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 991EAE2039; Fri, 24 Jul 2015 10:16:55 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20842-02; Fri, 24 Jul 2015 10:16:50 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 51266E2038; Fri, 24 Jul 2015 10:16:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1437747410; bh=ot7UKHgRj6LY6Q7qvPGQ5Fr1U5Pzx5f1tnK+7rtlQd8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=FQHQLY8adBz7hODN0J3/lfOPY1OdV74bcZEmHZD6WujNsp/q+DIndFOThaDDYOlqD 4EfL2+pR7LExIPmxbASVez71Z8fkBekU0vSYW9DZ6s4F8HG5i8ZZ45HGIHlDS6np20 JtSA8vMN4+cuSnpTuIlwX7KmR/E5WuukKv/jAIUs= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t6OEGnhU021256; Fri, 24 Jul 2015 10:16:49 -0400 From: Derek Atkins To: Stephen Farrell References: <55B20EFD.9080800@cs.tcd.ie> Date: Fri, 24 Jul 2015 10:16:49 -0400 In-Reply-To: <55B20EFD.9080800@cs.tcd.ie> (Stephen Farrell's message of "Fri, 24 Jul 2015 11:10:05 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "openpgp@ietf.org" Subject: Re: [openpgp] IESG conflict review check... X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 14:16:59 -0000 Hi, I was asked by the ISE to review this document (which I did) so I'm fairly familiar with the content. IMHO this document does not conflict with any current or potentially future work of this working group, however it could definitely *use* the output currently on the table and currently planned. -derek Stephen Farrell writes: > Hiya, > > > > This is a boring process thing, feel free to ignore. > > The IETF produces about 90% of all RFCs. The IRTF, IAB > and the independent submissions editor (ISE [1]) can > also produce non-IETF-stream RFCs. When the ISE figures > a document is almost ready to publish as an independent > submission stream RFC, they have to ask the IESG if their > publishing would cause any conflict with IETF work. That > process is documented in RFC 5742 [2]. > > Note that a "conflict" here means that the publication > of this would get in the way of the WG. If you have any > other comments on the document please send those to the > ISE and author(s). > > > > The IESG has been asked to do a 5742 conflict review [3] > of a document that describes an application of PGP so > I thought I'd check here. > > So the question is if the WG think there is any conflict > between this specification [4] and the work of this WG. > > IMO the answer is no (having quickly scanned the document). > > Please let me know if I'm wrong. Silence is a fine > non-answer here if I'm not wrong. > > Thanks, > S. > > [1] https://rfc-editor.org/indsubs.html > [2] https://tools.ietf.org/html/rfc5742 > [3] https://datatracker.ietf.org/doc/conflict-review-davin-eesst/ > [4] https://datatracker.ietf.org/doc/draft-davin-eesst/ > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 24 07:25:03 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBF01A896E for ; Fri, 24 Jul 2015 07:25:02 -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 YD76hCwsQYWk for ; Fri, 24 Jul 2015 07:25:01 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16101A92F4 for ; Fri, 24 Jul 2015 07:24:55 -0700 (PDT) Received: by wibud3 with SMTP id ud3so30274776wib.0 for ; Fri, 24 Jul 2015 07:24:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=KrSAuT8JvVS4CKUBEReLVw0gZ6MXHcR7p7kUY5b/wMQ=; b=k7W5hJXanfYHU7bAzzZPohUs9MaUNPOzY4sHhIIEcSZG/zNHOmR1POgDL7PgIgDP+W ClX+1Y9l7iJ3D7XzvHfrKklYdOUa4+CoIUglOg6n3+nCZxBRMM3SPqf3gT46JlkH89M9 VYdrK9LREBd8RF5BU1YiegMGs5gqA+zjiFpeZ/HgeDrR8BYooyeJdyoeU6QV6gtwbbKa Bmv/ueY0xUxNu4dhlwHJwsrAGwzGvR62aoOk+ZFOeKb+fuvyWH7CX0vaRtzpcdb1mFRD kGxAl3IvCDxrPuaPfysaSQZUd2kwKBAWV8RqPciIfs+fA+zVYuxH3sxz9PVWzbZmsqE6 9wPA== X-Gm-Message-State: ALoCoQkEX0RSxvpZgQVlTy6cxZ4mxLuXEoC/WF8gaoqA0cFz3C3BJQ8Y9DnMVFdEjTkQtbXYjGcN X-Received: by 10.194.58.7 with SMTP id m7mr26474364wjq.109.1437747894385; Fri, 24 Jul 2015 07:24:54 -0700 (PDT) Received: from [10.22.29.93] ([194.112.182.218]) by smtp.gmail.com with ESMTPSA id ib9sm12932231wjb.2.2015.07.24.07.24.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jul 2015 07:24:53 -0700 (PDT) Message-ID: <55B24AAB.7000601@azet.org> Date: Fri, 24 Jul 2015 16:24:43 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: IETF OpenPGP References: <55B231EB.6000703@cs.tcd.ie> In-Reply-To: <55B231EB.6000703@cs.tcd.ie> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE87FAD3F74FF879A697F0202" Archived-At: Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 14:25:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE87FAD3F74FF879A697F0202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey, Just wanted to point out that UTA has recieved a draft that's very interesting (and IMHO more valuable than anything that relies on DNSSEC) - it defines an extension to SMTP and SUBMISSION for querying e-mail address related information (e.g. PGP keys), and may be used to authenticate afterwards: https://tools.ietf.org/html/draft-moore-email-addrquery-01 I've read the document (though only skimmed a few sections) and it looks very promising if you ask me. I couldn't come up with any attack and it seems to be implementable rather painlessly. Aaron --------------enigE87FAD3F74FF879A697F0202 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVskqsAAoJEOTbZJL9ubXVc5AP/3QQb6f0f+a5D83AKJbcP7D/ Sx3VJxfUthi81lISULluL0YYenHIYuAudawBXzzBl1HUGFDs8Px98R0RZYMfMTCh F/GUgoUHCrGSUd6fwwPoAFLOxlbdiIvQVTqklWMQ3mqZs4AA8sM0oPfg/3en71lX HzuER0XvhOzcQO9UUd3aJGvC1a+12ZEEhgN3yBVrAN3MwgWs4Ucmh1vg+PjStajM YZvyEPIHk85FQCNfKIEIx5EUzRjYKDk8vjeKfxizb7FVO6KudcOpl6EGDsPOSBod 5NlypoPOZNHNkCCld+QCpfSfQ8ubjCC5cVpgehbGozAKpiu9wH3TN9J0t5QAbs1S BV+fM0wQDT49ob17Wl0vv6z3q/DyiJH18vepx/ewJ3bunJWdO5T68of9obclVO5Y DsTZYqQTJx4P6WkWT/SzqAtXf0Z8zaEMFHI3F/QlNMhkkNF0WeF1M6Ekpl5gGdj9 2GczsDkovoXkXDiaON+kR6vtO84TpWC07iyChFJdbyXdJ3livACCYlGky3WezhqP HDZjVmTMKJYm9IuRgweQQ4Un/aPfsK2Tl8ttjnYjai65jQPcxQ+awBp67KQybcru cwhaSRZoql8f50dU7TcR/ousoPeeFcTVoq1qxYm5kIFn+pqTho+GzU3EZ+HOANRr Dez5SwUaPVz3cvlTB6cq =OJLY -----END PGP SIGNATURE----- --------------enigE87FAD3F74FF879A697F0202-- From nobody Fri Jul 24 07:29:36 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0255F1A890D for ; Fri, 24 Jul 2015 07:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHhdT2UO064i for ; Fri, 24 Jul 2015 07:29:33 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D101A854B for ; Fri, 24 Jul 2015 07:29:33 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so30548504wib.1 for ; Fri, 24 Jul 2015 07:29: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 :subject:references:in-reply-to:content-type; bh=cMt2/RBB+DTFjY+rULsnvOyQ7iRC4IQabEikLRUtZjA=; b=Y0NrgGJG4BFMTEA1QJqRd84GF+5lIqkH9D++qILRiTqyNv1xcUXXLHO7H4rFN/EVqJ oLQCoz8UWdHZeI7ZwWy3Zt1FcO6eDQJueu6vzksXaa4mFJgfeKt73azXAKAIWOHqOk1e cd1f0iBFFUhmmZP7/9LVn2NeTRfouKcyAoDiNAG2TOoJv6R3FV2ngqW3Zp+RaQhIFU11 nycRuA6M4JASnnxMYk752SpYnfksNOoUvOOT7FneCruVrz6ftJsn17xjssAAeycG5sjG DDst2GnOh5rHYtCRG6l2pWuwG+oNv7Ha9tasZOWfLNQURZYcqItKS4DxvbQO9zYxRMzL JpBQ== X-Gm-Message-State: ALoCoQmWDzOoqvV8dyNgywm+R9GS1MxRhXcCafQSLCnVONi2ggutICUjnKTmTqgEfOWX21ImZelx X-Received: by 10.194.178.1 with SMTP id cu1mr27577705wjc.59.1437748171946; Fri, 24 Jul 2015 07:29:31 -0700 (PDT) Received: from [10.22.29.93] ([194.112.182.218]) by smtp.gmail.com with ESMTPSA id c7sm12925385wjb.19.2015.07.24.07.29.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jul 2015 07:29:31 -0700 (PDT) Message-ID: <55B24BB9.4000009@azet.org> Date: Fri, 24 Jul 2015 16:29:13 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: IETF OpenPGP References: <55B231EB.6000703@cs.tcd.ie> <55B24AAB.7000601@azet.org> In-Reply-To: <55B24AAB.7000601@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig07E6C055EEFBE35BCAF7EF58" Archived-At: Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 14:29:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig07E6C055EEFBE35BCAF7EF58 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aaron Zauner wrote: > [...] (Also just realized that his thread might not have been the best choice to bring that ID up, well. Sorry :)) Aaron --------------enig07E6C055EEFBE35BCAF7EF58 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVsku5AAoJEOTbZJL9ubXVTNIP/2jRbnkpnZNHiIcWvHViMwcH sZb5WSrr2sj5/9ktz5i0IjlDH6MJsHKbz9/FEkFYc2Fb2RP7GzXnTfktOT5b4Xsy uwTpi3LNmid2hlMaocGmCnnO/nA78ryP7pXQ+uSLbVHrWUKJtvC6ZD7McIQtMN9G RRT+VrMLv+qkhgN5gqE5DkFIBipdyTz3sEDvI+pWRqWo6S6TogzKZ19D0X6TC1tN qkAY599IwWLM+rXpznztlW4gzwEL9qX3ZCWRsx7f6pyN3opreAiur1VNfhe27d/1 MaBs6U3TxGsVh7gJ9PgTVcryE76kvlRKVZ57TqvQ/GeOPUgOrExWYIlt4MvZl1Uy sfQFNAPB1MWelsnNJURibb1y+F1wDVb5JiytVVB7AnUffRTcavITEUA5v5asUtLe KONTryz42S8lkxjhdtkr75t0v++zLAgUO8yTN0vMB2cAzAGu5dvWDREMawhZEzoY jTXQJYlueRTSNf+ZAN/pX5X7gfCFf2y0dI6IMTAv5U9mfurMUodxO/DOYJNJHNTN hMisYPxJt083zMCa/qbew+JchwBjFFrOwbftN29TLM7pAhtN7ArXA5Jzy+kz3Wl8 1NDFV8Qw4xuDHk9BvKP2sfBwYx+/aOC/W6vcoQDqx5XoodwSb9VHSvSG1P+8ocSx ZCiWNZTRfkTDFVYGm2h4 =rdZ8 -----END PGP SIGNATURE----- --------------enig07E6C055EEFBE35BCAF7EF58-- From nobody Fri Jul 24 10:43:28 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704C01A701D for ; Fri, 24 Jul 2015 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MwZbXe77FCJ for ; Fri, 24 Jul 2015 10:43:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517BB1A7004 for ; Fri, 24 Jul 2015 10:43:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32612BE7C; Fri, 24 Jul 2015 18:43:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwsZLPlmq_3l; Fri, 24 Jul 2015 18:43:21 +0100 (IST) Received: from [10.0.2.224] (unknown [62.168.35.68]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1562DBE88; Fri, 24 Jul 2015 18:43:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437759801; bh=74BV+W80GYQuwz7sD54GpNdYbLO4PYqDZE9crnVSJsg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ScbssaLw3nF01Xl8XBYLAKBVwYIzJTsKxEBKoXIqeq0cXdj6Y+pC0+exWxuH/SYpG xeZdLTZ+TFEqvvDn4t/P151NEynqRqqeYh5gwV54BkQktLiFZkySngFh3tFtOSVbqm ZM20E3Z9ebYQ+AS2Guw7RjRyVvK2xodAn+AKKYfY= Message-ID: <55B27938.8080307@cs.tcd.ie> Date: Fri, 24 Jul 2015 18:43:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Aaron Zauner , IETF OpenPGP References: <55B231EB.6000703@cs.tcd.ie> <55B24AAB.7000601@azet.org> In-Reply-To: <55B24AAB.7000601@azet.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IdvC6NCFb8Es2CpwvtrB4lTGC6cV4Wc6I" Archived-At: Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 17:43:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IdvC6NCFb8Es2CpwvtrB4lTGC6cV4Wc6I Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/07/15 15:24, Aaron Zauner wrote: > Hey, >=20 > Just wanted to point out that UTA has recieved a draft that's very > interesting (and IMHO more valuable than anything that relies on DNSSEC= ) > - it defines an extension to SMTP and SUBMISSION for querying e-mail > address related information (e.g. PGP keys), and may be used to > authenticate afterwards: >=20 > https://tools.ietf.org/html/draft-moore-email-addrquery-01 There's an ongoing discussion on saag@ietf.org about that and a webfinger based alternative. Please send comments to saag. Thanks, S. >=20 > I've read the document (though only skimmed a few sections) and it look= s > very promising if you ask me. I couldn't come up with any attack and it= > seems to be implementable rather painlessly. >=20 > Aaron >=20 >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --IdvC6NCFb8Es2CpwvtrB4lTGC6cV4Wc6I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVsnk4AAoJEC88hzaAX42i0bUH/iko/tjvRU+kd4Mz0KlJokEf /We+uq92Sf4NalwB+Uq0oWerbZqsdYfcACIzxLHlg3IfjJoHnmdjzFYbzUH75AIb O8Qp0eRNNRolbEkn2ufLg9ocReHIfFSCJVMM+xDsqnbPKKXWnFaMdqCZ469wZtUq nPsMOxs1WaMPaA6g5G9hrBiOQqUEoRpkrDElonPSHAl/NjRMvc8AEvHBhvPlUr6t w86KhJRuY4UCdelXWEfF5FjKepWlIseiiFnwiKL/HbVsszsDCvXzzK++NDkltL44 X6AullAtsefH98wRIpry1/sXh37JrrcSt3sztxV1dWP7ExzaPandzIdQHJmz0Ik= =cdsF -----END PGP SIGNATURE----- --IdvC6NCFb8Es2CpwvtrB4lTGC6cV4Wc6I-- From nobody Fri Jul 24 15:23:12 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD4F1A8AA0 for ; Fri, 24 Jul 2015 15:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.243 X-Spam-Level: X-Spam-Status: No, score=0.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, J_CHICKENPOX_34=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 wL3LenXUn9m9 for ; Fri, 24 Jul 2015 15:23:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8DB1A92F8 for ; Fri, 24 Jul 2015 15:19:47 -0700 (PDT) Received: from fifthhorseman.net (unknown [89.206.243.216]) by che.mayfirst.org (Postfix) with ESMTPSA id 3FADDF985; Fri, 24 Jul 2015 18:19:46 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0B8102027B; Fri, 24 Jul 2015 16:53:48 +0200 (CEST) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker , IETF OpenPGP In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 24 Jul 2015 16:53:48 +0200 Message-ID: <87bnf1hair.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] The DANE draft X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 22:23:04 -0000 On Fri 2015-07-24 12:40:31 +0200, Phillip Hallam-Baker wrote: > 1) The draft is approaching IETF last call. People working on OpenPGP > should review it now. I looked at it with Petr Spacek after the meeting, and i plan on providing Paul with a more detailed review shortly. > DANE is trying to do three different things. It is trying to be a key > discovery service, a security policy publication mechanism and a way > of validating keys using the DNSSEC. I think this overview is accurate. I also think all these things are necessary. While i'm not particularly excited at the prospect of a hierarchically controlled system like DNS being the One True System, we do need to find ways to address these three goals anyway. > So the way that I would approach using DNSSEC to validate a key for ' > alice@example.com' would be to introduce a record in the DNS with the > semantics 'X is authorized to sign for *@example.com'. I think you mean "X is authorized to certify any key+User ID where the user ID matches *.example.com", not that X is allowed to make sign mail for *@example.com. right? I like this idea as a way of validating keys for the DNSSEC (the third of your three prongs of DANE). If you were to make a record with the semantics "any OpenPGP key+User ID where the User ID matches *@example.com should not be considered valid *unless* it is certified by this key", then you could use it as a security policy mechanism (prong two). > I would not attempt to fill the DNS with keys for Alice, Billybob, > Carol, Doug, Ethelred and co. It is not working for TLS and I don't > think it will work for OpenPGP or S/MIME. So it sounds like the part you disagree with is the use of DNS/DANE as a key discovery service (prong one). > I do not find the idea of relying on the DNS for my keys remotely > comforting and would not want to rely on such a record directly. The DNS > has no persistence to it. Give me the MIT keyserver any day. > > What would interest me is if I could take a DNSSEC trust chain and intern > it in a blockchain. At that point the whole process becomes transparent and > I have a key I can place quite a bit of reliance on. It sounds to me like you're interested in DNSSEC Transparency. Perhaps you could take that up in the trans WG? I know there are other people interested there (i am!) but this discussion doesn't belong on the OpenPGP mailing list. --dkg From nobody Fri Jul 24 16:23:52 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD91ACE9F for ; Fri, 24 Jul 2015 16:23:50 -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 UO38PSM84FmK for ; Fri, 24 Jul 2015 16:23:49 -0700 (PDT) Received: from smtp1.emailarray.com (smtp1.emailarray.com [65.39.216.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C751ACE94 for ; Fri, 24 Jul 2015 16:23:48 -0700 (PDT) Received: (qmail 54123 invoked by uid 89); 24 Jul 2015 23:23:47 -0000 Received: from unknown (HELO ?204.29.149.87?) (Y2RsQGFzZ2FhcmQub3JnQDUwLjc2LjM0LjE4NQ==) (POLARISLOCAL) by smtp1.emailarray.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Jul 2015 23:23:47 -0000 From: "Christopher LILJENSTOLPE" To: "Daniel Kahn Gillmor" Date: Fri, 24 Jul 2015 16:23:44 -0700 Message-ID: <50B1BAAD-8197-4506-98E6-1EBB59A42833@asgaard.org> In-Reply-To: <87io99hlhn.fsf@alice.fifthhorseman.net> References: <55B20EFD.9080800@cs.tcd.ie> <87io99hlhn.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_0998DC31-C53E-49D6-B81F-04FD954A2294_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Clacks-Overhead: GNU Terry Pratchett X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: openpgp@ietf.org, Stephen Farrell Subject: Re: [openpgp] IESG conflict review check... X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 23:23:50 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_0998DC31-C53E-49D6-B81F-04FD954A2294_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, I agree with you, on both points... Christopher On 24 Jul 2015, at 3:56, Daniel Kahn Gillmor wrote: > On Fri 2015-07-24 12:10:05 +0200, Stephen Farrell wrote: > >> The IESG has been asked to do a 5742 conflict review [3] >> of a document that describes an application of PGP so >> I thought I'd check here. >> >> So the question is if the WG think there is any conflict >> between this specification [4] and the work of this WG. >> >> IMO the answer is no (having quickly scanned the document). > > i also agree that the answer is "no" -- I do not think this spec > conflicts with the work of the WG. It's basically saying "use OpenPGP > to sign and/or encrypt the transcript before sending, with a specific > mime structure". we're not aiming to get in the way of that. > >> [4] https://datatracker.ietf.org/doc/draft-davin-eesst/ > > the ascii art here is kind of "wow". > > --dkg > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- = =E6=9D=8E=E6=9F=AF=E7=9D=BF Avt tace, avt loqvere meliora silentio Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf keybase: https://keybase.io/liljenstolpe --=_MailMate_0998DC31-C53E-49D6-B81F-04FD954A2294_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVsskBAAoJEGmx2Mt/+Iw/Yf4H/Anteb5b/kIr+gW6tMCZ2OL8 v0MdC0za5h1HElnJhv4HrB55j8ZPKXnOG0x1BQQQOPLQWn54qhVXdEWYOMfr7DPi cTWnTvJ1TloaR4wUe/vClpVjDGyTAZE7NILQnxSum+62dGfptAYauIyMDjCBoo8J sF4k3d90ohdOz6+cg3cKvo4dIsuwSy8NFBwoTlNVcojCWhb5Z3jRKPQpW0PConHn pzPpFEbd0pqr0O4hb+gdDtL4SZGfCGPuz+Dn+3dIrX4Cumrvyt9WyEB80COThUTH hm+BM67IJDQ5N5EWwepQebnf9kl6ECRd/rGDx3nVZ/7PtEHJtvwVWIUzqoiMwXk= =QeM+ -----END PGP SIGNATURE----- --=_MailMate_0998DC31-C53E-49D6-B81F-04FD954A2294_=-- From nobody Sat Jul 25 04:11:15 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680851A219B for ; Sat, 25 Jul 2015 04:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4XxXyUCAP5N for ; Sat, 25 Jul 2015 04:11:12 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 756B71A014E for ; Sat, 25 Jul 2015 04:11:12 -0700 (PDT) Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZIxM8-0007sL-07; Sat, 25 Jul 2015 11:11:04 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZIxM5-0000MB-42; Sat, 25 Jul 2015 13:11:04 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZIxM4-00081p-2n; Sat, 25 Jul 2015 13:11:00 +0200 Date: Sat, 25 Jul 2015 13:10:58 +0200 Message-ID: <87k2too5kt.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor In-Reply-To: <87twsxjdgj.fsf@alice.fifthhorseman.net> References: <87bnfdldo3.wl-neal@walfield.org> <874ml1krev.wl-neal@walfield.org> <871tg3kuyl.wl-neal@walfield.org> <87twsxjdgj.fsf@alice.fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: Phillip Hallam-Baker , Bill Frantz , IETF OpenPGP Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 11:11:14 -0000 Hi Daniel, Thanks for your comments! At Wed, 22 Jul 2015 01:30:36 +0200, Daniel Kahn Gillmor wrote: > > On Mon 2015-07-20 12:02:42 +0200, Neal H. Walfield wrote: > > There are two possibilities here. > > > > First, the mailing list software reencrypts the message. This means > > that the plaintext is handled on the server and that either the > > private key material is directly on the server or it is on a smartcard > > permanently attached to the server. In the former case, the key > > material can be stolen and in the later case, an attacker can send out > > fake messages until the break-in is discovered. This implies absolute > > trust in the provider. These issues limit the applicability of this > > solution. > > I think the goal of an attacker in most scenarios isn't key recovery, > but cleartext recovery. an attack on the remailer service doesn't need > access to the key even if it's on a smartcard, they just want to > compromise the server enough to read the messages after the server > decrypts and before it encrypts. I wonder if key recovery is as unimportant as you suggest. If I were an attacker, I wanted to spy on a mailing list, and I got local access to the box doing the reencryption, I'd rather get the private key and get out than maintain a presence on the box. This would seem to reduce the chance that I was discovered. But, perhaps I'm misunderstanding something. > This approach is clunky, and i agree that your approach is superior to > it for key management. however, both of these approaches also leak the > size of the subscriber list (as well as historical join and leave dates) > in the public keyring. Good point. This can be mitigated by adding cover traffic. Concretely: we update the subscriber list with a fixed frequency (e.g., everyday at midnight) and we add / remove a number of subscribers drawn from an exponential distribution (or vice versa). If there aren't enough real new subscribers, then we add some dummy subscribers. Of course, an adversary can more or less figure out the subscriber list by watching the SMTP traffic. My understanding is that although it is possible to encrypt SMTP traffic, no one actually verifies the keys, which makes the whole thing susceptible to MITM attacks. Of course, a MITM attack requires significantly more resources than simply analyzing data that is explicitly stored in a public database. > if they're re-using their normal > encryption-capable subkeys (or if they have User IDs attached) then > anyone who has access to the list's OpenPGP certificate is going to know > who all of the subscribers are. I think what you are saying is that all posters know who all of the subscribers are (rather than just the list admin). I'm not sure this is really a problem in practice. It's normal that subscribers know more or less who the posters are. > I haven't seen anyone re-tread this idea to use more modern crypto, but > i think it might work. > > The idea is (roughly, from memory) that you're using some sort of > discrete-log-based encryption key (e.g. el gamal, encryption-capable > ECC), and the list has a public key. All correspondence to the list is > encrypted to the list's public key. Thanks for pointing this out. I wasn't aware of this work. > Of course, none of this avoids the problem of a large "private" list > actually having the security of the weakest link in the group :/ True. But that is a people problem and there is nothing we can do about that at the OpenPGP level. I spent some time reviewing the PLES paper that you linked to and I see major security and usability problems with it. The first problem is a security problem. - Since the user has a new private key for each mailing list, it is not practical to store all the keys on a smart card. Thus, the keys will probably be stored on the user's hard drive. This significantly lowers the practical upper bound of the security of the system. The rest of the problems are usability problems. - When the user subscribes to a mailing list, the list manager sends the subscriber the private key. The subscriber needs to import this. I don't think current MUAs make this easy. - If the user wants to use the key from multiple machines, she needs to import it on all of them. It is currently not easy to securly move one private key from one machine to another. Moving many keys would be a serious pain. - It encourages a bad mind set: we tell users that private keys should never be exported and yet here is a counter example. You identified two weaknesses with my proposed approach: - It exposes the subscriber list to subscribers (including historical join / leave times). - It exposes the size of the subscriber list to the world. I think these weaknesses are genuine, but not severe. Regarding the first issue, in practice, subscribers know who the other subscribers are (or, at least the posters). With respect to the second issue, this can be mitigated using cover traffic (although this would place a large burden on the keyservers). Nevertheless, there is no way to stop a well funded adversary who can monitor SMTP traffic, which is a problem for both systems. Do you still think we should drop my proposal? Thanks, Neal From nobody Sat Jul 25 05:19:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9871A3BA6; Sat, 25 Jul 2015 05:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t78toht4CJAU; Sat, 25 Jul 2015 05:19:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D941A2182; Sat, 25 Jul 2015 05:19:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mdmfS18XrzD7N; Sat, 25 Jul 2015 14:19:12 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=semLHouR X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WTcDtQiz-7Cz; Sat, 25 Jul 2015 14:19:09 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 25 Jul 2015 14:19:09 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 23EEC80042; Sat, 25 Jul 2015 08:19:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437826748; bh=bduqX1qCre1auQuoWi77XeMBOglrR8/P4evNY6WyE/s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=semLHouRIKQWQ8jrK3vXty8wzE9vOvJScvoAQFm/DpYjGFbpfdI1OiluY/9QXOx13 aBXYr6DQC1cfXMkXiOPiR66qPX19aDgwkHLCH3UbSjioD3+I0QewdAVupb0j/uZMoZ 1p4BTizK9WEh3qfng9yQCaIRarP9LExPAL1J6DvY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6PCJ4L9010246; Sat, 25 Jul 2015 08:19:04 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 25 Jul 2015 08:19:04 -0400 (EDT) From: Paul Wouters To: Werner Koch In-Reply-To: <87si8dagiz.fsf@vigenere.g10code.de> Message-ID: References: <87si8dagiz.fsf@vigenere.g10code.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Phillip Hallam-Baker , dane WG list , Olafur Gudmundsson , IETF OpenPGP Subject: Re: [openpgp] The DANE 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: Sat, 25 Jul 2015 12:19:18 -0000 On Fri, 24 Jul 2015, Werner Koch wrote: PHB wrote: >> 2) If people find it does not meet OpenPGP needs, they should say so and >> have no qualms about objecting. It is much more important that there be a >> spec people use than that the document progress quickly. This document has not progressed "quickly". The original draft was published in July 2013. No one is trying to rush this through. > I was a bit disappointed by the process: I learned about the I-D too late > and was surprised that it started out at the OpenPGP WG mailing list (2 > years ago?) with just a few messages and then continued at the DANE list > without having notified the OpenPGP list. This is now the fourth time I am having this discussion with you, so I think your representation is not entirely fair. The previous discussions ended with you saying we should not do this and stick to the CERT record type and me stating why I disagree with that view. > IIRC, I send some thoughts on > this to the GnuPG list but people told me that it is too late for > changes to the I-D - so I gave up. That is not a fair representation of what happened. I have told you on the openpgpkey, on the dane list and in private emails why we do not want to use the CERT record. It is fine to disagree with that, but the reason for not going back to CERT have nothing to do with timing. It is never too late to say a certain draft has no merit and should be shot or majorly changed. I am sorry if our previous communication did not make that clear. > Here are some thoughts, anyway: > > - Why a new DNS record despite that the CERT type has PGP support for > 9 years now (RFC-4398). > > The argument for a new record is that this makes parsing easier > because there is no need to loop over the record's sub-types. I do > not consider it a valid argument because there is a need to loop > anyway because there may be several DANE records for the same key. > Adding an extra loop over the sub-types is a non-brainer and the > selection logic to find the best matching record will be the same. Using subtypes for DNS is something the DNS people in general have concluded to be a wrong idea. As stated before, even Olafur who is one of the authors of the CERT RRtype advised us not to use CERT (or subtyping in general) Additionally, because the CERT record is a meta-container record, support for CERT is not good because to properly parse it you need all of openpgp and all of x509 and all of what other subtypes would be added later on. So instead of implementing CERT records partially, many DNS implementations just did not bother with it at all. > The CERT record is more flexible because it also allows the use of an > indirect specification via fingerprint. Which is a problem not a feature. It makes the security model very complex. Specifying a fingerprint and a URI that could be http or https reduces the security of the key to the strength of the fingerprint. Did we not already ran into issues in older (v3?) keys on this issue? Adding a level of indirection where not required does reduce the security. If using https, it adds back a whole trust mechanism of CA's, or it confusingly will ignore the CAs involved in the transaction. If the http(s) service is blocked by an attacker, it is indistinguishable from a regular outage. Putting the keys into DNS without indirection avoids all these problems. I know the CERT could also store the entire certificate, but this difference then has to be explained to the user, and that is way too complicated. Compare: "The user you are trying to mail has published their OpenPGP key in DNS, do you wish to use this key to encrypt this email?" versus: "The user you are trying to mail has published their OpenPGP key fingerprint in DNS and the key was obtained over HTTP(S) on anothersite.com whose certificate was validated by ACME inc. Do you wish to use this key to encrypt this email?" And the additional: "The user you are trying to mail has published their OpenPGP key fingerprint in DNS but the URI resource anothersite.com appears to be down. do you wish to postpone this email or send it unencrypted?" > GnuPG has support for such CERT records including a script to create > them also for about 9 years. It is not widely used because most users > have no way to add records to their zone - that is the same problem > for DANE of course. CERT wasn't widely used because frankly pgp is not widely used. Also, CERT without DNSSEC makes no sense, and we are only seeing DNSSEC protected application data being deployed recently in the last few years only. We now see small email providers adding webgui elements for their users to upload their pgp key to publish in DNS. So I do believe we are seeing an uptake in "pgp keys from dns". Of course this has no relation to the CERT vs OPENPGPKEY format question. > - The I-D says about the local-part of the mail address: The I-D was left unchanged at the request of the chairs. The intention right now is to use a base32 encoding split on 60 character labels. > ... it is turned into lowercase and hashed using the SHA2-256 > [RFC5754] algorithm, with the hash truncated to 28 octets ... > > Lowercasing UTF-8 characters is not easy and a likely reasons for > interoperability problems. It would be better to only require > lowercasing ASCII characters and keep characters > 127 as they are. Yes, that was discussed on the dane list and after consultation with internationalised email address experts, this same conclusion was reached. I am not sure if we actually reached consensus about the lowercase vs using a second DNS lookup for lowercase if the first query fails to find a record. The argument here is that a client should not "guess" that Paul@nohats.ca is the same as paul@nohats.ca, but there does seem to be concensus that in practise these are the same and it should be supported either through a lowercase before base32 (for ASCII only) or be allowing the client to try both as base32 lookups. One of the main reasons here is that virtual keyboards and web form fields often automatically capitalise recognised names, and otherwise we would need to add two records (Paul and paul) for each LHS side. > - There is no hint in the RFC on how to find a key to verify a > signature. This can't be done via a mail address but requires the > fingerprint (or as of today the key-id). The draft is about finding keys based on email address. It is not meant to be the global keyserver bag for all keyids or fingerprints. If you only have a keyid and nothing else, the DNS hierarchy cannot help you. But perhaps the openpgp group can extend the signature format allowing the inclusion of an ID so this could be possible in the future? > - How shall a key be retrieved or updated after a mail account has been > closed? It should be possible to verify signatures at all times. Why should that be possible? In fact, the key could be compromised so it might lead to the wrong actions if you verified the signature. The OPENPGPKEY draft specifies one method of finding a key. What you do with it, or what the lifetime of such a key or its signatures are is completely out of scope of this key discovery mechanism. If we want to specify those kind of usage scenarions, we can revive the openpgpkey-usage draft document. But I fear everyone has their own local policies on these. > Thus another non DNS service to keep the key available needs to be > setup too (e.g. a keyserver). I disagree. If the email was sent while the mail account was still operational with OPENPGPKEY, you should have fetched and stored the key then. If the account is closed and you don't have a copy of the key, than that is your problem. If you want to have some kind of global key store for all keys ever issued, then I guess you could look at something like "transparency" for openpgp keys. But that is a out of scope for this document, just as me sending you a key without any advertising on any public key server resource and then closing my mail account is. > dissemination of revocation certificates. IPGP records could be kept > as long as the mail address has not been re-assigned. Again, that seems like a "transparency" issue. The issue of losing control of your email address, and someone else generating a new key for that email address and advertising thism, whether in DNSSEC or on keyservers, in an attempt to get encrypted email intended for you, is really not in scope here either. It might be in scope for the openpgpkey-usage document, but it seems to me to be a more generic openpgp issue, so perhaps would be better in the openpgp bis document or elsewhere. (and of course this would be no different with CERT records in DNS) > - Implementation nit: The I-D states: > > The lookup result MUST pass DNSSEC validation; if validation > reaches any state other than "Secure", the verification MUST be > treated as a failure. > > As an implementer I see no way to do this without adding a full > fledged DNSSEC resolver. There are various libraries to do this. You can look at getdns, libunbound or various other libraries. We hope you would not write your own dnssec validation code. If you do not want to link against new unknown libraries you could outsource it to a separate tool, and possibly warn the user of that. I'm happy to help you with that. >> People have been attempting to put email address related records into the >> DNS since the first drafts of the spec and none has taken off. > > That is a general problem. You need the support from the mail > providers. Of course this is a big catch22. While I have been approached by a few email providers who have or are implementing this to allow their users to publish their openpgp keys this way, the 5 big email providers business model relies on advertisement targetted specifically by reading your email. So I do not expect those email providers to have much incentives to become free binary blob relaying services. >> I do not find the idea of relying on the DNS for my keys remotely >> comforting and would not want to rely on such a record directly. The DNS >> has no persistence to it. Give me the MIT keyserver any day. > > When intending to send a mail the first time the DNS is pretty useful > because it creates an association between mail address and key. Thus > you can pick the right key and the recipient won't be annoyed by > encrypted mails they can't decrypt because the keyservers carry several > "faked" keys for their mail address. Indeed. And no one is saying you should ONLY trust the DNS. In fact, no one is saying that. The prime motivation for this document is to allow MTAs and MUAs to encrypt emails that would otherwise be send out in the clear by the user. In no way is it intended to replace the web of trust or manual key verification, and I hope implementations will ensure this point to their users. Now, one thing I _would_ like to see from the openpgp working group, is comments on content of the public key ring format that we should or should not put into the OPENPGPKEY record. The draft basically refers to the openpgp RFC, but people have wondered about some things: - What to do when there is more than one pubkey? - Should it be mandatory for the email address to appear as an ID on the key? (if yes, how to support domain wild cards) - Should any third party signatures be allowed/encourages/discouraged? - Should revoked keys be allowed? One issue during deployment for all fedora developer keys was that people do have keys that are larger than 64k and those will not fit into the DNS. There is no easy way for tools to try and reduce the signatures because it does not know which signatures carry more weight for the user. Paul From nobody Sat Jul 25 05:30:31 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8BD1A7035 for ; Sat, 25 Jul 2015 05:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8sb2YXaiB_Y for ; Sat, 25 Jul 2015 05:30:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7828C1A037F for ; Sat, 25 Jul 2015 05:30:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mdmvM0BFKz21f; Sat, 25 Jul 2015 14:30:23 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=jlLRXwYX X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DEF5PXbM4W_b; Sat, 25 Jul 2015 14:30:21 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 25 Jul 2015 14:30:21 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B03B880042; Sat, 25 Jul 2015 08:30:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437827420; bh=nHJcBimJO5AGH+S0lkkU5Eo9TMV+a063jZfK+KzK6rI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jlLRXwYXiWNwPb4zb58G9+4KZDlvsDpvqsRKXwI19gXCbDmoNjyVOiuO78BJPzBZ1 +rAf/fsBJAJXpknveuIeR2Rd6hJVu+OX8iKxNtbgguOeZy6GTwM60rpaurKAA6aPaD qYhLUGqkI9DG0xcOh3rDvndXLVu6CVkMULfzQau0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6PCUKnE011683; Sat, 25 Jul 2015 08:30:20 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 25 Jul 2015 08:30:20 -0400 (EDT) From: Paul Wouters To: Aaron Zauner In-Reply-To: <55B24AAB.7000601@azet.org> Message-ID: References: <55B231EB.6000703@cs.tcd.ie> <55B24AAB.7000601@azet.org> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] The DANE 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: Sat, 25 Jul 2015 12:30:30 -0000 On Fri, 24 Jul 2015, Aaron Zauner wrote: > Just wanted to point out that UTA has recieved a draft that's very > interesting (and IMHO more valuable than anything that relies on DNSSEC) > - it defines an extension to SMTP and SUBMISSION for querying e-mail > address related information (e.g. PGP keys), and may be used to > authenticate afterwards: > > https://tools.ietf.org/html/draft-moore-email-addrquery-01 This has come up on the dane list too and was discussed at IETF 92 in Dallas. As the introduction to this draft stateS: This document defines several mechanisms which can be used by a client such as a Mail User Agent or Mail Submission Agent, to query an SMTP server which is configured to accept incoming mail for a mail domain, to The problem is that anti-spam policies generally block SMTP ports so an enduser often has no way of reaching a target user's SMTP server for querying the target user data/key. The draft does allow using one's SMTP server's submission port, so if I'm on coffeeshop wifi, presumbly this could still work, but it requires the sender to be an actual user with verifiable credentials. It also allows the ISP to lie about these extensions and to (be forced) to disable these and causing unencrypted emails. Think of the lavabit issue. Paul From nobody Sat Jul 25 05:56:25 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C71A9147 for ; Sat, 25 Jul 2015 05:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ImPBxrxbNnN for ; Sat, 25 Jul 2015 05:56:22 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CA61B2DF6 for ; Sat, 25 Jul 2015 05:56:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mdnT93PdnzD7S; Sat, 25 Jul 2015 14:56:13 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=P1uZcWOp X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bu3yM6g_Of6g; Sat, 25 Jul 2015 14:56:11 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 25 Jul 2015 14:56:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2D17180042; Sat, 25 Jul 2015 08:56:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437828970; bh=vmHGKQJ6x+IyTwZEzeFUGhHi9QADjNGhVUHSFp4Q5VU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=P1uZcWOpiBWTn2XOuZtEaOQUQ/APKszRLVwMoXfSujGns+XW9/bB5juRcG8LR2V4B QWQbl2qyJHw78+k64hGfCAlon7l3CPvT2IMTCiFDSudXG7TK7ooJN2JARxfz3wUAZg i6GGE03l5ULyTTEm+2lTX/SAeP3lppthRshvF6Mo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6PCu9Cr014247; Sat, 25 Jul 2015 08:56:09 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 25 Jul 2015 08:56:09 -0400 (EDT) From: Paul Wouters To: Daniel Kahn Gillmor In-Reply-To: <87bnf1hair.fsf@alice.fifthhorseman.net> Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] The DANE 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: Sat, 25 Jul 2015 12:56:24 -0000 Answering phb and dkg: > I looked at it with Petr Spacek after the meeting, and i plan on > providing Paul with a more detailed review shortly. Greatly appreciated! >> DANE is trying to do three different things. It is trying to be a key >> discovery service, a security policy publication mechanism and a way >> of validating keys using the DNSSEC. > > I think this overview is accurate. That's not how I see it. It is surely a discovery and distribution system for keys. But it is not a policy publication mechanism. The draft (carefully) does not tell you what you can or cannot do with the key. Some people tried to propose this (mostly for smime) by having different prefixes for _encrypt or _sign, but this was not adopted. Of course, one can deduce policy. If you get the key fedora22@fedoraproject.org from DNS you could expect that is the key which we use to sign our packages. But that's not different from grabbing a key from a random key server and assuming you can use it for email. the assumption of what to do with the key really lies in the ID/email address used for the key. So I do not think the openpgpkey draft changes that. >> I do not find the idea of relying on the DNS for my keys remotely >> comforting and would not want to rely on such a record directly. You dont have to rely only on DNSSEC. You grab the key from DNS, and then you can go out to other places (keyservers, your personal pubring, etc) to attempt to gain enough trust in the key for your personal taste. >> The DNS >> has no persistence to it. Give me the MIT keyserver any day. Let me generate another 1000 phb keys and upload those to the MIT keyserver. What DNS does provide is that you don't have to look through the chaf to find the wheat. You cannot add a bogus key for paul@nohats.ca into my DNSSEC zone. And importantly, if you control part of my network, you cannot confuse me into believing there is no such key published for paul@nohat.ca. Compare this to the MIT key server that accepts requests on port 80 and can easilly be MITM'ed to filter results. >> What would interest me is if I could take a DNSSEC trust chain and intern >> it in a blockchain. At that point the whole process becomes transparent and >> I have a key I can place quite a bit of reliance on. So turn your pubring.pgp into a blockchain? I don't see why it matters that the keyblob came from MIT or DNSSEC. In fact, I can also argue that the keyservers are worse because there is no sign that the key is still actively supported/known by its user, while the fact that the key is still in DNSSEC (or no longer in DNSSEC) gives me additional information to make a decision on whether or not to use the key or postpone my email until I know more. > It sounds to me like you're interested in DNSSEC Transparency. Perhaps > you could take that up in the trans WG? I know there are other people > interested there (i am!) but this discussion doesn't belong on the > OpenPGP mailing list. Agreed [*] Paul [*] speaking without my trans co-chair hat From nobody Sat Jul 25 08:14:06 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B301A1B1E for ; Sat, 25 Jul 2015 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuwtVk3wBJdE for ; Sat, 25 Jul 2015 08:14:04 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF41A87E7 for ; Sat, 25 Jul 2015 08:13:45 -0700 (PDT) Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZJ18u-0000np-C3; Sat, 25 Jul 2015 15:13:40 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZJ18r-0000bv-OP; Sat, 25 Jul 2015 17:13:39 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZJ18q-0008RZ-KP; Sat, 25 Jul 2015 17:13:36 +0200 Date: Sat, 25 Jul 2015 17:13:36 +0200 Message-ID: <87io98nucf.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor In-Reply-To: <87615dkygj.fsf@alice.fifthhorseman.net> References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Unuploadable 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: Sat, 25 Jul 2015 15:14:05 -0000 Hi Daniel, At Tue, 21 Jul 2015 23:11:40 +0200, Daniel Kahn Gillmor wrote: > However, this arrangement (or your signature subpacket proposal) has a > set of problems that make it far from ideal protection, especially in > the face of potentially adversarial users: My proposal was explicitly not about adversarial users. I'm convinced that if an attacker has access to the data, there is nothing we can do at the OpenPGP level to stop them from publishing it. The motivation for this feature is: some people have keys that they don't want to have widely distributed and training others to respect this is not easy. In other words, it is too easy to inadvertently publish a key. My proposal is to provide a mechanism that allows users to mark keys that they share with others as not intended for wide distribution. In other words, my proposal is about providing a better way to communicate the desired policy and provide a way for tools to help realize that policy. > You could craft an OpenPGP certificate with all its self-sigs marked > non-exportable, and that should have roughly the same effect for other > users of GnuPG. You'd have to use --import-options import-local to > import it at all, or else it would have no valid self-sigs, which GnuPG > should reject as a poorly-formed certificate. I think this would make sharing non-exportable keys a pain, because it overloads the meaning of local in a confusing way. Further, the current mechanism is simply not enough to realize all interesting policies. So, if we are forced to add something new, we should do it properly. Consider the following two scenarios. When Alice wants to share her key with Bob, but not with the world, she could sends it to him via email. To import her key, Bob has to do something like: `gpg2 --import-options import-local'. There should be no reason for Bob to have to do this in this situation. The policy that Alice wants to implement is about exporting keys, not importing them. When Bob wants to export Alice's key to forward it to Carol via email, he needs to run `gpg2 --export-options export-local'. This is annoying. Instead, when he exports the key, he should get a warning or a prompt saying that Alice has indicated that this key shouldn't be widely distributed. Of course, we can't enable `--import-options import-local' and `--export-options export-local' by default, because local signatures really shouldn't be imported or exported by default. The problem goes from a usability problem to a security problem when we consider private key servers. Now, the private key server needs to be configured to not discard local signatures. But, is this always the right decision? Sometimes signatures really are local and should not be discarded or they are intended for a different key server. > would this interpretation of non-exportable self-sigs be > a sufficient mechanism? I'm sorry, but I'm not clear on what definition you mean. I've read your mail several times, but I can't figure it out. Can you please repeat it. Thanks for your comments, :) Neal From nobody Sat Jul 25 08:44:57 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46DD1A86E0 for ; Sat, 25 Jul 2015 08:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPbjz26kyuVU for ; Sat, 25 Jul 2015 08:44:55 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7C1A905C for ; Sat, 25 Jul 2015 08:44:55 -0700 (PDT) Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZJ1d4-0000xR-Ic; Sat, 25 Jul 2015 15:44:50 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZJ1d2-0000dv-77; Sat, 25 Jul 2015 17:44:50 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZJ1d1-00007G-6W; Sat, 25 Jul 2015 17:44:47 +0200 Date: Sat, 25 Jul 2015 17:44:47 +0200 Message-ID: <87h9osnswg.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor In-Reply-To: <87y4i9je9f.fsf@alice.fifthhorseman.net> References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 15:44:56 -0000 Hi, At Wed, 22 Jul 2015 01:13:16 +0200, Daniel Kahn Gillmor wrote: >=20 > On Mon 2015-07-20 22:03:04 +0200, Neal H. Walfield wrote: > > At Mon, 20 Jul 2015 17:14:18 +0200, Werner Koch wrote: > >> On Mon, 20 Jul 2015 12:27, neal@walfield.org said: > >>=20 > >> > I propose that the description field be augmented to include optional > >> > email style headers. Further, we specify the following header to > >> > specify the new key: > >> > > >> > Superceded-by: fingerprint > >>=20 > >> I think it is better to have a signature subpacket or notation data to > >> the same effect. This has the advantage that it can also be used with= a > >> non-revoked key or data signature to declare a plan to supercede a key > >> in the near future. > > > > This is a good point. Either approach that you propose seems > > reasonable to me. >=20 > This is a great idea. Can you suggest a patch to the 4880bis draft that > Werner started? I decided to use a notation rather than a new signature subpacket. This is because the signature subpacket namespace is tiny compared to the notation data's namespace. Please let me know how I can improve this. Thanks! :) Neal =46rom 6160a4f49c23b35f8cc7105197ecb145aa6be9ad Mon Sep 17 00:00:00 2001 From: "Neal H. Walfield" Date: Sat, 25 Jul 2015 17:42:23 +0200 Subject: [PATCH] RFC4880bis: Describe the superseceded-by notation. --- misc/id/rfc4880bis/middle.mkd | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd index 80c0a61..6465019 100644 --- a/misc/id/rfc4880bis/middle.mkd +++ b/misc/id/rfc4880bis/middle.mkd @@ -1317,6 +1317,18 @@ addresses. If there is a critical notation, the criticality applies to that specific notation and not to notations in general. =20 +The following notations are currently defined: + + superseded-by: This notation is used within a "Reason for + Revocation" subpacket to indicate the key that superscedes this + one. The value of the notation SHOULD be an OpenPGP message + containing the fingerprint of the new key printed in + hexadecimal form and signed with the new key. If no key + supersedes this key, the value may instead be the 4 character + ASCII string "none". This notation should only be respected if + the "Reason for Revocation" subpacket does not indicate that + the key was compromised (code: 2). + #### {5.2.3.17} Key Server Preferences =20 (N octets of flags) --=20 2.1.4 From nobody Sat Jul 25 08:47:34 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD11A8F49 for ; Sat, 25 Jul 2015 08:47:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID_Jix98tulE for ; Sat, 25 Jul 2015 08:47:32 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 18A641A8F37 for ; Sat, 25 Jul 2015 08:47:32 -0700 (PDT) Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZJ1fb-0000yE-7j; Sat, 25 Jul 2015 15:47:27 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZJ1fa-0000eM-4M; Sat, 25 Jul 2015 17:47:27 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZJ1fZ-00007T-3o; Sat, 25 Jul 2015 17:47:25 +0200 Date: Sat, 25 Jul 2015 17:47:25 +0200 Message-ID: <87fv4cnss2.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor In-Reply-To: <87380hky9n.fsf@alice.fifthhorseman.net> References: <87pp3lk91r.wl-neal@walfield.org> <87pp3lhesi.fsf@vigenere.g10code.de> <87oaj5jvc9.wl-neal@walfield.org> <87380hky9n.fsf@alice.fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: Simon Josefsson , IETF OpenPGP Subject: Re: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 15:47:33 -0000 Hi, At Tue, 21 Jul 2015 23:15:48 +0200, Daniel Kahn Gillmor wrote: > > On Tue 2015-07-21 19:04:22 +0200, Neal H. Walfield wrote: > > At Tue, 21 Jul 2015 14:32:29 +0200, > > Werner Koch wrote: > >> > Simon pointed out to me in another context that the user id (section > >> > 5.11 of RFC 4880) is not always in RFC 2822 name-addr format, but is > >> > sometimes simply a hostname. I think we should expand the > >> > recommendation in that section to cover this usage. > >> > >> The name-addr convention has served us well for more than 20 years and I > >> see no reason to explicitly recommend the use of just a hostname. I see > >> no problem which will be solved by this. In case the hostname shall be > >> used similar to a a user id (e.g. for DNS lookup), it is easier to use a > >> pseudo mail address like hostmaster@foo.example.org. > > > > I'm not making a recommendation about what should be done, but > > suggesting we update the RFC to reflect current practice. > > Can you point to existing examples of this usage (by fingerprint, > maybe)? This usage was pointed out to me by Simon. I've cc'd him. I hope he'll be able to answer your question. Nevertheless, Derek Atkins' follow up to your question suggests that at least some people are using this convention. Thanks! :) Neal From nobody Sat Jul 25 08:48:49 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5831A906B for ; Sat, 25 Jul 2015 08:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiV0OGub6RBU for ; Sat, 25 Jul 2015 08:48:46 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0C1A9060 for ; Sat, 25 Jul 2015 08:48:46 -0700 (PDT) Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZJ1gn-0000yd-5u; Sat, 25 Jul 2015 15:48:41 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZJ1gj-0000ed-JP; Sat, 25 Jul 2015 17:48:40 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZJ1gi-00007Y-I8; Sat, 25 Jul 2015 17:48:36 +0200 Date: Sat, 25 Jul 2015 17:48:36 +0200 Message-ID: <87egjwnsq3.wl-neal@walfield.org> From: "Neal H. Walfield" To: Derek Atkins In-Reply-To: References: <87pp3lk91r.wl-neal@walfield.org> <87pp3lhesi.fsf@vigenere.g10code.de> <87oaj5jvc9.wl-neal@walfield.org> <87380hky9n.fsf@alice.fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 15:48:47 -0000 At Thu, 23 Jul 2015 20:15:39 -0400, Derek Atkins wrote: > In my deployment of PGP signatures we're using only FQDNs in the UserID > field in many cases (because they keys are tied to an entity and not a > person). I'll note that RFC4880 does not specify the contents of the > UserID field, only saying that by convention it's an email address but > not actually REQUIRING it. I would oppose text that requires an email > address in the ID field. I agree with you and I don't think anyone proposed changing this recommendation. :) Neal From nobody Sat Jul 25 09:23:18 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C281ACCD8; Sat, 25 Jul 2015 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ7MdrVp6FCe; Sat, 25 Jul 2015 09:23:14 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7401AC431; Sat, 25 Jul 2015 09:23:13 -0700 (PDT) Received: by lafd3 with SMTP id d3so18550572laf.1; Sat, 25 Jul 2015 09:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RuAs/0tN2VwIJjvOP4/AWH18fz3nvydFGO+mXTMgwKw=; b=s0+XYKRQjFV4p2qKEVDLdsBdLnFfAnJnEnUELZGzIASvEIlSeqCOtV4uIy+2gN20I7 SZuDSqftXasUc79A9o0UiJXYb/ftteGdPNbfrngJokonTI5b9322cV60Z/Ep8ydH5qhK ynvkEmZf+PI60/dYWfuwgOIdAcKpmK34RMWVCxppQb0wgYQxr5Xkuqg5Ckdz3wNjXMmZ qiG7v6SrDbqHCM5jb0dWO89g1qS+wCgsLK8A/An7AwioXKehK8buDCVUyGrN0OGVr4S/ wD8u+f0YB6vsx7xdSBmGOkTz2IqT5pKi/4vUGCVAjcI0GSXrFT2Aen7q9wHmkM9N3qdU KngA== MIME-Version: 1.0 X-Received: by 10.112.170.167 with SMTP id an7mr19054709lbc.103.1437841392309; Sat, 25 Jul 2015 09:23:12 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 25 Jul 2015 09:23:12 -0700 (PDT) In-Reply-To: References: <87si8dagiz.fsf@vigenere.g10code.de> Date: Sat, 25 Jul 2015 12:23:12 -0400 X-Google-Sender-Auth: MeydRE1-WGQDwcpn3_G2r3nhreM Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c368cc6e9e4a051bb5892c Archived-At: Cc: Werner Koch , IETF OpenPGP , Olafur Gudmundsson , dane WG list Subject: Re: [openpgp] The DANE 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: Sat, 25 Jul 2015 16:23:16 -0000 --001a11c368cc6e9e4a051bb5892c Content-Type: text/plain; charset=UTF-8 On Sat, Jul 25, 2015 at 8:19 AM, Paul Wouters wrote: > On Fri, 24 Jul 2015, Werner Koch wrote: > > PHB wrote: > > 2) If people find it does not meet OpenPGP needs, they should say so and >>> have no qualms about objecting. It is much more important that there be a >>> spec people use than that the document progress quickly. >>> >> > This document has not progressed "quickly". The original draft was > published in July 2013. No one is trying to rush this through I am quite happy waiting till 2016 or 2018. If it isn't done right its better not to publish at all. > I was a bit disappointed by the process: I learned about the I-D too late >> and was surprised that it started out at the OpenPGP WG mailing list (2 >> years ago?) with just a few messages and then continued at the DANE list >> without having notified the OpenPGP list. >> > > This is now the fourth time I am having this discussion with you, so I > think your representation is not entirely fair. The previous discussions > ended with you saying we should not do this and stick to the CERT record > type and me stating why I disagree with that view. Ummm watch your attributions, that is Werner, not me. The DANE group has been rather ineffective in getting the constituencies they purport to be serving to buy into their proposal. Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. All of X509 isn't a big barrier. Took me a week, four days of that was writing the Assinine One compiler. I am not aware of any major crypto package that doesn't have the ability to parse X.509 certs. Werner isn't the only person who has a PKIX package in his OpenPGP library. Back in 1990 the idea of using OpenPGP to avoid the need to mess with Assinine One made arguable sense. Today its a lost cause. I stopped fighting that battle in 1995. The CERT record is more flexible because it also allows the use of an >> indirect specification via fingerprint. >> > > Which is a problem not a feature. It makes the security model very > complex. No, the security model is complex because you are trying to use a vast, aging and vaguely understood infrastructure with a byzantine administrative model to provide security. Failing to accept that fact is one of the many reasons people are skeptical of this project and looking for ways to work round it. --001a11c368cc6e9e4a051bb5892c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 25, 2015 at 8:19 AM, Paul Wouters <paul@nohats.ca> wrote:
On Fri, 24 Jul 2015, Werner Ko= ch wrote:

PHB wrote:

2) If people find it does not meet OpenPGP needs, they should say so and have no qualms about objecting. It is much more important that there be a spec people use than that the document progress quickly.

 This document has not progressed "quickly". The original draft wa= s
published in July 2013. No one is trying to rush this through
<= div>
I am quite happy waiting till 2016 or 2018.=C2=A0
<= div>
If it isn't done right its better not to publish at = all.



I was a bit disappointed by the process: I learned about the I-D too late and was surprised that it started out at the OpenPGP WG mailing list (2
years ago?) with just a few messages and then continued at the DANE list without having notified the OpenPGP list.

This is now the fourth time I am having this discussion with you, so I
think your representation is not entirely fair. The previous discussions ended with you saying we should not do this and stick to the CERT record type and me stating why I disagree with that view.

Ummm watch your attributions, that is Werner, not me.
The DANE group has been rather ineffective in getting the const= ituencies they purport to be serving to buy into their proposal.
=

Additionally, becau= se the CERT record is a meta-container record,
support for CERT is not good because to properly parse it you need
all of openpgp and all of x509 and all of what other subtypes would
be added later on. So instead of implementing CERT records partially,
many DNS implementations just did not bother with it at all.

All of X509 isn't a big barrier. Took me a week, four= days of that was writing the Assinine One compiler. I am not aware of any = major crypto package that doesn't have the ability to parse X.509 certs= . Werner isn't the only person who has a PKIX package in his OpenPGP li= brary.=C2=A0

Back in 1990 the idea of using OpenPG= P to avoid the need to mess with Assinine One made arguable sense. Today it= s a lost cause. I stopped fighting that battle in 1995.



=C2=A0The CERT record is more flexible because it also allows the use of an=
=C2=A0indirect specification via fingerprint.

 Which is a problem not a feature. It makes the security model very
complex.

No, the security model is complex= because you are trying to use a vast, aging and vaguely understood infrast= ructure with a byzantine administrative model to provide security.

Failing to accept that fact is one of the many reasons peo= ple are skeptical of this project and looking for ways to work round it.
--001a11c368cc6e9e4a051bb5892c-- From nobody Sat Jul 25 09:25:36 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525891A87CB for ; Sat, 25 Jul 2015 09:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zKWZCK1AfPI for ; Sat, 25 Jul 2015 09:25:34 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011461A88C5 for ; Sat, 25 Jul 2015 09:25:34 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so30943867lbb.1 for ; Sat, 25 Jul 2015 09:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ev7EcCN1QB/O49GbHhDagCAe6T/PML+EcQQlNYt3jCI=; b=vQP4mq5ZoN0TE6/fwAcqp4kaszjVmJGEWWawmpJFSayCjuqhtH4MnKPd8oAdF0JMW9 qzSxMvKbeWBmkoTKvgDztMbNY5JRcWwH6ZE3fPx7xwpEyHAbA/tR9YOB2Dg4TARjEpRB js9hDBk20DBVrUOHYsUNzIU8bme7Q/Hq2THbUrDwZ1hqIVUi/qJK4Nyf88Al0p/AunYx bY19diyqZIBU3U6nI1sujl+HA5ue2/KuIjMvTUryJVHbLR86notuZxPDbRPBEvXOGhna lAWO1/E3n37ga0NOPWi55k8HloJXjIP07hvR4+SEiaw3jTc0R4UT2zBSUOs4XqbhmVxV q5gw== MIME-Version: 1.0 X-Received: by 10.112.185.100 with SMTP id fb4mr19191572lbc.79.1437841532583; Sat, 25 Jul 2015 09:25:32 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 25 Jul 2015 09:25:32 -0700 (PDT) In-Reply-To: References: <87bnf1hair.fsf@alice.fifthhorseman.net> Date: Sat, 25 Jul 2015 12:25:32 -0400 X-Google-Sender-Auth: 7kS_d4fTdFukNrxzlBm6HqDMzTY Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c3ca22cb0383051bb591a9 Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] The DANE 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: Sat, 25 Jul 2015 16:25:35 -0000 --001a11c3ca22cb0383051bb591a9 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 25, 2015 at 8:56 AM, Paul Wouters wrote: > > Answering phb and dkg: > > > I looked at it with Petr Spacek after the meeting, and i plan on >> providing Paul with a more detailed review shortly. >> > > Greatly appreciated! > > DANE is trying to do three different things. It is trying to be a key >>> discovery service, a security policy publication mechanism and a way >>> of validating keys using the DNSSEC. >>> >> >> I think this overview is accurate. >> > > That's not how I see it. It is surely a discovery and distribution > system for keys. But it is not a policy publication mechanism. The > draft (carefully) does not tell you what you can or cannot do with the > key. Some people tried to propose this (mostly for smime) by having > different prefixes for _encrypt or _sign, but this was not adopted. > Again, you don't seem to understand the spec. 'MUST USE TLS' is one of the purported benefits. Key pinning to a specific key is another. Those are security policy. I think those should be taken out of DANE but that hasn't happened yet as far as I am aware. --001a11c3ca22cb0383051bb591a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jul 25, 2015 at 8:56 AM, Paul Wouters <paul@nohats.ca> wrote:

Answering phb and dkg:


I looked at it with Petr Spacek after the meeting, and i plan on
providing Paul with a more detailed review shortly.

 Greatly appreciated!

DANE is trying to do three different things. It is trying to be a key
discovery service, a security policy publication mechanism and a way
of validating keys using the DNSSEC.

I think this overview is accurate.

 That's not how I see it. It is surely a discovery and distribution
system for keys. But it is not a policy publication mechanism.=C2=A0 The draft (carefully) does not tell you what you can or cannot do with the
key. Some people tried to propose this (mostly for smime) by having
different prefixes for _encrypt or _sign, but this was not adopted.

Again, you don't seem to understand the sp= ec. 'MUST USE TLS' is one of the purported benefits. Key pinning to= a specific key is another. Those are security policy.

=
I think those should be taken out of DANE but that hasn't happened= yet as far as I am aware.


<= /div> --001a11c3ca22cb0383051bb591a9-- From nobody Sat Jul 25 09:45:07 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1C1A8799 for ; Sat, 25 Jul 2015 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp94ENReG9Vj for ; Sat, 25 Jul 2015 09:45:04 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625B61ACE04 for ; Sat, 25 Jul 2015 09:45:03 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so31082391lbb.1 for ; Sat, 25 Jul 2015 09:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+VfX5mOC9keOZlGNErY/12k2fvzlYoPeHQbn+p19Etg=; b=Ju+PkIaRmG2LOLOZhIMHjwJDq7s7XLjEfyJk6jBpswp1jLQopc8phomM9ZAhYI8Mnh r4Ei1K8r6fjruGNfT4ktsUiwqm1rMV85WrFLSrOYke1IHLjpcZMCgw0b6dwn5BaNH9rl VsG1J5m/ROWDP+ZJWDEfIQPEw9us05ZEzarDKE4f/ZGvvi6QW630hZ8cfu+SwWK0tTOz 5Ewv+0gauyo185DEMrRZGxSWeG23+8W/IMLYMBhxJMq7S/1baF44+uOqewRb98indHA4 qtWGGkPDf0Ij22atN4B6W4jIN5WqRO/av2tKAY6/F4teK3g6lprlYTQaCGfmQhDX7Ni1 5tEg== MIME-Version: 1.0 X-Received: by 10.112.123.179 with SMTP id mb19mr19513676lbb.55.1437842701716; Sat, 25 Jul 2015 09:45:01 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Sat, 25 Jul 2015 09:45:01 -0700 (PDT) In-Reply-To: <87bnf1hair.fsf@alice.fifthhorseman.net> References: <87bnf1hair.fsf@alice.fifthhorseman.net> Date: Sat, 25 Jul 2015 12:45:01 -0400 X-Google-Sender-Auth: EX-eH2FuraG3LopILTchTzpLSyI Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=047d7bfd04767a9290051bb5d7e8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] The DANE 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: Sat, 25 Jul 2015 16:45:06 -0000 --047d7bfd04767a9290051bb5d7e8 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 24, 2015 at 10:53 AM, Daniel Kahn Gillmor wrote: > On Fri 2015-07-24 12:40:31 +0200, Phillip Hallam-Baker wrote: > > 1) The draft is approaching IETF last call. People working on OpenPGP > > should review it now. > > I looked at it with Petr Spacek after the meeting, and i plan on > providing Paul with a more detailed review shortly. > > > DANE is trying to do three different things. It is trying to be a key > > discovery service, a security policy publication mechanism and a way > > of validating keys using the DNSSEC. > > I think this overview is accurate. I also think all these things are > necessary. While i'm not particularly excited at the prospect of a > hierarchically controlled system like DNS being the One True System, we > do need to find ways to address these three goals anyway. Agreed. But OpenPGP already has a fairly effective key distribution infrastructure. As a rough guide: The CryptoMesh = OpenPGP Key Servers + Certificate Transparency - Cruft + Marketting bullcrap. I am happy to leverage the DNS as one way to validate keys but it can't be the only way. And the way it is designed means it isn't actually a particularly convenient one. And don't underestimate the value of marketing bullcrap. Before the Web, people had been trying to make network hypertext work for decades. > > So the way that I would approach using DNSSEC to validate a key for ' > > alice@example.com' would be to introduce a record in the DNS with the > > semantics 'X is authorized to sign for *@example.com'. > > I think you mean "X is authorized to certify any key+User ID where the > user ID matches *.example.com", not that X is allowed to make sign mail > for *@example.com. right? Yes, every end entity should have their own key. But if all you do is domain validation then the domain owner is alway going to be able to sign for alice@example.com by publishing a key. I don't think that is a big problem because I don't think you can expect digital signatures to be legally non-repudiable without some additional infrastructure to validate the key holder in the real world. Like an in-person notary verification at minimum. > I like this idea as a way of validating keys > for the DNSSEC (the third of your three prongs of DANE). If you were to > make a record with the semantics "any OpenPGP key+User ID where the User > ID matches *@example.com should not be considered valid *unless* it is > certified by this key", then you could use it as a security policy > mechanism (prong two). There might be a requirement for that type of record. It is in effect a cryptographically enforced variant of CAA. But stopping unauthorized use of OpenPGP is not top of my priority list right now. > > I would not attempt to fill the DNS with keys for Alice, Billybob, > > Carol, Doug, Ethelred and co. It is not working for TLS and I don't > > think it will work for OpenPGP or S/MIME. > > So it sounds like the part you disagree with is the use of DNS/DANE as a > key discovery service (prong one). Yes, the key servers work. They are deployed. The only reason to replace them would be with something better. > > I do not find the idea of relying on the DNS for my keys remotely > > comforting and would not want to rely on such a record directly. The DNS > > has no persistence to it. Give me the MIT keyserver any day. > > > > What would interest me is if I could take a DNSSEC trust chain and intern > > it in a blockchain. At that point the whole process becomes transparent > and > > I have a key I can place quite a bit of reliance on. > > It sounds to me like you're interested in DNSSEC Transparency. Perhaps > you could take that up in the trans WG? I know there are other people > interested there (i am!) but this discussion doesn't belong on the > OpenPGP mailing list. > Yes, I have written a TRANS notary (besides the one Rob wrote). I know the spec. But that is an infrastructure targeted at a single task and working within a set of rather obnoxious constraints (PKIX). Right now, that discussion certainly does not belong in TRANS any more than OpenPGP. I am suggesting we use therightkey@ietf.org for that sort of discussion. --047d7bfd04767a9290051bb5d7e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 24, 2015 at 10:53 AM, Daniel Kahn Gillmor <dkg@fifthho= rseman.net> wrote:
On Fri 2015-07-24 12:40:31 +0200, Phillip Hallam-Baker wrote:
> 1) The draft is approaching IETF last call. People working on OpenPGP<= br> > should review it now.

I looked at it with Petr Spacek after the meeting, and i plan on
providing Paul with a more detailed review shortly.

> DANE is trying to do three different things. It is trying to be a key<= br> > discovery service, a security policy publication mechanism and a way > of validating keys using the DNSSEC.

I think this overview is accurate.=C2=A0 I also think all these thin= gs are
necessary.=C2=A0 While i'm not particularly excited at the prospect of = a
hierarchically controlled system like DNS being the One True System, we
do need to find ways to address these three goals anyway.
=
Agreed. But OpenPGP already has a fairly effective key distr= ibution infrastructure. As a rough guide:=C2=A0

Th= e CryptoMesh =3D OpenPGP Key Servers + Certificate Transparency - Cruft
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ Marketting bullcrap.
<= br>
I am happy to leverage the DNS as one way to validate keys bu= t it can't be the only way. And the way it is designed means it isn'= ;t actually a particularly convenient one.

And don= 't underestimate the value of marketing bullcrap. Before the Web, peopl= e had been trying to make network hypertext work for decades.=C2=A0

=C2=A0
> So the way that I would approach using DNSSEC to validate a key for= '
> alice@exa= mple.com' would be to introduce a record in the DNS with the
> semantics 'X is authorized to sign for *@example.com'.

I think you mean "X is authorized to certify any key+User ID where the=
user ID matches *.example.com", not that X is allowed to make sign mail<= br> for *@e= xample.com.=C2=A0 right?=C2=A0

Yes, eve= ry end entity should have their own key. But if all you do is domain valida= tion then the domain owner is alway going to be able to sign for alice@example.com by publishing a key.
=

I don't think that is a big problem because I don&#= 39;t think you can expect digital signatures to be legally non-repudiable w= ithout some additional infrastructure to validate the key holder in the rea= l world. Like an in-person notary verification at minimum.=C2=A0
=
=C2=A0
I like this idea= as a way of validating keys
for the DNSSEC (the third of your three prongs of DANE).=C2=A0 If you were = to
make a record with the semantics "any OpenPGP key+User ID where the Us= er
ID matches *@example.com should not be considered valid *unless* it is
certified by this key", then you could use it as a security policy
mechanism (prong two).

There might be a req= uirement for that type of record. It is in effect a cryptographically enfor= ced variant of CAA. But stopping unauthorized use of OpenPGP is not top of = my priority list right now.

=C2=A0
> I would not attempt to fill the = DNS with keys for Alice, Billybob,
> Carol, Doug, Ethelred and co. It is not working for TLS and I don'= t
> think it will work for OpenPGP or S/MIME.

So it sounds like the part you disagree with is the use of DNS/DANE = as a
key discovery service (prong one).

Yes, the= key servers work. They are deployed. The only reason to replace them would= be with something better.=C2=A0


> I do not find the idea of relying on the DNS for my keys remotely
> comforting and would not want to rely on such a record directly. The D= NS
> has no persistence to it. Give me the MIT keyserver any day.
>
> What would interest me is if I could take a DNSSEC trust chain and int= ern
> it in a blockchain. At that point the whole process becomes transparen= t and
> I have a key I can place quite a bit of reliance on.

It sounds to me like you're interested in DNSSEC Transparency.= =C2=A0 Perhaps
you could take that up in the trans WG?=C2=A0 I know there are other people=
interested there (i am!) but this discussion doesn't belong on the
OpenPGP mailing list.

Yes, I have writt= en a TRANS notary (besides the one Rob wrote). I know the spec. But that is= an infrastructure targeted at a single task and working within a set of ra= ther obnoxious constraints (PKIX).

Right now, that= discussion certainly does not belong in TRANS any more than OpenPGP. I am = suggesting we use therightkey@ietf.= org for that sort of discussion.


--047d7bfd04767a9290051bb5d7e8-- From nobody Sat Jul 25 10:46:57 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDAB1A016A for ; Sat, 25 Jul 2015 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZgB6iLoEa4x for ; Sat, 25 Jul 2015 10:46:55 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578071A0161 for ; Sat, 25 Jul 2015 10:46:55 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so40757438igb.0 for ; Sat, 25 Jul 2015 10:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=g2YHsJDEOY9/JlYW8rdCR/I0FUunvDH5NJ5VzUDCEIo=; b=o5aaXekt4/PCuyW1D6va/FkSQ2n2Ecp+p/8+T5BxkYv7dzSq24ibvKC9HWHXUaH6bF zvYglki29I0mmkD1Z2WNs/BH+MPaH7FTs0ycTpoidBCApH5f3g8cLM2UKkzpTnR1d7Pv PklzvYrCmO/cCxcTLWxZinchrNsYriy1KegslAncYB0AZfYGH15YfDdORJDbHn+d8Ijt D1Vrw3O6Y0yqiM49qfHtnRI1e361Yc6uC7j6V4iz9mJfPCR9HCMOnZ0o0tJMbpZqCsV+ DMfUSXv/h3z4nskJog7yYpmMoeHkJfDAzuBSag9wSJK8USPkr7QGQkDaNruRLQZ/pwLL gPZA== MIME-Version: 1.0 X-Received: by 10.107.133.94 with SMTP id h91mr35410323iod.1.1437846414622; Sat, 25 Jul 2015 10:46:54 -0700 (PDT) Received: by 10.107.48.212 with HTTP; Sat, 25 Jul 2015 10:46:54 -0700 (PDT) In-Reply-To: <87bnf3ck5n.fsf@vigenere.g10code.de> References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> <87bnf3ck5n.fsf@vigenere.g10code.de> Date: Sat, 25 Jul 2015 17:46:54 +0000 Message-ID: From: Gregory Maxwell To: Daniel Kahn Gillmor , "Neal H. Walfield" , IETF OpenPGP Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Unuploadable 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: Sat, 25 Jul 2015 17:46:56 -0000 On Thu, Jul 23, 2015 at 9:12 AM, Werner Koch wrote: > On Tue, 21 Jul 2015 23:11, dkg@fifthhorseman.net said: > >> So the question is whether having this as an advisory mechanism (not a >> perfect bulwark against adversarial publication) is worthwhile. If it > > I would really like to see such a standard flag. For whatever reasons > some people do not like to have there keys on a keyserver and only make > them available by other means. Such a flag would also help with testing > to avoid accidental uploads of a key. A related flag, though sadly more complex to implement, would be making it so the list of signatures on a key must be signed by a selected subkey. This would prevent an irritating attack where people create random and sometimes harassing or offensive keyids and use them to sign your key and upload the result to the keyservers-- which is one of the most common reasons I've seen cited for people not wanting their keys on keyservers. From nobody Sat Jul 25 13:20:46 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9F61B3006 for ; Sat, 25 Jul 2015 13:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP75EX3ttie6 for ; Sat, 25 Jul 2015 13:20:42 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42911B2FEA for ; Sat, 25 Jul 2015 13:20:42 -0700 (PDT) Received: from localhost (p5798E8AE.dip0.t-ipconnect.de [87.152.232.174]) by mail.mugenguild.com (Postfix) with ESMTPSA id EA50561C84; Sat, 25 Jul 2015 22:16:47 +0200 (CEST) References: <87a8uxlcvz.wl-neal@walfield.org> <87615dkygj.fsf@alice.fifthhorseman.net> <87bnf3ck5n.fsf@vigenere.g10code.de> From: Vincent Breitmoser To: Werner Koch In-reply-to: <87bnf3ck5n.fsf@vigenere.g10code.de> Date: Sat, 25 Jul 2015 22:20:33 +0200 Message-ID: <8761587zvy.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Unuploadable 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: Sat, 25 Jul 2015 20:20:44 -0000 On 23 Jul 2015, Werner Koch wrote: > I would really like to see such a standard flag. For whatever > reasons some people do not like to have there keys on a keyserver > and only make them available by other means. I concur. We ask users during creation of keys whether they want it uploaded or not, and it would be helpful to associate this setting with the key in a standardized way. - V From nobody Sat Jul 25 13:41:42 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCDE1B3036 for ; Sat, 25 Jul 2015 13:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSDUJ99MQEJz for ; Sat, 25 Jul 2015 13:41:38 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BB11A1BA9 for ; Sat, 25 Jul 2015 13:41:38 -0700 (PDT) Received: from localhost (p5798E8AE.dip0.t-ipconnect.de [87.152.232.174]) by mail.mugenguild.com (Postfix) with ESMTPSA id BF9C461C8D; Sat, 25 Jul 2015 22:37:44 +0200 (CEST) References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> From: Vincent Breitmoser To: "Neal H. Walfield" In-reply-to: <87h9osnswg.wl-neal@walfield.org> Date: Sat, 25 Jul 2015 22:41:30 +0200 Message-ID: <874mks7yx1.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 20:41:40 -0000 On 25 Jul 2015, Neal H. Walfield wrote: > I decided to use a notation rather than a new signature subpacket. > This is because the signature subpacket namespace is tiny compared > to the notation data's namespace. I think I disagree with this. It's true that the signature subpacket namespace is not very large, but the numbers are that only ~30 subpacket ids out of 100 are actually used. If we ever get past 70, we might want to think about how to deal with the problem (there is always the 8th bit left for this purpose, too), until then unused namespace is wasted namespace and we gain nothing by avoiding its use. Are there any other standardized uses for the notation namespace? I am only aware of proposed ones, and none which have very widespread use outside of closed systems. - V From nobody Sat Jul 25 19:16:35 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6D1ACEF4 for ; Sat, 25 Jul 2015 19:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-2UQns9ulNy for ; Sat, 25 Jul 2015 19:16:32 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2F1ACEF2 for ; Sat, 25 Jul 2015 19:16:32 -0700 (PDT) Received: from p50813e87.dip0.t-ipconnect.de ([80.129.62.135] helo=mail.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZJBUJ-0000gf-8f; Sun, 26 Jul 2015 02:16:27 +0000 Received: from grit.huenfield.org ([192.168.20.253]) by mail.huenfield.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZJBUH-0001Do-Gm; Sun, 26 Jul 2015 04:16:26 +0200 Received: from ip6-localhost.huenfield.org ([::1] helo=grit.huenfield.org.walfield.org) by grit.huenfield.org with esmtp (Exim 4.84) (envelope-from ) id 1ZJBUG-0000LY-G1; Sun, 26 Jul 2015 04:16:24 +0200 Date: Sun, 26 Jul 2015 04:16:24 +0200 Message-ID: <87a8ujoe87.wl-neal@walfield.org> From: "Neal H. Walfield" To: Vincent Breitmoser In-Reply-To: <874mks7yx1.fsf@littlepip.fritz.box> References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 192.168.20.253 X-SA-Exim-Mail-From: neal@walfield.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 17:06:47 +0000) X-SA-Exim-Scanned: Yes (on mail.huenfield.org) Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 02:16:33 -0000 Hi, At Sat, 25 Jul 2015 22:41:30 +0200, Vincent Breitmoser wrote: > On 25 Jul 2015, Neal H. Walfield wrote: > > I decided to use a notation rather than a new signature subpacket. > > This is because the signature subpacket namespace is tiny compared > > to the notation data's namespace. > > I think I disagree with this. It's true that the signature subpacket > namespace is not very large, but the numbers are that only ~30 subpacket > ids out of 100 are actually used. If we ever get past 70, we might want > to think about how to deal with the problem (there is always the 8th bit > left for this purpose, too), until then unused namespace is wasted > namespace and we gain nothing by avoiding its use. > > Are there any other standardized uses for the notation namespace? I am > only aware of proposed ones, and none which have very widespread use > outside of closed systems. Are you arguing that since notations aren't used in practice that they are probably not widely supported and it would be better to use a new signature subpacket? If not, what is your argument against introducing a notation? Thanks! :) Neal From nobody Sat Jul 25 19:45:16 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7031B29A9 for ; Sat, 25 Jul 2015 19:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcqfO2xNXf7L for ; Sat, 25 Jul 2015 19:45:12 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B761B29AD for ; Sat, 25 Jul 2015 19:45:12 -0700 (PDT) Received: from localhost (p5798E8AE.dip0.t-ipconnect.de [87.152.232.174]) by mail.mugenguild.com (Postfix) with ESMTPSA id 0BD4661C84; Sun, 26 Jul 2015 04:41:18 +0200 (CEST) References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> <87a8ujoe87.wl-neal@walfield.org> From: Vincent Breitmoser To: "Neal H. Walfield" In-reply-to: <87a8ujoe87.wl-neal@walfield.org> Date: Sun, 26 Jul 2015 04:45:03 +0200 Message-ID: <87zj2j7i34.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 02:45:14 -0000 On 26 Jul 2015, Neal H. Walfield wrote: > Are you arguing that since notations aren't used in practice that > they are probably not widely supported and it would be better to use > a new signature subpacket? If not, what is your argument against > introducing a notation? I'm mostly thinking about consistency. The signature subpacket namespace seems like the natural place to put this piece of information, right next to similar data like "reason for revocation". We should not place it in a different place unless there is good reason to do so. - V From nobody Sun Jul 26 01:21:03 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55041A1A4B; Sun, 26 Jul 2015 01:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MI1OYbM5YPg; Sun, 26 Jul 2015 01:20:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7931A066C; Sun, 26 Jul 2015 01:20:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfHK35Bjmz5B6; Sun, 26 Jul 2015 10:20:55 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=R9sZZhON X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ZpBR6utdva3x; Sun, 26 Jul 2015 10:20:53 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Jul 2015 10:20:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D66D580042; Sun, 26 Jul 2015 04:20:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437898852; bh=89ETkdMo9o+pLPiUD2dob0GXKyJqDeFWDQeL+LFo0fU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R9sZZhONBouriIUginx4bZagQXuUVb72B3S7c65MywXxxDF+3C1aRN/j7jCBVhjEu 1egkXsVaGr1HbhggGYod6473qjMfnyFXA97XAVSFWMDeRUFfiy54mv8K6xUara1mhv h+rL6zU//jhFK/5QYKtjZYnS4Rly/dmjiM1F0pvM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6Q8KqDl030840; Sun, 26 Jul 2015 04:20:52 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Jul 2015 04:20:52 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor , dane WG list Subject: Re: [openpgp] The DANE 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: Sun, 26 Jul 2015 08:21:00 -0000 On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: > On Sat, Jul 25, 2015 at 8:56 AM, Paul Wouters wrote: > > Answering phb and dkg: [note I stated my answer was to both you and dkg, and I used traditional ">" and ">>" which your email client seems to have eaten, so it is unfortunate if that causes further confusion to a lot of people's email client when reading this response] > That's not how I see it. It is surely a discovery and distribution > system for keys. But it is not a policy publication mechanism.  The > draft (carefully) does not tell you what you can or cannot do with the > key. Some people tried to propose this (mostly for smime) by having > different prefixes for _encrypt or _sign, but this was not adopted. > > Again, you don't seem to understand the spec. 'MUST USE TLS' is one of the purported benefits. Which specification are you refering to? The OPENPGPKEY specification does not say "MUST USE TLS". > Key pinning to a specific key is another. I assume you mean "key pinning to a specific user"? If so, the OpenPGP RFC already binds the public key and the various key ID's. Any such existing pinning is in the OpenPGP RFC. This draft does not modify OpenPGP in any way whatsoever. It only provides a discovery mechanism to find an openpgp key based on an email address. > Those are security policy. whether or not they are, they are not specified in this draft. > I think those should be taken out of DANE but that hasn't happened yet as far as I am aware. I don't even understand what you mean with "DANE" in this context. This draft has nothing to do with the TLSA record which _does_ do further security policy specification using Selectors and Usage types. This draft specifically does not use Selectors or Usage types and leaves all the openpgp key policies to the OpenPGP RFC options. Paul From nobody Sun Jul 26 02:11:14 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C215D1B2A05; Sun, 26 Jul 2015 02:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv_koYZcSlKW; Sun, 26 Jul 2015 02:11:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA621B2A01; Sun, 26 Jul 2015 02:11:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfJQy3hSyz5G0; Sun, 26 Jul 2015 11:11:06 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=iJKOTCBh X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wkK7qdASboUG; Sun, 26 Jul 2015 11:11:04 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Jul 2015 11:11:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 673EE80042; Sun, 26 Jul 2015 05:11:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437901863; bh=4lPqdP+S68E+CAHCLwAYtJVK7skhOozrRIqZhPgJEw0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iJKOTCBhzCENnC0iZxVXrOcEPljuh7z7rKbygJ71IJMvrMBrieR6mDvRu1ONzTB5K 7rcTkhLjc2o2yZs6QWsu12Wbtysb2NNX382IZonS2HQcE4BVKP7HJuog7KBZgnUsQo XoLEQ11B6Ozn+5KrqrSOcTHMyLUUN61/thPWUTUw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6Q9B2RM004850; Sun, 26 Jul 2015 05:11:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Jul 2015 05:11:02 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <87si8dagiz.fsf@vigenere.g10code.de> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Werner Koch , IETF OpenPGP , dane WG list Subject: Re: [openpgp] [dane] The DANE 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: Sun, 26 Jul 2015 09:11:11 -0000 On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: > This document has not progressed "quickly". The original draft was > published in July 2013. No one is trying to rush this through > > I am quite happy waiting till 2016 or 2018.  > > If it isn't done right its better not to publish at all. While a worthwhile generic goal, let's do a reality check here. We are talking about assigning a DNS RRcode for an experimental RFC for storing RFC 4880 section 5 openpgp packet types into an RDATA field at a predictable DNS QNAME entry. If that takes 5 years, the IETF will be on its way to become irrelevant, and the associated working groups will be to blame for the proliferation of more TXT type records containing non-text content. It ignores that many of the original DNSSEC architects meant for the DNS to be able to securely store signed data. > I was a bit disappointed by the process: I learned about the I-D too late > and was surprised that it started out at the OpenPGP WG mailing list (2 > years ago?) with just a few messages and then continued at the DANE list > without having notified the OpenPGP list. > > This is now the fourth time I am having this discussion with you, so I > think your representation is not entirely fair. The previous discussions > ended with you saying we should not do this and stick to the CERT record > type and me stating why I disagree with that view. > > Ummm watch your attributions, that is Werner, not me. My apologies that was not made clearer. I indeed meant to indicate I was talking to Werner. > The DANE group has been rather ineffective in getting the constituencies they purport to be > serving to buy into their proposal. Are you referring to the OPENPGPKEY document when saying "their proposal" ? The DANE working group in general has the strange effect that it is completely ignored when it writes documents to use DNSSEC based Authentication (its main charter goal!) and only when documents are getting to WGLC, do people in other areas suddenly wake up and throw on the brakes waving their expert hats around saying that the DANE working group cannot make any decisions about their protocol. I've heard in hallway talks that some people felt so attacked that they basically left the DANE working group. We had a round of PKIX people, we had a round of email people, all coming in really late into the process. It would be really helpful if people get involved earlier in the process. > Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. > > All of X509 isn't a big barrier. The point is preventing needless CVE's, not adding ASN.1 parsers and X.509 parsers where not needed. If you don't think X.509 is a problem, then you haven't been paying attention to CVE's. > I am not aware of any major crypto package that doesn't have the ability to parse X.509 I am not aware of any major crypto package that did not have a number of CVE's in their X.509 code. > . Werner isn't the only person who has a PKIX package in his OpenPGP library.  Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of that do PKIX. And it would be good not to add new ones just because we are trying to save one DNS RRTYPE code point by re-using a bad idea from the past that is today basically unused (the CERT record). >  The CERT record is more flexible because it also allows the use of an >  indirect specification via fingerprint. > > Which is a problem not a feature. It makes the security model very > complex. > > No, the security model is complex because you are trying to use a vast, aging and vaguely > understood infrastructure with a byzantine administrative model to provide security. I am not even sure what refers to what in that sentence. DNS is a set of well maintained protocols, and RFC 4880 is solid and seeing an update now in the newly re-chartered openpgp working group. Email addresses in their current form while vast and old, aren't being obsoleted any time soon and I don't think my paul@nohats.ca address is aging. I also find it _really_ ironic that it is not the openpgp key servers that you are calling "vast, aging and vaguely understood infrastructure" because if anything is a dangerous misunderstood mess that we cannot seem to clean up, it is the current electronic garbage heap of pgp keys we can never clean up because the owners lost their keys or the keys were generated and uploaded by those not actually being the real owners of those email address specified in the openpgp key id. It is _really_ difficult to design any other method of openpgp key distribution that would be _worse_ than the current key servers. > Failing to accept that fact is one of the many reasons people are skeptical of this project and > looking for ways to work round it. And this is an actual real problem. There is no valid reason for needing to "work around" an experimental proposal that has a significant backing of people in the IETF, the mail community and opensource software writers and distributions. This document is not a protocol extension you are forced to deal even though you never wanted to. You can simply not publish OPENPGPKEY records and remain as secure as you are today. If there are real security issues or operational issues that this draft might cause, then I would love to hear those. But I've spoken with the bind implementors and others and they know how to serve big zones and big records and know how to deal with DOS attacks. They do not see this record as harmful. The latest suggested base32/split for QNAME was suggested to support the issues raised by the email and online signing communities. If you have any specific security concerns about the draft that is not addressed in the security section, let's discuss those on the list(s) and fix it. Paul From nobody Sun Jul 26 03:05:29 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6849E1A1B86 for ; Sun, 26 Jul 2015 03:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAaHZ-P9JwRa for ; Sun, 26 Jul 2015 03:05:25 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FA21A9026 for ; Sun, 26 Jul 2015 03:05:25 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJIo7-0007Aa-6j for ; Sun, 26 Jul 2015 12:05:23 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJImq-000352-GQ; Sun, 26 Jul 2015 12:04:04 +0200 From: Werner Koch To: Vincent Breitmoser References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> <87a8ujoe87.wl-neal@walfield.org> <87zj2j7i34.fsf@littlepip.fritz.box> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Vincent Breitmoser , "Neal H. Walfield" , IETF OpenPGP Date: Sun, 26 Jul 2015 12:04:04 +0200 In-Reply-To: <87zj2j7i34.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Sun, 26 Jul 2015 04:45:03 +0200") Message-ID: <874mkr9qwb.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , "Neal H. Walfield" Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 10:05:27 -0000 On Sun, 26 Jul 2015 04:45, look@my.amazin.horse said: > right next to similar data like "reason for revocation". We should not At the meeting we actually started a discussion to remove those reasons for revocations. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Jul 26 03:05:30 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E023F1A1B86 for ; Sun, 26 Jul 2015 03:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, WEIRD_PORT=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 ArbMZqDInT1x for ; Sun, 26 Jul 2015 03:05:25 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320B91A9029 for ; Sun, 26 Jul 2015 03:05:25 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJIo7-0007Av-Kq for ; Sun, 26 Jul 2015 12:05:23 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJIlD-00034Z-6p; Sun, 26 Jul 2015 12:02:23 +0200 From: Werner Koch To: Vincent Breitmoser References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Vincent Breitmoser , "Neal H. Walfield" , IETF OpenPGP , Daniel Kahn Gillmor Date: Sun, 26 Jul 2015 12:02:22 +0200 In-Reply-To: <874mks7yx1.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Sat, 25 Jul 2015 22:41:30 +0200") Message-ID: <878ua39qz5.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP , "Neal H. Walfield" , Daniel Kahn Gillmor Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 10:05:28 -0000 Hi, the minutes from the Prague meeting have not yet been posted but you can look at them here: http://etherpad.tools.ietf.org:9000/p/notes-ietf-93-openpgp On Sat, 25 Jul 2015 22:41, look@my.amazin.horse said: > I think I disagree with this. It's true that the signature subpacket > namespace is not very large, but the numbers are that only ~30 subpacket subpackets denoted data required for proper operation of the protocol or to implement extra features. I do not consider information of a superceeding key important for the protocol; thus a notation would the right way. > Are there any other standardized uses for the notation namespace? I am > only aware of proposed ones, and none which have very widespread use A small problem with the notations is that you can only use the non-IETF namespace (e.g. using a domain name based name) which make the notation data unnecessary long. At the meeting it was suggested that the process of allocating a new notation in the IETF namespace will be simplified for example by allow expert review. This will make it easier to add new small notions in the future (and perhaps also key flags). Adding new subpackets is a more delicate thing and should definitely not be done "ad-hoc" but using a proper process. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Jul 26 07:38:51 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844331A8949 for ; Sun, 26 Jul 2015 07:38:49 -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 4XMLgFNm8HzJ for ; Sun, 26 Jul 2015 07:38:47 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968A81A89AA for ; Sun, 26 Jul 2015 07:38:46 -0700 (PDT) Received: from localhost (p57B2D2F0.dip0.t-ipconnect.de [87.178.210.240]) by mail.mugenguild.com (Postfix) with ESMTPSA id 74AEF60030; Sun, 26 Jul 2015 16:34:51 +0200 (CEST) References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> <878ua39qz5.fsf@vigenere.g10code.de> From: Vincent Breitmoser To: Werner Koch In-reply-to: <878ua39qz5.fsf@vigenere.g10code.de> Date: Sun, 26 Jul 2015 16:38:34 +0200 Message-ID: <87y4i36l1x.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 14:38:49 -0000 > At the meeting we actually started a discussion to remove those reasons > for revocations. As in, deprecate the subpacket? Or move it towards notation data? Either way I'm in favor of this. > subpackets denoted data required for proper operation of the > protocol or to implement extra features. I do not consider > information of a superceeding key important for the protocol; thus a > notation would the right way. What I would like to avoid is ending up with this as the only defined notation name while stuff like "Policy URI" and "Reason for Revocation" exist as subpackets. Even if notation data is the "right" place to put this, there is at least some value in consistency. That said, I would not mind the superceded-by data as either a subpacket or notation data name. > At the meeting it was suggested that the process of allocating a new > notation in the IETF namespace will be simplified for example by allow > expert review. This will make it easier to add new small notions in > the future (and perhaps also key flags). +1 to this, especially for notations where the meaning is unambiguous (like this case), it would be helpful to have a relatively short assignment process. - V From nobody Sun Jul 26 08:42:12 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0230D1A9250 for ; Sun, 26 Jul 2015 08:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REGHVC4Yfug3 for ; Sun, 26 Jul 2015 08:42:06 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0C81A1BE7 for ; Sun, 26 Jul 2015 08:42:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfT645QfRzD6j; Sun, 26 Jul 2015 17:42:04 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=CkVRsmou X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id X5DtlXVvBxrx; Sun, 26 Jul 2015 17:42:03 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Jul 2015 17:42:03 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 97193800AD; Sun, 26 Jul 2015 11:42:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437925322; bh=4g6RDfKgUzWxUYXIU9PWHhROlZ49xiU+Vj5c6pvTmJY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CkVRsmouM+T+utuKIwlya5tsgtpXV1pOrMOvNLbpR6zgWM1TM7TB8LReDinx5FFEH xUzgvw5+CblQfc3uK2jhb5aNr63Z58DAtp4HrGO/N9WobYFCIY5K607BbKa86w52K/ zkL5rs+ZoGN9wHRyo6zPMBys7/EgF1nvmv5DZQmE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6QFg1WE002698; Sun, 26 Jul 2015 11:42:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 26 Jul 2015 11:42:01 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <87bnf1hair.fsf@alice.fifthhorseman.net> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] The DANE 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: Sun, 26 Jul 2015 15:42:11 -0000 On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: > Agreed. But OpenPGP already has a fairly effective key distribution infrastructure. You mean 3 or so commonly used pgp key servers, with the main MIT one being down for some considerable time recently? I takes about 5 firewall rules for any nationastate to block you from fetching pgp keys. > I am happy to leverage the DNS as one way to validate keys but it can't be the only way. And the way it is designed means it > isn't actually a particularly convenient one. No one saying it must be the only way. How would you design it differently to make it more convenient? We have an easy known QNAME, a dedicated RRtype, a known specified wire format payload of something you can feed straight into any pgp/gpg tool, and a DNS presentation format that is ascii armor format in the same way as the RFC and openpgp tools use themselves. How can I make this more convenient for you? > Yes, every end entity should have their own key. But if all you do is domain validation then the domain owner is alway going > to be able to sign for alice@example.com by publishing a key. Right now with what you call "fairly effective key distribution infrastructure", anyone can make a key for phill@hallambaker.com and publish it there. Limited bogus keys to only those who control the domain you picked based on the people running that domain seems like a great win to me. > Yes, the key servers work. They are deployed. The only reason to replace them would be with something better.  if openpgpkey saw as much usage as for example OTR, these servers would contain millions of bogus keys generated by adversaries. As I said before, it's hard to create infrastructure that's worse than the current key server scheme. > It sounds to me like you're interested in DNSSEC Transparency.  Perhaps > you could take that up in the trans WG?  I know there are other people > interested there (i am!) but this discussion doesn't belong on the > OpenPGP mailing list. > > Yes, I have written a TRANS notary (besides the one Rob wrote). I know the spec. But that is an infrastructure targeted at a > single task and working within a set of rather obnoxious constraints (PKIX). > > Right now, that discussion certainly does not belong in TRANS any more than OpenPGP. I am suggesting we use > therightkey@ietf.org for that sort of discussion. There is currently interest in picking up CT for DNSSEC. One of items that needs discussing is which records to allow in the log. Some of that discussion would definitly be useful on the trans mailing list. Paul From nobody Sun Jul 26 11:21:56 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05E1ACD29 for ; Sun, 26 Jul 2015 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGwvJJOHPWA3 for ; Sun, 26 Jul 2015 11:21:53 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94D01ACD26 for ; Sun, 26 Jul 2015 11:21:52 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so89441687wib.1 for ; Sun, 26 Jul 2015 11:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oIKhURJShg09WwX0UQwMjgkyZnzo5RM/Kjh3RAqcPBU=; b=m9CzAx6ZQOaVA/GTZOwyzW4e6bs5wYbnLaD/EZ2Ilf3iml428Klho23vqpaBtFGnOH N3fMnYcBwj6lAj4XZQPQOQ6KmU+ZK9Y9ejN96ooBBlX8iN2VAohob0V/vr0hsp8Fdatb 9rXtF37/xRNGgUXphcGK64qq7/kYDLYbBmvMZBcwIjoDc6AV/SbybrPMYPHvm437yPz3 gye5lzmJa5bz6j23cBJn235773ZdxU3YfE3gkUT6DYBuf5AFwjN47KBr3nxHoYOp+nFu QpJH0GlaiRrAgRFzGwwhK1rwZPBWPYwPYebNHFPZxaYl6SEwftfA5emu/Lm3QEk1vrG1 xduA== MIME-Version: 1.0 X-Received: by 10.180.80.138 with SMTP id r10mr16072396wix.18.1437934911482; Sun, 26 Jul 2015 11:21:51 -0700 (PDT) Received: by 10.28.155.136 with HTTP; Sun, 26 Jul 2015 11:21:51 -0700 (PDT) In-Reply-To: References: <87bnf1hair.fsf@alice.fifthhorseman.net> Date: Sun, 26 Jul 2015 11:21:51 -0700 Message-ID: From: Watson Ladd To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] The DANE 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: Sun, 26 Jul 2015 18:21:55 -0000 On Sun, Jul 26, 2015 at 8:42 AM, Paul Wouters wrote: > On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: > >> Agreed. But OpenPGP already has a fairly effective key distribution >> infrastructure. > > > You mean 3 or so commonly used pgp key servers, with the main MIT one > being down for some considerable time recently? I takes about 5 firewall > rules for any nationastate to block you from fetching pgp keys. Nationstates can also block DNSSEC resolution without breaking anything. > >> I am happy to leverage the DNS as one way to validate keys but it can't be >> the only way. And the way it is designed means it >> isn't actually a particularly convenient one. > > > No one saying it must be the only way. > > How would you design it differently to make it more convenient? We have > an easy known QNAME, a dedicated RRtype, a known specified wire format > payload of something you can feed straight into any pgp/gpg tool, and > a DNS presentation format that is ascii armor format in the same way as > the RFC and openpgp tools use themselves. How can I make this more > convenient for you? > >> Yes, every end entity should have their own key. But if all you do is >> domain validation then the domain owner is alway going >> to be able to sign for alice@example.com by publishing a key. > > > Right now with what you call "fairly effective key distribution > infrastructure", anyone can make a key for phill@hallambaker.com and > publish it there. Limited bogus keys to only those who control the domain > you picked based on the people running that domain seems like a great > win to me. But no one thinks that the presence of a key on a server is proof of identity. By contrast the whole point of DANE is to use DNSSEC signatures as such proofs. This notion of validity is pretty bad when we consider gmail.com or hotmail.com. The change to the trust model is being smuggled in here under the guise of key discovery, and it's a pretty big change. I don't see how you get the information to use PGP WoT with the keys discovered with DNS except through keyservers. > >> Yes, the key servers work. They are deployed. The only reason to replace >> them would be with something better. > > > if openpgpkey saw as much usage as for example OTR, these servers would > contain millions of bogus keys generated by adversaries. As I said > before, it's hard to create infrastructure that's worse than the current > key server scheme. The question is not how many bogus keys are there. The question is will users use them. > >> It sounds to me like you're interested in DNSSEC Transparency. >> Perhaps >> you could take that up in the trans WG? I know there are other >> people >> interested there (i am!) but this discussion doesn't belong on the >> OpenPGP mailing list. >> >> Yes, I have written a TRANS notary (besides the one Rob wrote). I know the >> spec. But that is an infrastructure targeted at a >> single task and working within a set of rather obnoxious constraints >> (PKIX). >> >> Right now, that discussion certainly does not belong in TRANS any more >> than OpenPGP. I am suggesting we use >> therightkey@ietf.org for that sort of discussion. > > > > There is currently interest in picking up CT for DNSSEC. One of items > that needs discussing is which records to allow in the log. Some of > that discussion would definitly be useful on the trans mailing list. > > > > Paul > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Jul 26 11:51:28 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35931ACD6D for ; Sun, 26 Jul 2015 11:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_ZLoo06m5oD for ; Sun, 26 Jul 2015 11:51:25 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277161ACD69 for ; Sun, 26 Jul 2015 11:51:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mfYJV4n0yzD7t; Sun, 26 Jul 2015 20:51:22 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=YftpJFsB X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Q3I8SO6N6aKL; Sun, 26 Jul 2015 20:51:21 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Jul 2015 20:51:21 +0200 (CEST) Received: from [192.168.10.222] (unknown [62.209.224.147]) by bofh.nohats.ca (Postfix) with ESMTPSA id E797D80042; Sun, 26 Jul 2015 14:51:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1437936680; bh=Ddsf5V1HvALxxfWKeAp6siZwBLmSc5wSnVBk6+yvz74=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=YftpJFsBkbG/QTUyFjdR6qwhynOQ/5OHt81MZVWfp5h+6BK2VG4x3aKiLVspAuEkK gx91YYE7fMuhNXXvZxIaeOcOZgS/BkRg33m4L+C5Lqi7Qx4AO2TlBQe+rZmvacxqCQ J6q7taU6YKfrhXSrQBSIEgViustX7eXcfwg+oyto= References: <87bnf1hair.fsf@alice.fifthhorseman.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2AB3B153-D594-46B2-B1F8-1A6A49ABC51B@nohats.ca> X-Mailer: iPhone Mail (13A4305g) From: Paul Wouters Date: Sun, 26 Jul 2015 20:51:16 +0200 To: Watson Ladd Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] The DANE 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: Sun, 26 Jul 2015 18:51:26 -0000 Sent from my iPhone >=20 > Nationstates can also block DNSSEC resolution without breaking anything. Then at least you have a confirmation you are under attack, unlike a non-res= ponsive http(s) connection. And economic pressure prevents nation states from fully blocking things like= IPsec VPNs - I would hope DNSSEC would share that fate in the future. From nobody Sun Jul 26 23:25:27 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9A1A8A6D for ; Sun, 26 Jul 2015 23:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIQdzzWqyxR1 for ; Sun, 26 Jul 2015 23:25:24 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0871A8A68 for ; Sun, 26 Jul 2015 23:25:24 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJbqk-0002Im-TI for ; Mon, 27 Jul 2015 08:25:22 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJbnj-0005cV-D9; Mon, 27 Jul 2015 08:22:15 +0200 From: Werner Koch To: Vincent Breitmoser References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> <878ua39qz5.fsf@vigenere.g10code.de> <87y4i36l1x.fsf@littlepip.fritz.box> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Vincent Breitmoser , IETF OpenPGP Date: Mon, 27 Jul 2015 08:22:14 +0200 In-Reply-To: <87y4i36l1x.fsf@littlepip.fritz.box> (Vincent Breitmoser's message of "Sun, 26 Jul 2015 16:38:34 +0200") Message-ID: <87mvyi86i1.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 06:25:26 -0000 On Sun, 26 Jul 2015 16:38, look@my.amazin.horse said: > As in, deprecate the subpacket? Or move it towards notation data? The discussion was around the idea to deprecate the use of the reason for revocation because it is pretty complicated to make real use of it due to non-easy semantics. > exist as subpackets. Even if notation data is the "right" place to put > this, there is at least some value in consistency. We can't avoid all inconsistencies created in the past or inherited from existsing implementaions. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Jul 26 23:50:28 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1751ACE1D for ; Sun, 26 Jul 2015 23:50: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 7Ju338EpqR4t for ; Sun, 26 Jul 2015 23:50:24 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259041ACE1C for ; Sun, 26 Jul 2015 23:50:24 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJcEw-0002g6-Gc for ; Mon, 27 Jul 2015 08:50:22 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJcEL-0005g5-1d; Mon, 27 Jul 2015 08:49:45 +0200 From: Werner Koch To: Paul Wouters References: <87si8dagiz.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Paul Wouters , Phillip Hallam-Baker , IETF OpenPGP , dane WG list Date: Mon, 27 Jul 2015 08:49:44 +0200 In-Reply-To: (Paul Wouters's message of "Sun, 26 Jul 2015 05:11:02 -0400 (EDT)") Message-ID: <87io968587.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Phillip Hallam-Baker , dane WG list , IETF OpenPGP Subject: Re: [openpgp] [dane] The DANE 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, 27 Jul 2015 06:50:25 -0000 On Sun, 26 Jul 2015 11:11, paul@nohats.ca said: > X.509 parsers where not needed. If you don't think X.509 is a problem, > then you haven't been paying attention to CVE's. There is a lot more X.509 code in use than OpenPGP code and thus it might be unfair to compare CVE counts. But sure, BER encoding along with all bug compatibility stuff is a mess. > Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of > that do PKIX. And it would be good not to add new ones just because we Do it on gpgsm and dirmngr and you will find libksba [1] which provides the X.509 and CMS parser and builder. gpgsm does high level processing including validation and dirmngr takes care of CRLs and OCSP. > I also find it _really_ ironic that it is not the openpgp key servers > that you are calling "vast, aging and vaguely understood infrastructure" > because if anything is a dangerous misunderstood mess that we cannot > seem to clean up, it is the current electronic garbage heap of pgp > keys we can never clean up because the owners lost their keys or We do not want to clean that up - there is and should be no need to ever delete a public key from a public server. Unfortunatly the keyservers are also the only working solution to map mail addresses to keys/fingerprints. This is the practical problem we need to solve - not the public storage of the keys. > the keys were generated and uploaded by those not actually being the > real owners of those email address specified in the openpgp key id. What is an "owner" of a mail address? Definitely nothing a keyserver has to decide. > It is _really_ difficult to design any other method of openpgp key > distribution that would be _worse_ than the current key servers. Nope. As I menotioned: distribution is not the problem. Association of mail addresses to keys is the problem because the WoT does not really scale. > And this is an actual real problem. There is no valid reason for needing > to "work around" an experimental proposal that has a significant backing > of people in the IETF, the mail community and opensource software Experimental? I might be confused but draft-ietf-dane-openpgpkey-03 states Standards Track and Intended Status. Salam-Shalom, Werner [1] KSBA = rot13("XFON") // X-Five-O-Nine -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Jul 27 00:00:27 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CA11ACE1D for ; Mon, 27 Jul 2015 00:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kbm8XFGF74H for ; Mon, 27 Jul 2015 00:00:25 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063191ACE1C for ; Mon, 27 Jul 2015 00:00:25 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJcOd-0002ub-5R for ; Mon, 27 Jul 2015 09:00:23 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJcMB-0005iT-0F; Mon, 27 Jul 2015 08:57:51 +0200 From: Werner Koch To: Paul Wouters References: <87bnf1hair.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Paul Wouters , Phillip Hallam-Baker , IETF OpenPGP , Daniel Kahn Gillmor Date: Mon, 27 Jul 2015 08:57:50 +0200 In-Reply-To: (Paul Wouters's message of "Sun, 26 Jul 2015 11:42:01 -0400 (EDT)") Message-ID: <87egju84up.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Phillip Hallam-Baker , Daniel Kahn Gillmor , IETF OpenPGP Subject: Re: [openpgp] The DANE 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, 27 Jul 2015 07:00:26 -0000 On Sun, 26 Jul 2015 17:42, paul@nohats.ca said: > You mean 3 or so commonly used pgp key servers, with the main MIT one > being down for some considerable time recently? I takes about 5 firewall > rules for any nationastate to block you from fetching pgp keys. Huh? The main pool currently as 105 active servers; 108 are not currently qualified due to operation problems or not enough sync sites. See https://sks-keyservers.net/status/ pgp.mit.edu is just fine if you don't mind that it runs only on legacy IP. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Jul 27 01:05:19 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9691AD09D for ; Mon, 27 Jul 2015 01:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CkXIjLCMXv6 for ; Mon, 27 Jul 2015 01:05:15 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AC21ACE0A for ; Mon, 27 Jul 2015 01:05:15 -0700 (PDT) Received: by lblf12 with SMTP id f12so48025181lbl.2 for ; Mon, 27 Jul 2015 01:05:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Dehiw70j6lW732aGiYJdVlnNnKksu2wE45SIhOpPMUI=; b=kRK1AqyZ+dcYpP3VmtgT9ZYLzG8uBLERFmDIVhfFxa+ZLs82mew9/uSQ7mf5saDpPx hd/OIUdDMIkpK0uP5xWNmkjELt3Nq0C4yLco0KZSDTpEKrS2t+8/CW0OTvBiJUy1ieDY jPi5Th7wFtJaesDkICqV2ByYA0hNySQHJe+Rtmc/kCTD4pPPGzPbFI9q+qpqlICoP52+ XBqQKk93uw50GbO/aNdpa2QG5uakFN8uD7EpmqDifEPVj/TD9UNVGW9STz0TWE4aB+U4 UgXpQhn5vPSq5brK6eFY7xiz7pfM8B+8/fR8r/MQuGR1cfvj6Ch8LDU0Q4UfEoMDct95 TR3Q== X-Gm-Message-State: ALoCoQlgLrnAZHnbFuvuuoIpOafI6tN/+tZOOGMJANv098NRFuZ/oyFA2HAhZwfXrDq/5dhR5Lkt X-Received: by 10.112.166.106 with SMTP id zf10mr25706027lbb.36.1437984313361; Mon, 27 Jul 2015 01:05:13 -0700 (PDT) Received: from [172.20.10.2] (2.150.32.140.tmi.telenormobil.no. [2.150.32.140]) by smtp.googlemail.com with ESMTPSA id ph4sm3764744lbb.3.2015.07.27.01.05.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 01:05:12 -0700 (PDT) To: Werner Koch References: <87wpxvjf9d.wl-neal@walfield.org> <87d1zmlv3p.fsf@vigenere.g10code.de> <87twsyk35z.wl-neal@walfield.org> <87y4i9je9f.fsf@alice.fifthhorseman.net> <87h9osnswg.wl-neal@walfield.org> <874mks7yx1.fsf@littlepip.fritz.box> <878ua39qz5.fsf@vigenere.g10code.de> <87y4i36l1x.fsf@littlepip.fritz.box> <87mvyi86i1.fsf@vigenere.g10code.de> From: Kristian Fiskerstrand Message-ID: <55B5E5E0.1090506@sumptuouscapital.com> Date: Mon, 27 Jul 2015 10:03:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <87mvyi86i1.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF OpenPGP , Vincent Breitmoser Subject: Re: [openpgp] Revoking Keys: Adding a superceded-by parameter X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 08:05:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07/27/2015 08:22 AM, Werner Koch wrote: > On Sun, 26 Jul 2015 16:38, look@my.amazin.horse said: > >> As in, deprecate the subpacket? Or move it towards notation >> data? > > The discussion was around the idea to deprecate the use of the > reason for revocation because it is pretty complicated to make real > use of it due to non-easy semantics. I can think of at least one specific use case where this information is needed. I'm somewhat ambivalent to whether this is given as specific subpacket or a notation; if we were to implement it again the latter would make sense, but not sure if it is worthwhile breaking backwards compatibility for deprecating it. Anyways, the use case is you have a revocation certificate as part of the will and a copy is stored with the executor. The reason for revocation states "This key is revoked by the Power of Attorney granted to the executor of the Last Will and Testament of Y", and likely contains a version identifier to be able to trace any non sanctioned use. Obviously you wouldn't give your attorney a copy of your private key, but you do want them to be able to follow the instructions for revoking and notifying the appropriate channels in the event a stone falls in the back of your head. The reason for revocation in this case at least should be a good indicator to other holders of the key about the situation and provides valuable information. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Aut disce aut discede Either learn or leave -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJVteXcAAoJECULev7WN52FHKgH/0bi2Ezq1ls9DOU/Qq748p0/ 44BcT5PC97X1uaqTkHV7pcb7azS5FUfnwdLIzy6wfWhce4L2jOqqho+sWl6Nq93G LYMPsCFYRvGCu/+oOU2K0BDb3nT5azL0U94nQUQEreDLssl0R2MyrIcNApZZVyf4 9oP0Fjxy/5hIoPpAmri1JVvHLuC6G833h/MEo864bMNvV/cTh+VwwFVlCX+nKRR8 3dzzfD5l691ri/I9pZ5s7EhDo0KlqidUmv1VzLr0mkei7hWPKwUzy//308CkWO9w Qh4YfOt20CFgtkKv/o0SM9NR8jlDWGBpjRCege1w+j3h19eS7oYbXbLqfWerKwY= =9+ie -----END PGP SIGNATURE----- From nobody Mon Jul 27 05:43:36 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02F1B2CB2; Mon, 27 Jul 2015 05:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpqHQ5YSQqi4; Mon, 27 Jul 2015 05:43:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6646B1B2CD1; Mon, 27 Jul 2015 05:43:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mg15X6r3CzDCl; Mon, 27 Jul 2015 14:43:28 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=VLrzlacm X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SycHWEtnp6bx; Mon, 27 Jul 2015 14:43:26 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 27 Jul 2015 14:43:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6D287800AD; Mon, 27 Jul 2015 08:43:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1438001005; bh=YioIGapDPO7ZEYDV4NIK2MOFVnKE7zy0GLwuxwhUALI=; h=Date:From:To:cc:Subject; b=VLrzlacmf9pB9fsJmLrlIKId2nLkHFTEvTyLVO6cM250+3QGBySoGZjkQPyu3ZyGf chIORak3yw6Lt8+4dp5YAgsdrW/E2shq+r6lp/SkfK/xBnckVWHX4wpfQTO1qLlg/g OQvFT19ljSGwmYIxinxSCFF56g/Een1EvCja++sI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6RChOSp030088; Mon, 27 Jul 2015 08:43:25 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 27 Jul 2015 08:43:24 -0400 (EDT) From: Paul Wouters To: Werner Koch Message-ID: User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] key distribition and IETF document status X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 12:43:35 -0000 On Mon, 27 Jul 2015, Werner Koch wrote: >> I also find it _really_ ironic that it is not the openpgp key servers >> that you are calling "vast, aging and vaguely understood infrastructure" >> because if anything is a dangerous misunderstood mess that we cannot >> seem to clean up, it is the current electronic garbage heap of pgp >> keys we can never clean up because the owners lost their keys or > > We do not want to clean that up - there is and should be no need to ever > delete a public key from a public server. Then you really need better tools that filter out bogus and older keys, if this has to work for average users. One of my old keys uses idea which most people couldn't even use if they fetched the older instead of newer key. >> the keys were generated and uploaded by those not actually being the >> real owners of those email address specified in the openpgp key id. > > What is an "owner" of a mail address? Definitely nothing a keyserver > has to decide. right. But at least with DNSSEC, at this moment, you know that no one can publish OPENPGPKEY records for paul@nohats.ca except those who run nohats.ca. That's already a lot more pinned down then the current key servers. If you say people can manually pick out the latest key to avoid using my old expired or forgotten keys, than it makes people more vulnerable to recently added bogus keys by others. Which is why I think this is the worst distribution/discovery mechanism. >> And this is an actual real problem. There is no valid reason for needing >> to "work around" an experimental proposal that has a significant backing >> of people in the IETF, the mail community and opensource software > > Experimental? I might be confused but draft-ietf-dane-openpgpkey-03 > states Standards Track and Intended Status. I will double check with the chairs what conclusion was reached on this. I thought at the ietf92 in Dallas it was thought to become Experimental. > Nope. As I menotioned: distribution is not the problem. > Huh? The main pool currently as 105 active servers; 108 are not > currently qualified due to operation problems or not enough sync sites. > See > > https://sks-keyservers.net/status/ > > pgp.mit.edu is just fine if you don't mind that it runs only on legacy > IP. There might be 100 of those, but those using the tools can't just let the tools find them, so if I'm on the wrong side of the Great Firewall, the only names I know of servers to use would be pgp.mit.edu, keys.pgpi.net (is that still alive even?) or pgp.surfnet.nl. for example, gpg fails: [paul@thinkpad ~]$ gpg --recv-key 0x12345678 gpg: requesting key 0x12345678 from hkp server search.keyserver.net gpgkeys: HTTP fetch error 6: Could not resolve host: search.keyserver.net So from a practical point of view, for newbies there are 0 key servers and for those who were around during Crypto War I, there are two or three key servers. Until today, I had not even heard of sks-keyservers.net, and I'm probably a long term, better than average informed security user. So in my view, distribution is a very big problem the current key servers and tools are not handling well. Note that I checked enigmail and it does seem use pool.sks-keyservers.net (also, apparently it had two different keys with ID 0x12345678) I know John Gilmore also had additional patches for gnupg to assist with keyring discovery in the same LAN, aimed at keysigning parties, but those patches were apparently reject and he has given up on this project. Having been at too many failed key signing parties, that makes me sad. Related pet peeves: you cannot use --recv-key 0x12345678 --keyserver pool.sks-keyservers.net (the order matters) I'm not smart enough to remember if it is --keyserver or --key-server or --keyservers or --key-servers, or --recvkeys or --recv-keys or --recvkey or --recv-key. Some aliases would be really nice here. Paul From nobody Mon Jul 27 06:50:34 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8C11B2DB1 for ; Mon, 27 Jul 2015 06:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJao2jKetm2z for ; Mon, 27 Jul 2015 06:50:24 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8511C1B2DA9 for ; Mon, 27 Jul 2015 06:50:24 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZJinO-0002pd-Gb for ; Mon, 27 Jul 2015 15:50:22 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZJimd-0006mo-Im; Mon, 27 Jul 2015 15:49:35 +0200 From: Werner Koch To: Paul Wouters References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Paul Wouters , IETF OpenPGP , dane WG list Date: Mon, 27 Jul 2015 15:49:35 +0200 In-Reply-To: (Paul Wouters's message of "Mon, 27 Jul 2015 08:43:24 -0400 (EDT)") Message-ID: <87mvyh7lsg.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF OpenPGP , dane WG list Subject: Re: [openpgp] key distribition and IETF document status X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 13:50:28 -0000 On Mon, 27 Jul 2015 14:43, paul@nohats.ca said: > Then you really need better tools that filter out bogus and older keys, > if this has to work for average users. One of my old keys uses idea NO! There a no bogus keys. It is a desirable feature that you can't remove the keys. If you want to revoke a key or user id you upload a copy of the key with the revocation certificiate. > right. But at least with DNSSEC, at this moment, you know that no one > can publish OPENPGPKEY records for paul@nohats.ca except those who run > nohats.ca. That's already a lot more pinned down then the current key Right and it is a Good Thing. I proposed that 9 years ago [1]. > There might be 100 of those, but those using the tools can't just let > the tools find them, so if I'm on the wrong side of the Great Firewall, > the only names I know of servers to use would be pgp.mit.edu, The example from gpg's conf file template is hkp://keys.gnupg.net which is just a CNAME for the mentioned pool.sks-keyservers.net. > [paul@thinkpad ~]$ gpg --recv-key 0x12345678 > gpg: requesting key 0x12345678 from hkp server search.keyserver.net keyserver.net is a proprietary keyserver services from a Belgian(?) company. I was not aware that this server still exists; it is/was also not synced with the regular keyserver network.=20 > three key servers. Until today, I had not even heard of > sks-keyservers.net, and I'm probably a long term, better than average SKS has replaced Marc's keyserver ~12 years ago. Bascially all sites are using it and perhabs keys.pgp.mit was the last to switch a few years ago. The old commonly pool used to be subkeys.pgp.net. For some time keys.gnupg.net ran its own pool but eventually it switched to the well maintained sks-keyservers.net pool. > Note that I checked enigmail and it does seem use pool.sks-keyservers.net > (also, apparently it had two different keys with ID 0x12345678) Always use the long keyid - there are less duplicates. And of course using the fingerprint is the canonical right way of specifiying keys. > I know John Gilmore also had additional patches for gnupg to assist > with keyring discovery in the same LAN, aimed at keysigning parties, but > those patches were apparently reject and he has given up on this project. We talked about that but he did not send any patches and iirc he gave up on this. gpg's new --quick-* commands have been implemented on his request. > you cannot use --recv-key 0x12345678 --keyserver pool.sks-keyservers.net > (the order matters) gpg's requires that option come before other arguments (classic Unix style, partly done this way for compatibility with pgp 2). Thus the above is equivalent to gpg --recv-key -- 0x12345678 --keyserver pool.sks-keyservers.net and --keyserver is thus not considered an option.=20=20=20 > I'm not smart enough to remember if it is --keyserver or --key-server or $ gpg --dump-options | grep keyserv --keyserver --keyserver-options --sig-keyserver-url --default-keyserver-url Shalom-Salam, Werner [1] W. Koch, =E2=80=9CPublic key association,=E2=80=9D in GUUG Fr=C3=BChjah= rsfachgespr=C3=A4che 2006: Proceedings. K=C3=B6ln, Germany: GUUG, 2006, pp. 159=E2=80=93167. [Online]. Available: http://g10code.com/docs/pka-intro.de.pdf --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Jul 27 08:03:07 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621931B2E68; Mon, 27 Jul 2015 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6JPPif3KBB2; Mon, 27 Jul 2015 08:02:59 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400641B2E66; Mon, 27 Jul 2015 08:02:58 -0700 (PDT) Received: by lblf12 with SMTP id f12so55446519lbl.2; Mon, 27 Jul 2015 08:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=bsGt2pWZQfB36Ye2jJ0b83oYi0Qrl1agbnWlT000qvk=; b=p+lFYJTQga38NgYAbxfVYiPjoZxqVZfQNy11MtoMbu/77AJkhvzOYbshVNPQcp7MvA kbYqmoYGZA6PUngIytRw5hBm2G5SzmRg+BtF3QXk02PS13sFZAM/F8VyxDopmCQopLCb 0lBUnJFGEAUJG1C+9Q4NzEROGNuuNdE/F6zf9uff1uVJNQ8Uihvxw5IOLfrG6tbouBeb ulrymgpX5OYPF/FHtOv3IcPIoPoJtKZbbT58th2CbfJA1bKEwM1HXkX1EPhPl4v2PaFc ExJtnOrUofJh28lJdhiIH0HcpVFzQ6ewr5zvuehRioAhpsa9vpGU6RcYF+7lCn1JNpd7 QN0w== MIME-Version: 1.0 X-Received: by 10.112.167.202 with SMTP id zq10mr26883850lbb.118.1438009376670; Mon, 27 Jul 2015 08:02:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 27 Jul 2015 08:02:56 -0700 (PDT) Date: Mon, 27 Jul 2015 11:02:56 -0400 X-Google-Sender-Auth: QqitSSf4Sy6cupiISgMnZKA_hvc Message-ID: From: Phillip Hallam-Baker To: "therightkey@ietf.org" , IETF OpenPGP , "dane@ietf.org" , smime@ietf.org Content-Type: multipart/alternative; boundary=001a11c269c2148aae051bdca6ef Archived-At: Subject: [openpgp] Using composite PKIs X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 15:03:01 -0000 --001a11c269c2148aae051bdca6ef Content-Type: text/plain; charset=UTF-8 [Followups on therightkey please] Thinking about the discussion of the OpenPGP/DANE draft in OpenPGP in my car, I came up with a metaphor for how to approach joining different PKIs. In particular, Werner's comment that Web of Trust doesn't scale. The CA model does scale but it isn't actually much better when trying to identify private individuals rather than employees of a company since the only thing I can validate economically is an email address and that isn't a person. We can approach the problem mathematically by considering the work factor (in US$) for causing a breach. Combining Web of Trust with CA approaches and interning the assertions in an immutable blockchain like log does provide an approach that scales. The blockchain makes the workfactor time dependent. If the workfactor is $100 before an assertion is enrolled, it will be $trillions after. Combining Web of Trust and CA trust is like building a dalek out of fiberglass: Individually, the glass fiber and the epoxy are weak. But using the two in combination locks the strands of glass fibre creating a lightweight shell that can support the weight of a small truck. This part is already written up: https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/ The question we are facing now is how we make sense of that type of data. Which is where the car trip comes in. I am using GPS to navigate a part of the city I don't know very well. There are multiple resources at my disposal: 1) My own knowledge of the area 2) Signposts on the road 3) The GPS maps in the car 4) Offline maps via my cell phone Any one of these guides can be fallible. The GPS maps are pre big-dig (no CANBUS modem car for me) so they are out of date. Offline maps are more likely to be up to date but a malicious provider can direct specific individuals to the wrong place. The fact that there is a human in the loop actually keeps the mapping service providers accountable. Even if 99% of drivers don't know where they are going. The fact that there are roadsigns and the fact that a few do know where they are going means that if the service defects, they are likely to be caught. Using a pure online mapping service like Google Maps and a thin client means that I am always up to date but exposes all my movements to them. It also breaks if I am in Prague on a crappy AT&T data plan costing $20/Mb for international roaming. [Do the AT&T execs consider the semiotics of sending their customers a text message saying 'we are going to try to steal from you now' every time they cross an international border. Using a pure offline map like the DVDRom based system in the Honda means that nobody can track me by my use of a mapping service. It also means that the maps are ten years out of date as I don't plan on replacing the van till the child whose car seat it was built to fit has learned to drive and won't trash the transmission. The best map I have is actually an application on the phone that has downloadable maps for the whole of Europe and North America. The mapping service obviously preprocesses the maps so that the phone has as little work to do as possible. So it is a 'thick client' but not as thick as it might be. I think the key to making a composite PKI work is to approach the problem in a similar fashion. In the short term we want to be using the 'thin client' as this allows us to change how we analyze data and add new formats. When trying to develop a new protocol, agility is key. But the medium term goal is to have a thick-ish client. --001a11c269c2148aae051bdca6ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Followups on therightkey please]

Think= ing about the discussion of the OpenPGP/DANE draft in OpenPGP in my car, I = came up with a metaphor for how to approach joining different PKIs. In part= icular, Werner's comment that Web of Trust doesn't scale. The CA mo= del does scale but it isn't actually much better when trying to identif= y private individuals rather than employees of a company since the only thi= ng I can validate economically is an email address and that isn't a per= son.

We can approach the problem mathematically by= considering the work factor (in US$) for causing a breach.

<= /div>
Combining Web of Trust with CA approaches and interning the asser= tions in an immutable blockchain like log does provide an approach that sca= les. The blockchain makes the workfactor time dependent. If the workfactor = is $100 before an assertion is enrolled, it will be $trillions after.=C2=A0=

Combining Web of Trust and CA trust is like build= ing a dalek out of fiberglass: Individually, the glass fiber and the epoxy = are weak. But using the two in combination locks the strands of glass fibre= creating a lightweight shell that can support the weight of a small truck.= This part is already written up:



The question we are facing now is how we ma= ke sense of that type of data. Which is where the car trip comes in.
<= div>
I am using GPS to navigate a part of the city I don'= t know very well. There are multiple resources at my disposal:
1) My own knowledge of the area
2) Signposts on the = road
3) The GPS maps in the car
4) Offline maps via my = cell phone

Any one of these guides can be fallible= . The GPS maps are pre big-dig (no CANBUS modem car for me) so they are out= of date. Offline maps are more likely to be up to date but a malicious pro= vider can direct specific individuals to the wrong place.

The fact that there is a human in the loop actually keeps the mappi= ng service providers accountable. Even if 99% of drivers don't know whe= re they are going. The fact that there are roadsigns and the fact that a fe= w do know where they are going means that if the service defects, they are = likely to be caught.

Using a pure online mapping s= ervice like Google Maps and a thin client means that I am always up to date= but exposes all my movements to them. It also breaks if I am in Prague on = a crappy AT&T data plan costing $20/Mb for international roaming. [Do t= he AT&T execs consider the semiotics of sending their customers a text = message saying 'we are going to try to steal from you now' every ti= me they cross an international border.

Using a pur= e offline map like the DVDRom based system in the Honda means that nobody c= an track me by my use of a mapping service. It also means that the maps are= ten years out of date as I don't plan on replacing the van till the ch= ild whose car seat it was built to fit has learned to drive and won't t= rash the transmission.

The best map I have is actu= ally an application on the phone that has downloadable maps for the whole o= f Europe and North America. The mapping service obviously preprocesses the = maps so that the phone has as little work to do as possible. So it is a = 9;thick client' but not as thick as it might be.


I think the key to making a composite PKI work is to appr= oach the problem in a similar fashion. In the short term we want to be usin= g the 'thin client' as this allows us to change how we analyze data= and add new formats. When trying to develop a new protocol, agility is key= . But the medium term goal is to have a thick-ish client.
--001a11c269c2148aae051bdca6ef-- From nobody Mon Jul 27 09:07:15 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D621ACE23 for ; Sat, 25 Jul 2015 05:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPV81mAzdP8b for ; Sat, 25 Jul 2015 05:50:45 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63C91AC41C for ; Sat, 25 Jul 2015 05:50:44 -0700 (PDT) Received: from smtp5.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4BFA1801F7; Sat, 25 Jul 2015 08:50:43 -0400 (EDT) Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id C2F5D801F5; Sat, 25 Jul 2015 08:50:39 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Sat, 25 Jul 2015 12:50:43 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Olafur Gudmundsson In-Reply-To: Date: Sat, 25 Jul 2015 08:50:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39995A26-5F1B-4DFF-9030-9743A7A83EC8@ogud.com> References: <87si8dagiz.fsf@vigenere.g10code.de> To: Paul Wouters X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 09:07:15 -0700 Cc: Werner Koch , Phillip Hallam-Baker , dane WG list , IETF OpenPGP Subject: Re: [openpgp] The DANE 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: Sat, 25 Jul 2015 12:50:48 -0000 > On Jul 25, 2015, at 8:19 AM, Paul Wouters wrote: >=20 > On Fri, 24 Jul 2015, Werner Koch wrote: >=20 > PHB wrote: >=20 >>> 2) If people find it does not meet OpenPGP needs, they should say so = and >>> have no qualms about objecting. It is much more important that there = be a >>> spec people use than that the document progress quickly. >=20 > This document has not progressed "quickly". The original draft was > published in July 2013. No one is trying to rush this through. >=20 >> I was a bit disappointed by the process: I learned about the I-D too = late >> and was surprised that it started out at the OpenPGP WG mailing list = (2 >> years ago?) with just a few messages and then continued at the DANE = list >> without having notified the OpenPGP list. >=20 > This is now the fourth time I am having this discussion with you, so I > think your representation is not entirely fair. The previous = discussions > ended with you saying we should not do this and stick to the CERT = record > type and me stating why I disagree with that view. >=20 >> IIRC, I send some thoughts on >> this to the GnuPG list but people told me that it is too late for >> changes to the I-D - so I gave up. >=20 > That is not a fair representation of what happened. I have told you on > the openpgpkey, on the dane list and in private emails why we do not > want to use the CERT record. It is fine to disagree with that, but the > reason for not going back to CERT have nothing to do with timing. It > is never too late to say a certain draft has no merit and should be > shot or majorly changed. I am sorry if our previous communication did > not make that clear. >=20 >> Here are some thoughts, anyway: >>=20 >> - Why a new DNS record despite that the CERT type has PGP support for >> 9 years now (RFC-4398). >>=20 >> The argument for a new record is that this makes parsing easier >> because there is no need to loop over the record's sub-types. I do >> not consider it a valid argument because there is a need to loop >> anyway because there may be several DANE records for the same key. >> Adding an extra loop over the sub-types is a non-brainer and the >> selection logic to find the best matching record will be the same. >=20 > Using subtypes for DNS is something the DNS people in general have > concluded to be a wrong idea. As stated before, even Olafur who is one > of the authors of the CERT RRtype advised us not to use CERT (or > subtyping in general) I want to strongly support this point, Bulk container records like CERT = have been shown to be a bad idea is=20 every time they get used in DNS. Lets learn from experience.=20 > Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. +1=20 >=20 >> The CERT record is more flexible because it also allows the use of an >> indirect specification via fingerprint. >=20 > Which is a problem not a feature. It makes the security model very > complex. Specifying a fingerprint and a URI that could be http or = https > reduces the security of the key to the strength of the fingerprint. > Did we not already ran into issues in older (v3?) keys on this issue? > Adding a level of indirection where not required does reduce the > security. >=20 > If using https, it adds back a whole trust mechanism of CA's, or it > confusingly will ignore the CAs involved in the transaction. >=20 > If the http(s) service is blocked by an attacker, it is = indistinguishable from > a regular outage. >=20 > Putting the keys into DNS without indirection avoids all these = problems. > I know the CERT could also store the entire certificate, but this > difference then has to be explained to the user, and that is way too > complicated. Compare: >=20 > "The user you are trying to mail has published their OpenPGP key in = DNS, > do you wish to use this key to encrypt this email?" >=20 > versus: >=20 > "The user you are trying to mail has published their OpenPGP > key fingerprint in DNS and the key was obtained over HTTP(S) on > anothersite.com whose certificate was validated by ACME inc. Do > you wish to use this key to encrypt this email?" >=20 > And the additional: >=20 > "The user you are trying to mail has published their OpenPGP > key fingerprint in DNS but the URI resource anothersite.com appears > to be down. do you wish to postpone this email or send it > unencrypted?" >=20 >> GnuPG has support for such CERT records including a script to create >> them also for about 9 years. It is not widely used because most = users >> have no way to add records to their zone - that is the same problem >> for DANE of course. >=20 > CERT wasn't widely used because frankly pgp is not widely used. Also, > CERT without DNSSEC makes no sense, and we are only seeing DNSSEC > protected application data being deployed recently in the last few > years only. We now see small email providers adding webgui elements > for their users to upload their pgp key to publish in DNS. So I do > believe we are seeing an uptake in "pgp keys from dns". Of course > this has no relation to the CERT vs OPENPGPKEY format question. >=20 >> - The I-D says about the local-part of the mail address: >=20 > The I-D was left unchanged at the request of the chairs. The intention > right now is to use a base32 encoding split on 60 character labels. Dane WG (which I co-chair) is trying to settle this issue by the end of = July=20 so if you have a comment please state it there.=20 >=20 >> ... it is turned into lowercase and hashed using the SHA2-256 >> [RFC5754] algorithm, with the hash truncated to 28 octets ... >>=20 >> Lowercasing UTF-8 characters is not easy and a likely reasons for >> interoperability problems. It would be better to only require >> lowercasing ASCII characters and keep characters > 127 as they are. >=20 > Yes, that was discussed on the dane list and after consultation with > internationalised email address experts, this same conclusion was > reached. I am not sure if we actually reached consensus about the > lowercase vs using a second DNS lookup for lowercase if the first > query fails to find a record. The argument here is that a client > should not "guess" that Paul@nohats.ca is the same as paul@nohats.ca, > but there does seem to be concensus that in practise these are the > same and it should be supported either through a lowercase before > base32 (for ASCII only) or be allowing the client to try both as > base32 lookups. One of the main reasons here is that virtual keyboards > and web form fields often automatically capitalise recognised names, > and otherwise we would need to add two records (Paul and paul) for > each LHS side. >=20 >> - There is no hint in the RFC on how to find a key to verify a >> signature. This can't be done via a mail address but requires the >> fingerprint (or as of today the key-id). >=20 > The draft is about finding keys based on email address. It is not = meant > to be the global keyserver bag for all keyids or fingerprints. If you > only have a keyid and nothing else, the DNS hierarchy cannot help you. >=20 > But perhaps the openpgp group can extend the signature format allowing > the inclusion of an ID so this could be possible in the future? As Paul says this is about connecting a one form of ID to a OPENPGP key=20= this can be used as additional method.=20 As a matter of fact the reason I stopped using PGP many years ago was = the difficulty in discovering someone=E2=80=99s else PGPkey, in particular there was no = way to look up based on the handles I had.=20 >=20 >> - How shall a key be retrieved or updated after a mail account has = been >> closed? It should be possible to verify signatures at all times. >=20 > Why should that be possible? In fact, the key could be compromised so > it might lead to the wrong actions if you verified the signature. >=20 > The OPENPGPKEY draft specifies one method of finding a key. What you > do with it, or what the lifetime of such a key or its signatures > are is completely out of scope of this key discovery mechanism. >=20 > If we want to specify those kind of usage scenarions, we can revive > the openpgpkey-usage draft document. But I fear everyone has their > own local policies on these. >=20 I asked the same questions and came to the following conclusion: OPENPGP via DANE/DNSSEC verification SHOULD be done when the email is = received and that information should be stored with the message. DNS lookup of a key via the method specified here provides a binding at = particular point in time.=20 For the email provider it is her choice to remove the key or revoke the = key, the net effect is the same=20 they key is not available for use after that action.=20 How this is done is depends on the software that validates the message.=20= >> Thus another non DNS service to keep the key available needs to be >> setup too (e.g. a keyserver). This is the core difference between the way Certificate world thinks and = how DNS world behaves.=20 DNS is and answer at particular point in time. Either the data exists or = does not exist. No history at all. Removal of OPENPGP is almost a revocation, addition is = =E2=80=9Cpublication=E2=80=9D.=20 >=20 > I disagree. If the email was sent while the mail account was still > operational with OPENPGPKEY, you should have fetched and stored the > key then. If the account is closed and you don't have a copy of the > key, than that is your problem. If you want to have some kind of > global key store for all keys ever issued, then I guess you could > look at something like "transparency" for openpgp keys. But that > is a out of scope for this document, just as me sending you a key > without any advertising on any public key server resource and > then closing my mail account is. >=20 >> dissemination of revocation certificates. IPGP records could be kept >> as long as the mail address has not been re-assigned. >=20 > Again, that seems like a "transparency" issue. The issue of losing > control of your email address, and someone else generating a new key > for that email address and advertising thism, whether in DNSSEC or > on keyservers, in an attempt to get encrypted email intended for you, > is really not in scope here either. It might be in scope for the > openpgpkey-usage document, but it seems to me to be a more generic > openpgp issue, so perhaps would be better in the openpgp bis document > or elsewhere. (and of course this would be no different with CERT > records in DNS) >=20 >> - Implementation nit: The I-D states: >>=20 >> The lookup result MUST pass DNSSEC validation; if validation >> reaches any state other than "Secure", the verification MUST be >> treated as a failure. >>=20 >> As an implementer I see no way to do this without adding a full >> fledged DNSSEC resolver. >=20 > There are various libraries to do this. You can look at getdns, > libunbound or various other libraries. We hope you would not write > your own dnssec validation code. If you do not want to link against > new unknown libraries you could outsource it to a separate tool, and > possibly warn the user of that. I'm happy to help you with that. >=20 >>> People have been attempting to put email address related records = into the >>> DNS since the first drafts of the spec and none has taken off. >>=20 >> That is a general problem. You need the support from the mail >> providers. >=20 > Of course this is a big catch22. While I have been approached by a few > email providers who have or are implementing this to allow their users > to publish their openpgp keys this way, the 5 big email providers > business model relies on advertisement targetted specifically by > reading your email. So I do not expect those email providers to have > much incentives to become free binary blob relaying services. >=20 >>> I do not find the idea of relying on the DNS for my keys remotely >>> comforting and would not want to rely on such a record directly. The = DNS >>> has no persistence to it. Give me the MIT keyserver any day. >>=20 >> When intending to send a mail the first time the DNS is pretty useful >> because it creates an association between mail address and key. Thus >> you can pick the right key and the recipient won't be annoyed by >> encrypted mails they can't decrypt because the keyservers carry = several >> "faked" keys for their mail address. >=20 > Indeed. And no one is saying you should ONLY trust the DNS. In fact, = no > one is saying that. The prime motivation for this document is to allow > MTAs and MUAs to encrypt emails that would otherwise be send out in = the > clear by the user. In no way is it intended to replace the web of = trust > or manual key verification, and I hope implementations will ensure = this > point to their users. >=20 >=20 > Now, one thing I _would_ like to see from the openpgp working group, = is > comments on content of the public key ring format that we should or > should not put into the OPENPGPKEY record. The draft basically refers > to the openpgp RFC, but people have wondered about some things: >=20 > - What to do when there is more than one pubkey? > - Should it be mandatory for the email address to appear as an ID > on the key? (if yes, how to support domain wild cards) > - Should any third party signatures be allowed/encourages/discouraged? > - Should revoked keys be allowed? >=20 > One issue during deployment for all fedora developer keys was that = people > do have keys that are larger than 64k and those will not fit into the > DNS. There is no easy way for tools to try and reduce the signatures > because it does not know which signatures carry more weight for the = user. >=20 > Paul Olafur=20= From nobody Tue Jul 28 07:52:09 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656BB1AC3EE for ; Tue, 28 Jul 2015 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4eCI5zZPlfO for ; Tue, 28 Jul 2015 07:52:07 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2A01AC3AB for ; Tue, 28 Jul 2015 07:52:06 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so76463146lbb.1 for ; Tue, 28 Jul 2015 07:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=wiU5uHnyyJ9pbumC/xSGph0pija1UxGPammy9pKrKkI=; b=w10hIoTLnbBgBFleMO6PJ8FcsoVdm7e6WTYVX4s8PeiCbYPXkKhnCkroCukEJrhHHp PFGL1cdSrQ8JS/HOitPyscnX91d/bJJr3XMtIGyWAYIuq5ulLFWMQL8sQq11zp/aMSv/ dvqKavUuAcVzQNmxTcwu9a79tVNjSSg67xTTr6ny5Hl/kwlSsAwvNO9s1qiDSiU4AEGr wl9Qj1VjZ/GTd6DazoUIpqDNFWND0kp2d/lU0j0mKp1GnwN96VnFZjEYX0u5EVc+Hl7O MWOql9bmJCdvKS2RZal/EDSZ7RSQDfdO+S8hoQ2tSpP0N3gj6DFBo8vJcEQ00A/ag96O rRLA== MIME-Version: 1.0 X-Received: by 10.112.172.4 with SMTP id ay4mr33801349lbc.124.1438095125263; Tue, 28 Jul 2015 07:52:05 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 28 Jul 2015 07:52:05 -0700 (PDT) Date: Tue, 28 Jul 2015 10:52:05 -0400 X-Google-Sender-Auth: 7saB32r9jMm-qdf4QSMFMwSIKak Message-ID: From: Phillip Hallam-Baker To: IETF OpenPGP Content-Type: multipart/alternative; boundary=001a11c345a8183c07051bf09d62 Archived-At: Subject: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 14:52:08 -0000 --001a11c345a8183c07051bf09d62 Content-Type: text/plain; charset=UTF-8 So following the discussion in Prague, I suggest: * Remove most of the motivation discussion from the draft and all of the bit that refers to stuff outside OpenPGP * Keep the MIME content type as the domain separation mechanism. Define the MIME Content types for OpenPGP vCurrent, PKIX SubjectKeyInfo and nothing else. [1] * Contact some usability types to ask about usability and changing up the block sizes. Does that work for folk? [1] We can do the SubjectKeyInfo thing as a separate registration but it means more work processing an extra draft. --001a11c345a8183c07051bf09d62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So following the discussion in Prague, I suggest:

=
* Remove most of the motivation discussion from the draft and al= l of the bit that refers to stuff outside OpenPGP

= * Keep the MIME content type as the domain separation mechanism. Define the= MIME Content types for OpenPGP vCurrent, PKIX SubjectKeyInfo and nothing e= lse. [1]

* Contact some usability types to ask abo= ut usability and changing up the block sizes.

Does= that work for folk?


[1] We can do = the SubjectKeyInfo thing as a separate registration but it means more work = processing an extra draft.
--001a11c345a8183c07051bf09d62-- From nobody Tue Jul 28 13:56:29 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94821B2E90 for ; Tue, 28 Jul 2015 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABHpwltrA0Yv for ; Tue, 28 Jul 2015 13:56:28 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6381B3066 for ; Tue, 28 Jul 2015 13:56:27 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6SKuLfT013460 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 28 Jul 2015 22:56:22 +0200 From: Simon Josefsson To: "Neal H. Walfield" References: <87pp3lk91r.wl-neal@walfield.org> <87pp3lhesi.fsf@vigenere.g10code.de> <87oaj5jvc9.wl-neal@walfield.org> <87380hky9n.fsf@alice.fifthhorseman.net> <87fv4cnss2.wl-neal@walfield.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150728:neal@walfield.org::KGHvpNFWsNw8HLLd:18LP X-Hashcash: 1:22:150728:dkg@fifthhorseman.net::xqU52RZSATKt9VYa:4VCl X-Hashcash: 1:22:150728:openpgp@ietf.org::lA2vjdes3zilZBsh:forV Date: Tue, 28 Jul 2015 22:56:20 +0200 In-Reply-To: <87fv4cnss2.wl-neal@walfield.org> (Neal H. Walfield's message of "Sat, 25 Jul 2015 17:47:25 +0200") Message-ID: <87a8ugvw5n.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] User ID Packet: expand recommendation to include hostname X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 20:56:28 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable "Neal H. Walfield" writes: > Hi, > > At Tue, 21 Jul 2015 23:15:48 +0200, > Daniel Kahn Gillmor wrote: >>=20 >> On Tue 2015-07-21 19:04:22 +0200, Neal H. Walfield wrote: >> > At Tue, 21 Jul 2015 14:32:29 +0200, >> > Werner Koch wrote: >> >> > Simon pointed out to me in another context that the user id (section >> >> > 5.11 of RFC 4880) is not always in RFC 2822 name-addr format, but is >> >> > sometimes simply a hostname. I think we should expand the >> >> > recommendation in that section to cover this usage. >> >>=20 >> >> The name-addr convention has served us well for more than 20 years an= d I >> >> see no reason to explicitly recommend the use of just a hostname. I = see >> >> no problem which will be solved by this. In case the hostname shall = be >> >> used similar to a a user id (e.g. for DNS lookup), it is easier to us= e a >> >> pseudo mail address like hostmaster@foo.example.org. >> > >> > I'm not making a recommendation about what should be done, but >> > suggesting we update the RFC to reflect current practice. >>=20 >> Can you point to existing examples of this usage (by fingerprint, >> maybe)? > > This usage was pointed out to me by Simon. I've cc'd him. I hope > he'll be able to answer your question. Nevertheless, Derek Atkins' > follow up to your question suggests that at least some people are > using this convention. I cannot recall what application this was for, but I distinctly recall working with OpenPGP keys issued for hostnames in some context. If nobody has any better pointer than this, I suggest to ignore this aspect. I'm not sure adding recommendations about using hostmaster@foo.example.org is a good idea, so -1 on that -- better to be silent on things without a use-case. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVt+x0AAoJEIYLf7sy+BGdznkH/3purBuPR0JMCJ93ERKtd9gV j2JPrmpEn827T7d2kA54E8hOxF33dAwMtqgBwBZUD2yOJQGFUYboemwCHprpWoEI MXRQBXH0RaJieTz7P/u497ek1IECZO7tZiyyGOhOvirgk4YmQq4wfMYIBginZ0Sz ciohH+1K1R0RxWwc+JoiOFwIK/VmxwZsgapWOtGL5PO0Nei4p5vLifEWZ9U2HMBK 9ibSmhmQqMuTTaOK//KtQZFJTCD4mDBaDVCi4HWzynB0DZZinFj/Qf38V2NiU7H7 E0axRxRoE55dD3mNcR2BH6NEcjSZ4vck3Ea6/zpE/egFmZtAq7mcc+MAqNyLJ7w= =c3JZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 28 14:40:07 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E036C1B2FA6 for ; Tue, 28 Jul 2015 14:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRqHZvK4QxUV for ; Tue, 28 Jul 2015 14:40:04 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 651671B2AB8 for ; Tue, 28 Jul 2015 14:40:04 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 93B8CF984 for ; Tue, 28 Jul 2015 17:40:03 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5E009200A4; Tue, 28 Jul 2015 23:39:53 +0200 (CEST) From: Daniel Kahn Gillmor To: IETF OpenPGP User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 28 Jul 2015 17:39:53 -0400 Message-ID: <87egjsgdw6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] draft minutes available X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 21:40:06 -0000 Hi IETF OpenPGP folks-- Draft minutes from the OpenPGP WG meeting at IETF-93 are available here: https://www.ietf.org/proceedings/93/minutes/minutes-93-openpgp Thanks to Jim Schaad for taking notes during the meeting and to Tero Kivinen for jabber scribing. If you have corrections or updates that should be made to the minutes, please send them to me (off-list is probably less noisy, but if you think the correction warrants everyone's attention i have no objection to seeing them on-list). Regards, --dkg From nobody Wed Jul 29 01:40:30 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCB21B2C8B for ; Wed, 29 Jul 2015 01:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm_CiN6XNawW for ; Wed, 29 Jul 2015 01:40:27 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0148E1B2C7F for ; Wed, 29 Jul 2015 01:40:27 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZKMuW-0004ts-6y for ; Wed, 29 Jul 2015 10:40:24 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZKMrE-0004EE-6g; Wed, 29 Jul 2015 10:37:00 +0200 From: Werner Koch To: Phillip Hallam-Baker References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Phillip Hallam-Baker , IETF OpenPGP Date: Wed, 29 Jul 2015 10:37:00 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 28 Jul 2015 10:52:05 -0400") Message-ID: <87twsn2wcz.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 08:40:29 -0000 On Tue, 28 Jul 2015 16:52, phill@hallambaker.com said: > * Contact some usability types to ask about usability and changing up the > block sizes. OpenPGP does not specify a user interface but the wire format. Obviously we use the most compact format there which is the plain binary format. The questions are - Do we need to explicity indicate the fingerprinting scheme (SHA-1 or SHA-256, or whatever) in the binary represenation. - Do we need truncation and how do we indicate a fingerprint scheme then given that it can't be deduced from the length. - Should we bind a certain fingerprint scheme to a public key packet versions as we did in the past (v3 = MD5, v4 = SHA1, maybe v5 = SHA256 with keyid being the leftmost octets). Or is it okay to allow for multipe fingerprint schemes for the same key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Jul 29 07:31:45 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716431A6FED for ; Wed, 29 Jul 2015 07:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjyiQ-KKdD4Q for ; Wed, 29 Jul 2015 07:31:42 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD631A701D for ; Wed, 29 Jul 2015 07:31:24 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so8211175lbb.0 for ; Wed, 29 Jul 2015 07:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=kVXS1kidGKLTUCGbczvDrzB/YuIHED5ePCwXf0ID9ic=; b=Uy4eXHwZqAnu+QQOGT1w1EnrBmu/SdDYObwRwZTWhj535FHVoXwnAyI7EAFPZRTOCn Oguca7nJI9t0pkrwX5aituEDlcZ3nwu8qdv5+0DwLI/uheGhOG223wtGFUDlcS1MBHqj jqxz50jAmX0a08SYDPyNh/V6Gw0WmMbxsmZ0XJ4m96gz2WGO/qXavWd2WCsM5+s0rUIS kvdDWzjhJFYt9v5zprp2VH0DsrkgZ4ZeWfbgUyBaAyOMaT/qpP7ReUCnSG6Pa0trLLLr +WW9OUjBhpb+5Q7OHSXNeKSJX2udYJAkKSB/pVpGRjfI9bPGbqDTyEiNf6GrRN+BPaH5 N9mQ== MIME-Version: 1.0 X-Received: by 10.152.2.2 with SMTP id 2mr39842650laq.58.1438180282559; Wed, 29 Jul 2015 07:31:22 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 29 Jul 2015 07:31:22 -0700 (PDT) In-Reply-To: <87twsn2wcz.fsf@vigenere.g10code.de> References: <87twsn2wcz.fsf@vigenere.g10code.de> Date: Wed, 29 Jul 2015 10:31:22 -0400 X-Google-Sender-Auth: xTPggAUifxij_pZ1UDKQYJcxcCo Message-ID: From: Phillip Hallam-Baker To: Phillip Hallam-Baker , IETF OpenPGP Content-Type: multipart/alternative; boundary=089e013c6470dd72d5051c047039 Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 14:31:44 -0000 --089e013c6470dd72d5051c047039 Content-Type: text/plain; charset=UTF-8 OK one thing from the meeting I forgot to mention, the security considerations have to address the use of a birthday attack by someone generating keys. If we are doing ECC, it is quite practical for someone to generate 2^50 keys and then pick the two that match in the first 100 bits. This can then be used for attacks, particularly if the keys are not enrolled in some sort of blockchain. The other bit I left out is the idea of compression. The idea here being that the person generating the key looks for a fingerprint that has 0s for the first n bits. Then the fingerprint starts with a version number that says 'the first 32 bits are 0s' or whatever. Yet another bit that should be mentioned in the security considerations is vanity fingerprints which are going to be more popular with all 26 Latin letters to choose from. And those are a bad idea for the reason given in the meeting. If my key starts off 'MERLI-Nxxxx' there is a temptation to only check those bits. Two important advantages of compression is that it provides an alternative to vanity fingerprints (shorter is better than fancy for most folk) and the work factor is not reduced by the birthday attack. Without compression, a 100 bit fingerprint is 20 characters and 150 bits is 30. The work factor for a birthday attack are 2^50 and 2^75 respectively With 32 bits of compression, the same strength against third party attack is achieved. with 14 and 24 characters. The work factor for a birthday attack are 2^66 and 2^81 respectively On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch wrote: > On Tue, 28 Jul 2015 16:52, phill@hallambaker.com said: > > > * Contact some usability types to ask about usability and changing up the > > block sizes. > > OpenPGP does not specify a user interface but the wire format. > Obviously we use the most compact format there which is the plain binary > format. The questions are > That is how we used to work in the 1990s. Since then we have had to do internationalization and such. As I started saying back then, the hardest part of a transaction to secure is the first/last two feet between the user's head and the screen. > - Do we need to explicity indicate the fingerprinting scheme (SHA-1 or > SHA-256, or whatever) in the binary represenation. > Yes, totally. I am suggesting we put code points in for the SHA-2-512 digest and the SHA-3-512 digest. The reason for going for the big digest even though we plan to truncate is that gives us maximal insurance against a compromise. These are the trust axioms of the system. > - Do we need truncation and how do we indicate a fingerprint scheme > then given that it can't be deduced from the length. > My preference is to just truncate and use the inferred length. That allows us to minimize the amount of data we need to put in front of the user without compromising security. Lets say that in 2020 Alice meets Bob and they exchange their fingerprints via a 150 bit QR code. Alice's smartphone goes to the mesh and pulls the corresponding profile which has Bob's key and full 512 bit fingerprint. The phone then stores the big fingerprint for Bob in her contacts directory. I cannot imagine wanting to rely on a contract signature without pulling the full record. > - Should we bind a certain fingerprint scheme to a public key packet > versions as we did in the past (v3 = MD5, v4 = SHA1, maybe v5 = > SHA256 with keyid being the leftmost octets). Or is it okay to > allow for multipe fingerprint schemes for the same key. This is the 'domain separation' issue that was mentioned in the meeting. I believe that we have to be able to revise the algorithm used to revise the fingerprint and the format of the data being formatted independently. As far as OpenPGP goes, the version indication inside the key packet should be sufficient for v5. The only reason the version indication would not be sufficient would be if a completely radical change to the format was being considered such as moving all the structures to YANG, CBOR, JSON or JSON-B. The proposal I have made is capable of dealing with that type of change with clean cryptographic separation of the content domains. --089e013c6470dd72d5051c047039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK one thing from the meeting I forgot to mention, the sec= urity considerations have to address the use of a birthday attack by someon= e generating keys.

If we are doing ECC, it is quite prac= tical for someone to generate 2^50 keys and then pick the two that match in= the first 100 bits. This can then be used for attacks, particularly if the= keys are not enrolled in some sort of blockchain.=C2=A0

The other bit I left out is the idea of compression. The idea here b= eing that the person generating the key looks for a fingerprint that has 0s= for the first n bits. Then the fingerprint starts with a version number th= at says 'the first 32 bits are 0s' or whatever.

Yet another bit that should be mentioned in the security consideratio= ns is vanity fingerprints which are going to be more popular with all 26 La= tin letters to choose from. And those are a bad idea for the reason given i= n the meeting. If my key starts off 'MERLI-Nxxxx' there is a tempta= tion to only check those bits.

Two important advan= tages of compression is that it provides an alternative to vanity fingerpri= nts (shorter is better than fancy for most folk) and the work factor is not= reduced by the birthday attack.


Wi= thout compression, a 100 bit fingerprint is 20 characters and 150 bits is 3= 0. The work factor for a birthday attack are 2^50 and 2^75 respectively

With 32 bits of compression, the same strength agains= t third party attack is achieved. with 14 and 24 characters. The work facto= r for a birthday attack are 2^66 and 2^81 respectively

=

On Wed, Jul = 29, 2015 at 4:37 AM, Werner Koch <wk@gnupg.org> wrote:
On Tue, 28 Jul 2015 16:52, phill@hallambaker.com said:

> * Contact some usability types to ask about usability and changing up = the
> block sizes.

OpenPGP does not specify a user interface but the wire format.
Obviously we use the most compact format there which is the plain binary format.=C2=A0 The questions are

That is= how we used to work in the 1990s. Since then we have had to do internation= alization and such.

As I started saying back then,= the hardest part of a transaction to secure is the first/last two feet bet= ween the user's head and the screen.

=C2=A0
=C2=A0 - Do we need to explicity indicate the fingerprinting scheme (SHA-1 = or
=C2=A0 =C2=A0 SHA-256, or whatever) in the binary represenation.

Yes, totally. I am suggesting we put code points = in for the SHA-2-512 digest and the SHA-3-512 digest.

<= div>The reason for going for the big digest even though we plan to truncate= is that gives us maximal insurance against a compromise. These are the tru= st axioms of the system.

=C2=A0
=C2=A0 - Do we need truncation and how do we indicate a fingerprint scheme<= br> =C2=A0 =C2=A0 then given that it can't be deduced from the length.
<= /blockquote>

My preference is to just truncate and use t= he inferred length. That allows us to minimize the amount of data we need t= o put in front of the user without compromising security.

Lets say that in 2020 Alice meets Bob and they exchange their finge= rprints via a 150 bit QR code. Alice's smartphone goes to the mesh and = pulls the corresponding profile which has Bob's key and full 512 bit fi= ngerprint. The phone then stores the big fingerprint for Bob in her contact= s directory.

I cannot imagine wanting to rely on a= contract signature without pulling the full record.

=C2=A0
=C2=A0 - Should we bind a certain fingerprint scheme to a public key packet=
=C2=A0 =C2=A0 versions as we did in the past (v3 =3D MD5, v4 =3D SHA1, mayb= e v5 =3D
=C2=A0 =C2=A0 SHA256 with keyid being the leftmost octets).=C2=A0 Or is it = okay to
=C2=A0 =C2=A0 allow for multipe fingerprint schemes for the same key.

This is the 'domain separation' issue th= at was mentioned in the meeting.

I believe that we= have to be able to revise the algorithm used to revise the fingerprint and= the format of the data being formatted independently.

=
As far as OpenPGP goes, the version indication inside the key packet s= hould be sufficient for v5. The only reason the version indication would no= t be sufficient would be if a completely radical change to the format was b= eing considered such as moving all the structures to YANG, CBOR, JSON or JS= ON-B.=C2=A0

The proposal I have made is capable of= dealing with that type of change with clean cryptographic separation of th= e content domains.=C2=A0

=C2=A0
<= /div>
--089e013c6470dd72d5051c047039-- From nobody Wed Jul 29 08:24:38 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488781A9068 for ; Wed, 29 Jul 2015 08:24:37 -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 YnFOtwRQY3tg for ; Wed, 29 Jul 2015 08:24:35 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2151A90C8 for ; Wed, 29 Jul 2015 08:10:26 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZKSzv-0001LE-Oe for ; Wed, 29 Jul 2015 17:10:23 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZKSwQ-0005De-1F; Wed, 29 Jul 2015 17:06:46 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <87twsn2wcz.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Phillip Hallam-Baker , IETF OpenPGP Date: Wed, 29 Jul 2015 17:06:45 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Wed, 29 Jul 2015 10:31:22 -0400") Message-ID: <87si870zqy.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 15:24:37 -0000 On Wed, 29 Jul 2015 16:31, phill@hallambaker.com said: > On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch wrote: >> OpenPGP does not specify a user interface but the wire format. >> Obviously we use the most compact format there which is the plain binary >> format. The questions are >> > > That is how we used to work in the 1990s. Since then we have had to do > internationalization and such. I can't see what internationalization has to do with the binary representation of a fingerprint. As I said RFC-4880 is about the wire format and not about user interfaces: It tells how to compute a fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1 hash. Now that a fingerprint is printed like this pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 is the choice of the concrete implementation. It is an interesting idea to have a common way of representing fingerprints to the user or in an URL but that is not in the scope of RFC-4800bis. > Yes, totally. I am suggesting we put code points in for the SHA-2-512 > digest and the SHA-3-512 digest. Until now we have bound the format of the fingerprint to the version of the public key format. The fingerprint for OpenPGP is a well defined and internally used property of OpenPGP. This avoids multiple fingerprints as we see with X.509 which does not have a specification for a fingerprint at all. > My preference is to just truncate and use the inferred length. That allows By truncation I mean an arbitary truncation like what we do with keyids. Those 64 keyids are for example used to locally lookup the secret keys for decryption - there is no need to have security here because it is just a convenience method (cf. wild card keyids) > This is the 'domain separation' issue that was mentioned in the meeting. > > I believe that we have to be able to revise the algorithm used to revise > the fingerprint and the format of the data being formatted independently. Again, OpenPGP does not specify how to format a fingerprint. That is and should stay out of scope for _this_ RFC but may be an additional item for the WG. > sufficient would be if a completely radical change to the format was being > considered such as moving all the structures to YANG, CBOR, JSON or JSON-B. The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Jul 29 16:34:24 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D077D1B2FD6 for ; Wed, 29 Jul 2015 16:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlLaaiol8d4G for ; Wed, 29 Jul 2015 16:34:20 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA341B2FC8 for ; Wed, 29 Jul 2015 16:34:15 -0700 (PDT) Received: from localhost (p5481D1FE.dip0.t-ipconnect.de [84.129.209.254]) by mail.mugenguild.com (Postfix) with ESMTPSA id B44975FAA6; Thu, 30 Jul 2015 01:30:17 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> From: Vincent Breitmoser To: Phillip Hallam-Baker In-reply-to: Date: Thu, 30 Jul 2015 01:34:09 +0200 Message-ID: <87oaiu7d3i.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 23:34:23 -0000 On 29 Jul 2015, Phillip Hallam-Baker wrote: > If we are doing ECC, it is quite practical for someone to generate > 2^50 keys and then pick the two that match in the first 100 > bits. This can then be used for attacks, particularly if the keys > are not enrolled in some sort of blockchain. What sort of attacks are we talking about here? > The other bit I left out is the idea of compression. The idea here > being that the person generating the key looks for a fingerprint > that has 0s for the first n bits. Then the fingerprint starts with a > version number that says 'the first 32 bits are 0s' or whatever. What do you mean here by "looks for"? Doesn't this effectively just limit the bitsize of used fingerprints? - V From nobody Wed Jul 29 20:53:29 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3051B2AAE for ; Wed, 29 Jul 2015 20:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cy-Tkv-Ya0B for ; Wed, 29 Jul 2015 20:53:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 22C961B2AAD for ; Wed, 29 Jul 2015 20:53:27 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 818E9F984; Wed, 29 Jul 2015 23:53:25 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 577E42009A; Thu, 30 Jul 2015 05:53:25 +0200 (CEST) From: Daniel Kahn Gillmor To: Werner Koch , Phillip Hallam-Baker In-Reply-To: <87si870zqy.fsf@vigenere.g10code.de> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87si870zqy.fsf@vigenere.g10code.de> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 29 Jul 2015 23:53:21 -0400 Message-ID: <873806e1xq.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 03:53:29 -0000 --=-=-= Content-Type: text/plain On Wed 2015-07-29 11:06:45 -0400, Werner Koch wrote: > By truncation I mean an arbitary truncation like what we do with keyids. > Those 64 keyids are for example used to locally lookup the secret keys > for decryption - there is no need to have security here because it is > just a convenience method (cf. wild card keyids) I'm not sure we should try to specify this kind of implementation shortcut. If a machine has a full fingerprint available to it (as it does if it has the keys themselves), expecting any lookup to be indexed by the full fingerprint seems like a reasonable expectation, and there's no need to get into hashtable-style bucketing implementation details as part of the RFC. > Again, OpenPGP does not specify how to format a fingerprint. That is > and should stay out of scope for _this_ RFC but may be an additional > item for the WG. The sense i got of the room in Prague was that there were mixed feelings about this point. In practice, the fingerprint seems to be most often used when there is a human in the loop, and in that scenario, the textual representation of the fingerprint is indeed relevant. If two humans are comparing fingerprints, or a human wants to pass a fingerprint to another human on a business card or sticker, then an unambiguous strong representation (not bits on the wire) is important. The only place where the fingerprint is used explicitly as part of wire format in RFC4880 is in the designated revoker subpacket, and on this list in the past there seems to have been no objection to replacing that with a full public key packet as a way of avoiding concerns about weak fingerprinting entirely (i'm hoping we can address this change in 4880bis). So the wire format concerns aren't relevant to this case. The other place where a fingerprint is used concretely is in HKP, as a lookup string. But again, here, it's not a bit-for-bit wire format. The fingerprint in hkp is transmitted as an ascii string of hexadecimal, which is human-readable (to map to an HTTP query parameter that a human could type or paste into a web form). As a result, it looks to me like a visual/textual representation of a fingerprint could be in-scope for a 4880bis, if the WG wants to take it on. >> sufficient would be if a completely radical change to the format was being >> considered such as moving all the structures to YANG, CBOR, JSON or JSON-B. > > The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON. If we're suddenly defining an entirely new OpenPGP packet format, then we could indeed move to one of these other models. But that seems like a pretty radical change to me, though, and not the incremental improvement/cleanup we're chartered for. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJVuZ+yXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcp+gP/ieR1l6U2Bg/vhE+J8aitx+h a/r9XoOvFuuGzLyvrxwq7hqPIGgnq56FgyCTQGsTbKxYHf2sxE30zWzAiil+PfXn k7FVEvjS24/gW0/aeZpJqlSjmWGYysjDnBk2ufcWobqYs3GNz6GrRPQTJdGYNIKX LyW8w6BE3A8eNgYbN6n8+XgauIz5RXJA17M4elVyBFRY5UNF042yuvz9wauOUoov KJffrKwceqBR7G71jHMm9R3RJpKNT1xcEgqgljwqXGBLWbyvj43qhdGBFVFNrR4q 1zrVy048UQCWAAq3ISBliLj7K204j/Bg/SZdn/1hLHa10xlHeLBOX4x8/M5iQrM9 hX/foQcScfO8pNdMZn5MTdtV/qxWkip+QrEcqtv19FYBCSCBPV69pVLG1Dt6Wg8n aojed2hyy9S+aLCsRkrBu3DCdaN6k4QxPb0TcqH4tBcNboHeBVIqLZaShYixPh+m mgZLbWjaYR73WIyZn0my+yv4DcSiS2eXy0IigKsHgUDvvG+Ei/FzFmoHrDRomZ4a lV9OTH3RCPu83HffFOBHFdLmN6XV9gooBqDdAZU2TTqMIERxsT0EGWaa93nTrGct dOg0O2XytwGga4BPMxuVEBNDF3fcoP7VNBeLxg8Alnuz49SlUNSeNpSZy2JhA+Ll 0wZAJlsr/NSD3T2lpQUe =MYrH -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 29 21:04:15 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4961B2ACB for ; Wed, 29 Jul 2015 21:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDlgflSDVNFz for ; Wed, 29 Jul 2015 21:04:12 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D3EC51B2AC4 for ; Wed, 29 Jul 2015 21:04:12 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 2FACAF984 for ; Thu, 30 Jul 2015 00:04:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 035DB202BD; Thu, 30 Jul 2015 06:04:11 +0200 (CEST) From: Daniel Kahn Gillmor To: IETF OpenPGP In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 30 Jul 2015 00:04:11 -0400 Message-ID: <87zj2ecmv8.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 04:04:14 -0000 On Wed 2015-07-29 10:31:22 -0400, Phillip Hallam-Baker wrote: > OK one thing from the meeting I forgot to mention, the security > considerations have to address the use of a birthday attack by someone > generating keys. I'll echo Vincent here and ask what specific attack you're concerned about. My current understanding of OpenPGP fingerprints is that we do not need collision resistance as a property of the fingerprint mechanism. We've discussed the possibility of birthday attacks against fingerprints by someone generating keys before, and i've yet to hear a concrete description of any attack that this permits. If there is such an attack, then we need to be really concerned about it now, since the current fingerprinting mechanism (SHA-1) is likely subject to a birthday attack by a motivated and well-financed attacker. > If we are doing ECC, it is quite practical for someone to generate 2^50 > keys and then pick the two that match in the first 100 bits. This can then > be used for attacks, particularly if the keys are not enrolled in some sort > of blockchain. if we want to discuss append-only logs of key material, i'd be happy to see that discussion happen formally in a separate thread, or over in the certificate transparency WG where that sort of thing is already under way. I think dragging blockchains into a discussion on OpenPGP fingerprint mechanisms is a distraction. > The other bit I left out is the idea of compression. The idea here being > that the person generating the key looks for a fingerprint that has 0s for > the first n bits. Then the fingerprint starts with a version number that > says 'the first 32 bits are 0s' or whatever. [...] > My preference is to just truncate and use the inferred length. That allows > us to minimize the amount of data we need to put in front of the user > without compromising security. These two proposals seem incompatible to me. If you give me a fingerprint that is shorter than the expected length, and both mechanisms are available, how am i supposed to know whether you've given me a truncated fingerprint or a "compressed" fingerprint? > Lets say that in 2020 Alice meets Bob and they exchange their fingerprints > via a 150 bit QR code. Alice's smartphone goes to the mesh and pulls the > corresponding profile which has Bob's key and full 512 bit fingerprint. The > phone then stores the big fingerprint for Bob in her contacts directory. Wouldn't the phone just store the key itself instead of the fingerprint? Why does the fingerprint matter in this scenario after the initial introduction? --dkg From nobody Wed Jul 29 23:35:29 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984831A8028 for ; Wed, 29 Jul 2015 23:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmAzjzAVymcN for ; Wed, 29 Jul 2015 23:35:26 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87051A6FFF for ; Wed, 29 Jul 2015 23:35:25 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZKhR6-0002dr-59 for ; Thu, 30 Jul 2015 08:35:24 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZKhQJ-0007Cm-Fr; Thu, 30 Jul 2015 08:34:35 +0200 From: Werner Koch To: Daniel Kahn Gillmor References: <87twsn2wcz.fsf@vigenere.g10code.de> <87si870zqy.fsf@vigenere.g10code.de> <873806e1xq.fsf@alice.fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com Mail-Followup-To: Daniel Kahn Gillmor , Phillip Hallam-Baker , IETF OpenPGP Date: Thu, 30 Jul 2015 08:34:35 +0200 In-Reply-To: <873806e1xq.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 29 Jul 2015 23:53:21 -0400") Message-ID: <87k2ti17d0.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Cc: Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 06:35:28 -0000 On Thu, 30 Jul 2015 05:53, dkg@fifthhorseman.net said: > I'm not sure we should try to specify this kind of implementation > shortcut. If a machine has a full fingerprint available to it (as it Please have a look at Public-Key Encrypted Session Key Packets (Tag 1): | The body of this packet consists of: | | * A one-octet number giving the version number of the packet | type. The currently defined value for packet version is 3. | | * An eight-octet number that gives the Key ID of the public key to | which the session key is encrypted. If the session key is encrypted | to a subkey, then the Key ID of this subkey is used here instead of | the Key ID of the primary key. | | * A one-octet number giving the public-key algorithm used. This requires the 64 bit key id. I doubt that anyone want to change this basic packet - implementations would need to implement two different types of these packet for no real benefit. The ECDH algorithm also needs a 20 byte identification of the key and thus we need a second truncation type here for non-SHA-1 fingerprints. Thus having a way to compute a keyid from a fingerprint is required. Quite some time ago this has already been discussed and the suggestion was for a future fingerprint format to right truncate it instead of the left truncation we do right now. > about this point. In practice, the fingerprint seems to be most often > used when there is a human in the loop, and in that scenario, the The fingerprint is the unique identifier for a key and it has the nice property that it has a fixed length. It is used at a lot of places to represent the key - not necessary for humans. > textual representation of the fingerprint is indeed relevant. If two > humans are comparing fingerprints, or a human wants to pass a Sure this is important for the use of an OpenPGP implementaions. But it is not required for the correct working of the protocol. The protocol is independet of the UI. > The only place where the fingerprint is used explicitly as part of wire > format in RFC4880 is in the designated revoker subpacket, and on this And the ECDH algo. > list in the past there seems to have been no objection to replacing that > with a full public key packet as a way of avoiding concerns about weak I see no reason to do this. It would require a lot of changes in existing code because both method will need to be supported for backward compatibility. If also does not ease the real complexity which is to evaluate whether that key is still valid (not revoked, not expired etc.). Supporting in addition a new type of fingerprint is much simpler. > The other place where a fingerprint is used concretely is in HKP, as a > lookup string. But again, here, it's not a bit-for-bit wire format. > The fingerprint in hkp is transmitted as an ascii string of hexadecimal, > which is human-readable (to map to an HTTP query parameter that a human This just an encoding required by the keyserver protocol. It is not intended for humans. > As a result, it looks to me like a visual/textual representation of a > fingerprint could be in-scope for a 4880bis, if the WG wants to take it If we begin to extend the scope to the UI we have no reason to reject other UI things. I do not think this belongs into RFC4880bis. The human readable format of a fingerprint should either be in implementations hints or in a separate RFC. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Thu Jul 30 07:12:48 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3008A1A1A0B for ; Thu, 30 Jul 2015 07:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5jM_KQEDRHg for ; Thu, 30 Jul 2015 07:12:44 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BE01A1A06 for ; Thu, 30 Jul 2015 07:12:43 -0700 (PDT) Received: by laah7 with SMTP id h7so25855042laa.0 for ; Thu, 30 Jul 2015 07:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=R0qInHLVSiT9FzFAHu2tEV6coqw+L8btJEO06t0LJL0=; b=EOSwZxthpXJz7G2/st/oehmgEDYCh0Hxv2yces0cFgMkdiDtYMkmTFLXi28UfPLYYC Vnv66rLeyY+SAIoBJ9XE9PpZb6OKvDGqTyvvn7YyTaiuQLeOYkGAMFc79iXX+lsxY94j 1z9fstl8sWn6iWvKozu6sq0pLXbgLw/sNtbyjfsXWQ3eWprXhrfoRRQGhGsJh31GTTg+ CiSRml4dBuCS4iirKew95J3y9Zj9eDefZZ8nJxuws1EiTwP+utkdKtmgoIlRjQI4E08A OXqiLQjnHshalFhNOUNH5gTT2adiEeyP5guMYGFaQWHzBijN27BBEMDBhn9xwQPCaJbI JXmg== MIME-Version: 1.0 X-Received: by 10.152.87.72 with SMTP id v8mr10146631laz.124.1438265561999; Thu, 30 Jul 2015 07:12:41 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 30 Jul 2015 07:12:41 -0700 (PDT) In-Reply-To: <87si870zqy.fsf@vigenere.g10code.de> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87si870zqy.fsf@vigenere.g10code.de> Date: Thu, 30 Jul 2015 10:12:41 -0400 X-Google-Sender-Auth: 9WyihiQ2WOI-ICeNFDwoUyWcHa0 Message-ID: From: Phillip Hallam-Baker To: Phillip Hallam-Baker , IETF OpenPGP Content-Type: multipart/alternative; boundary=001a11c36410ea7163051c184bf9 Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 14:12:47 -0000 --001a11c36410ea7163051c184bf9 Content-Type: text/plain; charset=UTF-8 OK, so looking through the threads, I think we are talking at cross purposes due to differences in terminology. For me a fingerprint is a presentation of a digest to be read by a human. Getting the nomenclature consistent may seem unimportant but it is actually 50% of getting a spec right. I suggest the following. We have a sequence of two modules as follows. Digested content = The input into the fingerprint digest function. Fingerprint digest function = Some function involving SHA-2/SHA-3 and a version identifier. Tagged Digest/Binary Fingerprint = The output from the Fingerprint digest function. Presentation Function = Converts the Binary Fingerprint for human readability. Probably involves truncation, BASE32 and inserting dashes. Fingerprint = What the user sees. Internally, the Tagged Digest/Binary Fingerprint is the structure that is closest to the existing OpenPGP 'fingerprint'. On Wed, Jul 29, 2015 at 11:06 AM, Werner Koch wrote: > On Wed, 29 Jul 2015 16:31, phill@hallambaker.com said: > > > On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch wrote: > > >> OpenPGP does not specify a user interface but the wire format. > >> Obviously we use the most compact format there which is the plain binary > >> format. The questions are > >> > > > > That is how we used to work in the 1990s. Since then we have had to do > > internationalization and such. > > I can't see what internationalization has to do with the binary > representation of a fingerprint. As I said RFC-4880 is about the wire > format and not about user interfaces: It tells how to compute a > fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1 > hash. Now that a fingerprint is printed like this > > pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] > Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 > > is the choice of the concrete implementation. It is an interesting idea > to have a common way of representing fingerprints to the user or in an > URL but that is not in the scope of RFC-4800bis. Back in the 1990s, we could ignore the user interface layer completely. Those times are past. For OpenPGP to work in the real world, people have to be able to write fingerpints on their business cards in ways that different implementations can interpret. When we designed URLs, they were not designed to be written on the side of a truck but they were designed to be printed in the references section of a scientific paper. > > Yes, totally. I am suggesting we put code points in for the SHA-2-512 > > digest and the SHA-3-512 digest. > > Until now we have bound the format of the fingerprint to the version of > the public key format. The fingerprint for OpenPGP is a well defined > and internally used property of OpenPGP. This avoids multiple > fingerprints as we see with X.509 which does not have a specification > for a fingerprint at all. By 'format of the fingerprint' you seem to be referring to the format in which the digested content is presented, i.e. the input to the Fingerprint digest function. I think it is better to have the version specify just the Fingerprint digest function. We can get domain separation between OpenPGP versions by putting a content version somewhere in the Digested Content. > > My preference is to just truncate and use the inferred length. That > allows > > By truncation I mean an arbitary truncation like what we do with keyids. > Those 64 keyids are for example used to locally lookup the secret keys > for decryption - there is no need to have security here because it is > just a convenience method (cf. wild card keyids) There are two points at which truncation might occur. The Presentation module really has to do truncation. Even 256 bits is too many. We might want to truncate the binary fingerprint to 256 bits as well. The reason for using SHA-2-512 is more rounds, not to get more output bits. > > > This is the 'domain separation' issue that was mentioned in the meeting. > > > > I believe that we have to be able to revise the algorithm used to revise > > the fingerprint and the format of the data being formatted independently. > > Again, OpenPGP does not specify how to format a fingerprint. That is > and should stay out of scope for _this_ RFC but may be an additional > item for the WG. Absolutely. This should be a separate document from RFC4880-BIS > > > sufficient would be if a completely radical change to the format was > being > > considered such as moving all the structures to YANG, CBOR, JSON or > JSON-B. > > The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON. One of the few things Rudy Guiliani ever said to me that made any sense is that you can't expect every disaster but you plan for all the disasters you can imagine and then you are most likely to be prepared for the one that happens. So planning for an invasion by a zombie hoard might sound like it is completely nuts. But that sort of planning might come in handy if you were facing a major outbreak of Ebola. I think its the same with extensibility. We can't predict every future possible use of the spec and we shouldn't try. But if we can cover all the possibilities we can imagine without undue burden on the spec, we maximize the possibility that someone can build the extension that turns out to be the killer app. --001a11c36410ea7163051c184bf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, so looking through the threads, I think we are talking= at cross purposes due to differences in terminology. For me a fingerprint = is a presentation of a digest to be read by a human.

Get= ting the nomenclature consistent may seem unimportant but it is actually 50= % of getting a spec right. I suggest the following.

We have a sequence of two modules as follows.

Digested content =3D The input into the fingerprint digest fun= ction.

Fingerprint digest function =3D Some functi= on involving SHA-2/SHA-3 and a version identifier.

Tagged Digest/Binary Fingerprint =3D The output from the Fingerprint diges= t function.

Presentation Function =3D Converts the= Binary Fingerprint for human readability. Probably involves truncation, BA= SE32 and inserting dashes.

Fingerprint =3D What th= e user sees.


Internally, the Tagged= Digest/Binary Fingerprint is the structure that is closest to the existing= OpenPGP 'fingerprint'.



On Wed, Jul 29, 2015 at 1= 1:06 AM, Werner Koch <wk@gnupg.org> wrote:
On Wed, 29 Jul 2015 16:31, phill@hallambaker.com said:

> On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch <wk@gnupg.org> wrote:

>> OpenPGP does not specify a user interface but the wire format.
>> Obviously we use the most compact format there which is the plain = binary
>> format.=C2=A0 The questions are
>>
>
> That is how we used to work in the 1990s. Since then we have had to do=
> internationalization and such.

I can't see what internationalization has to do with the binary<= br> representation of a fingerprint.=C2=A0 As I said RFC-4880 is about the wire=
format and not about user interfaces: It tells how to compute a
fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1
hash.=C2=A0 Now that a fingerprint is printed like this

pub=C2=A0 =C2=A0dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] =C2=A0 =C2=A0 =C2=A0 Key fingerprint =3D 8061 5870 F5BA D690 3336=C2=A0 86D= 0 F2AD 85AC 1E42 B367

is the choice of the concrete implementation.=C2=A0 It is an interesting id= ea
to have a common way of representing fingerprints to the user or in an
URL but that is not in the scope of RFC-4800bis.

Back in the 1990s, we could ignore the user interface layer completel= y. Those times are past. For OpenPGP to work in the real world, people have= to be able to write fingerpints on their business cards in ways that diffe= rent implementations can interpret.

When we design= ed URLs, they were not designed to be written on the side of a truck but th= ey were designed to be printed in the references section of a scientific pa= per.

=C2=A0
> Yes, totally. I am suggesting we put code points in for= the SHA-2-512
> digest and the SHA-3-512 digest.

Until now we have bound the format of the fingerprint to the version= of
the public key format.=C2=A0 The fingerprint for OpenPGP is a well defined<= br> and internally used property of OpenPGP.=C2=A0 This avoids multiple
fingerprints as we see with X.509 which does not have a specification
for a fingerprint at all.

By 'format of= the fingerprint' you seem to be referring to the format in which the d= igested content is presented, i.e. the input to the Fingerprint digest func= tion. I think it is better to have the version specify just the Fingerprint= digest function.

We can get domain separation bet= ween OpenPGP versions by putting a content version somewhere in the Digeste= d Content.

=C2=A0
> My preference is to just truncate and use the inf= erred length. That allows

By truncation I mean an arbitary truncation like what we do with key= ids.
Those 64 keyids are for example used to locally lookup the secret keys
for decryption - there is no need to have security here because it is
just a convenience method (cf. wild card keyids)

There are two points at which truncation might occur. The Presentatio= n module really has to do truncation. Even 256 bits is too many.
=
We might want to truncate the binary fingerprint to 256 bits= as well. The reason for using SHA-2-512 is more rounds, not to get more ou= tput bits.


=C2=A0

> This is the 'domain separation' issue that was mentioned in th= e meeting.
>
> I believe that we have to be able to revise the algorithm used to revi= se
> the fingerprint and the format of the data being formatted independent= ly.

Again, OpenPGP does not specify how to format a fingerprint.=C2=A0 T= hat is
and should stay out of scope for _this_ RFC but may be an additional
item for the WG.

Absolutely. This should be= a separate document from RFC4880-BIS

=C2=A0
=

> sufficient would be if a completely radical change to the format was b= eing
> considered such as moving all the structures to YANG, CBOR, JSON or JS= ON-B.

The OpenPGP format is the OpenPGP format and not BER, PER, XML, or J= SON.

One of the few things Rudy Guiliani ev= er said to me that made any sense is that you can't expect every disast= er but you plan for all the disasters you can imagine and then you are most= likely to be prepared for the one that happens. So planning for an invasio= n by a zombie hoard might sound like it is completely nuts. But that sort o= f planning might come in handy if you were facing a major outbreak of Ebola= .

I think its the same with extensibility. We can&= #39;t predict every future possible use of the spec and we shouldn't tr= y. But if we can cover all the possibilities we can imagine without undue b= urden on the spec, we maximize the possibility that someone can build the e= xtension that turns out to be the killer app.
=C2=A0
<= /div>
--001a11c36410ea7163051c184bf9-- From nobody Thu Jul 30 07:45:00 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DDF1A1A99 for ; Thu, 30 Jul 2015 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0asAVHQrLxT4 for ; Thu, 30 Jul 2015 07:44:50 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBB81A1B48 for ; Thu, 30 Jul 2015 07:44:50 -0700 (PDT) Received: by lbqc9 with SMTP id c9so3256108lbq.1 for ; Thu, 30 Jul 2015 07:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=50+ZD593WRG+pmhNVGVKlAZNeal1+z6QM1uR9E4rz3Y=; b=0FASLTOs2Ybpg64ncs89FgLWaA0iXKPxC06bDIHpZ+dPBOD8nWdUlR/UTbu3sUi6uR W94/i/W20QmVSNtjk7FFDvyZpRpYnxvduQyWqZtbOZqk6eoUA4/38v5uIjWSQjr6Bstx l9VLOW9WoJ7AWw9kiHI3zUzL1n254ay5Sc/xNiHjyxSgyv00QIr560htQR0hQMbwJzw2 tN8SDBAuC0YzT58QJt7KD+WXPd+Hum3VKOI25p5L4ffzt/n3Ydqy0btFldD/OvQdSlgM 74mFV8h6RkRyar4a7iM2ivvzrecBKIVQPZnWFsZuRdWL4loE40KWvuByp/Xrz1yg5/hf rxQA== MIME-Version: 1.0 X-Received: by 10.152.234.42 with SMTP id ub10mr43709750lac.60.1438267488524; Thu, 30 Jul 2015 07:44:48 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.10.226 with HTTP; Thu, 30 Jul 2015 07:44:48 -0700 (PDT) In-Reply-To: <87zj2ecmv8.fsf@alice.fifthhorseman.net> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> Date: Thu, 30 Jul 2015 10:44:48 -0400 X-Google-Sender-Auth: qpzl0dcCGzbz2gzfYD9yjqfMxXI Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a113438a0bee04b051c18bee3 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 14:44:52 -0000 --001a113438a0bee04b051c18bee3 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 12:04 AM, Daniel Kahn Gillmor wrote: > On Wed 2015-07-29 10:31:22 -0400, Phillip Hallam-Baker wrote: > > OK one thing from the meeting I forgot to mention, the security > > considerations have to address the use of a birthday attack by someone > > generating keys. > > I'll echo Vincent here and ask what specific attack you're concerned > about. > > My current understanding of OpenPGP fingerprints is that we do not need > collision resistance as a property of the fingerprint mechanism. > That depends on the use cases you anticipate for OpenPGP and what you expect people will build on top. The thing is that OpenPGP is not just an email security application, it is infrastructure. A lot of stuff is built on top of the spec that has nothing to do with email. That does not mean we have to support those applications. But it does mean that we have to write a security consideration telling people we have (1) considered the issue and that (2) either it isn't a problem or you should do stuff that is going to be affected. The concern here is that Mallet generates two keys that have the fingerprints Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and . Mxxxx-xxxxx-xxxxx-xxxxx-xxxx2 'M2' Mallet joins an open source project which only takes the first 100 bits for the fingerprint. He uploads the key for M1 to a keyserver. He then commits a large number of malicious patches using M2 for authentication. These are all authenticated against his public key M2 when he does the commit but the repository uses the key sent in band and does not keep the key for later verification. At this point, any attempt to hold Mallet accountable is going to have to rely on a human examining the logs and working out that Mallet must have generated the malicious pair of keys. There is going to be no way to unwind the thing automatically. if we want to discuss append-only logs of key material, i'd be happy to > see that discussion happen formally in a separate thread, or over in the > certificate transparency WG where that sort of thing is already under > way. I think dragging blockchains into a discussion on OpenPGP > fingerprint mechanisms is a distraction. The connection is that each blockchain output can be used as an axiom of trust. Since the purpose of fingerprints is to represent roots of trust, this is a possible use case that the spec should be capable of accommodating without opening up the question of how precisely that would be achieved. > > > The other bit I left out is the idea of compression. The idea here being > > that the person generating the key looks for a fingerprint that has 0s > for > > the first n bits. Then the fingerprint starts with a version number that > > says 'the first 32 bits are 0s' or whatever. > [...] > > My preference is to just truncate and use the inferred length. That > allows > > us to minimize the amount of data we need to put in front of the user > > without compromising security. > > These two proposals seem incompatible to me. If you give me a > fingerprint that is shorter than the expected length, and both > mechanisms are available, how am i supposed to know whether you've given > me a truncated fingerprint or a "compressed" fingerprint? Well, the fingerprint version tag would have to flag that encryption is being used. So instead of the fingerprint being Mxxxx-.... (SHA2-512) or Sxxxx-... (SHA3-512), it might be Xxxxx-... > Lets say that in 2020 Alice meets Bob and they exchange their fingerprints > > via a 150 bit QR code. Alice's smartphone goes to the mesh and pulls the > > corresponding profile which has Bob's key and full 512 bit fingerprint. > The > > phone then stores the big fingerprint for Bob in her contacts directory. > > Wouldn't the phone just store the key itself instead of the fingerprint? > Why does the fingerprint matter in this scenario after the initial > introduction? > OK, 'at least the 512 bit fingerprint'... Which you do probably depends on if you are using ECC or RSA. With RSA, those 2048 bit keys start to bulk up... For my particular implementation, I want to be able to rotate encryption keys on a monthly basis or any time a device is added or removed from a user's profile. so I am using fingerprints of key signing keys rather than end-entity keys. As a general rule, it seems that you can solve pretty much any usability problem at the cost of an additional key. Back in 1995, this would have ground the whole net to a halt. Today it isn't a problem. Right now on my testbed Alice has a personal profile of 3 keys, plus a device profile of 3 keys per device, plus individual keys for each use in application (1+1 per device for email, 1 for 2 factor auth, 1 for admin, 1 for data encryption, 1 for drive encryption). So assuming Alice has 2 desktops, a laptop, a tablet, a phone and a watch, that is 3 + 18 + 7 + 6 = 30 keypairs and an additional one per month. It might sound a bit extreme, but since I started in the business, machines have gotten roughly a million times faster and have a million times the memory. 30 keypairs instead of one does not seem like a big deal. --001a113438a0bee04b051c18bee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 30, 2015 at 12:04 AM, Daniel Kahn Gillmor <dkg@fifthho= rseman.net> wrote:
On Wed 2015-07-29 10:31:22 -0400, Phillip Hallam-Baker wrote:
> OK one thing from the meeting I forgot to mention, the security
> considerations have to address the use of a birthday attack by someone=
> generating keys.

I'll echo Vincent here and ask what specific attack you're c= oncerned
about.

My current understanding of OpenPGP fingerprints is that we do not need
collision resistance as a property of the fingerprint mechanism.

That depends on the use cases you anticipate for = OpenPGP and what you expect people will build on top.

<= div>The thing is that OpenPGP is not just an email security application, it= is infrastructure. A lot of stuff is built on top of the spec that has not= hing to do with email.

That does not mean we have = to support those applications. But it does mean that we have to write a sec= urity consideration telling people we have (1) considered the issue and tha= t (2) either it isn't a problem or you should do stuff that is going to= be affected.


The concern here is t= hat Mallet generates two keys that have the fingerprints

Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and .
Mxxxx-xxx= xx-xxxxx-xxxxx-xxxx2 'M2'
=C2=A0
Mallet joi= ns an open source project which only takes the first 100 bits for the finge= rprint. He uploads the key for M1 to a keyserver.

= He then commits a large number of malicious patches using M2 for authentica= tion. These are all authenticated against his public key M2 when he does th= e commit but the repository uses the key sent in band and does not keep the= key for later verification.

At this point, any at= tempt to hold Mallet accountable is going to have to rely on a human examin= ing the logs and working out that Mallet must have generated the malicious = pair of keys. There is going to be no way to unwind the thing automatically= .


if we w= ant to discuss append-only logs of key material, i'd be happy to
see that discussion happen formally in a separate thread, or over in the certificate transparency WG where that sort of thing is already under
way.=C2=A0 I think dragging blockchains into a discussion on OpenPGP
fingerprint mechanisms is a distraction.

Th= e connection is that each blockchain output can be used as an axiom of trus= t. Since the purpose of fingerprints is to represent roots of trust, this i= s a possible use case that the spec should be capable of accommodating with= out opening up the question of how precisely that would be achieved.
<= div>

=C2=A0

> The other bit I left out is the idea of compression. The idea here bei= ng
> that the person generating the key looks for a fingerprint that has 0s= for
> the first n bits. Then the fingerprint starts with a version number th= at
> says 'the first 32 bits are 0s' or whatever.
=C2=A0[...]
> My preference is to just truncate and use the inferre= d length. That allows
> us to minimize the amount of data we need to put in front of the user<= br> > without compromising security.

These two proposals seem incompatible to me.=C2=A0 If you give me a<= br> fingerprint that is shorter than the expected length, and both
mechanisms are available, how am i supposed to know whether you've give= n
me a truncated fingerprint or a "compressed" fingerprint?

Well, the fingerprint version tag would have to fl= ag that encryption is being used. So instead of the fingerprint being Mxxxx= -.... (SHA2-512) or Sxxxx-... (SHA3-512), it might be Xxxxx-...
<= br>

>= ; Lets say that in 2020 Alice meets Bob and they exchange their fingerprint= s
> via a 150 bit QR code. Alice's smartphone goes to the mesh and pul= ls the
> corresponding profile which has Bob's key and full 512 bit fingerp= rint. The
> phone then stores the big fingerprint for Bob in her contacts director= y.

Wouldn't the phone just store the key itself instead of the fing= erprint?
Why does the fingerprint matter in this scenario after the initial
introduction?

OK, 'at least the 512= bit fingerprint'...

Which you do probably dep= ends on if you are using ECC or RSA. With RSA, those 2048 bit keys start to= bulk up...

For my particular implementation, I wa= nt to be able to rotate encryption keys on a monthly basis or any time a de= vice is added or removed from a user's profile. so I am using fingerpri= nts of key signing keys rather than end-entity keys.

As a general rule, it seems that you can solve pretty much any usability= problem at the cost of an additional key. Back in 1995, this would have gr= ound the whole net to a halt. Today it isn't a problem. Right now on my= testbed Alice has a personal profile of 3 keys, plus a device profile of 3= keys per device, plus individual keys for each use in application (1+1 per= device for email, 1 for 2 factor auth, 1 for admin, 1 for data encryption,= 1 for drive encryption). So assuming Alice has 2 desktops, a laptop, a tab= let, a phone and a watch, that is 3 + 18 + 7 + 6 =3D 30 keypairs and an add= itional one per month.

It might sound a bit extrem= e, but since I started in the business, machines have gotten roughly a mill= ion times faster and have a million times the memory. 30 keypairs instead o= f one does not seem like a big deal.=C2=A0
--001a113438a0bee04b051c18bee3-- From nobody Thu Jul 30 08:16:47 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9F31A92FB for ; Thu, 30 Jul 2015 08:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO27rzlPQkgo for ; Thu, 30 Jul 2015 08:16:43 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2121B1A6FF9 for ; Thu, 30 Jul 2015 08:15:55 -0700 (PDT) Received: by igr7 with SMTP id 7so168939067igr.0 for ; Thu, 30 Jul 2015 08:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=zzfR/wlqCddZGUYNAqiIyAtJUqD7IFD2g4K6LLF8dOk=; b=CFrmnhKJcc7Kh1m8GmsqI2OzOXZdWYRjve6U3uTn0NzRWqjSBh9oL0fZj0D2ptBwxW 2GMlEmJApGmPwxclHa/sES5Ux75onjLmJCrTP2IPac4mRmPTVktVrAYtdqEAKeFgHpNi 0b57QhgpxgwROcL4cv3ChChG0b4x6Sbm/YDUzF9VLPgDHfm558Ykiyxr9nGdTuk3Prwd wjq6FFGbk4C+O1G8fEBsK2Bl6MnSFNGwXYDP+hP8yO6R92sn4OrxZzH8VssrsHCu+4e4 Iyn4kYlax6wMNIc9br/GYWSoAajDQW/tE5jRpCdX5l910OO5ZzuwZyU3ozAiw9ODy+S1 7EUQ== X-Received: by 10.50.1.43 with SMTP id 11mr6099782igj.76.1438269354600; Thu, 30 Jul 2015 08:15:54 -0700 (PDT) MIME-Version: 1.0 References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> In-Reply-To: From: Wyllys Ingersoll Date: Thu, 30 Jul 2015 15:15:45 +0000 Message-ID: To: Phillip Hallam-Baker , Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=047d7bdc15daf8efdd051c192d2b Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 15:16:45 -0000 --047d7bdc15daf8efdd051c192d2b Content-Type: text/plain; charset=UTF-8 > > > OK, 'at least the 512 bit fingerprint'... > > Which you do probably depends on if you are using ECC or RSA. With RSA, > those 2048 bit keys start to bulk up... > > For my particular implementation, I want to be able to rotate encryption > keys on a monthly basis or any time a device is added or removed from a > user's profile. so I am using fingerprints of key signing keys rather than > end-entity keys. > > As a general rule, it seems that you can solve pretty much any usability > problem at the cost of an additional key. Back in 1995, this would have > ground the whole net to a halt. Today it isn't a problem. Right now on my > testbed Alice has a personal profile of 3 keys, plus a device profile of 3 > keys per device, plus individual keys for each use in application (1+1 per > device for email, 1 for 2 factor auth, 1 for admin, 1 for data encryption, > 1 for drive encryption). So assuming Alice has 2 desktops, a laptop, a > tablet, a phone and a watch, that is 3 + 18 + 7 + 6 = 30 keypairs and an > additional one per month. > > It might sound a bit extreme, but since I started in the business, > machines have gotten roughly a million times faster and have a million > times the memory. 30 keypairs instead of one does not seem like a big deal. > Really? It sure does to me. PGP suffers from numerous usability issues, some of which are a result of implementation artifacts and some are unavoidable due to the nature of security and the spec itself. Making things more complicated or breaking compatibility with widely used existing implementations in order to satisfy an odd niche use case does not seem to me like its advancing the cause in a helpful way. People today balk at managing a single PGP keypair across multiple devices and applications, how in the world would they be expected to deal with 30+ (and growing) keys? Perhaps this is all handled automatically by whatever scheme you are developing and the user would never know or care that there are 30+ keys in their domain, but as described it seems way complicated. Im in agreement with Werner that we should tread carefully in redefining or overloading the meaning of a "fingerprint" beyond how it is already specified in 4880. > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --047d7bdc15daf8efdd051c192d2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

OK, 'at least the 512 bit fingerprint'= ;...

Which you do probably depends on if you are u= sing ECC or RSA. With RSA, those 2048 bit keys start to bulk up...

For my particular implementation, I want to be able to rot= ate encryption keys on a monthly basis or any time a device is added or rem= oved from a user's profile. so I am using fingerprints of key signing k= eys rather than end-entity keys.

As a general rule= , it seems that you can solve pretty much any usability problem at the cost= of an additional key. Back in 1995, this would have ground the whole net t= o a halt. Today it isn't a problem. Right now on my testbed Alice has a= personal profile of 3 keys, plus a device profile of 3 keys per device, pl= us individual keys for each use in application (1+1 per device for email, 1= for 2 factor auth, 1 for admin, 1 for data encryption, 1 for drive encrypt= ion). So assuming Alice has 2 desktops, a laptop, a tablet, a phone and a w= atch, that is 3 + 18 + 7 + 6 =3D 30 keypairs and an additional one per mont= h.

It might sound a bit extreme, but since I start= ed in the business, machines have gotten roughly a million times faster and= have a million times the memory. 30 keypairs instead of one does not seem = like a big deal.=C2=A0

<= div>
Really?=C2=A0 It sure does to me.=C2=A0 PGP suffers from= numerous usability issues, some of which are a result of implementation ar= tifacts and some are unavoidable due to the nature of security and the spec= itself.=C2=A0 Making things more complicated or breaking compatibility wit= h widely used existing implementations in order to satisfy an odd niche use= case does not seem to me like its advancing the cause in a helpful way.

People today balk at managing a single PGP keypair a= cross multiple devices and applications, how in the world would they be exp= ected to deal with 30+ (and growing) keys?=C2=A0 Perhaps this is all handle= d automatically by whatever scheme you are developing and the user would ne= ver know or care that there are 30+ keys in their domain, but as described = it seems way complicated.

Im in agreement with Wer= ner that we should tread carefully in redefining or overloading the meaning= of a "fingerprint" beyond how it is already specified in 4880.


=C2=A0
_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--047d7bdc15daf8efdd051c192d2b-- From nobody Thu Jul 30 08:42:40 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2ECC1A87A3 for ; Thu, 30 Jul 2015 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNotQAFFmej4 for ; Thu, 30 Jul 2015 08:42:37 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E22A1A87E2 for ; Thu, 30 Jul 2015 08:42:27 -0700 (PDT) Received: by lbqc9 with SMTP id c9so4399233lbq.1 for ; Thu, 30 Jul 2015 08:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aZBlboEMZcsoBtJV6hWeIcADxhLYfqeUqbiO9+lYVss=; b=UUQPrKgCpSX4xW/04KPcE1TfrDu12fnYUEUr44L4ySCXvSYbjkxY7mzkbTLvlsHMit YeYTHZod6XgywmfQJ508y7Y+Ek7fRBK+L0mBsVgKDJHj5l7kmZ3j/iRHC6p4nE0ww6v+ E8nHY63hLuFbv/DFOg4EAXYCFeF9DGaJGuUGJlDJtsmFTITaCDw3NDw+I+P1TJB2Ve/P kt5ee2TKfKtrM3AvDcaK6D11/S/4G9I8jVC8B9i9TgzCw2llDLadSJUgnqAl0ggayPZY rYmcuTBFXWkrc4451lG2thnrhiJvHzmFkXG+0eKFp92SgJDFpjCPVlzTgRrbtOeT1uP4 vNLw== MIME-Version: 1.0 X-Received: by 10.112.170.167 with SMTP id an7mr45270095lbc.103.1438270946044; Thu, 30 Jul 2015 08:42:26 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Thu, 30 Jul 2015 08:42:25 -0700 (PDT) In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> Date: Thu, 30 Jul 2015 11:42:25 -0400 X-Google-Sender-Auth: -ej0J4heX_VCBNL_2YY46GGHBNs Message-ID: From: Phillip Hallam-Baker To: Wyllys Ingersoll Content-Type: multipart/alternative; boundary=001a11c368ccd47124051c198cd6 Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 15:42:38 -0000 --001a11c368ccd47124051c198cd6 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 11:15 AM, Wyllys Ingersoll wrote: > >> OK, 'at least the 512 bit fingerprint'... >> >> Which you do probably depends on if you are using ECC or RSA. With RSA, >> those 2048 bit keys start to bulk up... >> >> For my particular implementation, I want to be able to rotate encryption >> keys on a monthly basis or any time a device is added or removed from a >> user's profile. so I am using fingerprints of key signing keys rather than >> end-entity keys. >> >> As a general rule, it seems that you can solve pretty much any usability >> problem at the cost of an additional key. Back in 1995, this would have >> ground the whole net to a halt. Today it isn't a problem. Right now on my >> testbed Alice has a personal profile of 3 keys, plus a device profile of 3 >> keys per device, plus individual keys for each use in application (1+1 per >> device for email, 1 for 2 factor auth, 1 for admin, 1 for data encryption, >> 1 for drive encryption). So assuming Alice has 2 desktops, a laptop, a >> tablet, a phone and a watch, that is 3 + 18 + 7 + 6 = 30 keypairs and an >> additional one per month. >> >> It might sound a bit extreme, but since I started in the business, >> machines have gotten roughly a million times faster and have a million >> times the memory. 30 keypairs instead of one does not seem like a big deal. >> > > > Really? It sure does to me. PGP suffers from numerous usability issues, > some of which are a result of implementation artifacts and some are > unavoidable due to the nature of security and the spec itself. Making > things more complicated or breaking compatibility with widely used existing > implementations in order to satisfy an odd niche use case does not seem to > me like its advancing the cause in a helpful way. > > People today balk at managing a single PGP keypair across multiple devices > and applications, how in the world would they be expected to deal with 30+ > (and growing) keys? Perhaps this is all handled automatically by whatever > scheme you are developing and the user would never know or care that there > are 30+ keys in their domain, but as described it seems way complicated. > If you have complicated use cases, trying to make the spec too simple is a mistake. It is probably also a mistake to dismiss someone's work as 'niche' before you bother to read it. My approach to dealing with the usability blunders in S/MIME and OpenPGP is to design the system in such a way that the user does not need to be aware that they are using encryption except in the very rare situation where they want to make sure that the message is sent encrypted or not at all. The use case I am dealing with is precisely the problem of managing keys across multiple devices. And it is all entirely automatic. As far as the user is concerned, they only really have one key like thing that they need to worry about. Right now, there aren't many implications for OpenPGP bis. The main difference is working with a key signing key rather than the key itself. But that is pretty much inevitable if you want to deal with real world problems like Alice wanting to make sure that she can encrypt her hard drive and there is absolutely no way that it is at all possible. But those are discussions to have on therightkey@ietf.org. --001a11c368ccd47124051c198cd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 30, 2015 at 11:15 AM, Wyllys Ingersoll &l= t;wyllys@gmail.com> wrote:
OK, 'at least the 512 bit fingerprint'...=

Which you do probably depends on if you are using= ECC or RSA. With RSA, those 2048 bit keys start to bulk up...
For my particular implementation, I want to be able to rotate = encryption keys on a monthly basis or any time a device is added or removed= from a user's profile. so I am using fingerprints of key signing keys = rather than end-entity keys.

As a general rule, it= seems that you can solve pretty much any usability problem at the cost of = an additional key. Back in 1995, this would have ground the whole net to a = halt. Today it isn't a problem. Right now on my testbed Alice has a per= sonal profile of 3 keys, plus a device profile of 3 keys per device, plus i= ndividual keys for each use in application (1+1 per device for email, 1 for= 2 factor auth, 1 for admin, 1 for data encryption, 1 for drive encryption)= . So assuming Alice has 2 desktops, a laptop, a tablet, a phone and a watch= , that is 3 + 18 + 7 + 6 =3D 30 keypairs and an additional one per month.

It might sound a bit extreme, but since I started i= n the business, machines have gotten roughly a million times faster and hav= e a million times the memory. 30 keypairs instead of one does not seem like= a big deal.=C2=A0

=
Really?=C2=A0 It sure does to me.=C2=A0 PGP suffers f= rom numerous usability issues, some of which are a result of implementation= artifacts and some are unavoidable due to the nature of security and the s= pec itself.=C2=A0 Making things more complicated or breaking compatibility = with widely used existing implementations in order to satisfy an odd niche = use case does not seem to me like its advancing the cause in a helpful way.=

People today balk at managing a single PGP keypai= r across multiple devices and applications, how in the world would they be = expected to deal with 30+ (and growing) keys?=C2=A0 Perhaps this is all han= dled automatically by whatever scheme you are developing and the user would= never know or care that there are 30+ keys in their domain, but as describ= ed it seems way complicated.

<= div>If you have complicated use cases, trying to make the spec too simple i= s a mistake. It is probably also a mistake to dismiss someone's work as= 'niche' before you bother to read it. My approach to dealing with = the usability blunders in S/MIME and OpenPGP is to design the system in suc= h a way that the user does not need to be aware that they are using encrypt= ion except in the very rare situation where they want to make sure that the= message is sent encrypted or not at all.




--001a11c368ccd47124051c198cd6-- From nobody Thu Jul 30 08:48:28 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EDA1B2C80 for ; Thu, 30 Jul 2015 08:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKV6bo5bEDJX for ; Thu, 30 Jul 2015 08:48:25 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAEC1B2C62 for ; Thu, 30 Jul 2015 08:48:18 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 17B53F984; Thu, 30 Jul 2015 11:48:16 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2590E2022A; Thu, 30 Jul 2015 17:48:17 +0200 (CEST) From: Daniel Kahn Gillmor To: Phillip Hallam-Baker In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 30 Jul 2015 11:48:17 -0400 Message-ID: <87a8udd4u6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 15:48:27 -0000 On Thu 2015-07-30 10:44:48 -0400, Phillip Hallam-Baker wrote: > That does not mean we have to support those applications. But it does > mean that we have to write a security consideration telling people we > have (1) considered the issue and that (2) either it isn't a problem > or you should do stuff that is going to be affected. Completely agreed that the security considerations should make a point of calling out what we think are legitimate and illegitimate uses of a fingerprint. > The concern here is that Mallet generates two keys that have the > fingerprints > > Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and . > Mxxxx-xxxxx-xxxxx-xxxxx-xxxx2 'M2' > > Mallet joins an open source project which only takes the first 100 bits for > the fingerprint. He uploads the key for M1 to a keyserver. > > He then commits a large number of malicious patches using M2 for > authentication. These are all authenticated against his public key M2 when > he does the commit but the repository uses the key sent in band and does > not keep the key for later verification. > > At this point, any attempt to hold Mallet accountable is going to have to > rely on a human examining the logs and working out that Mallet must have > generated the malicious pair of keys. There is going to be no way to unwind > the thing automatically. In either scenario, the committed code is done by Mallet, who was explicitly authorized by the system to commit code. So the failure here is one of auditing, right? And i think the implementation recommendation that would solve the auditing problem here is "do not store fingerprints when you could be storing keys" -- right? Are there any other attacks we should be aware of due to failures of collision resistance in the fingerprint? > The connection is that each blockchain output can be used as an axiom of > trust. I don't know what an "axiom of trust" is, or why i would believe that anything coming out of the blockchain would be one. The properties i think you're asking for are those of a global, append-only log. whether that's implemented by a blockchain or not seems like an implementation detail. > Since the purpose of fingerprints is to represent roots of trust, this > is a possible use case that the spec should be capable of > accommodating without opening up the question of how precisely that > would be achieved. Sure, so i think we're saying that fingerprints should be well-defined enough to be entered into a global append-only log. Do we need more than that? >> > The other bit I left out is the idea of compression. The idea here being >> > that the person generating the key looks for a fingerprint that has 0s for >> > the first n bits. Then the fingerprint starts with a version number that >> > says 'the first 32 bits are 0s' or whatever. >> [...] >> > My preference is to just truncate and use the inferred length. That >> allows >> > us to minimize the amount of data we need to put in front of the user >> > without compromising security. >> >> These two proposals seem incompatible to me. If you give me a >> fingerprint that is shorter than the expected length, and both >> mechanisms are available, how am i supposed to know whether you've given >> me a truncated fingerprint or a "compressed" fingerprint? > > Well, the fingerprint version tag would have to flag that encryption is > being used. So instead of the fingerprint being Mxxxx-.... (SHA2-512) or > Sxxxx-... (SHA3-512), it might be Xxxxx-... By "encryption" do you mean truncation or "leading-zero compression"? it seems like we're starting to come up with multidimensional representations of fingerprint formats. I'm already uneasy with the idea of having multiple forms of fingerprint -- if i'm given form M on my peer's business card, and then i'm shown a key by my software that uses form S (or form XS or form XM or whatever) how am i supposed to compare them? >> Wouldn't the phone just store the key itself instead of the >> fingerprint? Why does the fingerprint matter in this scenario after >> the initial introduction? > > OK, 'at least the 512 bit fingerprint'... > > Which you do probably depends on if you are using ECC or RSA. With RSA, > those 2048 bit keys start to bulk up... [...] > It might sound a bit extreme, but since I started in the business, machines > have gotten roughly a million times faster and have a million times the > memory. 30 keypairs instead of one does not seem like a big deal. Following this logic, i think the answer is still that the endpoints should store the keys that they think are currently valid and not the fingerprints. Fingerprints aren't for storage, they're either for discovery or for verification. --dkg From nobody Thu Jul 30 09:45:31 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3121F1A90ED for ; Thu, 30 Jul 2015 09:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzdvaty5dJKy for ; Thu, 30 Jul 2015 09:45:27 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100581A9108 for ; Thu, 30 Jul 2015 09:45:24 -0700 (PDT) Received: from localhost (gate.ibr.cs.tu-bs.de [134.169.34.1]) by mail.mugenguild.com (Postfix) with ESMTPSA id EC8645FCD9; Thu, 30 Jul 2015 18:41:25 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> From: Vincent Breitmoser To: Phillip Hallam-Baker In-reply-to: Date: Thu, 30 Jul 2015 18:45:05 +0200 Message-ID: <87mvyd7fxq.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 16:45:29 -0000 On 30 Jul 2015, Phillip Hallam-Baker wrote: > OK, 'at least the 512 bit fingerprint'... How are we even back to talking about 512 bit fingerprints? I'm getting a feeling we are starting to repeat everything that was discussed in the original "fingerprints" thread here. - V From nobody Thu Jul 30 13:30:26 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E851ACE9E; Thu, 30 Jul 2015 13:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys3GFmh6fYVH; Thu, 30 Jul 2015 13:30:23 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBC31ACE77; Thu, 30 Jul 2015 13:30:22 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t6UKU4PL024041 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 30 Jul 2015 22:30:05 +0200 From: Simon Josefsson To: Paul Wouters References: <87si8dagiz.fsf@vigenere.g10code.de> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150730:ogud@ogud.com::BKQTMAmbI0+O6qYE:4u7f X-Hashcash: 1:22:150730:paul@nohats.ca::O5LAUn6/NBOzLkEr:Jjy6 X-Hashcash: 1:22:150730:wk@gnupg.org::REuC5UBXS/4ET53T:MoJq X-Hashcash: 1:22:150730:openpgp@ietf.org::Y++BJQc0ysdtvZAf:Mt3U X-Hashcash: 1:22:150730:dane@ietf.org::+bKdhcCx134st6Xs:Nvac X-Hashcash: 1:22:150730:phill@hallambaker.com::fRCIlYoSkT55G9U2:DdO+ Date: Thu, 30 Jul 2015 22:30:03 +0200 In-Reply-To: (Paul Wouters's message of "Sat, 25 Jul 2015 08:19:04 -0400 (EDT)") Message-ID: <87fv45v16c.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Werner Koch , IETF OpenPGP , Phillip Hallam-Baker , Olafur Gudmundsson , dane WG list Subject: Re: [openpgp] The DANE 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: Thu, 30 Jul 2015 20:30:24 -0000 --=-=-= Content-Type: text/plain Paul Wouters writes: >> Here are some thoughts, anyway: >> >> - Why a new DNS record despite that the CERT type has PGP support for >> 9 years now (RFC-4398). >> >> The argument for a new record is that this makes parsing easier >> because there is no need to loop over the record's sub-types. I do >> not consider it a valid argument because there is a need to loop >> anyway because there may be several DANE records for the same key. >> Adding an extra loop over the sub-types is a non-brainer and the >> selection logic to find the best matching record will be the same. > > Using subtypes for DNS is something the DNS people in general have > concluded to be a wrong idea. As stated before, even Olafur who is one > of the authors of the CERT RRtype advised us not to use CERT (or > subtyping in general) Then I believe that community should attempt to move RFC 2538/4398 to historic. I don't believe there is sufficient consensus for doing that -- there is good use of CERT records already, although limited. > Additionally, because the CERT record is a meta-container record, > support for CERT is not good because to properly parse it you need > all of openpgp and all of x509 and all of what other subtypes would > be added later on. So instead of implementing CERT records partially, > many DNS implementations just did not bother with it at all. I disagree -- CERT can be implemented without understanding any of OpenPGP or X.509, and it is implemented by DNS software already. >> GnuPG has support for such CERT records including a script to create >> them also for about 9 years. It is not widely used because most users >> have no way to add records to their zone - that is the same problem >> for DANE of course. > > CERT wasn't widely used because frankly pgp is not widely used. Also, > CERT without DNSSEC makes no sense This is false -- CERT makes a lot of sense without DNSSEC, as OpenPGP keys can be verified through the web of trust. I don't believe comparing deployment sizes should be a deciding factor in this context, but I disagree with your notion that OpenPGP is not widely used. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVuolLAAoJEIYLf7sy+BGdGOAH/29XBaHqu5JT5gEoX899dsdA dbvIalfTQYxjZRDAuS8sX7f/q+Sq9H7HlsbhFcWccOg0C0YplemAOOBqLzSIsta7 //jq3FuA+7ghbG0w+JfnbVy8FdS47eWjBw/AzxnMUvRuw0mOfTzoZHXchPIQ1olb pqQ4usg4oheL6G93NN08Z2ktkpCB1+QBpP1FWiOIkEh7Gk49Lz8/o9+wuw3EpveY KAI2yENmh2IVPt6srYdxcr0itTLcjCZE9oCnVhIVLIIS8MJVfwfHOqR6Oh+9o7l3 Al+QehBihbi6pPxBjHyW8UaC4hrCcHL2zUKi1ZbVZZwsJWjRSmJUrUh6hJBPtXk= =YrH9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 31 06:28:53 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10A71A87A8 for ; Fri, 31 Jul 2015 06:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJSKZ6Z63k-P for ; Fri, 31 Jul 2015 06:28:50 -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 4FDC51A87A4 for ; Fri, 31 Jul 2015 06:28:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C60F6E2035; Fri, 31 Jul 2015 09:28:48 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12935-03; Fri, 31 Jul 2015 09:28:46 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 8307FE2034; Fri, 31 Jul 2015 09:28:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1438349326; bh=FXaGDh4jRTuvr1UZ63xIy+0jtRSmf9Fpvry0fDKXhMU=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=BRGVFuMCKhy7ik0fj3T0dOpwVy0ttbvXg7lW7pc/wqVE9lZZrShOVoH95GM6B7T7a /pA8cc7wnQQSCajkjFI++zymQesowT7q98ydGMbMInZImxt+Ei2TM2rfsom2x5lwi/ 2APBCYsYP0tDBH7IdJLFy4uqRBLcBzsyAxHr3bAo= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t6VDSjK5026223; Fri, 31 Jul 2015 09:28:45 -0400 From: Derek Atkins To: Daniel Kahn Gillmor References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> Date: Fri, 31 Jul 2015 09:28:45 -0400 In-Reply-To: <87a8udd4u6.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 30 Jul 2015 11:48:17 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Phillip Hallam-Baker , IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 13:28:52 -0000 Daniel Kahn Gillmor writes: > On Thu 2015-07-30 10:44:48 -0400, Phillip Hallam-Baker wrote: >> That does not mean we have to support those applications. But it does >> mean that we have to write a security consideration telling people we >> have (1) considered the issue and that (2) either it isn't a problem >> or you should do stuff that is going to be affected. > > Completely agreed that the security considerations should make a point > of calling out what we think are legitimate and illegitimate uses of a > fingerprint. > >> The concern here is that Mallet generates two keys that have the >> fingerprints >> >> Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and . >> Mxxxx-xxxxx-xxxxx-xxxxx-xxxx2 'M2' >> >> Mallet joins an open source project which only takes the first 100 bits for >> the fingerprint. He uploads the key for M1 to a keyserver. >> >> He then commits a large number of malicious patches using M2 for >> authentication. These are all authenticated against his public key M2 when >> he does the commit but the repository uses the key sent in band and does >> not keep the key for later verification. >> >> At this point, any attempt to hold Mallet accountable is going to have to >> rely on a human examining the logs and working out that Mallet must have >> generated the malicious pair of keys. There is going to be no way to unwind >> the thing automatically. Why? M1 and M2 are completely different fingerprints, unless you're assuming that the x's are the same. If the x's are the same that means that Mallet has performed a 2^50 level attack to get 100 bits to match! How long and how much energy does Mallet have to do this? It's certainly not something s/he is going to do over a long weekend! > In either scenario, the committed code is done by Mallet, who was > explicitly authorized by the system to commit code. So the failure here > is one of auditing, right? > > And i think the implementation recommendation that would solve the > auditing problem here is "do not store fingerprints when you could be > storing keys" -- right? > > Are there any other attacks we should be aware of due to failures of > collision resistance in the fingerprint? I'll note that this attack isn't due to a failure of collision resistance in the fingerprint. It's an attack due to the application (on top of OpenPGP) truncating the fingerprint and throwing away extra data. Personally I don't see this as a bug in OpenPGP -- the data is there in the OpenPGP data structures. I see this as a bug in the application built on top of OpenPGP that is throwing away data. It's also an authorization issue; at some point someone needed to authorize the M1 and M2 keys to commit, so someone *saw* the full fingerprint at some point. The fact that someone looked at the full fingerprint and then threw away 60 bits just means they did a poor design. [snip] >> Which you do probably depends on if you are using ECC or RSA. With RSA, >> those 2048 bit keys start to bulk up... > [...] >> It might sound a bit extreme, but since I started in the business, machines >> have gotten roughly a million times faster and have a million times the >> memory. 30 keypairs instead of one does not seem like a big deal. > > Following this logic, i think the answer is still that the endpoints > should store the keys that they think are currently valid and not the > fingerprints. Fingerprints aren't for storage, they're either for > discovery or for verification. Or identification (e.g., the fingerprint/keyID of a signing key). But yes, the full key should be stored on the service when Mallet registered. There's yet another bug in the service (not OpenPGP) -- not storing the keys of authorized users. > --dkg -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 31 11:31:15 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1EB1B3443 for ; Fri, 31 Jul 2015 11:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdhN-JXLg642 for ; Fri, 31 Jul 2015 11:31:13 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3871B3434 for ; Fri, 31 Jul 2015 11:31:12 -0700 (PDT) Received: by lbqc9 with SMTP id c9so25802079lbq.1 for ; Fri, 31 Jul 2015 11:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Juv16e10VChUXdU0UANVyXLFHRyWYGu1QQBA+X/R85w=; b=nBdJYbrtAlkH0bH70gk4J6pj0E+z+CpaZiLffzIim2CHxFOi29V5D5NdUGhSkhS1IN NZWuQp+B70fGbwJFujzxtARUPVCvhmYoCA2m8oLlBSrdd2xk1jgBX8RDzX+HRaPwKoiH VX81KX+4j+q3t6IRFTnmRmzUvm8ANrYpaSuGRxVREvdLLW63wfNgVHYeFPtD77rlAaUi h4BfA+RMtQ3GCji6rVYxAVBNlWqoPHC7BPvwbH1Zj5xOQI/FGxwFmS5fy3byLj6gOp6x b+QypjornjFNYeYgPxS9qGLx6jNamKSA8ZhWE12vVNxjbAAGS76qoBEylLj5rF6R2CP4 gaRw== MIME-Version: 1.0 X-Received: by 10.152.2.2 with SMTP id 2mr4638800laq.58.1438367471414; Fri, 31 Jul 2015 11:31:11 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 31 Jul 2015 11:31:11 -0700 (PDT) In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> Date: Fri, 31 Jul 2015 14:31:11 -0400 X-Google-Sender-Auth: LarZs7mbT3Jfq6rXFIMdAzXGiIw Message-ID: From: Phillip Hallam-Baker To: Derek Atkins Content-Type: multipart/alternative; boundary=089e013c647030b5a1051c3006a9 Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:31:14 -0000 --089e013c647030b5a1051c3006a9 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 9:28 AM, Derek Atkins wrote: > Daniel Kahn Gillmor writes: > > >> At this point, any attempt to hold Mallet accountable is going to have > to > >> rely on a human examining the logs and working out that Mallet must have > >> generated the malicious pair of keys. There is going to be no way to > unwind > >> the thing automatically. > > Why? M1 and M2 are completely different fingerprints, unless you're > assuming that the x's are the same. If the x's are the same that means > that Mallet has performed a 2^50 level attack to get 100 bits to match! > How long and how much energy does Mallet have to do this? It's > certainly not something s/he is going to do over a long weekend! Not with RSA keys. With ECC keys, different matter entirely. > > Are there any other attacks we should be aware of due to failures of > > collision resistance in the fingerprint? > > I'll note that this attack isn't due to a failure of collision > resistance in the fingerprint. It's an attack due to the application > (on top of OpenPGP) truncating the fingerprint and throwing away extra > data. > Which is makes this a Security Consideration. If people build 'stuff' on top of OpenPGP as a foundation then they have to understand what the foundation is designed to support. I think a 25 character / 125 bit fingerprint is going to be fine. BUT there are two issues I don't want to come up. One is someone builds something that depends on the fingerprints being collision resistant and blames it on the spec. The second is that some yahoo works this out again in five years time and writes a paper claiming to have 'broken' the spec. --089e013c647030b5a1051c3006a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 9:28 AM, Derek Atkins <derek@ihtfp.com> wrote:
Daniel Kahn= Gillmor <dkg@fifthhorseman.net= > writes:

>> At this point, any attempt to hold Mallet accountable is going to = have to
>> rely on a human examining the logs and working out that Mallet mus= t have
>> generated the malicious pair of keys. There is going to be no way = to unwind
>> the thing automatically.

Why?=C2=A0 M1 and M2 are completely different fingerprints, unless y= ou're
assuming that the x's are the same.=C2=A0 If the x's are the same t= hat means
that Mallet has performed a 2^50 level attack to get 100 bits to match!
How long and how much energy does Mallet have to do this?=C2=A0 It's certainly not something s/he is going to do over a long weekend!

Not with RSA keys. With ECC keys, different matter en= tirely.


> Are there any other attacks we should be aware of due to failures of > collision resistance in the fingerprint?

I'll note that this attack isn't due to a failure of collisi= on
resistance in the fingerprint.=C2=A0 It's an attack due to the applicat= ion
(on top of OpenPGP) truncating the fingerprint and throwing away extra
data.

Which is makes this a Security Co= nsideration. If people build 'stuff' on top of OpenPGP as a foundat= ion then they have to understand what the foundation is designed to support= .

I think a 25 character / 125 bit fingerprint is = going to be fine. BUT there are two issues I don't want to come up. One= is someone builds something that depends on the fingerprints being collisi= on resistant and blames it on the spec. The second is that some yahoo works= this out again in five years time and writes a paper claiming to have '= ;broken' the spec.
--089e013c647030b5a1051c3006a9-- From nobody Fri Jul 31 11:54:53 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6B51B2F37 for ; Fri, 31 Jul 2015 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51cxd5KlMgtG for ; Fri, 31 Jul 2015 11:54:49 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F611ACC89 for ; Fri, 31 Jul 2015 11:54:49 -0700 (PDT) Received: from localhost (p5481C3F2.dip0.t-ipconnect.de [84.129.195.242]) by mail.mugenguild.com (Postfix) with ESMTPSA id 868CE5FC53; Fri, 31 Jul 2015 20:50:49 +0200 (CEST) References: <87twsn2wcz.fsf@vigenere.g10code.de> <87zj2ecmv8.fsf@alice.fifthhorseman.net> <87a8udd4u6.fsf@alice.fifthhorseman.net> From: Vincent Breitmoser To: Phillip Hallam-Baker In-reply-to: Date: Fri, 31 Jul 2015 20:54:43 +0200 Message-ID: <87k2tg6tu4.fsf@littlepip.fritz.box> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP , Derek Atkins , Daniel Kahn Gillmor Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 18:54:52 -0000 On 31 Jul 2015, Phillip Hallam-Baker wrote: > I think a 25 character / 125 bit fingerprint is going to be > fine. BUT there are two issues I don't want to come up. One is > someone builds something that depends on the fingerprints being > collision resistant and blames it on the spec. The second is that > some yahoo works this out again in five years time and writes a > paper claiming to have 'broken' the spec. We can just mention that fingerprints are not (meant to be) collision resistant in the spec, that should take care of that. - V From nobody Fri Jul 31 17:54:08 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31551ACEA2 for ; Fri, 31 Jul 2015 17:54:07 -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 SCcFWUOd6dSZ for ; Fri, 31 Jul 2015 17:54:06 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAD21ACE96 for ; Fri, 31 Jul 2015 17:53:22 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id EC12F6D749; Fri, 31 Jul 2015 20:53:20 -0400 (EDT) Message-ID: <55BC187F.1070300@iang.org> Date: Sat, 01 Aug 2015 01:53:19 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <87twsn2wcz.fsf@vigenere.g10code.de> <87si870zqy.fsf@vigenere.g10code.de> In-Reply-To: <87si870zqy.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 00:54:08 -0000 On 29/07/2015 16:06 pm, Werner Koch wrote: > On Wed, 29 Jul 2015 16:31, phill@hallambaker.com said: > >> On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch wrote: > >>> OpenPGP does not specify a user interface but the wire format. >>> Obviously we use the most compact format there which is the plain binary >>> format. The questions are >>> >> >> That is how we used to work in the 1990s. Since then we have had to do >> internationalization and such. > > I can't see what internationalization has to do with the binary > representation of a fingerprint. As I said RFC-4880 is about the wire > format and not about user interfaces: It tells how to compute a > fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1 > hash. Now that a fingerprint is printed like this > > pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] > Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 > > is the choice of the concrete implementation. It is an interesting idea > to have a common way of representing fingerprints to the user or in an > URL but that is not in the scope of RFC-4800bis. I thought we were agreed on all that and there was a separate draft that PHB had written that just covered fingerprints for the user? Ie, we've cut this out of 4880(bis) because it has merit but it doesn't belong there. iang (mystified, am I imagining this separate document?) From nobody Fri Jul 31 18:29:06 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC16A1A1A4B for ; Fri, 31 Jul 2015 18:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZBxhpLKbc4W for ; Fri, 31 Jul 2015 18:29:03 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FA31A07BD for ; Fri, 31 Jul 2015 18:29:03 -0700 (PDT) Received: by iodd187 with SMTP id d187so101140245iod.2 for ; Fri, 31 Jul 2015 18:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RhJCIN31wTsAnG0TDe+zwvNLdERDz5i+61cCcWmOBnI=; b=NNXd2mqoCCgpHzGgK7hRAcMR3JP2iQfe9I6oDONCsF7SaELkBnQqSMVIVtzdWj1aP/ DLTzvzLR22zEkQRA9WkezYvR8q1O7m2ixqtxenJpdXj6uqS90v2WD32N0O+8mPPVXRNj 3ytSN1eehud+vZmAnm/Y/qNr/WlNu50pWFLzFVzMG1oRylPtFwds0aNJF5HpEja/8l+w CvuLcjrQc1oApFbfDb5VIQCWAEmuiLdbQsuSplrbH0ouST9RV5euX9D6YlIiTjNCKkxB rlSwby2Vk/DbRgyRWPR0yZZKqYXAz1BdGn40nEsPlB/pIRN+voS1H6txXVuKZl3EozLB IHFg== MIME-Version: 1.0 X-Received: by 10.107.132.15 with SMTP id g15mr9811964iod.134.1438392542494; Fri, 31 Jul 2015 18:29:02 -0700 (PDT) Received: by 10.107.48.212 with HTTP; Fri, 31 Jul 2015 18:29:02 -0700 (PDT) In-Reply-To: References: <87twsn2wcz.fsf@vigenere.g10code.de> Date: Sat, 1 Aug 2015 01:29:02 +0000 Message-ID: From: Gregory Maxwell To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 01:29:05 -0000 On Wed, Jul 29, 2015 at 2:31 PM, Phillip Hallam-Baker wrote: > other bit that should be mentioned in the security considerations is > vanity fingerprints which are going to be more popular with all 26 Latin > letters to choose from. And those are a bad idea for the reason given in the > meeting. If my key starts off 'MERLI-Nxxxx' there is a temptation to only > check those bits. To be clear, there are two attack vectors I'm aware of in the space of user-factors around digest for visual comparison by users. One is that users are more likely to trust vanity identifiers (fingerprints that spell out specific words), "it says right there in the fingerprint, it must be right". The second, is that users will tend to much more strongly compare only the vanity portion and ignore the following line noise; and thus be more vulnerable to substution than they would be with ordinary randomly selected identifiers; as the attacker need focus only on matching the vanity part (which will necessarily be small owing to the computational resources of the actual user). This conjecture has been experimentally validated both with Bitcoin addresses (base58) and (especially) Tor hidden services (base32): At one time there were several hundred silkroadXXXXXX onions addresses active and being used to scam people. I don't think there is much room left to debate that schemes which better accommodate 'vanity' identifiers are more vulnerable in practice. Devoweled encodings seems somewhat safer in that they're less likely to get appriciable vanity use (and also less likely to spell offensive words). Beyond your suggestion to make fingerprints purposefully expensive to create, another possibility it encouraging comparison methods which are more robust. E.g. here is a cut-and-choose based scheme I had previously implemented-- it uses a much larger digest and then encourages the user to compare an actually random subset of it: https://en.bitcoin.it/wiki/User:Gmaxwell/visual_fingerprint_comparison From nobody Fri Jul 31 18:49:13 2015 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E881A6F0A for ; Fri, 31 Jul 2015 18:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMg_dCdebwrl for ; Fri, 31 Jul 2015 18:49:10 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057451A6EE6 for ; Fri, 31 Jul 2015 18:49:10 -0700 (PDT) Received: by lbqc9 with SMTP id c9so29868774lbq.1 for ; Fri, 31 Jul 2015 18:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1nEDga4uriPCCRv08i027hYXl/aIqOJvKlj1sSH+/Vw=; b=A39UE+zQEwgnI3ja4GD68h828ArcC+pNULmd8zMtQWeajS9qoEBMNyaVvh2gi3yz3J a7RVm8SFMTRCZp+f4IMmziuY2h4XOEkign7iwuv6tpZc0792eft+F6HxL2hPA3fbwNdo x0X27BTWRieplcVg8g3dAY4UmLqtmx3OS0o43yJQV79NBtDdtJDGlMAHY4A382LZasZO sR35puhHm1iywmZpomXepdJVzeIyHvIG9ZaLbA5L53RQzr1mKfNkFPPVEtPKoW4QP/X8 cMdiE+xkFlf2hMyEgP0AhDs/TB3jJe7A7Ebosu9PQYYLKTJnQ2LzW/6LFhypC5X9mm4C xHyg== MIME-Version: 1.0 X-Received: by 10.112.126.42 with SMTP id mv10mr6498580lbb.58.1438393748462; Fri, 31 Jul 2015 18:49:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Fri, 31 Jul 2015 18:49:08 -0700 (PDT) In-Reply-To: <55BC187F.1070300@iang.org> References: <87twsn2wcz.fsf@vigenere.g10code.de> <87si870zqy.fsf@vigenere.g10code.de> <55BC187F.1070300@iang.org> Date: Fri, 31 Jul 2015 21:49:08 -0400 X-Google-Sender-Auth: 6xnoCzvNQxzx5Lw2ndPmSKeGA1M Message-ID: From: Phillip Hallam-Baker To: ianG Content-Type: multipart/alternative; boundary=001a11c36bc66ca46b051c362462 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Followup on fingerprints X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 01:49:12 -0000 --001a11c36bc66ca46b051c362462 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 31, 2015 at 8:53 PM, ianG wrote: > On 29/07/2015 16:06 pm, Werner Koch wrote: > >> On Wed, 29 Jul 2015 16:31, phill@hallambaker.com said: >> >> On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch wrote: >>> >> >> OpenPGP does not specify a user interface but the wire format. >>>> Obviously we use the most compact format there which is the plain binary >>>> format. The questions are >>>> >>>> >>> That is how we used to work in the 1990s. Since then we have had to do >>> internationalization and such. >>> >> >> I can't see what internationalization has to do with the binary >> representation of a fingerprint. As I said RFC-4880 is about the wire >> format and not about user interfaces: It tells how to compute a >> fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1 >> hash. Now that a fingerprint is printed like this >> >> pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] >> Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 >> B367 >> >> is the choice of the concrete implementation. It is an interesting idea >> to have a common way of representing fingerprints to the user or in an >> URL but that is not in the scope of RFC-4800bis. >> > > > I thought we were agreed on all that and there was a separate draft that > PHB had written that just covered fingerprints for the user? > > Ie, we've cut this out of 4880(bis) because it has merit but it doesn't > belong there. > > > > iang (mystified, am I imagining this separate document?) You are riight. https://tools.ietf.org/html/draft-hallambaker-udf-00 I will rename the next one with OpenPGP in the title so the search tools can find it. The plan is a separate document that essentially only tracks stuff related to OpenPGP but can be built on by others elsewhere. --001a11c36bc66ca46b051c362462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 31, 2015 at 8:53 PM, ianG <iang@iang.org> wrote:=
On 29/07/2015 16:06 pm,= Werner Koch wrote:
On Wed, 29 Jul 2015 16:31, phill@hallambaker.com said:

On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch <wk@gnupg.org> wrote:

OpenPGP does not specify a user interface but the wire format.
Obviously we use the most compact format there which is the plain binary format.=C2=A0 The questions are


That is how we used to work in the 1990s. Since then we have had to do
internationalization and such.

I can't see what internationalization has to do with the binary
representation of a fingerprint.=C2=A0 As I said RFC-4880 is about the wire=
format and not about user interfaces: It tells how to compute a
fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1
hash.=C2=A0 Now that a fingerprint is printed like this

pub=C2=A0 =C2=A0dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] =C2=A0 =C2=A0 =C2=A0 =C2=A0Key fingerprint =3D 8061 5870 F5BA D690 3336=C2= =A0 86D0 F2AD 85AC 1E42 B367

is the choice of the concrete implementation.=C2=A0 It is an interesting id= ea
to have a common way of representing fingerprints to the user or in an
URL but that is not in the scope of RFC-4800bis.


 I thought we were agreed on all that and there was a separate draft that PH= B had written that just covered fingerprints for the user?

Ie, we've cut this out of 4880(bis) because it has merit but it doesn&#= 39;t belong there.



iang (mystified, am I imagining this separate document?)
<= br>
You are riight.


I will rename the= next one with OpenPGP in the title so the search tools can find it. The pl= an is a separate document that essentially only tracks stuff related to Ope= nPGP but can be built on by others elsewhere.
--001a11c36bc66ca46b051c362462--