From nobody Wed Nov 7 07:29:08 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB2A130DCA for ; Wed, 7 Nov 2018 07:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV5PKLt_c1aD for ; Wed, 7 Nov 2018 07:29:04 -0800 (PST) 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 8D9BD130DC8 for ; Wed, 7 Nov 2018 07:29:04 -0800 (PST) Received: from localhost (w0953.wlan.rz.tu-bs.de [134.169.203.191]) by mail.mugenguild.com (Postfix) with ESMTPSA id 668615FA76 for ; Wed, 7 Nov 2018 16:29:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1541604542; bh=iCK+m2kHAJJ0uO3BhiQzuGpRIW65UbyK2ITBLNvkfoM=; h=Date:From:To:Subject:Autocrypt:From; b=AZ0I+wNJksATARkA1Fl4PDnxQnHsZK5diQo9rjG8ZrKH3tdLzflUkJHtglIYRKTUD DdawIrKnuDr6KKd3mE1v1vdqRWwlNb7k0eBVNSaksRVS+M0lQl8Vk1rv70EE0mDxCT VNls1KxCshYvu9/7qUKq1JIBpnkBsRir697zpcsU= Message-Id: Date: Wed, 07 Nov 2018 16:28:59 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: openpgp@ietf.org Cc: Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 15:29:07 -0000 Hey folks, I'd like to get some opinions on a thing: When a message is encrypted to a public key whose key flags indicate that it may not be used for encryption - should the receiving implementation still decrypt data using this key? Personally I think the only cryptographically sane thing to do is to reject the data. There is no valid use case for this, and if it happens it's either a bug or an attack happening. I would also welcome a clarification in the spec that explicitly stated that a key MUST not be used for purposes that aren't indicated by its key flags. The reason why I bring this up is that it does come up in practice and at the moment, there is no consensus on how to handle such a case between OpenKeychain and GnuPG. See: https://github.com/open-keychain/open-keychain/issues/2413 https://dev.gnupg.org/T4235 Cheers - V From nobody Wed Nov 7 11:49:25 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5394A127B92 for ; Wed, 7 Nov 2018 11:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 s261cIfoPBG8 for ; Wed, 7 Nov 2018 11:49:21 -0800 (PST) Received: from chiark.greenend.org.uk (v6.chiark.greenend.org.uk [IPv6:2001:ba8:1e3::]) (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 A5098127133 for ; Wed, 7 Nov 2018 11:49:21 -0800 (PST) Received: by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with local (return-path ijackson@chiark.greenend.org.uk) id 1gKTpI-0001Kv-4q; Wed, 07 Nov 2018 19:49:20 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23523.16831.292658.490356@chiark.greenend.org.uk> Date: Wed, 7 Nov 2018 19:49:19 +0000 To: openpgp@ietf.org CC: Werner Koch X-Mailer: VM 8.2.0b under 24.4.1 (i586-pc-linux-gnu) Archived-At: Subject: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 19:49:23 -0000 I was referred here https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ I'm not sure exactly what the status of this I-D is or whether the openpgp ietf list is the right place, but it seems to be the best place to send comments. I. URL final pathname component format It specifies a URL format ending in a base-32-encocded SHA-1 of a mangled version of the email address associated with the PGP key. This seems rather odd. 1. SHA-1 is obsolete. 2. The use of a cryptographic hash here makes it harder for a server to conduct an appropriate lookup. For example, if a server defines that all email addresses alice+@example.com are owned by Alice, and Alice tells the server `please advertise my one OpenPGP key for all my email addresses', it is not clear how the server could implement that. 2a. The cryptographic hash does not, however, provide any significant degree of useful obfuscation since a search will usually be able to reverse it. 2b. The cryptographic hash is not needed for space reasons since URLs can easily be as long as email addresses. 3. Supposing the hash were to be retained, choice of base-32 rather than base-64 is unusual and needs to be justified. 4. The lowercasing of the email address is contrary to the Internet mail specifications, where case-sensitivity of the email address is up to the mail domain in question. If the email address were not obfuscated by hashing it would be easy for the webserver to handle case-sensitivity by URL remapping. Suggested modification: Replace this part of the URL with the URL-encoded email address. II. URL domain name part The mail system for some domain, and its web server, are not necessarily on the same host or under the same practical administration. Often webservers are outsourced. Trying to provide this .well-known/openpgpkey subpath may therefore involve complicated interactions between different teams or even different organisations entirely. Furthermore, the webserver may be less secure than the mail system; whereas this protocol assumes that it is at least as secure. Suggested modification: the domain name part should have a fixed string prepended. III. Normative status of this document I was referred to this I-D from this trail of web pages: https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept https://wiki.gnupg.org/WKDDetails which I reached from someone who asked whether they should deploy this system. This seems a bit odd. Ian. -- Ian Jackson These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. From nobody Wed Nov 7 14:11:38 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3655B1294D7 for ; Wed, 7 Nov 2018 14:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS0uYGszi1Ct for ; Wed, 7 Nov 2018 14:11:34 -0800 (PST) Received: from st14p23im-asmtp003.me.com (st14p23im-asmtp003.me.com [17.164.101.13]) (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 51AE71286E3 for ; Wed, 7 Nov 2018 14:11:34 -0800 (PST) Received: from process-dkim-sign-daemon.st14p23im-asmtp003.me.com by st14p23im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PHU01000FBG3C00@st14p23im-asmtp003.me.com> for openpgp@ietf.org; Wed, 07 Nov 2018 22:11:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1541628693; bh=LpFOzOGjD7tEwSmsO2+9HKikOxrASJJ+JQoMgUybjHE=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=ggZu7R75tZFsEDM21E4zp5IABP6XKlJVdxJjARo1wgiNrHMwFwYYJkgwNhu7hNmpE nrhjQjYAfwy8GRYZqfJtCT8PmZM6fDZ7jdpiCi1ybyq7Lc+SYCgj5vPsGYxAnYwQ7V RfB41V8PXDLs/tftIhmZ0YQgOOVdV/dSwQeWFTXF7fxOxIqmXxfnFzCr3tB/gfUuZE qF95gAcz1Fm5NAYiANt+1fy2AezJ4wSmfEc/aPNIKLcRpNL2yrGVg0BOD2Hdw17l0e Avc5wc2x5rDi80NH/UAbvzDofgny18MOLFarzpmebkMAvkm4436VmIeBU657AustRF kXoLOVdnG4QGw== Received: from icloud.com ([127.0.0.1]) by st14p23im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PHU003W0GB6VL20@st14p23im-asmtp003.me.com>; Wed, 07 Nov 2018 22:11:32 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811070196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-07_18:,, signatures=0 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Jon Callas In-reply-to: Date: Wed, 07 Nov 2018 14:11:29 -0800 Cc: Jon Callas , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> References: To: Vincent Breitmoser X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 22:11:36 -0000 > On Nov 7, 2018, at 7:28 AM, Vincent Breitmoser = wrote: >=20 >=20 > Hey folks, >=20 > I'd like to get some opinions on a thing: >=20 > When a message is encrypted to a public key whose key flags indicate = that it may > not be used for encryption - should the receiving implementation still = decrypt > data using this key? >=20 > Personally I think the only cryptographically sane thing to do is to = reject the > data. There is no valid use case for this, and if it happens it's = either a bug > or an attack happening. I would also welcome a clarification in the = spec that > explicitly stated that a key MUST not be used for purposes that aren't = indicated > by its key flags. I disagree.=20 Before going further, let=E2=80=99s remember that if I set up my key so = that I have a signing key and an encryption key (or even no encryption = key), and Alice sent me something encrypted to my signing key, it=E2=80=99= s *Alice* who has broken protocol, not me. Why punish me because someone = else has a broken implementation? Also let me say that if there=E2=80=99s an implementation that wants to = do this, that=E2=80=99s fine. What I=E2=80=99m objecting to is that this = would be in OpenPGP. OpenPGP oughta say that an implementation MUST NOT = encrypt to a sign-only key, but it should leave it at that. Additionally, I see nothing wrong with an implementation letting me know = that this thing it decrypted was encrypted to my signing key. In fact, = I=E2=80=99d prefer to be told that. I can think of circumstances in = which this is impractical, but in general, I=E2=80=99d like to be told.=20= If the software I run messes me up because someone else has a bug, I = think I am justified in saying that my software has a resiliency = problem. If the implementer came back and said that they do that because = the OpenPGP standard says they MUST NOT, my reply would be that then the = standard is broken with a resiliency problem.=20 Imagine this conversation between Alice, who has a broken = implementation, and me with a =E2=80=9Ccorrect one.=E2=80=9D Me: Hey Alice, here=E2=80=99s a note about, blah blah blah, let me = know what you think. Alice: Me: Alice, I can=E2=80=99t decrypt what you sent me because you = encrypted to my signing key. Could you re-encrypt to my encryption key? Alice: Me: No, it happened again, could you try that again? Alice: Okay, so what do I do know? Here are some options: * Change my key so that my signing-only key is dual-use. * Give Alice my coordinates on Signal, Wire, etc. * Send Alice an S/MIME cert for me and ask her to use that. It=E2=80=99s suboptimal to set things up so that a single badly-behaving = implementation can poison the community. It would be completely reasonable in this situation to promote that = signing-only keys are utterly broken because the XXX program doesn=E2=80=99= t handle it correctly and that means that you=E2=80=99re screwed when = someone picked the wrong software. It would be completely reasonable to = ask the people not use OpenPGP in any form at all, because you=E2=80=99re = screwed by this situation. In short, the standard should not mandate fragile, brittle, or = user-surly behavior. The standard should not forbid resiliency in the = face of a bug. We have one instance in the standard of mandated fragility, and that=E2=80= =99s the Critical flag in some sub packets. In this case, the whole = point of the feature is to make it brittle, but this is also why in = general people will say not to use the Critical flag unless it=E2=80=99s = really, really, really critical because you=E2=80=99re almost always = just shooting yourself in the foot. >=20 > The reason why I bring this up is that it does come up in practice and = at the > moment, there is no consensus on how to handle such a case between = OpenKeychain > and GnuPG. See: > https://github.com/open-keychain/open-keychain/issues/2413 > https://dev.gnupg.org/T4235 I=E2=80=99m with Werner on the gnupg side of this. In decrypting anyway, = gnupg is doing something resilient. Moreover, gnupg is not merely a = tool, it=E2=80=99s a reference implementation and as a reference = implementation it needs to have meta-features for the purpose of = debugging.=20 Jon From nobody Wed Nov 7 17:17:22 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28821130DCC for ; Wed, 7 Nov 2018 17:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6COTiTy7ful for ; Wed, 7 Nov 2018 17:17:19 -0800 (PST) Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (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 228B2130DC2 for ; Wed, 7 Nov 2018 17:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=/V+zPgEJIDPJlkuzM3/tEnYCOnr6ZETIMiLxMXN9QwU=; b=qRWrEyXYg1f9pAQ77sRQUaZHek jW9LOPB28mdfLRrGZtkqvpeCEl5jvyRS3GKH76yRMTIrjETWNNEIAk0dg1TsT3ctB/Z89PQWeJii6 BufuKTmzqmOybjnYJ6PJjiNR6KmuHRaf2O5RzqlIYVOL0kkayyw3Vgy3FNq+o1HdfMgc8w5g4ETgu I3AxpUI+td3xm+TgEE05kI9KxsaCH9xpBvWJDMM/v7yCjgVK0y0uDmXgkGGmgEiBLhEii/MQHT/Bk q/jOJJKtwo4iwp4bEJck0lXfW4g5e2fvNTt75G7E9yN1cqyp4qN1s6KZz3EDDTGBJkGwwJ/oRr35M goaPmqTQ==; Received: from 140.200.232.153.ap.dti.ne.jp ([153.232.200.140] helo=iwagami.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gKYwb-0006Ce-5H; Thu, 08 Nov 2018 02:17:14 +0100 Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Thu, 08 Nov 2018 10:17:08 +0900 From: NIIBE Yutaka To: Ian Jackson Cc: openpgp@ietf.org, Werner Koch In-Reply-To: <23523.16831.292658.490356@chiark.greenend.org.uk> References: <23523.16831.292658.490356@chiark.greenend.org.uk> Date: Thu, 08 Nov 2018 10:17:08 +0900 Message-ID: <87zhukmkq3.fsf@iwagami.gniibe.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 01:17:21 -0000 Hello, Ian Jackson wrote: > II. URL domain name part [...] > Suggested modification: the domain name part should have a fixed > string prepended. In page 4, the draft suggests possible use of "wkd" sub-domain by DNS SRV resource record. The example says: "wkd.example.org" for "example.org". Does it work for your intended use case? Or... should we care about some broken edge router implementation which behaves wrongly about DNR SRV RR query? -- From nobody Wed Nov 7 17:26:09 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D12C130DCC for ; Wed, 7 Nov 2018 17:26:08 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VWHBWd4-xW6 for ; Wed, 7 Nov 2018 17:26:05 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (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 C4F911286E7 for ; Wed, 7 Nov 2018 17:26:05 -0800 (PST) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:941b:b2ff:ecfe:7f28]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 1EA476077B; Thu, 8 Nov 2018 01:26:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1541640364; bh=qCyVMyhaTVi6jumqU52poLRXMNoLHoVOypj+aXhb2HE=; h=Date:From:To:Cc:Subject:References:Content-Type: Content-Disposition:In-Reply-To:From:Reply-To:Subject:Date:To:CC: Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=rFkQ995/hDPjNHDuBlmRg+v2sXlza3zk/qMteraFV9o13B0QNmeQgKYJdpPW7Aw2x Y6O4mTYOineHPPR9EPGkrDsMrc8XA6ddJSjnOd3Xqk8QIKdwHsxhz3dnhR3hRq/C86 qQ0wRCgZsA4weda0JaPmIQYJJ3aHbXWvcJYAxd2y7sYcD341CwSEP3BMyekpAS0KOP qtjBwzHa7OVECTtCNFiYGYc8729KsG9i0A75Fi/Kk1MmBM6wTDXrPF9i0NtH76xThQ gPUcH8IWTtcoIW3DFtwPsQ+jbIKC/4sIAPN1P2u7O8xb3g+opB/LerDQnrQD8ejM6P 1mKrIRNnNAEKTUhYRnbGmolfc1h59leZ/GMC/LTu7jb8dKvaIeNfff3hWLrdeHTIyz kSmW4QYjQGsLKn0m4rqLkD0MxLovp6KdDZEDPtx79yjZQMWujchQldHdb02zFkTui1 yB1Qvl0JfTsgG7zCDXa3IB+2qFmYpL0mF2Uqoz7Mwe8BG6Wfi7z Date: Thu, 8 Nov 2018 01:25:59 +0000 From: "brian m. carlson" To: Ian Jackson Cc: openpgp@ietf.org, Werner Koch Message-ID: <20181108012559.GF890086@genre.crustytoothpaste.net> References: <23523.16831.292658.490356@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aPdhxNJGSeOG9wFI" Content-Disposition: inline In-Reply-To: <23523.16831.292658.490356@chiark.greenend.org.uk> X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.18.0-2-amd64) User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 127.0.1.1 Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 01:26:08 -0000 --aPdhxNJGSeOG9wFI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 07, 2018 at 07:49:19PM +0000, Ian Jackson wrote: > 4. The lowercasing of the email address is contrary to the Internet > mail specifications, where case-sensitivity of the email address > is up to the mail domain in question. If the email address were > not obfuscated by hashing it would be easy for the webserver to > handle case-sensitivity by URL remapping. I definitely agree that lowercasing the address is wrong. The RFCs say that the local part is case sensitive, and there are many case-sensitive systems on the Internet today. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --aPdhxNJGSeOG9wFI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.10 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlvjkKcACgkQv1NdgR9S 9ou9bRAAwqf2AB3qyAUGBmPYV9B5TS2VvcVKoJTLyBg0JbID2RekifhYL3CtN7Xn jssfID1sDcYJgXLlED12bAmUqqk2dIwjv+NZ+BtYXDACIlCkgstfmKNGm5iKX2yG FfFjOXsmk1XjOqmH+Fe4SCq/Wsc8BwwCK24rwqClr07I0rtXuj3iP78PZVcZqXwL 7/zWs9kA1PF4lreHmkQ/+64B/EtXMhpTK7QGgglqyzLyiT6A53OpPGFYGb5t43EL WmdVZ63xaE0XfzMG5bUsdQU876FPjvj99PEc6oO0TULkrIjsKNCB0IRUC9yCqTf5 WwOklyUmoPJ8P88B4Ml0+0QMwFlJfNvoPuKxyoaKmPx2thWJejvcw11GhkxCoSNp nZpCzforcEKKg9beOwf10QtD4VVF8FwG0C24wHsy5wdqLW1VxEqBlT3RF3UQCO3p u0SVVYcQK1ll057KCh8XpK/5mxnJCeoyGqm2L2fu5EvJ9pxljXCkyDwbrNanjNns pkveefsbAicWe8U5n36gUUrPPmK0nfEp5h/+1bXQExXoDx7H0S/75qf5M13e68+F 51pIMFuJTl0sBQCXUAD4JHIalcoowSIqt1MeeX6JnE0DWHARj2b/arz1CsG+JjR0 KtSRsblB8Rm9U2g0xIj8hp8w6xWld+crSZ0yZaI4KM/JIbhwslA= =5tNN -----END PGP SIGNATURE----- --aPdhxNJGSeOG9wFI-- From nobody Wed Nov 7 23:00:17 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE6130DEF for ; Wed, 7 Nov 2018 23:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETlF2XXoidw3 for ; Wed, 7 Nov 2018 23:00:12 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 56A881294D7 for ; Wed, 7 Nov 2018 23:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=BFLT68C0x5POUA3skQ73w4KA+GOd0V3T1wbVKkt3UZ8=; b=E4JvGEGOhUNv2I5xqOASVgUOcl haK6cMR0qT5XRASglSSRUcmrcGehrc4C1TICKNB/Pvva8kfho908Sb6A/8V660ES4o6vtanIjU8Gc rzEs6kHsQctgPqChxAJkcL18jyCDlmcagf5dGwISy8SlbWZoyyHy6ZHnvdJWJY04RVvw=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gKeIT-0008K1-K9 for ; Thu, 08 Nov 2018 08:00:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gKeHl-0002dy-6d; Thu, 08 Nov 2018 07:59:25 +0100 From: Werner Koch To: "brian m. carlson" Cc: Ian Jackson , openpgp@ietf.org References: <23523.16831.292658.490356@chiark.greenend.org.uk> <20181108012559.GF890086@genre.crustytoothpaste.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "brian m. carlson" , Ian Jackson , openpgp@ietf.org Date: Thu, 08 Nov 2018 07:59:24 +0100 In-Reply-To: <20181108012559.GF890086@genre.crustytoothpaste.net> (brian m. carlson's message of "Thu, 8 Nov 2018 01:25:59 +0000") Message-ID: <878t24yrzn.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=corporate_security_tempest_S_Key_ANZUS_CDMA_pre-emptive_Dateline_NAT"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 07:00:16 -0000 --=corporate_security_tempest_S_Key_ANZUS_CDMA_pre-emptive_Dateline_NAT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 8 Nov 2018 02:25, sandals@crustytoothpaste.net said: > I definitely agree that lowercasing the address is wrong. The RFCs say > that the local part is case sensitive, and there are many case-sensitive > systems on the Internet today. Please tell me a single public accessible system which is case-sensitive. Ask any non-hacker about mail addresses; almost everyone enters mail addresses in whatever case they like. I have seen many business cards which spell Joe.Hacker@example.org despite that the canonical address is joe.hacker@example.org. See also the OpenPGP DANE RFC for this. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=corporate_security_tempest_S_Key_ANZUS_CDMA_pre-emptive_Dateline_NAT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+PezAAKCRD/gK6dHew1 jXqnAP9CeJhShZnszJKqqeGwjRS6Z6seRCtRisHlW0tiZHr9QgEA23E08DMU6Il+ 4SAdnjlQoXlnIopOxz2E/NMnxb0/GAI= =xpFb -----END PGP SIGNATURE----- --=corporate_security_tempest_S_Key_ANZUS_CDMA_pre-emptive_Dateline_NAT-- From nobody Wed Nov 7 23:20:13 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275D51294D7 for ; Wed, 7 Nov 2018 23:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm65Q4rt2nYr for ; Wed, 7 Nov 2018 23:20:10 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 776FD1294D0 for ; Wed, 7 Nov 2018 23:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=K6L3YYI+UkYetvHDsfH+iv98SmJ37d3+h3X4vpb0o/w=; b=fuOA/qgIXXjKsHKC5IGY+w2U64 THZKmBhMLQrClvtiUr1BKcPQKBZ5yaSgxoQfCYBTNNQd+J5BZeecISDj6etwSEd+ycJdXsQDB9khF 2i9LatN8e3Q3VW43abdqU0oTQ/pLsDrS9j0xkYX9fenRz1z64CQZSeUjPuI5oDDETyZE=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gKebo-0008Ri-Vn for ; Thu, 08 Nov 2018 08:20:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gKeaJ-0002n1-Ce; Thu, 08 Nov 2018 08:18:35 +0100 From: Werner Koch To: Ian Jackson Cc: openpgp@ietf.org References: <23523.16831.292658.490356@chiark.greenend.org.uk> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Ian Jackson , openpgp@ietf.org Date: Thu, 08 Nov 2018 08:18:34 +0100 In-Reply-To: <23523.16831.292658.490356@chiark.greenend.org.uk> (Ian Jackson's message of "Wed, 7 Nov 2018 19:49:19 +0000") Message-ID: <874lcsyr3p.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=top_secret_Roswell_Ortega_Firefly_president_data_haven_United_Nation"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 07:20:12 -0000 --=top_secret_Roswell_Ortega_Firefly_president_data_haven_United_Nation Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 7 Nov 2018 20:49, ijackson@chiark.greenend.org.uk said: > 1. SHA-1 is obsolete. | The use of SHA-1 for the mapping of the local-part to a fixed string | is not a security feature but merely used to map the local-part to a | fixed-sized string made from a well defined set of characters. It is | not intended to conceal information about a mail address. > 2. The use of a cryptographic hash here makes it harder for a server > to conduct an appropriate lookup. For example, if a server defines > that all email addresses > alice+@example.com > are owned by Alice, and Alice tells the server `please advertise > my one OpenPGP key for all my email addresses', it is not clear how > the server could implement that. The problem here is that the client needs to know how the server handles this. This is because the client should filter the returned key for a matching mail-addresses. Actually we have had a discussion about this recently in Brussels with the outcome that for experiments we now appened "?l=3Djoe.hacker" to the request. Currently implemented servers will just ignore these parameters. > 2a. The cryptographic hash does not, however, provide any significant > degree of useful obfuscation since a search will usually be able to > reverse it. See above > 2b. The cryptographic hash is not needed for space reasons since URLs > can easily be as long as email addresses. Right. A constant length can make implementations easier. YMMV. Further there is no limit on the length of the local part of the addrspec. It may well exceed the max. length of file names. > 3. Supposing the hash were to be retained, choice of base-32 rather > than base-64 is unusual and needs to be justified. Easy: The standard Base-64 includes a slash and thus the has can't be used as a file name. > 4. The lowercasing of the email address is contrary to the Internet > mail specifications, where case-sensitivity of the email address > is up to the mail domain in question. If the email address were > not obfuscated by hashing it would be easy for the webserver to > handle case-sensitivity by URL remapping. See my reply to Brian and above. > > Suggested modification: Replace this part of the URL with the > URL-encoded email address. Nope: That breaks existing implementations and would not allow to serve the data from static files. > II. URL domain name part > > The mail system for some domain, and its web server, are not > necessarily on the same host or under the same practical > administration. Often webservers are outsourced. That is rarely the case but given that I know a pretty large provider which has this problem, SRV records are used to overcome this problem. > Suggested modification: the domain name part should have a fixed > string prepended. This is an open question but for a different reason: Current web browsers have no way to lookup SRV records. > III. Normative status of this document | Internet-Drafts are draft documents valid for a maximum of six months | and may be updated, replaced, or obsoleted by other documents at any | time. It is inappropriate to use Internet-Drafts as reference | material or to cite them other than as "work in progress." OTOH, it is a standard practise that RFCs are based on existing implementations and we have that implemented in in GnUPG 2.1.12 (May 2016) and thus for example also in Debian Stretch Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=top_secret_Roswell_Ortega_Firefly_president_data_haven_United_Nation Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+PjSwAKCRD/gK6dHew1 jY6uAQDzUt/s9+7P2mUn27I7Rm9htsAw6MtLFAGkUTzZJYAESwD9H1HO62RWpz2I YUHISDYQ+YKy8i+dSsKOPd8ePdambAg= =kke3 -----END PGP SIGNATURE----- --=top_secret_Roswell_Ortega_Firefly_president_data_haven_United_Nation-- From nobody Thu Nov 8 03:08:32 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896F9130DE1 for ; Thu, 8 Nov 2018 03:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fluidkeys-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMxLF8jyhOSc for ; Thu, 8 Nov 2018 03:08:28 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 48797130DC6 for ; Thu, 8 Nov 2018 03:08:28 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id f19-v6so1283403wmb.0 for ; Thu, 08 Nov 2018 03:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fluidkeys-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=npx1isZ1B/PEyypUBJRm88C2IMkWhnKK+sb7yCVUCXU=; b=sZuUziTUjTeu7onOkF9sHobwvSpk4/UcsU3Wiv8h7xPmfNcnfIDFRNX6uHa9YGoPMl EgqdtkGWDoS7cz2b1al38sgDCcG+ha8TnD4QECq042K7pcAQ3RTp+L3HsAljby+04Wr6 NBqzWcWg58LVXHOr3N7u+p4L+Yt06/F38NCUBAQHvIO5VYIDNKknClggfAjHJ12UNGT0 Sp7Sxx4XZE4CPE4yz5nFgk5N2a62vGFESOY6jEY3K1ix7JvIuRnZhy2RBh4T/zIgdzfE Vy0A38hC+JvkdufTtYHRowhc8ancqECvcBPE3FB0c/B/ApYcqooDGnPMSvi4WwLxBmgY xMSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=npx1isZ1B/PEyypUBJRm88C2IMkWhnKK+sb7yCVUCXU=; b=FKeNegLQbP5Z6f8b7v8TRzD37rzZ42OCTDB6AFDVJ0oHpcQ8Z8a/k47I5sYoCDB7id WX090SiyRnnZJmTh3M+QD4rRgwmpVDg83Q2wdpw48gMmrBOAvK5FbiV6bDomj7/VUJNz vthqLN06UNbddrymNevvX3tMol3YZKs9TXeYcwoDcJrwb96FqQDk/5fJGYa1SXi1RVKj 9dd4SXg/S+fXNdd3UaSeGBGaZdnRjMAXghFrjgpTUp7XB9pWqlBKVKfDiBgclvNKWifX Zv0nt/dvpr7rsSnc4jrkVpht1Q3GVrXhLMOiEHemH+8WKU6yp9XYJXWa03LLN920N7f7 A2sw== X-Gm-Message-State: AGRZ1gIhU5T8+qlMNAg6xNLDhYh8DCHNFg/VniolcGxBiPLV3UU2yFEi 9bSipaQi5rL+8/chhLK8/3JeEeNpAyL/ X-Google-Smtp-Source: AJdET5evYRkjHoo3yImaOc8BscQLx+UKLGe++wUMhVdjYpuMZYNvVUftFHM1sG4U26x+en9+2Rm2Tw== X-Received: by 2002:a1c:9dc5:: with SMTP id g188-v6mr776283wme.141.1541675305791; Thu, 08 Nov 2018 03:08:25 -0800 (PST) Received: from ?IPv6:2001:8b0:d5c:9cbd:495f:f7e6:35cb:3566? (6.6.5.3.b.c.5.3.6.e.7.f.f.5.9.4.d.b.c.9.c.5.d.0.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:d5c:9cbd:495f:f7e6:35cb:3566]) by smtp.gmail.com with ESMTPSA id l140-v6sm7505927wmb.24.2018.11.08.03.08.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 03:08:25 -0800 (PST) To: openpgp@ietf.org References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> From: Paul Fawkesley Openpgp: preference=signencrypt Autocrypt: addr=paul@fluidkeys.com; keydata= xsFNBFuOr7IBEADj5wnhRc07sX1rNNqEvMEZIXYZgElhxNRpN4qc4ES4Xp9rlckLIgqARyiY Nc87arYP3CIgfbTFJTy7g7q3jjbm7jmYSvpxe1J40kgbKMOjAtula2vdKzddXcgNkmDiWHsc bvoG2cxNSqx5lUU9SsPO2lVU1C44g3k0A1NgueEwus9blb2/qwHB6Zn7L/jOSM+AV6zpWeSH gRWigN+1m21GE2i09Um0W/W8WhFJDV5M4+IfYVvysReLcfFvzGJjZMlkVWOfE/nWPhBQpQOC u4Wtu5490hmtTt4/hXBrqYBDOgXFYDZAsyUgTctXUiH0/bBNWZ2hHrMWeMOvGI0p6DhGfuAk M793lttcjsWX1ff6Nz+vBSucqZnXD/tOAhFjTaWggFEMPwb8Shvy79a+0F+LP8Qk0e88y9Jn 5wSlstMee7EYx8CH1KaJuvSchyK3Dvf2QQLVJ1axPTsDrqvbtmETUN5Wo/G/sKwlXcdn8rd9 Z9iCuvremUddN75LcRSOEg2drncK95b08JP0mn4oDrmVLVskEtF24IXxkmyPVE8yH51sMpRf B7VUDS3SftCINOmH0Xh3qtRQapmMp6HJ/Bs2P3DPDLS1NK+8gPA/2vd6zlLwTqWJVJvlKoIZ GShxBb8XI7zriY6Bgmn4OaMJUB9vj3dNjjj7Cvic5gwGzEJWdQARAQABzRQ8cGF1bEBmbHVp ZGtleXMuY29tPsLBeQQTAQoALQUCW8DK0AkQcyekTCFXp1gCGwMFCQBzH04CGQEFCwkIBwMF FQoJCAsEFgIBAAAArSYQAJA3oxxceY+spH+TgTMe35R+oVquZOzdqCCyM5DLVMt7mx0LV7pX VYJwY7TweqnL5rMnz+65W6VRkluE/XQYH7Kdy7EI2KWICmAs7z1IaMZXB7KYzWB3l2YUttmf RBtgdq4xanEFKhRbFX9XyRmh1kXD/MFLHqH4F1Nkn5ZT6TtGsMc1tpTBkWOWmMbnQetSQfrQ UYCTM7o0c3S11lhqNA47uk8rAcj+DS8HRZHz5S2b4/BUVpOHqxuKGVXGqTsMY4woTPzm++jB +UYDuCVAw1HPpMIPUmmnAETyikIfyaK58v0owwn97Wdi4mFTWftEVjYbDsvfLLa0d3THTxO3 GmaVRbLCbSWisCrUP678jUfJUqalN8ZrdBBXjUMtabaVxF/gK020czCxiZIm88PzG8sxO4ln WUqqw9p1zUCV6mzFR+VmB0S4GYLsWHm9jCcdrzF397zMSNlySBE21tcNcFi1sbRKnC8hcdcT qtNx/KpNvxVAC0nvDKS6XYG3VWK6N+Aa4XAamrITu5ZG6U1AkWp7PcyXorTK9IONAEroxX99 0ANE0Bd+IKWt6baO0D5LKXXdKtpjwKSe2PZoCXd5orK/hVgamSp7GEcNUBULha9k4O8OMj8N cFXO2rJ9NgK1KFhF/1WDEcv4rskIclRhqLZ9Cz/XLzbIs9BAtOz4kRIrzsBNBFu12cIBCADN I/U4wOQzsbrXSgCj5ARkqvHYnOwtybXVi5ufP7xvnUMzghjo5QbiChVk4owYNL2sOTCl+UGw qcr0cAONFvKY04340kXHrvqbJOgY27HEs1SiopmDQ2sANydz6HB4tKrh1KXjZz9xPtEllGeq LgByGES78ZuLS8KcDWLXZ5BL2TUkT9SiULsgejqNF7DXM+8bBihTO7YolVPk9iI7dVi3NHTQ D0EVil5Ta2Ni65TfRNRvcvhH1E4bGfF84hbmmZddyq7muc0qR3xiFXIeWifxSq0iINaMjGkQ eTyWBSQA9oLJCfzBPXSt+whr8Iiu8O8fP7UcK7+lRPu5m+HJe3ghABEBAAHCwWUEGAEIABkF Alu12cIJEHMnpEwhV6dYAhsMBQkAS/U9AAAGeQ//XhOKIg04EfrMjnZ4OhLfmXZNHpzGnel1 6UWLWcXWkplO1nFi1dHnyKSedCIvMTIs3G26CCpVGF89/46ChHfKTLkwkgyhk0Lfk+5xEd4b I47KVfPGAyrfzp2NVwk6iOZ1nxM8Wo2OvmmXpSYlI2bxGj0VWDOzB0KZwyJhAUKnLf3xF3kG lZWG5hJrJidbOrAzfXDrb633oxksAl1ScSbzZ82MkJ5xEVfPSvVP+U/0vWPplIZO3f/MPI4D Yy0RmsuYqmtYxoDf3YrIC1S+mvjCRnCPzD5TfHID4iuLA3/rfvJ18aFAQGprG6IyTvm0xAnx lDu3sh6hfN1/Ugt/nrAuirXh+Ub2RFX/ZgUva4quNtiLY0kMTXgEFh1lZWaN0cdvU9s8Es33 iRUSIq3BWm6ZEd4NeqI/el3FZ7+1eLQagARUgnLKa21jyBkTyuv+LA/qKAcAJI7AelzoL2SY iBKrPzcohmfnduNM7uBmMh4TLNKCVeMd6DITqTz4xD+DMdgC32i5r/9Cgc1HT5oP+637rrcX /GS54l2EGsEvK27KhD0EiYDSbzLCHQmtS83Q1HogSHRk2GeNLC97b+eDVaa4tAaxWVU5SU5x i+pL5T+m8gsZR7wC0WZY52pCIcgmUOq4HTbu4K5zFxHCQF1taHSkwpiU1ZPm0GiG+mp3FOHz uEw= Message-ID: <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> Date: Thu, 8 Nov 2018 11:08:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <874lcsyr3p.fsf@wheatstone.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YEoUCiQDU8DjDesd7JBCnLYkHtNZQwNHC" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 11:08:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YEoUCiQDU8DjDesd7JBCnLYkHtNZQwNHC Content-Type: multipart/mixed; boundary="jfgQXlLUUHwe0qNiwDnZzWKYd9cJlnD5q"; protected-headers="v1" From: Paul Fawkesley To: openpgp@ietf.org Message-ID: <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> Subject: Re: [openpgp] OpenPGP Web Key Directory I-D References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> In-Reply-To: <874lcsyr3p.fsf@wheatstone.g10code.de> --jfgQXlLUUHwe0qNiwDnZzWKYd9cJlnD5q Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08/11/2018 07:18, Werner Koch wrote: > On Wed, 7 Nov 2018 20:49, ijackson@chiark.greenend.org.uk said: >=20 >> 1. SHA-1 is obsolete. >=20 > | The use of SHA-1 for the mapping of the local-part to a fixed strin= g > | is not a security feature but merely used to map the local-part to = a > | fixed-sized string made from a well defined set of characters. It = is > | not intended to conceal information about a mail address. >=20 >> 2. The use of a cryptographic hash here makes it harder for a server >> to conduct an appropriate lookup. For example, if a server defines= >> that all email addresses >> alice+@example.com >> are owned by Alice, and Alice tells the server `please advertise >> my one OpenPGP key for all my email addresses', it is not clear how= >> the server could implement that. >=20 > The problem here is that the client needs to know how the server handle= s > this. This is because the client should filter the returned key for a > matching mail-addresses. The requirement for the client to filter the return key for matching user IDs is a fairly big blocker for us. We (and previous large organisations I've worked in) use + aliases feature extensively to distinguish different services, for example: * paul+github@fluidkeys.com * invoices+hetzner@fluidkeys.com > Actually we have had a discussion about this > recently in Brussels with the outcome that for experiments we now > appened "?l=3Djoe.hacker" to the request. Currently implemented server= s > will just ignore these parameters. For experimenting, fine, but I'd prefer to get to a "production" solution ASAP. >=20 >> >> Suggested modification: Replace this part of the URL with the >> URL-encoded email address. >=20 > Nope: That breaks existing implementations and would not allow to serve= > the data from static files. To stay compatible, keep supporting static files *and* resolve the case and aliasing issues, I'd support: 1. keep supporting sha1-z-base-32 identifier 2. additionally start supporting z-base-32 identifier with no SHA1 2.a maybe put them at different path 2.b don't lowercase anything before searching for these 2.c in the client, don't filter on the user id for these Ian, apart from z-base-32 not being exactly mainstream, does 2. work for you? >> II. URL domain name part >> >> The mail system for some domain, and its web server, are not >> necessarily on the same host or under the same practical >> administration. Often webservers are outsourced. >=20 > That is rarely the case but given that I know a pretty large provider > which has this problem, SRV records are used to overcome this problem. Given that SRV records can't be accessed by Javascript implementations, I don't think we can point to that as a solution I'm recalling a large organisation I worked in that were heavy users of PGP. I can see two options for how I could have implemented WKD there: 1. request an HTTP redirect on the root domain (this one change would take weeks of "change control" process, with lots of signing off by line managers etc.) Then I can run a WKD service wherever I like. (the hosting for different subdomains and mail server were sprawling across many different systems and providers) 2. use a subdomain e.g. wkd.example.com (also through a lengthy change control process to get the subdomain) Given that we can't rely on SRV records: >=20 >> Suggested modification: the domain name part should have a fixed >> string prepended. >=20 > This is an open question but for a different reason: Current web > browsers have no way to lookup SRV records. I'd support this. I'd also support dropping the whole SRV records part to simplify the spec= =2E Paul --jfgQXlLUUHwe0qNiwDnZzWKYd9cJlnD5q-- --YEoUCiQDU8DjDesd7JBCnLYkHtNZQwNHC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJb5BknAAoJEHMnpEwhV6dY4ZkP/1s2TZBEVAkqycB6ktmulhw6 IKdDLBTgFA2EEJTZDo8J+fraDCpM27Xf1DXSyom4biqJlAYyaB0DcR1MLEwdzEUL dfSol1EgClK9qFy1OT0M4twTXg5xx9Z3wjCpQMTbD39jAsBZBt8s9DBV9KFwzVbR 7WYUcWJyb6nxVqSkXVZEboOBa4EwXrxed1DOjNEL2UXQtCPXthan7JfvU8SVIz7z NsZ4YV+kQCtiymV/jQD4tz1NbePM/Q1KH7Q9Thzez/JrrosMcOrTpiSeHbgLjvzb kpdCAOWDb6DOx2aC6HT4ydZPlZZXoJL4v8e3b8o0HFJ5CoVJoAEzTqP5p3eZv02T DJ9qnOEVXq2HjetpFCbm22CuIt4OMUsfqsBN+HWPI33OpEA5QgtpE6zjRZ8DuZio R2jc2ITHXYDwP8YY/YG7wL+W7aB9psdMrBDUwnOqwV3UCbzrfPye3c5eIl1UvN7A FFQOpwfQTKQAUdrSI4hbiLJkdizdhi+HsqzKq+Dl3XaEEANdkWxpqK2kIQbM5R6i WV9W5Vpi1ts9ipS0Oz1oEiDXe5ucUJLJDB1E7Tyb5q0xYdwzH6HoLEYaDY260cBX 9yE/6LRUbo0lLHtfkdIm/J8zjL2HduKxSkyHCXLPUKfHCDK0bxZen/3uxV4sb6bh JTZZ8FIVDIc9hK8UlMLk =ysLB -----END PGP SIGNATURE----- --YEoUCiQDU8DjDesd7JBCnLYkHtNZQwNHC-- From nobody Thu Nov 8 03:25:03 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B048C130EB2 for ; Thu, 8 Nov 2018 03:25:01 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tTdZXKurJrM for ; Thu, 8 Nov 2018 03:24:59 -0800 (PST) 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 335BB130E6C for ; Thu, 8 Nov 2018 03:24:59 -0800 (PST) Received: from localhost (gate.ibr.cs.tu-bs.de [134.169.34.1]) by mail.mugenguild.com (Postfix) with ESMTPSA id 6FF755FA99; Thu, 8 Nov 2018 12:24:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1541676297; bh=ZhQJZLUSy2lCiocKHE1prIG3Gv9HQ3iHFpvNS7TSW2A=; h=Date:From:To:Subject:Autocrypt:From; b=ZwaB9YwjBUQ2NPqTuLJV0h2iJlglhBOQusHBTJYGNKlpUQXYZVsqodkTCthLqaqnS mjOCkgnyYpiWIgxHfBRLxgA3hgZJS4jbis2ZHVykGZZZN/PnkZcJ9QazpbEGkJjjOa lxf3vZ+YUb1N2ECTM/3b33PwsUbczqShiGRz1keA= Message-Id: In-Reply-To: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> References: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> Date: Thu, 08 Nov 2018 12:24:54 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Breitmoser To: Jon Callas Cc: openpgp@ietf.org Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 11:25:02 -0000 Hey Jon, thanks for your thoughtful reply! > Moreover, gnupg is not merely a tool, it’s a reference implementation and as > a reference implementation it needs to have meta-features for the purpose of > debugging. I agree with thre premise here, but not the conclusion. In the concrete bug report I have, a bank(!) implemented OpenPGP in a way that included two major blunders: 1) they encrypt to a subkey that doesn't have the flag. 2) they include a one-pass signature packet, but then no actual signature (which isn't a valid OpenPGP message, by spec). The reason this happened, I strongly suspect, is exactly because they treated GnuPG as a reference implementation: they tested that it worked against GnuPG (or some frontend), found it worked in practice (without even a warning), and then left it at that. > it’s *Alice* who has broken protocol, not me. Why punish me because someone > else has a broken implementation? > OpenPGP oughta say that an implementation MUST NOT encrypt to a sign-only key, > but it should leave it at that. I believe that this all goes back to Postel's law of "conservative in what you emit, liberal in what you accept". You're advocating for being "resilient" in the face of bugs in implementations, and that sounds like a good idea on paper. However, I've come to believe that for the long term health of an ecosystem. The reason is that the required "bug compatibility" that is required to actually be interoperable accumulates over time. This leads to more and more implicit knowledge (rather than explicit, as in by spec) being necessary to create or maintain an implementation. Martin Thomson put these thoughts into an I-D fairly recently: https://www.ietf.org/archive/id/draft-thomson-postel-was-wrong-03.txt It is at this point terribly hard and time consuming to write an OpenPGP implementation that works interoperably, because of a general expectation that everyone be 100% GnuPG bug compatible. It's just a blip on the radar, but the case described above happened five years into working on OpenKeychain. And it's not a fluke, I have more similar incidents (will post about them soon). > The standard should not forbid resiliency in the face of a bug. This is a very reasonable sentiment for specs like HTML, we certainly wouldn't want to outright reject a website just because of a missing . But in the context of a cryptographic protocol, this is super dangerous. Being overly relaxed in what we accept means giving attackers a large amount of wiggling room. This is exactly what brought us EFAIL. We should learn from that, and I hope we can do better in the future. - V From nobody Thu Nov 8 04:05:15 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4E9130E6A for ; Thu, 8 Nov 2018 04:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeA0IvAKgsxc for ; Thu, 8 Nov 2018 04:05:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 4D75B130E46 for ; Thu, 8 Nov 2018 04:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=C1KU56KzMnIHgcbGhrvPhIh4KdkkYWMPvbXqDAbrUMY=; b=VMIJuerEv5S/1KrA0ydJ6yqWYk Lc+jlBqMTt5webptbZt+rqcg9fkM6vY2sjyB2B7MdM0XHunIPYaWe/Xi/V7Q9SrQRK+fRe3Ut1z/e 2OVbo8HZMBneUx1T1g7XPkC4Ro2Yj/nWjF46EeMhuBJ/JTrTyp8a/7ESE2bMMQwOgJC8=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gKj3d-0002Qv-0S for ; Thu, 08 Nov 2018 13:05:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gKizA-0005Fo-6m; Thu, 08 Nov 2018 13:00:32 +0100 From: Werner Koch To: Paul Fawkesley Cc: openpgp@ietf.org References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Paul Fawkesley , openpgp@ietf.org Date: Thu, 08 Nov 2018 13:00:31 +0100 In-Reply-To: <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> (Paul Fawkesley's message of "Thu, 8 Nov 2018 11:08:23 +0000") Message-ID: <87ftwbye1s.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Fortezza_mindwar_MIT-LL_United_Nations_UNSCOM_Security_Council=Venez"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 12:05:14 -0000 --=Fortezza_mindwar_MIT-LL_United_Nations_UNSCOM_Security_Council=Venez Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 8 Nov 2018 12:08, paul@fluidkeys.com said: > The requirement for the client to filter the return key for matching > user IDs is a fairly big blocker for us. We can't request a certain address and then work with any address returned from the server. I am pretty sure that there will be server's which store the entire key and not used the key stripped off all other user-ids. Thus the filtering on the client site is important. > We (and previous large organisations I've worked in) use + aliases > feature extensively to distinguish different services, for example: Yes, I know. We discussed this withe protonmail folks. One idea was to ask the server for the rules it uses to canonicalize the address. That will be quite complex and needs additional roundtrips. So the other idea is to simply go with the '+' separator and have a special case for it. Implementation wise it this requires changes at several palce to have a consistent user experience. > To stay compatible, keep supporting static files *and* resolve the case > and aliasing issues, I'd support: > > 1. keep supporting sha1-z-base-32 identifier Already doing that. > 2. additionally start supporting z-base-32 identifier with no SHA1 > > 2.a maybe put them at different path > 2.b don't lowercase anything before searching for these GnuPG 2.2.11 does this as descipned in my last mail. For example the URI to lookup the key for Joe.Doe@Example.ORG is now https://example.org/.well-known/openpgpkey/ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe@example.org No hashing is required, the case is not changed; the parameters undergo the usual percent-quoting. > 2.c in the client, don't filter on the user id for these That is the harder part. The matching in gpg is anyway case-insensitive and I would like to implement '+' style sub-addresses; that is ignoring everything from '+' to '@'. > Given that SRV records can't be accessed by Javascript implementations, > I don't think we can point to that as a solution It is a pity that solid network techniques need to be dropped in favor of large but uncooperative browser vendors. Adding an interface for SRV records would be really easy and helps to support flexible network administration. Note that I don't wan't them to use SRV records for generic http requests but extensions should be able to use it instead of resorting to external DNS lookup providers. [Arggh, it is the whole everything must be http thing - I bet we will sooner or later see a new IP protocol number for HTTP-ng]. >> This is an open question but for a different reason: Current web >> browsers have no way to lookup SRV records. > > I'd support this. > > I'd also support dropping the whole SRV records part to simplify the spec. I recently looked into a protocol *forgot which one) which didn't used SRV but a domain name prefix. So, do you think that a strategy of: First try https://openpgpkey.example.org/.well-known/openpgpkey/... if that host can't be resolved (or accessed?), fallback to https://example.org/.well-known/openpgpkey/... be a practical replacement for SRV records here? Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Fortezza_mindwar_MIT-LL_United_Nations_UNSCOM_Security_Council=Venez Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+QlXwAKCRD/gK6dHew1 jTt4AQCgNqz/JPYuR9z8hQwiEfi4oV5ONHvGUAUmbfN/bbCKLgEAhW4funBnaQKI 1+Bfe/ZbTiC1DfarrD2rVrVewpFF1Qk= =tGP+ -----END PGP SIGNATURE----- --=Fortezza_mindwar_MIT-LL_United_Nations_UNSCOM_Security_Council=Venez-- From nobody Thu Nov 8 14:31:56 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9D130DF9 for ; Thu, 8 Nov 2018 14:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZn_d3J6iza4 for ; Thu, 8 Nov 2018 14:31:53 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 BF0D3130EC0 for ; Thu, 8 Nov 2018 14:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1541716312; x=1573252312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XzoVFMGla0+SwUNHV0KiGd4q7CbhS92A8bX/1q0woPU=; b=X3zMz1HalE+y6oiYQ4QtLCACKLTEQxbCLuIdza3bUl10sXGM9LVMO+PU 3WIdGcy3KreP/3MCVfuObL5iBubK39LtjcdWMJ4PRNQv/f9eU8SzP4IjX z1rUFGjyKYteFE2i4nuTwDyUjwWV2vzlqpsFjb6yscBsMBS3aHykFBpRx MKXBNxz+6S49CC+rD2LQmpqPTwPug9h5mRZaDgtvvvigJyf1wE44qD7o2 iIyP9s5g3qSuvbswR9DOVudvZao+RWZdHH1MP87S7LojCwpDi/pO39FFM Ungg/yEqevvBiqwVlpO9UUxktUw2FVHtduen1QsYoyTi4kROnAmaU/zwj Q==; X-IronPort-AV: E=Sophos;i="5.54,481,1534766400"; d="scan'208";a="38857997" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Nov 2018 11:31:51 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Nov 2018 11:31:50 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 9 Nov 2018 11:31:50 +1300 From: Peter Gutmann To: Vincent Breitmoser , Jon Callas CC: "openpgp@ietf.org" Thread-Topic: [openpgp] respecting key flags for decryption Thread-Index: AQHUdq6nvTjqM1Dj2EWug5wDrVC4uKVEBl6AgADdrgCAAZQk6A== Date: Thu, 8 Nov 2018 22:31:50 +0000 Message-ID: <1541716302530.66616@cs.auckland.ac.nz> References: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 22:31:55 -0000 Vincent Breitmoser writes:=0A= =0A= >The reason this happened, I strongly suspect, is exactly because they trea= ted=0A= >GnuPG as a reference implementation: they tested that it worked against Gn= uPG=0A= >(or some frontend), found it worked in practice (without even a warning), = and=0A= >then left it at that.=0A= =0A= This is a problem with several protocols where there's a single widely-used= =0A= implementation. It also affects SSH, a standards-conformant implementation= =0A= isn't something that follows RFC 4251-4, it's something that you can connec= t=0A= to with Putty (server) or that connects to OpenSSH (client). That really i= s=0A= the conformance-test for SSH, "we can connect to it with Putty, it's now=0A= complete and fully standards-compliant".=0A= =0A= Maybe all of these unofficial reference implementations need a strict-check= ing=0A= mode for when they're being (incorrectly) used as reference implementations= ...=0A= =0A= Peter.=0A= From nobody Thu Nov 8 17:37:04 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDDF1252B7 for ; Thu, 8 Nov 2018 17:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwU0wfo5L0H6 for ; Thu, 8 Nov 2018 17:37:01 -0800 (PST) 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 3BA1A124D68 for ; Thu, 8 Nov 2018 17:37:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CE0E3BE51; Fri, 9 Nov 2018 01:36:57 +0000 (GMT) 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 bd-Dw8l0YBd3; Fri, 9 Nov 2018 01:36:56 +0000 (GMT) Received: from [31.133.156.151] (dhcp-9c97.meeting.ietf.org [31.133.156.151]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6C297BE3E; Fri, 9 Nov 2018 01:36:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1541727416; bh=XmN92YFMRLqpLblimWmSg7l91lcT6NGGojcVk0087Pg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=W7Ph4EntKGBXZkFZdPn4MU35rD2aAbmhRwD5FK+U/MzigWpddtRKH4J29RL+dtznl eUTul1lCgE3FHIHtE+dCGamVbnfHKvrFN/O3NQBiSWKHRBy3DeDlaK7dl4PVJtMEUv 9uVE0IzTNXYujuvnCfOcOUKmrDtjWTTNIRTn/f4k= To: Peter Gutmann , Vincent Breitmoser , Jon Callas Cc: "openpgp@ietf.org" References: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> <1541716302530.66616@cs.auckland.ac.nz> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 9 Nov 2018 01:36:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1541716302530.66616@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RXVFhkRWz13AyJVb5AHbcIwP0NFxfRvn5" Archived-At: Subject: Re: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 01:37:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RXVFhkRWz13AyJVb5AHbcIwP0NFxfRvn5 Content-Type: multipart/mixed; boundary="a2yLAyVblhDr68DGXseCu4wsIJhERZx8l"; protected-headers="v1" From: Stephen Farrell To: Peter Gutmann , Vincent Breitmoser , Jon Callas Cc: "openpgp@ietf.org" Message-ID: Subject: Re: [openpgp] respecting key flags for decryption References: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> <1541716302530.66616@cs.auckland.ac.nz> In-Reply-To: <1541716302530.66616@cs.auckland.ac.nz> --a2yLAyVblhDr68DGXseCu4wsIJhERZx8l Content-Type: multipart/mixed; boundary="------------E91D4F201C58177A4D2E8EAD" Content-Language: en-GB This is a multi-part message in MIME format. --------------E91D4F201C58177A4D2E8EAD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/11/2018 22:31, Peter Gutmann wrote: > Maybe all of these unofficial reference implementations need a strict-c= hecking > mode for when they're being (incorrectly) used as reference implementat= ions... Nice idea. S. --------------E91D4F201C58177A4D2E8EAD Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------E91D4F201C58177A4D2E8EAD-- --a2yLAyVblhDr68DGXseCu4wsIJhERZx8l-- --RXVFhkRWz13AyJVb5AHbcIwP0NFxfRvn5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvk5LEACgkQWrL68XsX K+qdsg//eRyBGld4Pk6soViwicdxkCqPpj1ABUSfJYi6m1G0OGwhLvyu+lGkwO/g rIlNmW0SjR8HpdGIfCVjunu22dv1OBozEIHDfWYX5wxfBHTFGi1V3wB/kiPOIY2O uTZxAmGNOP35i2IhZ3EvOWfTmh46ahgFSlcIeyNI66TU/633FzZZY9f8rA8GUA+e jdAF3QLe3Vl6hDEPYgW0lfv/jOSQAsjot62lmTWTCc4nqPdRN6mzMTnB157R0Klw Aq8jDBlAVOweArhqiOzzzDoOiWvCvxKSkckSTVDKjtV+FgBOc9C7bH27oq9eh61X tKIipcO48e6L1rvZW2KhAXdtjqFfKdX9rSyJjI4JVkooZBpLmq+xYd04p8U6ZQRu RyDrdw70kZx/TeD8Xwc9hSaiJXpJKcWjqB4YDGQ9Y/bJcEtWqJN6CpRO4lEAqa/H BMwvXL+UqIrBTdd+skq9o0nliSMzMQg0RzaYsLBOvSPpCsCOJJFrAmieE8csqtfo ggzAjxGk/YdEvmacy3/7OblK021PbEJuDnwwLhcq6yvT+M/2QiMdG6u8p5IbLkvm 6lU9OAHfbS27KybQZQIH9JDt1FMhN/qI4rmY8vcDEU0eK01fkpco8U7+VUPwegVK N1gqoSuQQrbEuepOKKEVWJombU0TV1vw+2P0FpzdRkROzsFWcMA= =nWYO -----END PGP SIGNATURE----- --RXVFhkRWz13AyJVb5AHbcIwP0NFxfRvn5-- From nobody Fri Nov 9 00:10:16 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5FC130E6B for ; Fri, 9 Nov 2018 00:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ5krIWpl7T8 for ; Fri, 9 Nov 2018 00:10:12 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 09CED130E04 for ; Fri, 9 Nov 2018 00:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=OicXcE0EcQp/A3GBBX2Pmr269qVQPHU1MgBfSbecLlo=; b=Jqm4SlcZLK6nNh77Ke/h7R0Z3B Vl4X5ylYPnewcNOmBPLa/bAm9wlsSVaTNfRpwGpDa1ribda1JfkCPUfdJX6RsfWUR7rI+Y2WTQWb2 gY1oZhDotFinuvO+Mo1JcMRdWi0eJXXvarUw7zZ4qRG2D61/ryQE80xCaeL/P6s0vRXI=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gL1rl-0001Sr-7U for ; Fri, 09 Nov 2018 09:10:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gL1oc-0005f2-Oh; Fri, 09 Nov 2018 09:06:54 +0100 From: Werner Koch To: Peter Gutmann Cc: Vincent Breitmoser , Jon Callas , "openpgp\@ietf.org" References: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> <1541716302530.66616@cs.auckland.ac.nz> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Peter Gutmann , Vincent Breitmoser , Jon Callas , "openpgp\@ietf.org" Date: Fri, 09 Nov 2018 09:06:54 +0100 In-Reply-To: <1541716302530.66616@cs.auckland.ac.nz> (Peter Gutmann's message of "Thu, 8 Nov 2018 22:31:50 +0000") Message-ID: <87va56wu75.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=anarchy_Firefly_bullion_ASIO_NSA_9705_Samford_Road_UOP_MD2_militia=i"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 08:10:14 -0000 --=anarchy_Firefly_bullion_ASIO_NSA_9705_Samford_Road_UOP_MD2_militia=i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 8 Nov 2018 23:31, pgut001@cs.auckland.ac.nz said: > Maybe all of these unofficial reference implementations need a strict-che= cking > mode for when they're being (incorrectly) used as reference > implementations gpg --compliance=3Dopenpgp .... is intended to do just that. However there is a wide range of case where things are not specified. For example the decryption with a key having from the usage flags. Actually I expected to see a warning there but that is unfortunately not the case and currently master even rejects to decrypt with bad usage flags [1]. Shalom-Salam, Werner [1] https://dev/gnupg.org/T4246 =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=anarchy_Firefly_bullion_ASIO_NSA_9705_Samford_Road_UOP_MD2_militia=i Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+VAHgAKCRD/gK6dHew1 jQEmAPwKVYkld0IyNmQGobE7lEMO2uNkvV4I/gWZmCtQdX2fwgEAk4zQKAukhx/y sfLXZ4BB6LsXz5BLZ5yLHi4nooF7Tgk= =vq0a -----END PGP SIGNATURE----- --=anarchy_Firefly_bullion_ASIO_NSA_9705_Samford_Road_UOP_MD2_militia=i-- From nobody Fri Nov 9 02:50:38 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787E01277D2 for ; Fri, 9 Nov 2018 02:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 D1ORg4sBo-Dh for ; Fri, 9 Nov 2018 02:50:32 -0800 (PST) Received: from chiark.greenend.org.uk (v6.chiark.greenend.org.uk [IPv6:2001:ba8:1e3::]) (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 CF00F130DD0 for ; Fri, 9 Nov 2018 02:50:31 -0800 (PST) Received: by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with local (return-path ijackson@chiark.greenend.org.uk) id 1gL4Mw-0007sm-1y; Fri, 09 Nov 2018 10:50:30 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23525.26229.995360.750323@chiark.greenend.org.uk> Date: Fri, 9 Nov 2018 10:50:29 +0000 To: Werner Koch Cc: openpgp@ietf.org In-Reply-To: <874lcsyr3p.fsf@wheatstone.g10code.de> References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> X-Mailer: VM 8.2.0b under 24.4.1 (i586-pc-linux-gnu) Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 10:50:35 -0000 Werner Koch writes ("Re: OpenPGP Web Key Directory I-D"): > On Wed, 7 Nov 2018 20:49, ijackson@chiark.greenend.org.uk said: > > Suggested modification: Replace this part of the URL with the > > URL-encoded email address. > > Nope: That breaks existing implementations and would not allow to serve > the data from static files. It certainly would allow serving the data from static files. If you wanted case-insensitivity and can't configure your webserver to smash the case, then then in practice you could make three files. Overall, I described this protocol to Simon Tatham (author of PuTTY) in the pub last night and he spluttered into his cider and said "is it April the 1st in a different timezone?" > > III. Normative status of this document > > | Internet-Drafts are draft documents valid for a maximum of six months > | and may be updated, replaced, or obsoleted by other documents at any > | time. It is inappropriate to use Internet-Drafts as reference > | material or to cite them other than as "work in progress." > > OTOH, it is a standard practise that RFCs are based on existing > implementations and we have that implemented in in GnUPG 2.1.12 (May > 2016) and thus for example also in Debian Stretch I don't think most of the Debian folks realise they are participating in a protocol design experiment. Since you are still in the protocol design phase, you would no doubt welcome implementation and deployment of an alternative simpler protocol ? Ian. -- Ian Jackson These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. From nobody Fri Nov 9 03:20:14 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D87128A6E for ; Fri, 9 Nov 2018 03:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-4Snagb7W7r for ; Fri, 9 Nov 2018 03:20:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 E5384124D68 for ; Fri, 9 Nov 2018 03:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=O1KCehgskmeh63rqWUIlkz6aqgyxKN5C77GjYatY+aM=; b=IBFCyYrbHoQNH59Z9NE6mCBxGT rF1oV3ODeXmAbPcwh4ByoLzYE2k/w0VFk0EAfRSKfrAeJGNpnQeZiZ/+S/+f7pYF+HXuv4gklj00e VXHWOdgck73aP8mte1iH5ZpPmI3Vlnf+n8ewueI0OrC9xlZaDHJnkuCu+8Gk2672j33s=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gL4pd-0003Ls-8I for ; Fri, 09 Nov 2018 12:20:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gL4nO-00071c-Sa; Fri, 09 Nov 2018 12:17:50 +0100 From: Werner Koch To: Ian Jackson Cc: openpgp@ietf.org References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <23525.26229.995360.750323@chiark.greenend.org.uk> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Ian Jackson , openpgp@ietf.org Date: Fri, 09 Nov 2018 12:17:50 +0100 In-Reply-To: <23525.26229.995360.750323@chiark.greenend.org.uk> (Ian Jackson's message of "Fri, 9 Nov 2018 10:50:29 +0000") Message-ID: <87r2fuv6sh.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=national_information_infrastructure_Semtex_9705_Samford_Road=illumin"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 11:20:13 -0000 --=national_information_infrastructure_Semtex_9705_Samford_Road=illumin Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 9 Nov 2018 11:50, ijackson@chiark.greenend.org.uk said: > It certainly would allow serving the data from static files. If you > wanted case-insensitivity and can't configure your webserver to smash It is not only about the case but about allowed characters in a file name. In particular '/' and depending on file system the length. Noet that '/' is a valid character in the local part of the addrspec. > Since you are still in the protocol design phase, you would no doubt > welcome implementation and deployment of an alternative simpler Nope. It is in use for more than 2 years. The only simpler thing which could have been done would be to skip the hashing and directly use the z-base-32 encoding. The only drawback would have been that very long addresses won't work on all file systems. Changes to the SVR record thing should be possible because I doubt that this is widely used (Caesonia specifies it use, though). Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=national_information_infrastructure_Semtex_9705_Samford_Road=illumin Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+Vs3gAKCRD/gK6dHew1 jedhAP9pXENvlGa83+reL3sfip1FQgkbFzDkMtVR3FksdSWecgD6A9Di7pD1GpgS bq+al03cKBFVmUsvHU6x71f6ve94Uw4= =kQyp -----END PGP SIGNATURE----- --=national_information_infrastructure_Semtex_9705_Samford_Road=illumin-- From nobody Fri Nov 9 03:37:17 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4353A130DE9 for ; Fri, 9 Nov 2018 03:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukujIFq1Pn1O for ; Fri, 9 Nov 2018 03:37:14 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 A19C7130DDA for ; Fri, 9 Nov 2018 03:37:13 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id t9-v6so1306360ljh.6 for ; Fri, 09 Nov 2018 03:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:references:cc:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8o66T3ABvQN+RAR/JPcgktb2KtAuf8F5wfDc4qi+5OU=; b=duEQMUnje9jlgeQmTT0XlvQIYBJHi83M/i7DVd5+ZSse9mL+SltVosnLyE17GJ8Ik+ 4HOE7SYtdQnZNXkzTGxwoVVTSNhT9qhS9tNCzzrjcFsf1EumG93QSTqqRezE1jhX2LjN rt9sGkyBbzBa/qvIdBKUGIqc7mMOiOfM4co79Y8+ZRKMJsXv+nkwZGTk3pzokB7VyaOM YxHycZBSQslDCJ3WtH9Fd86eSPAdOGTvyfT0qI2+ifWPvFOXOVbph0bExI6o4asBIEnW Expp5foHc2xxiEIWbx56l8sua6WV17MNmatubW6Vxkt5VsW16z+XLepIMFwWmyEpGAdw EAkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:cc:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8o66T3ABvQN+RAR/JPcgktb2KtAuf8F5wfDc4qi+5OU=; b=IjPwsDvisGDHkm1kICeIH7L4c/DveArp45fE57UGc+7cs6+RmCFZLQwFA38tvLiEcT aAMoKLJ9TQ1PGHR7kuNwLoHA5qIdSol6ceCJXSVYycDtED7whljcrOlu4gjaklknGf4A 5vNS6s/ossc4Tk3lM42/pywTg0lU7jwVxiwdZY6w84LIXXgAmxvFIafYS11D4wnx/VDB l/qXJGEsKueMqtjy25h2B62fbGITZEMYTMkLx/kgzGFUJVL4OJtX+4NzuZgGPPMt/tff 89g4Xoxb1O+8LDk5aaMT3XD2vc5noYXgfNc2Z+BcYvoacyENl+JW1F6Cb1KrjUJNETjq vjXg== X-Gm-Message-State: AGRZ1gITlHYroQTQDCPrySi2MzXsSM3eN9MUDXYbVtXHQoA+x5DUatzb RpMtYmCjD25WMw3cfTGWWssf1LWRsoQ= X-Google-Smtp-Source: AJdET5cBUzHQ+et7B8YI7uTsnGBr0JrIBgA5MbAeHW55iMQlBzAcvVd15RRDDhPa5VL/dH86yJOMvQ== X-Received: by 2002:a2e:7c13:: with SMTP id x19-v6mr5236951ljc.83.1541763431209; Fri, 09 Nov 2018 03:37:11 -0800 (PST) Received: from ?IPv6:2a02:a317:4e3d:4680:f6ed:4b3c:7510:34c3? ([2a02:a317:4e3d:4680:f6ed:4b3c:7510:34c3]) by smtp.googlemail.com with ESMTPSA id m6-v6sm1288673ljh.16.2018.11.09.03.37.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 03:37:10 -0800 (PST) To: Werner Koch References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <23525.26229.995360.750323@chiark.greenend.org.uk> <87r2fuv6sh.fsf@wheatstone.g10code.de> Cc: openpgp@ietf.org From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsBNBFs/lS0BCAC5oX3r3luF7czMF8UFxJz55XuvNRs4tEjo Hzqcqoe4+RJyfNDtspgevYIq1WTKw/H3ZYsd2wZpkM3I+BJn9eeHZKs77qXQZGN5PBB65rZo LjMx+qHa6wH4lIYMYW7eB9HHMsT/5E3ILBSRzZIwJimd/QdIMKSrJ5mPMkAd+9+xob5zKHO5 L5pbQtJSGS0m17/hA0kCTLI885hLtT3JsI/KWwuAYDrTwsayzh/hG/NgdA3I8xlrQCLC0EFJ oxHkN9tCyXeKPlrIPYyMB1jHTo1iNV0CQGpk+zf6DA/ySGfJxd30ksJZ8y5qxD43zS0YffYM C01CeuqPoGZ2Fy9VxhODABEBAAHCwXwEGAEKACYWIQRlOQmi8ON8EG9fr1RsiFfg2OjwdAUC Wz+VLQIbDAUJAeEzgAAKCRBsiFfg2OjwdKQ4D/wIb8s2Tw8MhbbwASutzTwg3g3KReDRHgSz z7RJtePIM8HC6qm9++9sxoqww7qm35vb604HtMRORYmfXgVSocsYg/eAk8LoBVfCZidDVBia /i/dYx/8LHeX/0PqPluSusQh64BFUoVetUCP+kISbK8vgDt4HfDSgtenC5lpTAdk257A84p2 zDnUtVr8XNv09m7ASft6Wh5Wrn+aWlJrf6T6eysk9OIw8VpSuq0oG3vcEoTbHKJN8TDliPUc QVz5Qti0tgB40PLrqOpTdENdxbiaUNFpHm3Tkk+n7CEFcOayFvy5vU6Nih0hu+LFC2XHzQRw sLnuQ2EilWtXRulcwvFo6A3Vp+gidxc6UwC+LBFJjvDMv5hmsdhSm08r2hd2k61oL6NCGVB3 fxuJT85UHsEC04N72Fa26+Spkh3DtJMrKqJlBBas7oJYh6644DB4rccd6VT3n7Zv1pd2uIWv gjORztfBzRJEysOeHoNpr4hEocg62beu9cnGHpYB9j3mhv+E2IYPnJKqit18G7xb7QnyQU7L YfctLO0GLNdTBavWJggHPzUp09vb3uGS3dMdAYbWTBtnXttkdYuLx/oCe1LVUQYotsX7s83V kVc2n6xzrcaebmgoFtGUfUmOV0U0xbqv6Mxg27qctYh1QidvRyt0xqGA0Qhz/vvoQdfQeMlO Tg== Organization: Metacode Message-ID: <50990b61-ddff-93c7-ca96-ff864d1f4d79@metacode.biz> Date: Fri, 9 Nov 2018 12:37:07 +0100 MIME-Version: 1.0 In-Reply-To: <87r2fuv6sh.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 11:37:16 -0000 On 09.11.2018 12:17, Werner Koch wrote: > The only simpler thing which could have been done would be to skip the > hashing and directly use the z-base-32 encoding. The only drawback > would have been that very long addresses won't work on all file systems. There is also base64*url* variant that is "URL-safe": https://en.wikipedia.org/wiki/Base64#URL_applications It's widely used in several "Web" technologies (e.g. JSON Web Tokens RFC 7519). > Nope. It is in use for more than 2 years. I agree. "?l=" solves most practical problems with WKD for service-providers in a backwards-compatible way and there is a lot of software using WKD (GnuPG, Enigmail, OpenKeychain, Openpgpjs, Mailpile...). If I'd be designing such a protocol now I'd probably overlay it on top of WebFinger (RFC 7033) but currently the benefits would not counter-balance added work for everyone involved. Kind regards, Wiktor -- https://metacode.biz/@wiktor From nobody Fri Nov 9 05:45:14 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89F5130DFF for ; Fri, 9 Nov 2018 05:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsZqtWe_EzDB for ; Fri, 9 Nov 2018 05:45:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 75E4D130DFB for ; Fri, 9 Nov 2018 05:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=21YhP+u241dcQMGiBKOd2aCo2S6LI7wsHBfGKppFfCo=; b=bWx7J3T9xKhvoMa5TbO0GvlgA7 q2Nst89nt3gnZ0Og+s4Aq7lPMKab+UNTlGfI8HJz8gpyrIHf55e2mIku2/+slPLGCoMA88YJgEo66 5ncXnNfQ5qYQBJFaCGHxGcYlTq97dv0JxczuUDf8TnXgzRO4trGKZduhckTMWBYacZ3A=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gL75x-00050l-Lz for ; Fri, 09 Nov 2018 14:45:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gL72n-00089l-16; Fri, 09 Nov 2018 14:41:53 +0100 From: Werner Koch To: Wiktor Kwapisiewicz Cc: openpgp@ietf.org References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <23525.26229.995360.750323@chiark.greenend.org.uk> <87r2fuv6sh.fsf@wheatstone.g10code.de> <50990b61-ddff-93c7-ca96-ff864d1f4d79@metacode.biz> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Wiktor Kwapisiewicz , openpgp@ietf.org Date: Fri, 09 Nov 2018 14:41:52 +0100 In-Reply-To: <50990b61-ddff-93c7-ca96-ff864d1f4d79@metacode.biz> (Wiktor Kwapisiewicz's message of "Fri, 9 Nov 2018 12:37:07 +0100") Message-ID: <878t22v04f.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Fortezza_class_struggle_FBI_Ansar_al-Islam_Zachawi_FIPS140_DRM_Belkn"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 13:45:13 -0000 --=Fortezza_class_struggle_FBI_Ansar_al-Islam_Zachawi_FIPS140_DRM_Belkn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 9 Nov 2018 12:37, wiktor@metacode.biz said: > If I'd be designing such a protocol now I'd probably overlay it on top > of WebFinger (RFC 7033) but currently the benefits would not > counter-balance added work for everyone involved. I actually looked into WebFinger but figured that there is no need to employ yet another protocol format (JSON) and possible require special handling on the server side. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Fortezza_class_struggle_FBI_Ansar_al-Islam_Zachawi_FIPS140_DRM_Belkn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+WOoAAKCRD/gK6dHew1 jQkuAQDThWeox3WxkRJIXtZ5TziEzxvAKzZ9zk4pmtrUtZXzagD9Es+BUg1s9Kaz WxENlc6C7ZPsN/Fl+CzbycY+uVVCVAE= =qrKu -----END PGP SIGNATURE----- --=Fortezza_class_struggle_FBI_Ansar_al-Islam_Zachawi_FIPS140_DRM_Belkn-- From nobody Fri Nov 9 06:16:36 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72576130E08 for ; Fri, 9 Nov 2018 06:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osBKA1ObA_UF for ; Fri, 9 Nov 2018 06:16:33 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 2495E1277C8 for ; Fri, 9 Nov 2018 06:16:32 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id q186-v6so1717101ljb.5 for ; Fri, 09 Nov 2018 06:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:references:from:openpgp:autocrypt:organization:cc:subject :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IHAhFiMeHdXrGfdotB4NCMrGU7OIJOx89MaGRitDrhU=; b=4vtzEd7Z/9UZ+l007AR7PlziiDDe+jJrV7n8GSRjftsdFOJHfz8vF1pwEEnQHt4/XG w/fsDhc+1ax88ZgBZoFOgAzeEKwD2otpuQpxBmzv56qHqMWkLhTPIICejUCHjy14zjJt RlKW5pjc5LN7i/pBf6aIyf/YS3rGUvA8vQvEmX/5jNWNTvr/wbaJwWRPKDhonSbMQhP8 0S80eTyw+21BrB6LzJgm8S3NbHqwvq5Ye+vKEl+stIlgLQ8GHciboPKqwsrLXtw0kaU1 XfdV54omj8Um5MfIXgHSU+HOglS1EPI2bKToMWaeLJHdQQp7WU3348MDYuSHQta5XsK9 5maw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:openpgp:autocrypt :organization:cc:subject:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=IHAhFiMeHdXrGfdotB4NCMrGU7OIJOx89MaGRitDrhU=; b=b8Jlf7hI1lym/QxH/0mbzOkIdNCL5J5h94KzcEB2rXnLdIfrvvX8jz280SAnsAVWta WTUBWjeAKIWDkEE0oKhxYwlg/cnCfixwy0FfyEIKGYw77VM7sHSioQzTEtioHQCw1qvc 5WFl52zFFH90bkvbOKct9eGZKwNJuNfKBRvIo4q18Rh5GSQgcdAsaKl7xxGl7UEqu9mJ oURM/PO748rp0XmxNlGFTUCav3inqovsig2RaG6bctF+Pa+bXwnxyAwwuMb7Y3SM2VA5 B0a1FqLZ0B+OLMn4axw4EJxGOM7o0S9pi3Uobm9ktLSDoRpcNcA4cl1A26wJxYeG0qX5 I8jg== X-Gm-Message-State: AGRZ1gKlSRH2mTAaLibHz5JandhlojT/1AYr8K3/pBtCP182qK29Uchw ZdpeMIXKEy1bbS7tilqdDNt0PeUNkcQ= X-Google-Smtp-Source: AJdET5dr/va3YnsMtIERGklaiihSxJbvFpJKnXN8MZ4otwLbcw2J5MuGDFYZACQrNkwYsFLbDu+DLw== X-Received: by 2002:a2e:63cd:: with SMTP id s74-v6mr5606610lje.117.1541772990595; Fri, 09 Nov 2018 06:16:30 -0800 (PST) Received: from ?IPv6:2a02:a317:4e3d:4680:f6ed:4b3c:7510:34c3? ([2a02:a317:4e3d:4680:f6ed:4b3c:7510:34c3]) by smtp.googlemail.com with ESMTPSA id g3-v6sm1269665lfj.3.2018.11.09.06.16.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 06:16:29 -0800 (PST) To: Werner Koch References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <23525.26229.995360.750323@chiark.greenend.org.uk> <87r2fuv6sh.fsf@wheatstone.g10code.de> <50990b61-ddff-93c7-ca96-ff864d1f4d79@metacode.biz> <878t22v04f.fsf@wheatstone.g10code.de> From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsBNBFs/lS0BCAC5oX3r3luF7czMF8UFxJz55XuvNRs4tEjo Hzqcqoe4+RJyfNDtspgevYIq1WTKw/H3ZYsd2wZpkM3I+BJn9eeHZKs77qXQZGN5PBB65rZo LjMx+qHa6wH4lIYMYW7eB9HHMsT/5E3ILBSRzZIwJimd/QdIMKSrJ5mPMkAd+9+xob5zKHO5 L5pbQtJSGS0m17/hA0kCTLI885hLtT3JsI/KWwuAYDrTwsayzh/hG/NgdA3I8xlrQCLC0EFJ oxHkN9tCyXeKPlrIPYyMB1jHTo1iNV0CQGpk+zf6DA/ySGfJxd30ksJZ8y5qxD43zS0YffYM C01CeuqPoGZ2Fy9VxhODABEBAAHCwXwEGAEKACYWIQRlOQmi8ON8EG9fr1RsiFfg2OjwdAUC Wz+VLQIbDAUJAeEzgAAKCRBsiFfg2OjwdKQ4D/wIb8s2Tw8MhbbwASutzTwg3g3KReDRHgSz z7RJtePIM8HC6qm9++9sxoqww7qm35vb604HtMRORYmfXgVSocsYg/eAk8LoBVfCZidDVBia /i/dYx/8LHeX/0PqPluSusQh64BFUoVetUCP+kISbK8vgDt4HfDSgtenC5lpTAdk257A84p2 zDnUtVr8XNv09m7ASft6Wh5Wrn+aWlJrf6T6eysk9OIw8VpSuq0oG3vcEoTbHKJN8TDliPUc QVz5Qti0tgB40PLrqOpTdENdxbiaUNFpHm3Tkk+n7CEFcOayFvy5vU6Nih0hu+LFC2XHzQRw sLnuQ2EilWtXRulcwvFo6A3Vp+gidxc6UwC+LBFJjvDMv5hmsdhSm08r2hd2k61oL6NCGVB3 fxuJT85UHsEC04N72Fa26+Spkh3DtJMrKqJlBBas7oJYh6644DB4rccd6VT3n7Zv1pd2uIWv gjORztfBzRJEysOeHoNpr4hEocg62beu9cnGHpYB9j3mhv+E2IYPnJKqit18G7xb7QnyQU7L YfctLO0GLNdTBavWJggHPzUp09vb3uGS3dMdAYbWTBtnXttkdYuLx/oCe1LVUQYotsX7s83V kVc2n6xzrcaebmgoFtGUfUmOV0U0xbqv6Mxg27qctYh1QidvRyt0xqGA0Qhz/vvoQdfQeMlO Tg== Organization: Metacode Cc: openpgp@ietf.org Message-ID: <110d48b9-3e43-b6b1-f51d-f30e000fa165@metacode.biz> Date: Fri, 9 Nov 2018 15:16:26 +0100 MIME-Version: 1.0 In-Reply-To: <878t22v04f.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 14:16:35 -0000 On 09.11.2018 14:41, Werner Koch wrote: > On Fri, 9 Nov 2018 12:37, wiktor@metacode.biz said: > >> If I'd be designing such a protocol now I'd probably overlay it on top >> of WebFinger (RFC 7033) but currently the benefits would not >> counter-balance added work for everyone involved. > > I actually looked into WebFinger but figured that there is no need to > employ yet another protocol format (JSON) and possible require special > handling on the server side. Good points, now WKD is single-roundtrip and easy to deploy in static setups although at the cost of making "special handling on the server side" harder (due to SHA-1). Looking forward to the I-D updated with "?l="! Kind regards, Wiktor -- https://metacode.biz/@wiktor From nobody Fri Nov 9 13:27:21 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A330512008A for ; Fri, 9 Nov 2018 13:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx_kPdKrliD7 for ; Fri, 9 Nov 2018 13:27:17 -0800 (PST) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (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 8BE13129619 for ; Fri, 9 Nov 2018 13:27:17 -0800 (PST) Received: from genre.crustytoothpaste.net (unknown [24.240.240.68]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 7CB0D6077B; Fri, 9 Nov 2018 21:27:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1541798834; bh=KrQpGjDdJAQCUEHYZpfXAdOX/rqm3+dAp2jjARZxOh8=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=ZWZDyqEzSrenVkgV1QVPAAE1X0xZUhvJKHdFw7EVEMc99EaEjGyG6P6rC1TMuQtFl hTpVCzMo3qfZXnHucLmUOomgnxWYYivWEX6GNihxlEyUpFKhvjapoIbscj2ykahJLK FIsWrGzLjuF+5jSw01suSKhmoPCXW0DHoptn1BZhGz6MBtIbg+AqIXVFg1XxHZ1DH1 NApjBrjkIDqVfOuS2x960R/fdwnsByhhR6pT3Ft0hdy9UGmHMYNZ4qx01pfkAR1OXg fOGrxuznbETS8gCD1YqqIkhGdXAsxe3tdTIWbpio7PW5mj8gE7GmUH0nD1k6V9UCkF bcWrel9mNV5yrNbFq5HNn4dS5lvxFVXhf3lKegvvixExXDZwFCaYqq9uBYV3TJaN8N Fi1ciaF++YIODsgCBUyBE90MyF+EY3xNXRyjBrUYBgXXuLorJISmTZ+mZXV6+rEoIa j62ubpQH0zajvdboUqoBSNScpGs4+Toi8XHjap6N//j0nvJFi+B Date: Fri, 9 Nov 2018 21:27:05 +0000 From: "brian m. carlson" To: Ian Jackson , openpgp@ietf.org Message-ID: <20181109212704.GI890086@genre.crustytoothpaste.net> References: <23523.16831.292658.490356@chiark.greenend.org.uk> <20181108012559.GF890086@genre.crustytoothpaste.net> <878t24yrzn.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HuXIgs6JvY9hJs5C" Content-Disposition: inline In-Reply-To: <878t24yrzn.fsf@wheatstone.g10code.de> X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.18.0-2-amd64) User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 127.0.1.1 Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 21:27:20 -0000 --HuXIgs6JvY9hJs5C Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 08, 2018 at 07:59:24AM +0100, Werner Koch wrote: > On Thu, 8 Nov 2018 02:25, sandals@crustytoothpaste.net said: >=20 > > I definitely agree that lowercasing the address is wrong. The RFCs say > > that the local part is case sensitive, and there are many case-sensitive > > systems on the Internet today. >=20 > Please tell me a single public accessible system which is > case-sensitive. Ask any non-hacker about mail addresses; almost > everyone enters mail addresses in whatever case they like. I have seen > many business cards which spell Joe.Hacker@example.org despite that the > canonical address is joe.hacker@example.org. See also the OpenPGP DANE > RFC for this. My mail system is case sensitive. Even ignoring me as an example, there's now SMTPUTF8, which means that case folding is nontrivial. Turkish has a dotted I and dotless I, and case folding a Turkish email address in the traditional ASCII way could produce invalid results even if the system is case-insensitive. Greek sigma case folds differently depending on position. Moreover, I expect some SMTPUTF8-capable systems don't case fold non-ASCII characters. Even if you think this is not an issue, RFC 5321 requires that the local-part "MUST be=E2=80=A6assigned semantics only by the host specified",= and we should not knowingly violate other IETF RFCs in writing our own. This is a MUST directive; it is not optional. If you adopted Ian Jackson's suggestion to not hash the name, then case sensitivity wouldn't be a concern; you could simply choose to let the remote system accept whichever case you wanted. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --HuXIgs6JvY9hJs5C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.10 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlvl+6gACgkQv1NdgR9S 9ovq6Q//XD+b9I55wamHhqcpZX9WfeqdsoWJtj9koBwHJifY59892Vq0rVVpow7J E5jCZwtToW4o9Syu1g+168AALz/JgkTaL3y0uzxXCxSJnjM7rla7qm1l+po4Jjyb rJdD6J2R+IiwMYk3/y2EwuYIshV6JyYoQnPv8f8skrIQaoFBm8obHWRLATjDs0Qm KL/tRdF/jflXnmnXOA0mtHZUEhLlpcgrHbd5thExfeZnRzPXqEH5qV/SU6rS58Oq aIWp/t0FbtCbQHmjkIUJKSwEkj/jt7faDpqksXVk/xbwP2qQ9heia5o7Gn5KrfDY vJYG4QY6GdOxRKdetU/5XCCCZZzWgWKvAzgE2N9ROZtLEXkmsVg+TkZuylnpCTkS x0A2KJNDQH7yNuEt636oWDDp4pVeJDs6J9q/CNgOrBWimaXRkNRuBMO4mbiPDt4s rjS/ppgGvX4NVvpIgRVU064ShmTEECECtyBEuwADSuzkDAR+J/16PF3Up6+YP5x4 eD2RLNhMIj8G3yKuIZaC3oVWS48Rqj8lzSYm/rT6E0CE9U9rFWOQk0B1Q52nTY/m E0unKDV43fOFaZ9tColw5zfNmY5Mef5tZU2xJ3fylnPip0BPqe/3hm1fHxyNhw0T fkXtQms5qHZV1skVQWhB5/jciOCckRiUqE2r0GsvIjevVvjnnf8= =0ypI -----END PGP SIGNATURE----- --HuXIgs6JvY9hJs5C-- From nobody Fri Nov 9 15:19:15 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53291277CC for ; Fri, 9 Nov 2018 15:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSC6LSEHJs3w for ; Fri, 9 Nov 2018 15:19:11 -0800 (PST) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (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 B8F661274D0 for ; Fri, 9 Nov 2018 15:19:09 -0800 (PST) Date: Fri, 09 Nov 2018 23:18:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1541805542; bh=Gll9t1HuAEekxbr1hWORW/MsQVQp9h61eLbVHfJOKT0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=eV7g3pBgs6RMzphdn+TvMhLCfDjjjjPFsrfv6PSC2SGijdfywJgBa5MGdDrUu8syr USbn32cG+JeuPl7S2pxkLBH/3jld31ZAAe9kIUzomR8QlJYtUNr+/2B4+6Njed6IFj oj+7f+Bt04M6SvJ7pkQrvh6Ej19oeUFedTQ6uJiU= To: Werner Koch From: Bart Butler Cc: Paul Fawkesley , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <87ftwbye1s.fsf@wheatstone.g10code.de> References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> <87ftwbye1s.fsf@wheatstone.g10code.de> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------4e0fbff813624bef82da5260eb102f9d"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 23:19:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------4e0fbff813624bef82da5260eb102f9d Content-Type: multipart/mixed; boundary="---------------------e40ec91144945dc8ebd3aedf8804a429" -----------------------e40ec91144945dc8ebd3aedf8804a429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi all, Based on discussions in Brussels, our current plan at ProtonMail is to imp= lement, on the 'serving' side: .well-known/openpgpkey/hu/?l=3DJoe.Doe@example.org accepting everything including and empty string for the hash and using the= 'l' query string parameter exclusively for lookup for all the reasons pre= viously mentioned in this thread and discussed in Brussels (case sensitivi= ty, +aliases/subaddresses, Unicode, catch-all addresses). The hash would b= e ignored. I think that long-term, two parameters that do the same thing and could co= nflict is bad and that while compatibility is a good short-term goal, we s= hould try drop the hash and to migrate to this final form as soon as possi= ble: .well-known/openpgpkey/hu/?l=3DJoe.Doe@example.org While this doesn't allow a filesystem to serve WKD directly, I'm fairly ce= rtain that one could do it reasonably easily with, say mod_rewrite and som= e minimal transformations or use RewriteMap with a script which does which= ever transformation you'd like (lowercase, remove subaddresses, etc). As for the SRV record discussion, I agree that JS support is a problem and= unfortunately that means supporting HTTPS. I'm wondering if we should sim= plify this and simply mandate the 'wkd' subdomain, full stop, rather than = having a fallback mechanism to the main domain. The reason for this is tha= t a client could determine whether the HTTP lookup is worth doing from whe= ther the WKD subdomain resolves rather than making an experimental HTTP re= quest for every domain periodically and contributing to the internet's 404= rate. With the current scheme, relatively high-volume clients like us would prob= ably need to do requests for the policy document periodically for each dom= ain we send to and cache the result to avoid getting banned for generating= too many 404s. The TTL for that caching would be decided by the us, the c= lient. With the 'wkd' subdomain all clients would get that kind of caching= for free via DNS, with a TTL controlled by the WKD server, which is both = simpler and more logical I think. -Bart Butler Sent from ProtonMail, encrypted email based in Switzerland. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, November 8, 2018 4:00 AM, Werner Koch wrote: > On Thu, 8 Nov 2018 12:08, paul@fluidkeys.com said: > = > > The requirement for the client to filter the return key for matching > > user IDs is a fairly big blocker for us. > = > We can't request a certain address and then work with any address > returned from the server. I am pretty sure that there will be server's > which store the entire key and not used the key stripped off all other > user-ids. Thus the filtering on the client site is important. > = > > We (and previous large organisations I've worked in) use + aliases > > feature extensively to distinguish different services, for example: > = > Yes, I know. We discussed this withe protonmail folks. One idea was to > ask the server for the rules it uses to canonicalize the address. That > will be quite complex and needs additional roundtrips. So the other > idea is to simply go with the '+' separator and have a special case for > it. Implementation wise it this requires changes at several palce to > have a consistent user experience. > = > > To stay compatible, keep supporting static files and resolve the case > > and aliasing issues, I'd support: > > = > > 1. keep supporting sha1-z-base-32 identifier > = > Already doing that. > = > > 2. additionally start supporting z-base-32 identifier with no SHA1 > > 2.a maybe put them at different path > > 2.b don't lowercase anything before searching for these > > = > = > GnuPG 2.2.11 does this as descipned in my last mail. > For example the URI to lookup the key for Joe.Doe@Example.ORG is now > = > https://example.org/.well-known/openpgpkey/ > hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe@example.org > = > No hashing is required, the case is not changed; the parameters undergo > the usual percent-quoting. > = > > 2.c in the client, don't filter on the user id for these > = > That is the harder part. The matching in gpg is anyway case-insensitive > and I would like to implement '+' style sub-addresses; that is ignoring > everything from '+' to '@'. > = > > Given that SRV records can't be accessed by Javascript implementations= , > > I don't think we can point to that as a solution > = > It is a pity that solid network techniques need to be dropped in favor > of large but uncooperative browser vendors. Adding an interface for SRV > records would be really easy and helps to support flexible network > administration. Note that I don't wan't them to use SRV records for > generic http requests but extensions should be able to use it instead of > resorting to external DNS lookup providers. [Arggh, it is the whole > everything must be http thing - I bet we will sooner or later see a new > IP protocol number for HTTP-ng]. > = > > > This is an open question but for a different reason: Current web > > > browsers have no way to lookup SRV records. > > = > > I'd support this. > > I'd also support dropping the whole SRV records part to simplify the s= pec. > = > I recently looked into a protocol *forgot which one) which didn't used > SRV but a domain name prefix. So, do you think that a strategy of: > = > First try > = > https://openpgpkey.example.org/.well-known/openpgpkey/... > = > if that host can't be resolved (or accessed?), fallback to > = > https://example.org/.well-known/openpgpkey/... > = > be a practical replacement for SRV records here? > = > Shalom-Salam, > = > Werner > = > ------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= ----------------------- > = > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -----------------------e40ec91144945dc8ebd3aedf8804a429-- -----------------------4e0fbff813624bef82da5260eb102f9d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvmFd4JEJkFRGXvMx5EAADsUQEA8O5t/wGSbG39ibt0Vk0v SP+Ae0+tRVQrm42JcENQiIQA/R4GdJUO0hDv4RrHB/+hhPqXBQbOY7ENUNkM UW5z6qIO =XUch -----END PGP SIGNATURE----- -----------------------4e0fbff813624bef82da5260eb102f9d-- From nobody Fri Nov 9 15:50:18 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509CD1286E3 for ; Fri, 9 Nov 2018 15:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7cvYi4GjRGp for ; Fri, 9 Nov 2018 15:50:12 -0800 (PST) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (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 5DF531277CC for ; Fri, 9 Nov 2018 15:50:12 -0800 (PST) Date: Fri, 09 Nov 2018 23:50:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1541807405; bh=0FN+8pcxAdPpDwD9r/qaEqyZ6he+V46q+U7ATZhZG8Y=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=iuOhMGbCVY1e56fAhfqgzIa7DgHlLgHPuN5QRe2sisRU71VHQbjf6mkww/oZfwXdd K8DJlJ0icJwGVZ/93yiJDdpyDTIwok9zK8pvcMRyRM/TCbvEPkt5G6MvjHXIWaHxiM 1sZRRc2DmZI3goeQGXg7yRJFznug5BmgbjtuJ6TU= To: Bart Butler From: Bart Butler Cc: Werner Koch , Paul Fawkesley , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> <87ftwbye1s.fsf@wheatstone.g10code.de> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------70162d41f57adbcaf333f3159e6b259c"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 23:50:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------70162d41f57adbcaf333f3159e6b259c Content-Type: multipart/mixed; boundary="---------------------d5eb70f1375939dbfaf4b45c105b7524" -----------------------d5eb70f1375939dbfaf4b45c105b7524 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 I also wanted to clarify in the WKD I-D that requests should follow HTTP r= edirects (301, 302). As I provider we would like this so that a client usi= ng us to host their email could just set up a redirect to our WKD server. = It needs to be at the HTTP level rather than using a CNAME record because = we do not want to have to host our clients' TLS certificates. -Bart Butler Sent from ProtonMail, encrypted email based in Switzerland. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday, November 9, 2018 3:18 PM, Bart Butler wrote: > Hi all, > = > Based on discussions in Brussels, our current plan at ProtonMail is to i= mplement, on the 'serving' side: > = > ..well-known/openpgpkey/hu/?l=3DJoe.Doe@example.org > = > accepting everything including and empty string for the hash and using t= he 'l' query string parameter exclusively for lookup for all the reasons p= reviously mentioned in this thread and discussed in Brussels (case sensiti= vity, +aliases/subaddresses, Unicode, catch-all addresses). The hash would= be ignored. > = > I think that long-term, two parameters that do the same thing and could = conflict is bad and that while compatibility is a good short-term goal, we= should try drop the hash and to migrate to this final form as soon as pos= sible: > = > ..well-known/openpgpkey/hu/?l=3DJoe.Doe@example.org > = > While this doesn't allow a filesystem to serve WKD directly, I'm fairly = certain that one could do it reasonably easily with, say mod_rewrite and s= ome minimal transformations or use RewriteMap with a script which does whi= chever transformation you'd like (lowercase, remove subaddresses, etc). > = > As for the SRV record discussion, I agree that JS support is a problem a= nd unfortunately that means supporting HTTPS. I'm wondering if we should s= implify this and simply mandate the 'wkd' subdomain, full stop, rather tha= n having a fallback mechanism to the main domain. The reason for this is t= hat a client could determine whether the HTTP lookup is worth doing from w= hether the WKD subdomain resolves rather than making an experimental HTTP = request for every domain periodically and contributing to the internet's 4= 04 rate. > = > With the current scheme, relatively high-volume clients like us would pr= obably need to do requests for the policy document periodically for each d= omain we send to and cache the result to avoid getting banned for generati= ng too many 404s. The TTL for that caching would be decided by the us, the= client. With the 'wkd' subdomain all clients would get that kind of cachi= ng for free via DNS, with a TTL controlled by the WKD server, which is bot= h simpler and more logical I think. > = > -Bart Butler > = > Sent from ProtonMail, encrypted email based in Switzerland. > = > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original= Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Thursday, November 8, 2018 4:00 AM, Werner Koch wk@gnupg.org wrote: > = > > On Thu, 8 Nov 2018 12:08, paul@fluidkeys.com said: > = > > > The requirement for the client to filter the return key for matching > > > user IDs is a fairly big blocker for us. > = > > We can't request a certain address and then work with any address > > returned from the server. I am pretty sure that there will be server's > > which store the entire key and not used the key stripped off all other > > user-ids. Thus the filtering on the client site is important. > = > > > We (and previous large organisations I've worked in) use + aliases > > > feature extensively to distinguish different services, for example: > = > > Yes, I know. We discussed this withe protonmail folks. One idea was to > > ask the server for the rules it uses to canonicalize the address. That > > will be quite complex and needs additional roundtrips. So the other > > idea is to simply go with the '+' separator and have a special case fo= r > > it. Implementation wise it this requires changes at several palce to > > have a consistent user experience. > = > > > To stay compatible, keep supporting static files and resolve the cas= e > > > and aliasing issues, I'd support: > = > > > 1. keep supporting sha1-z-base-32 identifier > = > > Already doing that. > = > > > 2. additionally start supporting z-base-32 identifier with no SHA1 > > > 2.a maybe put them at different path > > > 2.b don't lowercase anything before searching for these > > > = > = > > = > = > > GnuPG 2.2.11 does this as descipned in my last mail. > > For example the URI to lookup the key for Joe.Doe@Example.ORG is now > = > > https://example.org/.well-known/openpgpkey/ > > hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe@example.org > = > > No hashing is required, the case is not changed; the parameters underg= o > > the usual percent-quoting. > = > > > 2.c in the client, don't filter on the user id for these > = > > That is the harder part. The matching in gpg is anyway case-insensitiv= e > > and I would like to implement '+' style sub-addresses; that is ignorin= g > > everything from '+' to '@'. > = > > > Given that SRV records can't be accessed by Javascript implementatio= ns, > > > I don't think we can point to that as a solution > = > > It is a pity that solid network techniques need to be dropped in favor > > of large but uncooperative browser vendors. Adding an interface for SR= V > > records would be really easy and helps to support flexible network > > administration. Note that I don't wan't them to use SRV records for > > generic http requests but extensions should be able to use it instead = of > > resorting to external DNS lookup providers. [Arggh, it is the whole > > everything must be http thing - I bet we will sooner or later see a ne= w > > IP protocol number for HTTP-ng]. > = > > > > This is an open question but for a different reason: Current web > > > > browsers have no way to lookup SRV records. > = > > > I'd support this. > > > I'd also support dropping the whole SRV records part to simplify the= spec. > = > > I recently looked into a protocol *forgot which one) which didn't used > > SRV but a domain name prefix. So, do you think that a strategy of: > = > > First try > = > > https://openpgpkey.example.org/.well-known/openpgpkey/... > = > > if that host can't be resolved (or accessed?), fallback to > = > > https://example.org/.well-known/openpgpkey/... > = > > be a practical replacement for SRV records here? > = > > Shalom-Salam, > = > > Werner > = > > = > = > > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -----------------------d5eb70f1375939dbfaf4b45c105b7524-- -----------------------70162d41f57adbcaf333f3159e6b259c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvmHSUJEJkFRGXvMx5EAAD0egEAuWU/Bhuw3q+aHk4eo8UD O6tLvnxCLekoUWVcBCEOZPwA/2TD6B+im2kLSfj1TmwLtrrt+f4B/0/mzfS0 YS/J9SUE =6BUo -----END PGP SIGNATURE----- -----------------------70162d41f57adbcaf333f3159e6b259c-- From nobody Fri Nov 9 19:12:19 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91083130DD5 for ; Fri, 9 Nov 2018 19:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sO-TAt0rT9B for ; Fri, 9 Nov 2018 19:12:16 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 DBCA012D4EB for ; Fri, 9 Nov 2018 19:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1541819536; x=1573355536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OXASOKYmS3/sz56aEjAujf+G1PS/R7XnEZs+qfr9vEg=; b=rt9objjr5CVaBaX3Hoxkb2LN1ZLMmpGMXp9unmkrZlOUg9RM1qLLMU0q C8Q5cmqw9ksMBCAfdOcwO3xTtXVoY+9AzdhwVqFGtk/PzlF5fYj0859jb d93eoc9Dwy9PGQf/7iYhc7z2GaSCRtIraOzBpbrahHCHaoFePsoqpF3/t jdbQZ14KqjZ7XACiZHhGvp3drGWt6n0RN1ujORXJhqWEjGu7jEzzANVuU CSTZjRssh1q0MsHDEtG9c/VhHRG6CFmdCd5oJH4iYPuxkvnCTDXs4YwXB cTEQkYceL68x0KRM4nhchFSpi/gscF//LSkMjiYjcWdjwlgD8v90qUUpQ w==; X-IronPort-AV: E=Sophos;i="5.54,485,1534766400"; d="scan'208";a="38990068" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Nov 2018 16:12:11 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 10 Nov 2018 16:12:11 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 10 Nov 2018 16:12:11 +1300 From: Peter Gutmann To: Werner Koch CC: Vincent Breitmoser , Jon Callas , "openpgp@ietf.org" Thread-Topic: [openpgp] respecting key flags for decryption Thread-Index: AQHUeAMtvTjqM1Dj2EWug5wDrVC4uKVIVgI3 Date: Sat, 10 Nov 2018 03:12:10 +0000 Message-ID: <1541819520454.36449@cs.auckland.ac.nz> References: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> <1541716302530.66616@cs.auckland.ac.nz>, <87va56wu75.fsf@wheatstone.g10code.de> In-Reply-To: <87va56wu75.fsf@wheatstone.g10code.de> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 03:12:19 -0000 Werner Koch writes:=0A= =0A= >> Maybe all of these unofficial reference implementations need a strict-= =0A= >> checking mode for when they're being (incorrectly) used as reference=0A= >> implementations=0A= >=0A= > gpg --compliance=3Dopenpgp ....=0A= >=0A= >is intended to do just that.=0A= =0A= In hindsight my phrasing of the problem wasn't the best, it needs both a=0A= compliance-checking mode and someone who enforces it. At the moment the=0A= compliance check is "the message is accepted by GPG/Putty/OpenSSH in it's= =0A= default/most-tolerant configuration", in the sense of "XYZ accepts our=0A= message, therefore it's not our fault if your one doesn't". So you'd need= =0A= either some certification body that says "yes, your implementation really i= s=0A= compliant", or for the standard implementation to warn that the other side = is=0A= non-compliant when a message is received from it in order to force it to be= =0A= fixed - think Vista's UAC warnings that were created in order to deal with = the=0A= everyone-is-admin-all-the-time assumption of many/most Windows apps at the= =0A= time.=0A= =0A= Unfortunately I don't think either of those will be terribly palatable...= =0A= =0A= Peter.=0A= From nobody Fri Nov 9 21:01:00 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BD913111D for ; Fri, 9 Nov 2018 21:00:58 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Das-AgyWuGvs for ; Fri, 9 Nov 2018 21:00:57 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 1CE101310D8 for ; Fri, 9 Nov 2018 21:00:57 -0800 (PST) X-AuditID: 1209190e-adbff7000000394e-45-5be666077444 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.66.14670.70666EB5; Sat, 10 Nov 2018 00:00:56 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wAA50stI006440; Sat, 10 Nov 2018 00:00:55 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAA50opq016478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Nov 2018 00:00:53 -0500 Date: Fri, 9 Nov 2018 23:00:50 -0600 From: Benjamin Kaduk To: Ian Jackson , openpgp@ietf.org Message-ID: <20181110050050.GS65098@kduck.kaduk.org> References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <23525.26229.995360.750323@chiark.greenend.org.uk> <87r2fuv6sh.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r2fuv6sh.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDIsWRmVeSWpSXmKPExsUixCmqrMuR9izaYNIKRovVLYtYLBr+PWR3 YPL4dmoTs8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJWbjIoWMBVcbntLlsDYz9HFyMnh4SAicTm fX3sXYxcHEICa5gkti/czQrhbGSU6L3dwgpSJSRwl0li9fcoEJtFQEXi5vXTLCA2G5Dd0H2Z uYuRg0NEwFli8gZxkLAw0NAZl2+wgdi8QPaUw/ehFhxllLh3cAc7REJQ4uTMJ2BzmAW0JG78 e8kEModZQFpi+T8OEJNTwFji6RQekApRAWWJvX2H2Ccw8s9C0jwLSfMshOYFjMyrGGVTcqt0 cxMzc4pTk3WLkxPz8lKLdI31cjNL9FJTSjcxggNRkm8H46QG70OMAhyMSjy8P5Y/jRZiTSwr rsw9xCjJwaQkyqsb+yxaiC8pP6UyI7E4I76oNCe1+BCjBAezkgiv7Bagct6UxMqq1KJ8mJQ0 B4uSOO8vkcfRQgLpiSWp2ampBalFMFkZDg4lCV7PVKChgkWp6akVaZk5JQhpJg5OkOE8QMNv pwDV8BYXJOYWZ6ZD5E8xKkqJ884DSQiAJDJK8+B6QYlCInt/zStGcaBXhHkrQKp4gEkGrvsV 0GAmoMHWXx+DDC5JREhJNTAGeS97bPxA/er346my6T2LDojX8lUeav1VtrUn9F/0m3BJVv7b DsITBM9+ub3untvvS1r32J8kzBTz0Pa4kNnw6ZZ9ft2r5u93lNVkTtzdrXAnVTfbgvXU7ZsW izXWlPxZ3n3mxsZpH5PMz86dcmePkPGP1CXu4nMm7lQLTmh64NVYMrvfjZlFiaU4I9FQi7mo OBEA16vPTe8CAAA= Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 05:00:59 -0000 On Fri, Nov 09, 2018 at 12:17:50PM +0100, Werner Koch wrote: > On Fri, 9 Nov 2018 11:50, ijackson@chiark.greenend.org.uk said: > > > It certainly would allow serving the data from static files. If you > > wanted case-insensitivity and can't configure your webserver to smash > > It is not only about the case but about allowed characters in a file > name. In particular '/' and depending on file system the length. Noet > that '/' is a valid character in the local part of the addrspec. > > > Since you are still in the protocol design phase, you would no doubt > > welcome implementation and deployment of an alternative simpler > > Nope. It is in use for more than 2 years. I feel some obligation to push back on this -- if there is no willingness to deviate from the deployed implementation, why not just document the existing implementation behavior as part of the implementation's documentation and move on? -Ben > The only simpler thing which could have been done would be to skip the > hashing and directly use the z-base-32 encoding. The only drawback > would have been that very long addresses won't work on all file systems. > > Changes to the SVR record thing should be possible because I doubt that > this is widely used (Caesonia specifies it use, though). From nobody Sat Nov 10 00:52:44 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F9F130DED for ; Sat, 10 Nov 2018 00:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vft68kyVn4Y for ; Sat, 10 Nov 2018 00:52:41 -0800 (PST) Received: from pv35p14im-ztdg05061101.me.com (pv35p14im-ztdg05061101.me.com [17.133.187.44]) (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 8F8251294D7 for ; Sat, 10 Nov 2018 00:52:41 -0800 (PST) Received: from process-dkim-sign-daemon.pv35p14im-ztdg05061101.me.com by pv35p14im-ztdg05061101.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PHY00K00YZQU700@pv35p14im-ztdg05061101.me.com> for openpgp@ietf.org; Sat, 10 Nov 2018 08:52:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1541839960; bh=KPo/W2goLjD8FkcEayc/p0H7FMjV4//sqiokJXJZn+s=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=fBysty23grzsoGXRM7eXeUrXJwm88yytwmYJCyNELztQVLAryrjy1dNj949bJSHMg lQ4xTPaDRKcg7uOa0E8+Z1qewVaHvEW43WIKwOAjmz/KRmPdPSej08GTXPtr4vmOrI 5Vdu9DFbdEeTO9ZWB97kMVOyJnTUnz/3wK0/hJVDTwhWx1QwI80zvLQBTYvDljbNq+ b+bKks6HhQz13vKJoOSipeufr/DqOyNfA7UIXRoDyQTp3whefV4KwhkLRdeTtrKR7c Sx6Mh+1K8uKN2edl2jNCYOdH4z2JWI2H4ikNx10Czxq9Ig6fnkXKZw7IYnrw/P9qx4 7OSs+62I/lC3g== Received: from icloud.com ([127.0.0.1]) by pv35p14im-ztdg05061101.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PHY00A6UZBQQZ20@pv35p14im-ztdg05061101.me.com>; Sat, 10 Nov 2018 08:52:40 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811100047 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-10_05:,, signatures=0 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Jon Callas In-reply-to: Date: Sat, 10 Nov 2018 00:52:38 -0800 Cc: Jon Callas , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <75BF6022-6C87-45A7-9FE9-678EA022C39A@icloud.com> To: Vincent Breitmoser X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [openpgp] respecting key flags for decryption X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 08:52:43 -0000 > On Nov 8, 2018, at 3:24 AM, Vincent Breitmoser = wrote: >=20 >=20 > Hey Jon, >=20 > thanks for your thoughtful reply! And thank you for appreciating it. >=20 >> Moreover, gnupg is not merely a tool, it=E2=80=99s a reference = implementation and as >> a reference implementation it needs to have meta-features for the = purpose of >> debugging. >=20 > I agree with thre premise here, but not the conclusion. In the = concrete bug > report I have, a bank(!) implemented OpenPGP in a way that included = two major > blunders: 1) they encrypt to a subkey that doesn't have the flag. 2) = they > include a one-pass signature packet, but then no actual signature = (which isn't > a valid OpenPGP message, by spec). >=20 > The reason this happened, I strongly suspect, is exactly because they = treated > GnuPG as a reference implementation: they tested that it worked = against GnuPG > (or some frontend), found it worked in practice (without even a = warning), and > then left it at that. I think you=E2=80=99re mischaracterizing my conclusion. My point and conclusion is that you shouldn=E2=80=99t let people who do = stupid stuff contaminate the ecosystem. We are starting from people who have screwed up. They screwed up because = they didn=E2=80=99t understand or they didn=E2=80=99t care. You=E2=80=99re= not going to make them understand by typing harder and making your keys = click louder. Most importantly of all, you=E2=80=99re not going to make = a stupid person smart by modifying the standard. The whole premise that = we are starting from is a botched implementation. My conclusion is that we shouldn=E2=80=99t make working implementations = brittle in the belief that this will make the botched implementations = suddenly correct. Now I did go off into a rant and a jeremiad, and that may not have been = clear, because good rants and jeremiads tend to wander. So let me try to = be clearer while still being entertainingly ranty. The purpose of a standard is for interoperability. The standard = describes a language that my software and your software can use so that = together we are better than either one separately. However, the standard = is a map, it is not the territory. The territory is the software in part = and the people most of all. If the software is inferior or brain-damaged by following the standard, = then this is very bad. Sometimes this happens accidentally. It should = never, ever happen that the standard *intentionally* forgets its place = in the world and mandates bad experiences for the users. A good software = developer makes good experiences for the users. Always. If that means = breaking the standard, you break the standard. Especially when the = precipitating action is that someone *else* broke the standard. I never invoked Postel=E2=80=99s principle. If you read what I wrote = again, I very carefully, *intentionally* did not invoke it. Trust me, I = know what it is, and I have also read Thomson=E2=80=99s I-D. He has a = point, but I think that his point is basically just the flip side of the = problem. I believe that you=E2=80=99re bringing up as a straw man to = beat. Nonetheless, let=E2=80=99s examine it for a moment. All virtues when taken too far end up being vices. Nearly every = nourishing food is bad for you if you eat too much. Nearly every = medicine is a poison if you use it improperly. Even moderation (which is = what I am preaching here) can be taken too far, and be mealy-mouthed = wishy-washiness. Sometimes one has to take a stand. The questions of = course include which stand to take, how firmly one takes it, and so on. There are a lot of people who use (or used) Postel=E2=80=99s principle = as an excuse and justification for being a lazy programmer, for being a = bad programmer, for writing misfeatures for being unwilling to fix their = bugs. People use it as a way to say their shit doesn=E2=80=99t stink, if = you=E2=80=99ll forgive my language. When someone uses it as an excuse = for their bad behavior, that is bad. But it is not Postel=E2=80=99s = principle that is bad, it is the people using it to justify bad behavior = that is bad. Let me digress into an example. This digression is very relevant as it = is directly analogous to this situation as you will see. For better or worse, the PGP software did not implement Blowfish. = Personally, I think it was for worse, but it doesn=E2=80=99t matter. The = point is that we didn=E2=80=99t, and while the reasons make for a fun = anecdote, they genuinely are a digression. We had a problem, though, and = that was that there was an implementation that encrypted using Blowfish = even when someone=E2=80=99s key didn=E2=80=99t have Blowfish in their = symmetric cipher preferences. This is a violation of the protocol. It=E2=80=99s a bug. The protocol = states that you are not to encrypt using a cipher that is not on the = recipient=E2=80=99s preference list. Here=E2=80=99s where you should = notice the similarity to the sign-only public key.l In each case, the = recipient has made statements to the sender and the sender botched them. Our problem was that our users were getting messages that they = couldn=E2=80=99t decrypt and they were justifiably irked. Our initial = answer was the same as what this discussion advocated =E2=80=94 passing = the blame on to the other software. In each case, as well, the = implementation that provides the bad experience is in the right. The = other side is broken. However, it was *our* users who were getting the = bad experience and the other people didn=E2=80=99t want to fix it. What we did was to get off our our high horse just a little and do the = right thing for our users. We put Blowfish into PGP, but only on the = decrypt path. It was never in the UI, we never encrypted to Blowfish. = (For all of the wacky, downright stupid reasons that are orthogonal to = this story.) In the case where someone else=E2=80=99s implementation was = broken, we did the right thing for our users. We decrypted the message, = and showed it to them as if everything was done correctly, despite the = fact that someone else had a botched implementation, and arguably we = were botching our own. Our allegiance was to our users. That is good software engineering, in = my opinion. We also went behind the scenes and got the other people to = do the right thing, but it took a while, and even after the other = implementation was fixed, the latent issue still hung around for a long, = long time until all the other users upgraded. I know what some people are thinking, they want to come up with some = contrived example in which if this had happened or that had happened, it = would be bad. They=E2=80=99re right that if it was bad, it would have = been bad. It=E2=80=99s always true that bad things are bad. But = sometimes, ugly things are less bad than the pretty ones. In the case of = our Blowfish example, or this one with sign-only keys, it doesn=E2=80=99t = *hurt* anything to make a good experience. It doesn=E2=80=99t ruin = security. It doesn=E2=80=99t give wrong answers. (To the contrary, it = gives *right* answers.) Yeah, it=E2=80=99s ugly. It=E2=80=99s inelegant. = If you=E2=80=99d prefer that I characterize it as the =E2=80=9Cleast = bad=E2=80=9D answer as opposed to a right answer, sure. I=E2=80=99ll = concede that. Ultimately, I care about good experiences for the user = over purity. However, I also have a huge live and let live streak as well. If you = disagree, and you want to do *your* implementation so that when your = users say, =E2=80=9CWTF=E2=80=9D the answer is, =E2=80=9CThat=E2=80=99s = what the standard says,=E2=80=9D then more power to you! It=E2=80=99s = your gun and your users=E2=80=99 foot, to my mind. What I object to, and the whole reason I started this is that I object = to changing the standard so that it says I should shoot my users in the = foot. That=E2=80=99s the real point. I=E2=80=99m all in favor of the = standard saying, =E2=80=9CLook here, doofus, don=E2=80=99t encrypt to = sign-only keys!=E2=80=9D I am not in favor of it saying, =E2=80=9CWhen = some doofus has encrypted to your sign-only key, OMG, whatever you do = don=E2=80=99t decrypt it!=E2=80=9D You talk below about the health of the ecosystem, and this is where we = agree. What we apparently disagree on to my mind is how this case is = handled. Remember one again that this starts with a broken = implementation that was done by someone else. It isn=E2=80=99t, in my = opinion, about Postel=E2=80=99s principle. My interpretation of his = principle is about how you handle gray areas, or the inevitable case = where reasonable people might disagree about an interpretation. This is = a case where the other implementation is flat-out wrong. My principle is = not Postel=E2=80=99s. My principle is to do what=E2=80=99s right for the = user. In these two cases, the right thing for the user is to decrypt the = message. In other cases, it=E2=80=99s going to be to the opposite. (If = this were, for example, about someone who botched an MDC, you=E2=80=99d = be hearing a very different thing from me, as that can hurt the user.) = It sounds to me like yours is to follow the spec. I also think that you = believe that there is some greater good in following the spec. I confess = that with me, it=E2=80=99s far more whether I as a user would rage-quit = the software and just stop using it. A few more inline comments below. >> OpenPGP oughta say that an implementation MUST NOT encrypt to a = sign-only key, >> but it should leave it at that. >=20 > I believe that this all goes back to Postel's law of "conservative in = what you > emit, liberal in what you accept". You're advocating for being = "resilient" in > the face of bugs in implementations, and that sounds like a good idea = on paper. Again, no, this isn=E2=80=99t Postel=E2=80=99s principle. This is about = what=E2=80=99s right for the user. It=E2=80=99s also about freedom to = implement. I think it=E2=80=99s fine for you to be strict, what I object to is the = meta-point, that there are no other reasonable interpretations. >=20 > It is at this point terribly hard and time consuming to write an = OpenPGP > implementation that works interoperably, because of a general = expectation that > everyone be 100% GnuPG bug compatible. Then those people are wrong. As I mentioned above, PGP was not 100% compatible with GnuPG. It = didn=E2=80=99t implement Blowfish. I=E2=80=99ve been involved in other = implementations where we implemented a subset of all the possibilities = of OpenPGP. The most problematic part of subsetting OpenPGP is dealing with = compression, but even that, if you make your keys correctly will work = just fine. You can make an OpenPGP implementation that just does a very = few things. > It's just a blip on the radar, but the > case described above happened five years into working on OpenKeychain. = And it's > not a fluke, I have more similar incidents (will post about them = soon). Sure. People screw up implementations all the time. So what? Repeating myself, if your software gives your users a bad experience, = they=E2=80=99ll find other software. That software might be OpenPGP = compliant, but likely they=E2=80=99ll say something like, =E2=80=9CWhy = are you using OpenPGP when you could be using Signal?" >=20 >> The standard should not forbid resiliency in the face of a bug. >=20 > This is a very reasonable sentiment for specs like HTML, we certainly = wouldn't > want to outright reject a website just because of a missing . But = in the > context of a cryptographic protocol, this is super dangerous. >=20 Why? You assert that, but give no evidence. There is no cryptographic = problem here. It=E2=80=99s a policy problem. > Being overly relaxed in what we accept means giving attackers a large = amount of > wiggling room. This is exactly what brought us EFAIL. We should learn = from that, > and I hope we can do better in the future. You used the weasel word =E2=80=9Coverly=E2=80=9D and I think that=E2=80=99= s the crux. The debate we=E2=80=99re having is over what =E2=80=9Coverly=E2= =80=9D means. And frankly, this has nothing to do with EFAIL. But = that=E2=80=99s another discussion. I would be happy to talk about EFAIL, = but it=E2=80=99s irrelevant to this discussion. Jon From nobody Sat Nov 10 02:15:15 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2101294D0 for ; Sat, 10 Nov 2018 02:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkOUTKWhj9C2 for ; Sat, 10 Nov 2018 02:15:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 197E5130DBE for ; Sat, 10 Nov 2018 02:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uk1sfk+kYFL7/tgdEBofJuxBvNWEFYXv3Eaw4G5DktI=; b=GYN6FItUSBjbqxw9rdU9mWL0jz TO4WVfxvgp+RcO/CqyjwHuTr0LeXYCq7lZ5Z7ZYhiomvP7hhelh7KGQzTQ4qntMk0poGIpUNNoczX 78QLZXvwKJdd6vfntiFUMROgpjMQ4a1/N8fmYq/Xl38U4OCSgQ3HRUozwhjpj7HPpDoM=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gLQIH-0000Qw-8N for ; Sat, 10 Nov 2018 11:15:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gLQGQ-0001p8-8U; Sat, 10 Nov 2018 11:13:14 +0100 From: Werner Koch To: Benjamin Kaduk Cc: Ian Jackson , openpgp@ietf.org References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <23525.26229.995360.750323@chiark.greenend.org.uk> <87r2fuv6sh.fsf@wheatstone.g10code.de> <20181110050050.GS65098@kduck.kaduk.org> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Benjamin Kaduk , Ian Jackson , openpgp@ietf.org Date: Sat, 10 Nov 2018 11:13:08 +0100 In-Reply-To: <20181110050050.GS65098@kduck.kaduk.org> (Benjamin Kaduk's message of "Fri, 9 Nov 2018 23:00:50 -0600") Message-ID: <87lg61tf4b.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=jihad_BROMURE_Exon_Shell_ISEC_BLU-97_A/B_Vince_Foster_.400_million_i"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 10:15:13 -0000 --=jihad_BROMURE_Exon_Shell_ISEC_BLU-97_A/B_Vince_Foster_.400_million_i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 10 Nov 2018 06:00, kaduk@mit.edu said: > I feel some obligation to push back on this -- if there is no willingness > to deviate from the deployed implementation, why not just document the > existing implementation behavior as part of the implementation's Simply because there are deployed services which required quite some in-person discussion. Telling them that they need to replace it by something new is not a convincing argeument for running a web key directory. Sure over time it can eventually be removed. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=jihad_BROMURE_Exon_Shell_ISEC_BLU-97_A/B_Vince_Foster_.400_million_i Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+avNAAKCRD/gK6dHew1 jbubAQCIOTMGuBPlv6SpwdNL+KSdfZfu7DDV+35z4TGmnox60gD+NHJ67Tl63EFk 8oUpuIaNeE3wmmZF41I1+8UNvMivYA0= =3T07 -----END PGP SIGNATURE----- --=jihad_BROMURE_Exon_Shell_ISEC_BLU-97_A/B_Vince_Foster_.400_million_i-- From nobody Sat Nov 10 02:30:13 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53823127332 for ; Sat, 10 Nov 2018 02:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjgof1o_MX_s for ; Sat, 10 Nov 2018 02:30:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 D47A4124408 for ; Sat, 10 Nov 2018 02:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=m3FJhXX3fVAIVrdbIEDY9djoL1+7lg2VFGPIXJZLznc=; b=YdoPw4DlU744bwduD9DYpq/0e1 FXELXj8GveNAUGOoX8BfL99jylhsh3jclcRyDSnFb6evXhG4xRPMUA71Qemp0NgKYjcG9upOX3GKG r0+mWT+H9d7JR3jWEi0aGswIp6C+rIfQx1ODogbktd6YHkPhHYlSrwp5nEPaPUGI5c1A=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gLQWn-0000Wi-A6 for ; Sat, 10 Nov 2018 11:30:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gLQSA-0001ux-7K; Sat, 10 Nov 2018 11:25:22 +0100 From: Werner Koch To: Bart Butler Cc: Paul Fawkesley , "openpgp\@ietf.org" References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> <87ftwbye1s.fsf@wheatstone.g10code.de> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bart Butler , Paul Fawkesley , "openpgp\@ietf.org" Date: Sat, 10 Nov 2018 11:25:21 +0100 In-Reply-To: (Bart Butler's message of "Fri, 09 Nov 2018 23:18:57 +0000") Message-ID: <87h8gptejy.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=offensive_information_warfare_gamma_bemd_csim_MP5K-SD_Capricorn=inve"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 10:30:12 -0000 --=offensive_information_warfare_gamma_bemd_csim_MP5K-SD_Capricorn=inve Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 10 Nov 2018 00:18, bartbutler=3D40protonmail.com@dmarc.ietf.org said: > reasons previously mentioned in this thread and discussed in Brussels > (case sensitivity, +aliases/subaddresses, Unicode, catch-all > addresses). The hash would be ignored. BTW, the sub-addressing does not seem to be a real problem. A cursory inspection of some large keyrings showed that user-ids with sub-addresses are quite rare and there is always the opportunity for the user (or a tool) to create another user-id w/o the sub-address. Thus the sub-addresses can be handled in the MUA and won't need protocol support. > I think that long-term, two parameters that do the same thing and could c= onflict is bad and that while compatibility is a good short-term goal, we s= hould try drop the hash and to migrate to this final form as soon as possib= le: > > ..well-known/openpgpkey/hu/?l=3DJoe.Doe@example.org I disagree but I don't think it is the time to discuss this now. Let us first deploy a useful key discovery and then see how it can be improved/changed. > should simplify this and simply mandate the 'wkd' subdomain, full > stop, rather than having a fallback mechanism to the main domain. The I concur. Given that we need to drop the SRV records for silly reasons anyway, we can also demand a fixed subdomain. Given that I don't like the "wkd" acronym, I would prefer to use a different name, like "openpgpkey". And regarding your other mail: Sure, a redirection can only be allowed to use a http redirect and not with a CNAME. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=offensive_information_warfare_gamma_bemd_csim_MP5K-SD_Capricorn=inve Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+ayEQAKCRD/gK6dHew1 jXx6AP9N3Xx4TRhTCCKEOhGv6CzanHE8/tkBtVLr1Ic3hcRoGAD/SgNMiVWtR1U8 WwOma20Lh2xNyzaRUxYirSk5qfKGXwE= =fDAZ -----END PGP SIGNATURE----- --=offensive_information_warfare_gamma_bemd_csim_MP5K-SD_Capricorn=inve-- From nobody Sat Nov 10 02:30:49 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C503130DBE for ; Sat, 10 Nov 2018 02:30:42 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 CQn3ZtmIXfNc for ; Sat, 10 Nov 2018 02:30:40 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 6D10712F18C for ; Sat, 10 Nov 2018 02:30:40 -0800 (PST) X-AuditID: 1209190d-623ff70000000a08-c8-5be6b34e8e7a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.A4.02568.E43B6EB5; Sat, 10 Nov 2018 05:30:39 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wAAAUYDG023952; Sat, 10 Nov 2018 05:30:35 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAAAUU38011991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Nov 2018 05:30:33 -0500 Date: Sat, 10 Nov 2018 04:30:30 -0600 From: Benjamin Kaduk To: Ian Jackson , openpgp@ietf.org Message-ID: <20181110103029.GV65098@kduck.kaduk.org> References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <23525.26229.995360.750323@chiark.greenend.org.uk> <87r2fuv6sh.fsf@wheatstone.g10code.de> <20181110050050.GS65098@kduck.kaduk.org> <87lg61tf4b.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <87lg61tf4b.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixG6nruu/+Vm0wYkF3BarWxaxWDT8e8ju wOTx7dQmZo8lS34yBTBFcdmkpOZklqUW6dslcGXcfNnAXDCBt+JXyzP2Bsa93F2MnBwSAiYS mx6cYuxi5OIQEljDJLF92jQoZyOjxLcHP6Ccu0wSu2YeYANpYRFQlZi7tB/MZhNQkWjovszc xcjBISLgLDF5gzhIWBho6ozLN8BKeIHs7TcXsEDMmckk8f1KHztEQlDi5MwnLCA2s0CZxLzd c9lA5jALSEss/8cBEuYUMJaYMeEwK4gtKqAssbfvEPsERv5ZSLpnIemehdANEdaSuPHvJROG sLbEsoWvmSFsW4l1696zLGBkX8Uom5JbpZubmJlTnJqsW5ycmJeXWqRrpJebWaKXmlK6iREU 7JySvDsY/931OsQowMGoxMMbsOpptBBrYllxZe4hRkkOJiVRXt3YZ9FCfEn5KZUZicUZ8UWl OanFhxhVgHY92rD6AqMUS15+XqqSCK/sFqBW3pTEyqrUonyYMmkOFiVx3t8ij6OFBNITS1Kz U1MLUotgsjIcHEoSvCWbgBYIFqWmp1akZeaUIKSZODgPMUpw8AAN1wSp4S0uSMwtzkyHyJ9i 1OXYdqZzBrMQ2AVS4hBFAiBFGaV5cHNAyUsie3/NK0ZxoBeFeVeCVPEAEx/cpFdAS5iAllh/ fQyypCQRISXVwPhsZrDMuSSfv6eWmZh/MXP4l3pml4Fos00/g/zDIqPJEixNB8XnSVrsDKtj aFJ0vWd1baendO0Kkz95S4Le/wvdOrPLK9/P7eOeU449Z7j0nvbk82hOaF/IJrSYs4/NUSLA dM7x+4ZB3x5Id+yN/TJ/yemFV3c2rju2cAoPu7L1LhWV0HZ/HiWW4oxEQy3mouJEAC3nelY5 AwAA Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 10:30:43 -0000 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 10, 2018 at 11:13:08AM +0100, Werner Koch wrote: > On Sat, 10 Nov 2018 06:00, kaduk@mit.edu said: >=20 > > I feel some obligation to push back on this -- if there is no willingne= ss > > to deviate from the deployed implementation, why not just document the > > existing implementation behavior as part of the implementation's >=20 > Simply because there are deployed services which required quite some > in-person discussion. Telling them that they need to replace it by > something new is not a convincing argeument for running a web key > directory. >=20 > Sure over time it can eventually be removed. Thanks for the clarification -- I probably misread the context in which the original message was given. -Ben --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlvmszYACgkQKNmm82Tr dRLdSgwbBk+TWs/EpMqt67xrDLSIZZtTPsKukdgoGWDjnRASr2UDSRuTS+f1YYbz v3O9COiQztYu/muNT+nQ3f4hg7Jj2QMhFgR1tINT+Z16np71a0BSIU5cTT74QCvG Fush0U9G1U521QBlirtbfeUDQNisFFA0rW9TOg3xuMVV0GMkHdtp7yZkVKpv0XC4 Jg3MfLsB3TzlFXUjS72uEjuUKbKgtXoo5dteQl0n12RLiQ6u/4hICzfIXRwR4rho /wv+EI2f5vTJv5CVXVG8PXlUtf2VPSsLt1Z0n6AP96OqNMSKo/H78vXhHDx5HYpz UUu33OzV51NBdjmYvbUENxyetSXWdiDE9HESOcUJqr66MgGFsg+OIoImRYYFyHI/ eEfZJcdnyR9wikyt92FtiZUS+J+tcuYxloZAM4bFNOTWNQ1wbz7QNyz4x1Gyusg6 jT09YYI2X3Hio6MKK9uPkKgh8mFhQWnlMgXS8RqawI/D8yBc3xhKGB1Wmb857Ogo x6wdPw6gpH3Fjg== =tY7M -----END PGP SIGNATURE----- --xgyAXRrhYN0wYx8y-- From nobody Sun Nov 11 04:57:20 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A806A1292AD for ; Sun, 11 Nov 2018 04:57:18 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TOR4kaKwVvnX for ; Sun, 11 Nov 2018 04:57:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 4CBF9128DFD for ; Sun, 11 Nov 2018 04:57:15 -0800 (PST) Received: from [192.168.178.30] ([79.244.53.218]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lx4dh-1fOu1G3Rhx-016jjs for ; Sun, 11 Nov 2018 13:57:12 +0100 To: openpgp@ietf.org References: <877ei9szyc.fsf@wheatstone.g10code.de> <87mur2nyt6.fsf@wheatstone.g10code.de> <87tvlam1iz.fsf@wheatstone.g10code.de> <87lg6lm2w8.fsf@wheatstone.g10code.de> <486d2345-69c1-c329-d887-f164b5dc90d4@metacode.biz> From: Heiko Stamer Openpgp: preference=signencrypt Autocrypt: addr=HeikoStamer@gmx.net; prefer-encrypt=mutual; keydata= xsDiBDdYKNkRBACRdsFzaQn0HChOX38WHXlIYcNZAAxBQxa7gdmPXTUK+tgwQuwAr/XViQxn ExKwyOteRhwHZNSYdoKPlCOJ3c3FWCKAdflINr53NvN/qnnaF+3M1HaluiwVdfHD9a0+k7fd NFZMq2bTpzSCQBsPGipSK0K8ET8UPrXm54pXhqYL2wCgsuMBOv64bmg2zjg6vHSTKADGykcD /Agjoa7y7Cpifk4WEKDKu8nlrE9OFOJppjZ9bdJedrmZq5A/jHr35UOgbZItTmgBiz7bfMLq 7HD05ZQ3BplBmmiE0412f55GadCjN4vvnCdTqZ/ewzWdz/rzQGaJm9IvW6rupuFgrTx0GJhf we7cr6GQQo0nqA0LMCyhGHQASC56A/9NOroBzLM6wl9QlE9lybxd3cxI2UnrfHIu63tklFKF vL1XnjyJ4YR0sDs6/f56JbtEGUKTCI7ZAw+241Va4MrbDVmmsGJjQBcKxNbHDfkkjoJ9NBwr pUo2nMT3BWyKHCfnMqoyT+nN04b0Em1ffbhptKiLJSeY1mcPxvA1h7PrKc0lSGVpa28gU3Rh bWVyIDxoZWlrby5zdGFtZXJAcG9zdGVvLmRlPsJiBBMRAgAiAhsDAh4BAheABQJTnH9pBgsJ CAcDAgYVCAIJCgsEFgIDAQAKCRBPWE64+yvhT4n9AJwNsUcN5bx9/gtUs4LMmqBcePkQKwCf Y4FmM1D4rmTWsHQ1NRgsiqQhc27Owk0EN1gq2RAMAK4ZTZJZeaOmjIYhf9QfN7rQ6iXEF20r OG8NkeHLVLPw02t2QjejO5g4zGQplktPD+JCKBU1B/DL7l8BTDopofw4+fAierJ6C4jo/AbS pArZxaVJNkOVNbwHYPdCmO3yxieeMYQgYoZvtkBSA4OZZh2xLfmi3IRBPRSf+REiqPJBy9aA 0f7634vKldTG7R4PR2UP+THjpM/2SpNiyv/y9ZaEPYn3zHRkWsUw3xAMIiE73Hen6o/J9KIB 2e4jiI3VFiwq0LaKRv5whzltjKydGi2zVqcDLc93lDxsW2OXPE89GH3S/9irlEz/ciBuxtLT MMjSV3OeV34Mid7Muz8RE6whOaZteuEgAcLxONxe3FZHeG2cUuciCZDdFqDRtB6w0XhjltdI ZzD8zHBZyboRfBxubtRzriTxjFcxjI3L5df9uLWjuvkl0fSYpQV5dMX1Yus2kXiMHKUeTVE0 NtHqSnozzu88l6D+dCHX0i1BDFgkZi70oGEEaEW0NQgDItOdNwADBQv/a0d7nasV4JW9mjtF nlJDL9pyXHuGc+y9vfJNdy+DlzuHB44vtl+yH9ecTdpxE7RgB8ZvQvEwUmV+keBw+5NkR3ms +AnPrwZxwAIE/DxnwyBAQETkf9SIBH8cz0BCYQ37B+N4OW/pkYSWadjn2Bgi4IZRWyrDmnAI KwsGzfGUxPIKI3AMcRFFqjdhMaFo3L2GwJ2o0dBxd1LN0Xo6298ydcjrtAbKI1xuNXBfBAeU YCzGjg7cUw6XXfyjU5rTQkxKTu13xsKUwCnse7jOvDnfdNnYC+n7o4WNQBDhTiF0QMZ482ba FtCKcqdQJ3fQ9uioh1kOZirhJJ40xtYrDLcS3H9rQZff0X+CeOa94EdJYYYH7BIpysrfJ9c1 cxrg5brzeb9ofWaxLQvRIXBubbDtd0AunQMJXTfXHUmgYCdzSZVyy1tUzso1QacI4D0PhRIo euP8ihlWhqnHRv5tY8Ue18uFybaVIOWrsXXjQOVBUvXFmYCc9ykvJcyYSadLYkJlwkYEGBEC AAYFAjdYKtkACgkQT1hOuPsr4U9xEwCeKB7jHvmUrWnuxsqx2Flvq2/gIk8AoKkOpGf2jud+ 8uWi5c1ohHWeuLtz Message-ID: <5b72cd41-2941-54a3-92fc-3bc6a633798b@gmx.net> Date: Sun, 11 Nov 2018 13:57:12 +0100 MIME-Version: 1.0 In-Reply-To: <486d2345-69c1-c329-d887-f164b5dc90d4@metacode.biz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:k2Eje2j6bYD5W460piLU4WTv9byS07qLPjKbglSVmZIVWBjrXoi qAS3iM4r5N1tvGiPN6mlqagQMcjT9Ci9vwdEM/8xpOa4qC4U8Om6cdk6Na4kJxlbvOa2JbJ Ae9O00l0hm0KEpun9c56a1zOvQ0SuUqLGDoJkPB0kAeY3oZApOqv/2/BZzWJ1EEzeZWCKvO JbpYQUBFBbfLvfAVR+SJg== X-UI-Out-Filterresults: notjunk:1;V01:K0:gtjbosILO58=:jFI4CyW+b1Tl2val21sokw jtxfjLTxtjc/ktxg+qnToG7NhVA8ihCZztHuXUlAqGnopx3choP8sdI1/8094DNRS8hdvLpN/ kjYKzNKBXX0kXe2//g7+D3ssQPaIgapJ0cDiAMg7RjTdj0BygGESUFns+wMWueVsdQxczo1AM 1tvuPjciggEaOHDCShwjxdecZCweXcMeCrrVU/ns8T5rQFIZ1BEl4wXpDhmQvIvD2V3j59TYB F2tetveZ+34UIf50xRdPOlrFW/M6Y/GrCqi8K3LqlaS9U+SwAZXHcX/dB7FawEhRXzCVuq17L uFTosaVwobmEICYvH4cuKWUgszGSfeOywh6hqDnnvcFLZupoKDr4sdwh+y16yD9jAsKIcts+M rx2eWM7cpkDJ3tf39Wtk6mUAw/4bSuPovP0MPWLR40ItUUOb+yiIWphSmtaBqZYUdcAbzY0Zp hWNnX1MwREgGhIJuPcOrH9zhc5Pz7f5AeG4yAzMOa8TRzVjWpgELn08rm5ZIR3ydJeLw2d8e8 mJrIlmTkJWBNXAc2zVjPA6BDzqYzlvctvVkSesI7HitLkEq7CXUFjlXci6Wy6P4/nfjO0ojE9 3pEYX8wsjnsl3JzXL0Mn0ZhUFwHXepeSRmtjJ3crpMQVC1t8JFU8GpnnMw8f/ZU+51t8aQUKK D13AF+5uM/W82jbyLoPKUDqn2bxLyJd7+k0C+JXF9Hxh5rY4BsyJEV3XVhDq/hxqrr+nXbVSM ntThFgOxQPQbZWe1ZY8NlO0UBgQR9hp7Eqf+Ct/zT4rp1rEHJB+pyoBBjdhP4BxNG5Mgpqcg9 lA02rNXfTpIydkiKFW8eU+84LDjv9ZG86mGjJLibVg0KCKHlZieqPhKlE84/mDx0gvxCde8Pj dFmg0X0EXkZLmPoKYFtzA8IxFCso7CQUU1/ELL8ql+yyMuLHVJBmfno5KIVhPX Archived-At: Subject: Re: [openpgp] Clarifiction on v5 signatures X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 12:57:19 -0000 Hey Wiktor, Am 26.10.18 um 13:19 schrieb Wiktor Kwapisiewicz: > Split key (0x10) looks like a good way to implement separation of duties > (where multiple people are needed to use the key). I don't think this is > possible in OpenPGP now. This was one reason to create DKGPG: https://www.nongnu.org/dkgpg/ Currently, there are some efforts at NIST on threshold cryptography: https://csrc.nist.gov/projects/threshold-cryptography Best regards, Heiko. From nobody Sun Nov 11 13:08:25 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25D130DD0 for ; Sun, 11 Nov 2018 13:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh60e1oKz_II for ; Sun, 11 Nov 2018 13:08:22 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 D67D81286D9 for ; Sun, 11 Nov 2018 13:08:21 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id s5-v6so5817893ljd.12 for ; Sun, 11 Nov 2018 13:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:references:cc:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=phVX5fa+1ED/c4XvngWEwcBtcWm7lwkW7NHLcaAJG2g=; b=A+LmgRnk4iY0G8WrK+yaen3OGNW1rcx09ZosLz6QND8rC4X0oVg4NQjH7155qS/JH5 cepOd36bFhcPSNtwH1myQNMvV2CYMegv4+r5Al7IVkXaHvXKgNRT4yJ0cw3SidVoXlzZ Cy7VThYOZuEwnyGZ4sZ3jj6DKcD16AIbmsnXrpa9DGUOdXZlcn8yZSt/OIbrgmebLtWt rTpVmqRMyRKWDg9xgRbgDEOQeIBpuR/FGK5fBvit2mgGOmWkMzLICqEaJDJ8vtEj7C/E hWX+b7FApg+adNviPbvOfrpz+JoCM5XkYLaq6tOmc4PqnQJ5btSSUJdbSayJVzwlkouf LTpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=phVX5fa+1ED/c4XvngWEwcBtcWm7lwkW7NHLcaAJG2g=; b=oB791uWt1soyadTEPORreq5QDN10vnBOrcqhc0OETPEQWYaP3b5aTdczzJAHNX+GMd CQLePIXQbKm/F3faqawnH09HPjFSiLoW/bm2aEXdzADWhw4P0M4Qz+txoJ4wnQatnPJI 9KiZSzb/G/4jKefiOXVPTw7vjHuFSwDm3J5lxM0DWHzS94j951vyNKbOjGzvPnG7OfgC VoaqbUfApPIqf833XnxmFTIZl+qfja4Jgcs0fDFbAT2avED/zkTjKFkf2beoQSeW/sKU 14Utw/xyrB/8Gg9mLFcqvGEZvoi+cOMCzmUAyCY1QA5Pw9qCDnoRnWJJyrjMrxnvKirJ nPcw== X-Gm-Message-State: AGRZ1gIGOsMSlIb88wkFzxMMMubyUTYzGYjT6cp0x4EBUADc/pJNAdYi f0b/I42AVzQjGGy2vCbvPn0v1Euud8g= X-Google-Smtp-Source: AJdET5fdAyR5MKg7vMtpux/RBvgsf5N3dyS4vm05LXfbU+Y9nvBWBIBQ7mjyIpmJwOlDuo3FRXJVqw== X-Received: by 2002:a2e:9819:: with SMTP id a25-v6mr11432880ljj.6.1541970499263; Sun, 11 Nov 2018 13:08:19 -0800 (PST) Received: from ?IPv6:2a00:f41:382b:93aa:7cc1:dead:5dc0:6d6e? ([2a00:f41:382b:93aa:7cc1:dead:5dc0:6d6e]) by smtp.googlemail.com with ESMTPSA id r27-v6sm2801690lja.65.2018.11.11.13.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Nov 2018 13:08:18 -0800 (PST) To: Heiko Stamer References: <877ei9szyc.fsf@wheatstone.g10code.de> <87mur2nyt6.fsf@wheatstone.g10code.de> <87tvlam1iz.fsf@wheatstone.g10code.de> <87lg6lm2w8.fsf@wheatstone.g10code.de> <486d2345-69c1-c329-d887-f164b5dc90d4@metacode.biz> <5b72cd41-2941-54a3-92fc-3bc6a633798b@gmx.net> Cc: openpgp@ietf.org From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsBNBFs/lS0BCAC5oX3r3luF7czMF8UFxJz55XuvNRs4tEjo Hzqcqoe4+RJyfNDtspgevYIq1WTKw/H3ZYsd2wZpkM3I+BJn9eeHZKs77qXQZGN5PBB65rZo LjMx+qHa6wH4lIYMYW7eB9HHMsT/5E3ILBSRzZIwJimd/QdIMKSrJ5mPMkAd+9+xob5zKHO5 L5pbQtJSGS0m17/hA0kCTLI885hLtT3JsI/KWwuAYDrTwsayzh/hG/NgdA3I8xlrQCLC0EFJ oxHkN9tCyXeKPlrIPYyMB1jHTo1iNV0CQGpk+zf6DA/ySGfJxd30ksJZ8y5qxD43zS0YffYM C01CeuqPoGZ2Fy9VxhODABEBAAHCwXwEGAEKACYWIQRlOQmi8ON8EG9fr1RsiFfg2OjwdAUC Wz+VLQIbDAUJAeEzgAAKCRBsiFfg2OjwdKQ4D/wIb8s2Tw8MhbbwASutzTwg3g3KReDRHgSz z7RJtePIM8HC6qm9++9sxoqww7qm35vb604HtMRORYmfXgVSocsYg/eAk8LoBVfCZidDVBia /i/dYx/8LHeX/0PqPluSusQh64BFUoVetUCP+kISbK8vgDt4HfDSgtenC5lpTAdk257A84p2 zDnUtVr8XNv09m7ASft6Wh5Wrn+aWlJrf6T6eysk9OIw8VpSuq0oG3vcEoTbHKJN8TDliPUc QVz5Qti0tgB40PLrqOpTdENdxbiaUNFpHm3Tkk+n7CEFcOayFvy5vU6Nih0hu+LFC2XHzQRw sLnuQ2EilWtXRulcwvFo6A3Vp+gidxc6UwC+LBFJjvDMv5hmsdhSm08r2hd2k61oL6NCGVB3 fxuJT85UHsEC04N72Fa26+Spkh3DtJMrKqJlBBas7oJYh6644DB4rccd6VT3n7Zv1pd2uIWv gjORztfBzRJEysOeHoNpr4hEocg62beu9cnGHpYB9j3mhv+E2IYPnJKqit18G7xb7QnyQU7L YfctLO0GLNdTBavWJggHPzUp09vb3uGS3dMdAYbWTBtnXttkdYuLx/oCe1LVUQYotsX7s83V kVc2n6xzrcaebmgoFtGUfUmOV0U0xbqv6Mxg27qctYh1QidvRyt0xqGA0Qhz/vvoQdfQeMlO Tg== Organization: Metacode Message-ID: Date: Sun, 11 Nov 2018 22:08:15 +0100 MIME-Version: 1.0 In-Reply-To: <5b72cd41-2941-54a3-92fc-3bc6a633798b@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] Clarifiction on v5 signatures X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2018 21:08:25 -0000 Hi Heiko, >> Split key (0x10) looks like a good way to implement separation of duties >> (where multiple people are needed to use the key). I don't think this is >> possible in OpenPGP now. > > This was one reason to create DKGPG: https://www.nongnu.org/dkgpg/ > > Currently, there are some efforts at NIST on threshold cryptography: > https://csrc.nist.gov/projects/threshold-cryptography That's intriguing, thanks for bringing this up, I'll definitely check this out as this is something I've been thinking of for quite some time. Kind regards, Wiktor -- https://metacode.biz/@wiktor From nobody Sun Nov 11 21:58:25 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E2512D4E7 for ; Sun, 11 Nov 2018 21:58:24 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LgYQR9SoDVvr for ; Sun, 11 Nov 2018 21:58:22 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 01E19130DD6 for ; Sun, 11 Nov 2018 21:58:21 -0800 (PST) X-AuditID: 1209190e-e8fff70000000fd5-93-5be9167c3223 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E4.11.04053.C7619EB5; Mon, 12 Nov 2018 00:58:20 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wAC5wJoT024050; Mon, 12 Nov 2018 00:58:19 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAC5wF3r020002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Nov 2018 00:58:18 -0500 Date: Sun, 11 Nov 2018 23:58:15 -0600 From: Benjamin Kaduk To: Bart Butler , Paul Fawkesley , "openpgp@ietf.org" Message-ID: <20181112055814.GA99562@kduck.kaduk.org> References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de> <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com> <87ftwbye1s.fsf@wheatstone.g10code.de> <87h8gptejy.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h8gptejy.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrFsj9jLaYNUvA4v1B9tYLBr+PWS3 WDB7G5sDs8ecOS2sHkuW/GTy6GnbxBTAHMVlk5Kak1mWWqRvl8CV8XP5S+aCBUIVm9/+ZGtg vMzXxcjJISFgIvFp1Ry2LkYuDiGBNUwSH/teMUM4GxklLs7/xALh3GWSuPiohwmkhUVAVeLZ 2g8sIDabgIpEQ/dlsA4RgU5GiQfvusESwkBzZ1y+wQZi8wLZE+a+gJp0h0ni+u3/7BAJQYmT M5+ANTALaEnc+PcSaAMHkC0tsfwfB0iYU8BY4vKVlWAlogLKEnv7DrFPYOSfhaR7FpLuWQjd CxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6+VmluilppRuYgSHqSTfDsZJDd6HGAU4GJV4 eBvKX0QLsSaWFVfmHmKU5GBSEuV9f+5ZtBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXj6el9FC vCmJlVWpRfkwKWkOFiVx3l8ij6OFBNITS1KzU1MLUotgsjIcHEoSvFGiQI2CRanpqRVpmTkl CGkmDk6Q4TxAw3eB1PAWFyTmFmemQ+RPMSpKifMWgiQEQBIZpXlwvaA0IpG9v+YVozjQK8K8 Z0GqeIApCK77FdBgJqDBJS+fgwwuSURISTUwlq7bvPcKZ75Csk/Yg2KBDFvdRImGYM+5efJd v1LKFz/Ju/G96EeR9/b/CV8fble7XFK1nqFc11/p7wfnwnU/WdVP2DjucKyc2RKwzJztvXvV pfJU9cZ66b29FbfZbfoP28q9XH6M7WWpYgtrLMvbqn2CHfaZ/o1iLVpP9/lVPXosckR8/wEl luKMREMt5qLiRACcjxcx/gIAAA== Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 05:58:24 -0000 On Sat, Nov 10, 2018 at 11:25:21AM +0100, Werner Koch wrote: > On Sat, 10 Nov 2018 00:18, bartbutler=40protonmail.com@dmarc.ietf.org > said: > > > reasons previously mentioned in this thread and discussed in Brussels > > (case sensitivity, +aliases/subaddresses, Unicode, catch-all > > addresses). The hash would be ignored. > > BTW, the sub-addressing does not seem to be a real problem. A cursory > inspection of some large keyrings showed that user-ids with > sub-addresses are quite rare and there is always the opportunity for the > user (or a tool) to create another user-id w/o the sub-address. Thus > the sub-addresses can be handled in the MUA and won't need protocol > support. > > > I think that long-term, two parameters that do the same thing and could conflict is bad and that while compatibility is a good short-term goal, we should try drop the hash and to migrate to this final form as soon as possible: > > > > ..well-known/openpgpkey/hu/?l=Joe.Doe@example.org > > I disagree but I don't think it is the time to discuss this now. Let us > first deploy a useful key discovery and then see how it can be > improved/changed. > > > should simplify this and simply mandate the 'wkd' subdomain, full > > stop, rather than having a fallback mechanism to the main domain. The > > I concur. Given that we need to drop the SRV records for silly reasons > anyway, we can also demand a fixed subdomain. Given that I don't like > the "wkd" acronym, I would prefer to use a different name, like > "openpgpkey". I'll note that the IESG is generally not super-keen on reserved leaf names in the DNS, though it is not something that is entirely disallowed when there are not usable alternatives. https://tools.ietf.org/html/draft-moonesamy-dnsop-special-use-label-registry-00 is (IIUC) supposed to be a way forward to at least provide a discoverable registry of these "reserved" names. -Ben > And regarding your other mail: Sure, a redirection can only be allowed > to use a http redirect and not with a CNAME. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From bre@beanstalks-project.net Mon Nov 12 08:37:19 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1E2130DF2 for ; Mon, 12 Nov 2018 08:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=beanstalks-project-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNhNKhS6tHHg for ; Mon, 12 Nov 2018 08:37:18 -0800 (PST) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 22CF012F1AC for ; Mon, 12 Nov 2018 08:37:17 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id u3so3437024ota.5 for ; Mon, 12 Nov 2018 08:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beanstalks-project-net.20150623.gappssmtp.com; s=20150623; h=sender:mime-version:subject:from:cc:in-reply-to:references :user-agent:message-id:date:openpgp:to; bh=l7i531LcDFtVU9krjsrj4FlrWVDg7oyLyb4PESlrblI=; b=AMK6I8wfIon3CuQiCEvaKQJ4+HDrnGndwFYCCwaw2tEu/k9rfdKz/44OE/YMTYJGJr 5DMT6jsHnnPRQxxjk9bS5Bp/Xr0V8eW5naUt9jF/8Papu6MbyD1weZRlWE8rhldP/E61 vFMiCdVWqxjrX3qaPhsVeEJ120v8XGrwfOxYwa3YjJdwn9f1Ad0y+KsEoj2z2f5uxLc6 VBTFtmBNL4YXY7xGo4k5uOS/1BvOUH+igMBaVCexiYi2H7/p/sfFgcx29RfPyjmBdbJB xKrTrhOzaU1Ina80CkU1A6yviwUfCRQSTjCElT557A5u89jZO98VMObALHhyQv3TdNBc x6OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:cc:in-reply-to :references:user-agent:message-id:date:openpgp:to; bh=l7i531LcDFtVU9krjsrj4FlrWVDg7oyLyb4PESlrblI=; b=cFaMEPpVWebGSfBHBW46sDH+xvLyAejGMPCP1p7MYwiMwPxOFzravb4CAcCHs/FMP/ SkdEoNlVKhTmsxt/7Prr1Pd7OZ7YSph2saUXZm0uDMRYPMoor2nDHhRTgLDAFMuMvtWG rwSledbXdtmC81Lix7OQd4BP9H1rrsC2zuZB7Gi+MDrcKHpqISGOv3U+rsmLDg9TmiSE lsr+O36HaM1D05KCdK/NcfQ0IHJBFq0ItYrQ0Yx/xM8O35b9lJ/6Cg/vTvBcdekrOwHV ninFlpQUFMcqm24u/Bi3aBFUyzP8PWS7UFNxsIpOplPLg3ZiF/oLjbiQ7ivZXHjcIlDc HI7A== X-Gm-Message-State: AGRZ1gJp3ea9mTMWDtaT65WcssKC6u2WaMVqlfBhmPRPFheWhdAjUlVp Ug3IAJEEvSS4+JmceAhC1rsM3956Azs= X-Google-Smtp-Source: AJdET5eJhs2mUyh8WFmqWOtChRjv+0QQzv/mUFJiqPKT9mpr2wGoYa1xyuaC3cbhMvhTbXUw+CATng== X-Received: by 2002:a9d:118a:: with SMTP id v10mr913341otf.281.1542040636850; Mon, 12 Nov 2018 08:37:16 -0800 (PST) Received: from mailpile.local ([199.249.224.44]) by smtp.gmail.com with ESMTPSA id f9sm6873511oth.17.2018.11.12.08.37.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 08:37:16 -0800 (PST) Sender: =?UTF-8?Q?Bjarni_R=C3=BAnar_Einarsson?= Content-Type: multipart/mixed; boundary="==g5yJGnbfeNsHkeFwujIbKv4cvvFpYY==" MIME-Version: 1.0 From: Bjarni Runar Einarsson Cc: "Paul Fawkesley" , "openpgp@ietf.org" In-Reply-To: <87ftwbye1s.fsf@wheatstone.g10code.de> References: <87ftwbye1s.fsf@wheatstone.g10code.de> User-Agent: Mailpile Message-Id: Date: Mon, 12 Nov 2018 16:33:33 -0000 OpenPGP: id=61A015763D28D410A87B197328191D9B3B4199B4; preference=signencrypt To: "Werner Koch" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 17:15:08 -0000 --==g5yJGnbfeNsHkeFwujIbKv4cvvFpYY== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all! Werner Koch wrote: > > > Given that SRV records can't be accessed by Javascript implementations, > > I don't think we can point to that as a solution > > It is a pity that solid network techniques need to be dropped > in favor of large but uncooperative browser vendors. Adding an > interface for SRV records would be really easy and helps to > support flexible network administration. Note that I don't > wan't them to use SRV records for generic http requests but > extensions should be able to use it instead of resorting to > external DNS lookup providers. On behalf of Mailpile, I'd just like to speak up and say I am very glad to hear we are moving away from SRV records. Mailpile tries very hard to protect the privacy of its users; when fetching things from the public Internet (usually the web), the easiest way to do that is to route the requests over Tor. This is very easy for HTTPS - so looking up keys at predictable, stable HTTPS URLs (exactly what the format of the URL is, doesn't matter much) is something we are very comfortable and happy to do. This means WKD (w/o SRV records) is currently our preferred mechanism for discovering keys that we haven't already received over AutoCrypt or imported by hand. If I were to implement support for SRV records, that would mean I can no longer rely on Tor to do that for us, but need to start thinking about DNS-over-HTTPS or other emerging standards (or, hacks ;-) in order to maintain the same security/privacy guarantees. It's just more complicated to do in a privacy-preserving fashion, which means in any resource-starved project (aren't we all?) it might not happen at all. I'm very happy not to have to deal with that. > First try > > https://openpgpkey.example.org/.well-known/openpgpkey/... > > if that host can't be resolved (or accessed?), fallback to > > https://example.org/.well-known/openpgpkey/... > > be a practical replacement for SRV records here? This works well for Mailpile. I might be tempted to suggest trying the bare domain first, and openpgpkey.example.org as a fallback, simply because from a privacy point of view that leaks less information about what the client is doing. But I understand this would probably waste more bytes/CPU cycles and it requires more complicated logic to determine when to fall back, and when to treat the server's 404 as final. So it may not be worth it. I am also quite happy with the ?l=... solution to expose the original e-mail address to servers who want to be smarter than can be accommodated with a fixed hash in the filesystem. In general, I applaud the fact that this appears to be converging on something that is dead-simple to implement both on the client and the server, even if the "fixed subdomain" is a hack from a protocol-purity point of view. It's pragmatic and it works, which is (IMO) exactly what we need in this space. All the best, - Bjarni - -- PageKite.net lets your personal computer be part of the web -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAlvpq0MACgkQjgA3FgDP lJG/mgf9EuYwdEvRJc+wfRA5CflRy99oFeaHJHTSMlvOy8mOwvXRrq6u7Qtr+pt7 nu0EYFPxO7/NiLctVJmSkJXNqjagzCuZpOeozbN2/C1q2y9wk5kcN6DjW+2ncQxr 2Ut0x9fZVjQdUbJvZTE2PF8ORGXrsRpaxqBgYgfurV1UhGopwCy3DsKIFRvNFis3 pRoMadTMsWny8ELkc4+dHTuzkz9NGdUd/cGWHIva2OkAUJwMRXl96myjRZx8Q+G/ mAdXL5MkZiq07zTaZZgkKYkHRaNjfzzrYeRsyfG6Nc3Bum8gxKw/w5qGrx2esxeY f90ip0D+EJaJcS5JMFFGdkaCOcJCvA== =JoN2 -----END PGP SIGNATURE----- --==g5yJGnbfeNsHkeFwujIbKv4cvvFpYY==-- From nobody Tue Nov 13 06:05:19 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52989130DDA for ; Tue, 13 Nov 2018 06:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQbx8g3S11ED for ; Tue, 13 Nov 2018 06:05:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 A1D5F12D4EE for ; Tue, 13 Nov 2018 06:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZZP3J7/ApoGb7n+g2WLGAZvPuvEQG6/G3HtawHAruMY=; b=ezygIY8+3iCkcw1BHCJjXEwKB7 rpcW6EuqKGKvHzIIp8tZW/Y06X5Z7U+TyT0R3h5pxmxpfa8FS9Pzu91OnhXHZUEXbjpvraldgyT/z 05s/EGdR/lhLuGcYD9lQ2kfx6yRnVvakLKwcqhG8y/Ap8B8VvG04ozHqd+ZEGzvKEiRQ=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gMZJU-0005Uc-Tg for ; Tue, 13 Nov 2018 15:05:08 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gMZGc-00083d-E5 for ; Tue, 13 Nov 2018 15:02:10 +0100 From: Werner Koch To: openpgp@ietf.org Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: openpgp@ietf.org Date: Tue, 13 Nov 2018 15:02:04 +0100 Message-ID: <878t1xoz37.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=chameleon_man_ASDIC_Yukon_Mena_STARLAN_Rumsfeld_bootleg_undercover=L"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 14:05:18 -0000 --=chameleon_man_ASDIC_Yukon_Mena_STARLAN_Rumsfeld_bootleg_undercover=L Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! A new revision of the Web Key Directory I-D has been published: https://www.ietf.org/id/draft-koch-openpgp-webkey-service-07.txt Changes since -06 are: =2D Specify the advanced method with the openpgpkey sub-domain. =2D Specify the l=3DLOCAL-PART query parameter. =2D Require the provider to filter the key for publication. =2D Drop the use of DNS SRV records. See below for the gist of the change. GnuPG master implements the new advanced method. You may use my address for testing. For now the SRV method is still used as a fallback by GnuPG. Note that the domain name is now also part of the file name if the openpgpkey sub-domain is used. This should make it easier to server the directory for several domains from a single server. This sub-domain approach is similar to Mozilla's mail auto configuration [1]. Shalom-Salam, Werner =2D-8<---------------cut here---------------start------------->8--- There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. The advanced method requires a sub-domain with the fixed name "openpgpkey" is created and queried. It constructs the URI from the concatenation of these items: o The scheme "https://", o the domain-part, o the string "/.well-known/openpgpkey/", o the domain-part in lowercase, o the string "/hu/", o the above constructed 32 octet string, o the unchanged local-part as a parameter with name "l" using proper percent escaping. An example for such an advanced method URI to lookup the key for Joe.Doe@Example.ORG is: https://openpgpkey.example.org/.well-known/openpgpkey/ example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe (line has been wrapped for rendering purposes) The direct method requires no additional DNS entries and constructs the URI from the concatenation of these items: o The scheme "https://", o the domain-part, o the string "/.well-known/openpgpkey/hu/", o the above constructed 32 octet string, o the unchanged local-part as a parameter with name "l" using proper percent escaping. Example for a direct method URI: https://example.org/.well-known/openpgpkey/ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe (line has been wrapped for rendering purposes) [...] The benefit of the advanced method is its greater flexibility in setting up the Web Key Directory in environments where more than one mail domain is hosted. DNS SRV resource records, as used in earlier specifications of this protocol, posed a problem for implementations which have only limited access to DNS resolvers. The direct method is kept for backward compatibility and to allow providing a Web Key Directory even with without DNS change requirements. =2D-8<---------------cut here---------------end--------------->8--- [1] =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=chameleon_man_ASDIC_Yukon_Mena_STARLAN_Rumsfeld_bootleg_undercover=L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+rZXAAKCRD/gK6dHew1 jWtrAQD1aQ/ElwzCX6LUlZ/1BZP9/MkRP1Z2QstRztY+ICJm/gD9FxAN92pNX7/Y EoVRpTi9jul6R+uAccyy54tofNzmhAc= =QreT -----END PGP SIGNATURE----- --=chameleon_man_ASDIC_Yukon_Mena_STARLAN_Rumsfeld_bootleg_undercover=L-- From nobody Tue Nov 13 06:15:13 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464F9130DDA for ; Tue, 13 Nov 2018 06:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk3EZQ_zorcG for ; Tue, 13 Nov 2018 06:15:10 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 A34A3129BBF for ; Tue, 13 Nov 2018 06:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=a34bfl2aLUy338vD83SN6WIYWl8ow8MB0elCSIEkw10=; b=VpU8NPmQbsFBVtThNBW69PoQP1 Ax+zz9c2xGMVbmZb9MZa0rXeVwWj0Wynq4hIT+iHRhFPskt2gkagVmhCu1owg24d4JhTiAVkm6uik D+UfEdQWergzJaaTyyckJ7u/IuOJsEP/Goju7BjY11Ty2RzYK89hTIMtOnb7bl/SkKyI=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gMZTB-0005YZ-21 for ; Tue, 13 Nov 2018 15:15:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gMZT7-0008A7-Ub; Tue, 13 Nov 2018 15:15:05 +0100 From: Werner Koch To: Bjarni Runar Einarsson Cc: Paul Fawkesley , "openpgp\@ietf.org" References: <87ftwbye1s.fsf@wheatstone.g10code.de> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bjarni Runar Einarsson , Paul Fawkesley , "openpgp\@ietf.org" Date: Tue, 13 Nov 2018 15:15:05 +0100 In-Reply-To: (Bjarni Runar Einarsson's message of "Mon, 12 Nov 2018 16:33:33 -0000") Message-ID: <874lcloyhi.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=MD4_wire_transfer_UOP_.Hello_to_all_my_friends_and_fans_in_domestic="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] OpenPGP Web Key Directory I-D X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 14:15:12 -0000 --=MD4_wire_transfer_UOP_.Hello_to_all_my_friends_and_fans_in_domestic= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 12 Nov 2018 17:33, bre@pagekite.net said: > If I were to implement support for SRV records, that would mean I > can no longer rely on Tor to do that for us, but need to start > thinking about DNS-over-HTTPS or other emerging standards (or, Well, GnuPG implements a full DNS resolver over Tor (but w/o DNSSEC). This was required to properly implement access to the keyserver pools. If there is a need we coul turn this into a public API. > I'm very happy not to have to deal with that. Mailpile will also like it. >> First try >> >> https://openpgpkey.example.org/.well-known/openpgpkey/... >> > This works well for Mailpile. I changed this in the -07 I-D to=20 https://openpgpkey.example.org/.well-known/openpgpkey/example.org/... to make it easier to host several domains and to convey the domain info without resorting to HTTP header info. > I might be tempted to suggest trying the bare domain first, and > openpgpkey.example.org as a fallback, simply because from a > privacy point of view that leaks less information about what the > client is doing. But in this regard it is not different from SRV RRs. The requests should anyway be easy to identify because the reply is pretty small or by utilizing the fact that an encrypted mail is anyway soon send to the same provider. > on something that is dead-simple to implement both on the client > and the server, even if the "fixed subdomain" is a hack from a > protocol-purity point of view. It's pragmatic and it works, which Right, but Mozilla and MS Exchange do something very similar to ease the configuraion of a mail account. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=MD4_wire_transfer_UOP_.Hello_to_all_my_friends_and_fans_in_domestic= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+rcaQAKCRD/gK6dHew1 jcOZAP9rt2BMM4kMGZWnFFwaHcsdfRpteyxBoucfjJDlHSPRyQEAmmb6K39WYhBF SpGY/3BUYKpS9ETQAvx+a9i8d5FUXAI= =TypB -----END PGP SIGNATURE----- --=MD4_wire_transfer_UOP_.Hello_to_all_my_friends_and_fans_in_domestic=-- From nobody Tue Nov 13 07:10:14 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8FB128A6E for ; Tue, 13 Nov 2018 07:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQwtH8nQTbtk for ; Tue, 13 Nov 2018 07:10:10 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 7AA24128D09 for ; Tue, 13 Nov 2018 07:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=itkGspcKvmACtMaHumCR84cc3DPkvmegKPiLagcPx2Q=; b=lycw+rcKOX4hpO+J2j0/QkYsJU esO1K47m+FIlHOwvdcA23NzvIxaDQbZHuwNzIr8ShzPNZ3u8uIsubx3p8SxBrEcqXIVXcXCM0ExE7 vFYWcPsHhJ29FTr7sJPVaq9MS+v1R1ywvljvokmeoKGKd+bZfXPtfJzqbHmyLy9qy66s=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gMaKO-0005sb-Tz for ; Tue, 13 Nov 2018 16:10:08 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gMaGy-00008o-Ag; Tue, 13 Nov 2018 16:06:36 +0100 From: Werner Koch To: Paul Fawkesley Cc: openpgp@ietf.org References: <877ei9szyc.fsf@wheatstone.g10code.de> <87mur2nyt6.fsf@wheatstone.g10code.de> <87tvlam1iz.fsf@wheatstone.g10code.de> <87lg6lm2w8.fsf@wheatstone.g10code.de> <486d2345-69c1-c329-d887-f164b5dc90d4@metacode.biz> <8736ssn94c.fsf@wheatstone.g10code.de> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Paul Fawkesley , openpgp@ietf.org Date: Tue, 13 Nov 2018 16:06:35 +0100 In-Reply-To: (Paul Fawkesley's message of "Fri, 26 Oct 2018 14:42:45 +0100") Message-ID: <87bm6tnhj8.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Waco,_Texas_Zachawi_Ron_Brown_JUWTF_NORAD_Bosnia_fraud_clandestine=a"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Clarifiction on v5 signatures X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 15:10:13 -0000 --=Waco,_Texas_Zachawi_Ron_Brown_JUWTF_NORAD_Bosnia_fraud_clandestine=a Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 26 Oct 2018 15:42, paul@fluidkeys.com said: > If a key has multiple valid encryption subkeys, it's advertising that > it's OK to pick *any* of those subkeys. That's pretty arbitrary. I don't > see why picking *all* would be any worse than picking an arbitrary one. Because they might not be intended for encryption of mail or the keys are offline etc. Further if you use wildcards extra encryption subkeys are extra annoying. >> does but a more selective approach. OTOH, I am not sure whether one can >> find a threat model where such a scheme would be useful. > > Not sure I understand what you mean about threat model here? A threat model which can be mitigated by having different private subkeys on each device. The problem is that you want to read the mails on every device and thus the sender needs to encrypt it to all subkeys. The compromise of a single device and its subkey will anyway compromise all your mails encrypted to that set of subkeys. Thus my conclusion is copying the private key onto all device is much easier. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Waco,_Texas_Zachawi_Ron_Brown_JUWTF_NORAD_Bosnia_fraud_clandestine=a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+rofAAKCRD/gK6dHew1 jQmRAQCOzzGBz+ZWYzsqYjYx2lFaYZMn8faX86ED8mFF+qHCkAEAneBW57APNlsK rkc3+2utnTm/kI938eINIuQ3Ti53agk= =xwu6 -----END PGP SIGNATURE----- --=Waco,_Texas_Zachawi_Ron_Brown_JUWTF_NORAD_Bosnia_fraud_clandestine=a-- From nobody Tue Nov 13 12:35:35 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26127130E73 for ; Tue, 13 Nov 2018 12:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmfam7RimlAU for ; Tue, 13 Nov 2018 12:35:23 -0800 (PST) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 4B69E130E37 for ; Tue, 13 Nov 2018 12:35:23 -0800 (PST) Date: Tue, 13 Nov 2018 20:35:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542141316; bh=kYSkk4SziVLz7l/RWXn+AT6pZcjPeVU9TqEie/QF8qU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=VY/+cdpYm+SLwVoYA/7ZvgBc6esyIbh67Z7iSpP+oirkfQsY3cHZgx0mteo13VbsW v8J+ei4/LcIIIUPKHsaYO4IeisqLtjW5hVvrtdVKysRizaFS68UbD3WY729NJjn+m9 92MtEz6omaJhSwHntK0+6upwDlMV3a1z1137v1Rc= To: Werner Koch From: Bart Butler Cc: "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> In-Reply-To: <878t1xoz37.fsf@wheatstone.g10code.de> References: <878t1xoz37.fsf@wheatstone.g10code.de> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------2819441be6cb66b394ba59864cb98816"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 20:35:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------2819441be6cb66b394ba59864cb98816 Content-Type: multipart/mixed; boundary="---------------------31eca8b1f9f001788443a9d24589cd2e" -----------------------31eca8b1f9f001788443a9d24589cd2e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Werner, Thanks for making these changes! On first read my only comment is about th= is line: "The key needs to carry a User ID packet ([RFC4880]) with that mail address." I think this statement is a little vague, as one of the reasons for provid= ing the unchanged local part was to allow the server to do routing in the = same way for WKD as it does for incoming mail. As such, things like case, = subaddresses with +, catch-all, etc. will necessarily sometimes return a k= ey with a UserID packet which does not exactly match the local part used t= o query. I was wondering what you think about saying something like: The key MUST carry a User ID packet ([RFC4880]) with what the server considers the canonical= form of the requested mail address. So if I request from ProtonMail Bart.Butler@protonmail.com, I would get a = key back with bartbutler@protonmail.com, and the clients could then prompt= on unrecognized types of mismatches if desired because they would know th= at the server is returning the canonical form of the address. -Bart Sent from ProtonMail, encrypted email based in Switzerland. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, November 13, 2018 6:02 AM, Werner Koch wrote: > Hi! > = > A new revision of the Web Key Directory I-D has been published: > = > https://www.ietf.org/id/draft-koch-openpgp-webkey-service-07.txt > = > Changes since -06 are: > = > - Specify the advanced method with the openpgpkey sub-domain. > = > - Specify the l=3DLOCAL-PART query parameter. > = > - Require the provider to filter the key for publication. > = > - Drop the use of DNS SRV records. > = > See below for the gist of the change. GnuPG master implements the ne= w > advanced method. You may use my address for testing. For now the SRV > method is still used as a fallback by GnuPG. > = > Note that the domain name is now also part of the file name if the > openpgpkey sub-domain is used. This should make it easier to server = the > directory for several domains from a single server. This sub-domain > approach is similar to Mozilla's mail auto configuration [1]. > = > Shalom-Salam, > = > Werner > = > --8<---------------cut here---------------start------------->8--- > There are two variants on how to form the request URI: The advanced > and the direct method. Implementations MUST first try the advanced > method. Only if the required sub-domain does not exist, they SHOULD > fall back to the direct method. > = > The advanced method requires a sub-domain with the fixed name > "openpgpkey" is created and queried. It constructs the URI from the > concatenation of these items: > = > o The scheme "https://", > = > o the domain-part, > = > o the string "/.well-known/openpgpkey/", > = > o the domain-part in lowercase, > = > o the string "/hu/", > = > o the above constructed 32 octet string, > = > o the unchanged local-part as a parameter with name "l" using proper > percent escaping. > = > An example for such an advanced method URI to lookup the key for > Joe.Doe@Example.ORG is: > = > https://openpgpkey.example.org/.well-known/openpgpkey/ > example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe > = > (line has been wrapped for rendering purposes) > = > The direct method requires no additional DNS entries and constructs > the URI from the concatenation of these items: > = > o The scheme "https://", > = > o the domain-part, > = > o the string "/.well-known/openpgpkey/hu/", > = > o the above constructed 32 octet string, > = > o the unchanged local-part as a parameter with name "l" using proper > percent escaping. > = > Example for a direct method URI: > = > https://example.org/.well-known/openpgpkey/ > hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe > = > (line has been wrapped for rendering purposes) > = > [...] > The benefit of the advanced method is its greater flexibility in > setting up the Web Key Directory in environments where more than one > mail domain is hosted. DNS SRV resource records, as used in earlier > specifications of this protocol, posed a problem for implementations > which have only limited access to DNS resolvers. The direct method > is kept for backward compatibility and to allow providing a Web Key > Directory even with without DNS change requirements. > --8<---------------cut here---------------end--------------->8--- > = > = > [1]https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconf= iguration > = > -- > = > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -----------------------31eca8b1f9f001788443a9d24589cd2e-- -----------------------2819441be6cb66b394ba59864cb98816 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvrNYIJEJkFRGXvMx5EAAAMDgEAqRIGGja5E38wmMzYtYKQ glhH7SyQfoWBObdPeGDhuUsBALGDa+YxJGZY90fBwEKk14VYrD/n7UsBCyVS fyqSA/4D =jr1B -----END PGP SIGNATURE----- -----------------------2819441be6cb66b394ba59864cb98816-- From nobody Tue Nov 13 13:15:16 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52142130DCB for ; Tue, 13 Nov 2018 13:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2djTL_rmWDVj for ; Tue, 13 Nov 2018 13:15:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 B69CA130DE0 for ; Tue, 13 Nov 2018 13:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e2vjEm5IBMT5SaJHSLTkRuE5od/j+t8RiUyZS2MtzwY=; b=Dau+SBztjtdYevA722PHf8pM0Q DZqvQKyXPJTGwtAWz3t6zzgeVypIYoHwoGdo/Pqhr9j5UotIKnxLgHj4lftNOVKWt68Hj8FUOxUPa VxI5ddwlnz0Ups0i293xzcDeFgsD87v8xQbcQkzTw68uIlE4zpQVN6IscTwSR0RCxTN8=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gMg1d-0003jp-2G for ; Tue, 13 Nov 2018 22:15:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gMg0I-00059y-KT; Tue, 13 Nov 2018 22:13:46 +0100 From: Werner Koch To: Bart Butler Cc: "openpgp\@ietf.org" References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bart Butler , "openpgp\@ietf.org" Date: Tue, 13 Nov 2018 22:13:46 +0100 In-Reply-To: <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> (Bart Butler's message of "Tue, 13 Nov 2018 20:35:15 +0000") Message-ID: <875zx0n0j9.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=keyhole_morse_SRI_Belknap_Vince_Foster_Bosnia_Merlin_CID_CISU_securi"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 21:15:14 -0000 --=keyhole_morse_SRI_Belknap_Vince_Foster_Bosnia_Merlin_CID_CISU_securi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 13 Nov 2018 21:35, bartbutler=3D40protonmail.com@dmarc.ietf.org said: > routing in the same way for WKD as it does for incoming mail. As such, > things like case, subaddresses with +, catch-all, etc. will We had some internal discussion and came to the conclusion that it is best to not care about sub-addresses in the protocol. It should be a MUA only thing and nobody should create a key for a subaddress. With the help of Kristian I took a look at the 5.3 million keys on the SKS servers and we found only 3055 unique mailboxes with a '+' in it. After removing leading and trailing '+' as well as multiple '+' (e.g. "c++" or "foo+bar+baz") 2697 were left which seem to be valid sub-addresses.=20 Now this is definitely a minority and there oweners can be asked (or gpg-wks-client does it on the fly) to create another user-id without the subaddress. To help MUAs, I started to change gpg to strip off sub-addresses; at least for WKD queries. > So if I request from ProtonMail Bart.Butler@protonmail.com, I would > get a key back with bartbutler@protonmail.com, and the clients could I doubt that we can do anything about this except for adding another user id to the key. There would be just too many cases and that simple protocol would be much complex to implement and also fully lose the property of a simple one to one match. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=keyhole_morse_SRI_Belknap_Vince_Foster_Bosnia_Merlin_CID_CISU_securi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+s+igAKCRD/gK6dHew1 jX60AQDgM1OQUxaL9ljttAenKQldTwA5PNaveGhicD5KcqHRhgD/bMg/KFQOFRoO kPzW7gEGvJJ2jQ1bm4w/Pyb8KE5HWAI= =ZsWi -----END PGP SIGNATURE----- --=keyhole_morse_SRI_Belknap_Vince_Foster_Bosnia_Merlin_CID_CISU_securi-- From nobody Tue Nov 13 13:37:52 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90E8130DE7 for ; Tue, 13 Nov 2018 13:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87jc1_uTqNOm for ; Tue, 13 Nov 2018 13:37:48 -0800 (PST) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (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 C9F01130DEE for ; Tue, 13 Nov 2018 13:37:47 -0800 (PST) Date: Tue, 13 Nov 2018 21:37:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542145059; bh=XRYYzcsLk9ek1dRX3vPBgFifnGnOriJ/PvOvcnGJ7uE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=MwH/HgtslZfW7QYIz7DW+UiDNH5pZQXB4XATMRqcpGo4/9gVx0K0lYpl6HLDBPecO v5JXtw7fYW+8md48KxL0iA3mHmvcf5pijIIflM5WMr9LlZmQVeuFpiG4E1coqKCKHy CPvACT5NOeayo5+dda/vNXGxcv5tl6M0YTNAz36Y= To: Werner Koch From: Bart Butler Cc: "openpgp\\@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <875zx0n0j9.fsf@wheatstone.g10code.de> References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <875zx0n0j9.fsf@wheatstone.g10code.de> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------d791f192715410c32a6803b573952746"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 21:37:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------d791f192715410c32a6803b573952746 Content-Type: multipart/mixed; boundary="---------------------25361b015303868577d56b4ff1adb430" -----------------------25361b015303868577d56b4ff1adb430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Werner, I don't think I was very clear before so I'll try to clarify a bit. I thin= k we are in agreement that the MUA should do all of this kind of processin= g exclusively and we should not do any funny business in the WKD spec abou= t secondary UserIDs or the like. My concern was that this language: "The key needs to carry a User ID packet ([RFC4880]) with that mail address." could be read as requiring that the UserID packet in the key match the que= ried address exactly, and I'd like to relax that requirement to make it cl= ear that servers can essentially serve up whichever key they choose based = on how they want to route mail. Whatever checks the MUA does on this UserI= D is not the business of the WKD spec. Here's another suggestion: "The key MUST carry a User ID packet ([RFC4880]) containing the email addr= ess to which mail sent to the queried email address will be routed." which should take care of this case without implying that requested mail a= ddress must match the mail address in the UserID. -Bart Sent from ProtonMail, encrypted email based in Switzerland. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, November 13, 2018 1:13 PM, Werner Koch wrote: > On Tue, 13 Nov 2018 21:35, bartbutler=3D40protonmail.com@dmarc.ietf.org > said: > = > > routing in the same way for WKD as it does for incoming mail. As such, > > things like case, subaddresses with +, catch-all, etc. will > = > We had some internal discussion and came to the conclusion that it is > best to not care about sub-addresses in the protocol. It should be a > MUA only thing and nobody should create a key for a subaddress. > = > With the help of Kristian I took a look at the 5.3 million keys on the > SKS servers and we found only 3055 unique mailboxes with a '+' in it. > After removing leading and trailing '+' as well as multiple '+' > (e.g. "c++" or "foo+bar+baz") 2697 were left which seem to be valid > sub-addresses. > = > Now this is definitely a minority and there oweners can be asked (or > gpg-wks-client does it on the fly) to create another user-id without the > subaddress. > = > To help MUAs, I started to change gpg to strip off sub-addresses; at > least for WKD queries. > = > > So if I request from ProtonMail Bart.Butler@protonmail.com, I would > > get a key back with bartbutler@protonmail.com, and the clients could > = > I doubt that we can do anything about this except for adding another > user id to the key. There would be just too many cases and that simple > protocol would be much complex to implement and also fully lose the > property of a simple one to one match. > = > Shalom-Salam, > = > Werner > = > ------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= ---------------------------------------------------- > = > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -----------------------25361b015303868577d56b4ff1adb430-- -----------------------d791f192715410c32a6803b573952746 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvrRBsJEJkFRGXvMx5EAABNWwD/djHUBsMVh6cNT5nUvySo mEfMYQk6SCb01fXpysBlf2YA/iz5W7yPx0TL36I+yhKPqEvVJdmoJvG7faeV D8E+S3UN =itZ/ -----END PGP SIGNATURE----- -----------------------d791f192715410c32a6803b573952746-- From nobody Wed Nov 14 02:10:24 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4CA124408 for ; Wed, 14 Nov 2018 02:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VW4O3n2WqKY for ; Wed, 14 Nov 2018 02:10:15 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 5E71B12D4E6 for ; Wed, 14 Nov 2018 02:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AWVtcGY4TiCwfx1K0mktJTwv5B0LzdoVlt/aMzNFSoI=; b=fYHSp1DyTF4+kR5WFFWrRQY4iT xohhsqix8jHklBDmcykxxyuAzRjj2ecwgk5dX2FMss5hs4npwbsvwkM1EfJAIc4dL7uT95cYXnDHk DwvzuTYx9EKRvETCCJiHNjWJzC9XDSUtIuAgF1dh9Dzvip3xhF1gZjamO2CP0XfgYTkY=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gMs7d-00007C-5J for ; Wed, 14 Nov 2018 11:10:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gMs76-0004qz-EO; Wed, 14 Nov 2018 11:09:36 +0100 From: Werner Koch To: Bart Butler Cc: "openpgp\@ietf.org" References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <875zx0n0j9.fsf@wheatstone.g10code.de> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bart Butler , "openpgp\@ietf.org" Date: Wed, 14 Nov 2018 11:09:30 +0100 In-Reply-To: (Bart Butler's message of "Tue, 13 Nov 2018 21:37:33 +0000") Message-ID: <87sh04km1x.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=satellite_imagery_pre-emptive_spies_argus_ASDIC_arrangements_beanpol"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 10:10:18 -0000 --=satellite_imagery_pre-emptive_spies_argus_ASDIC_arrangements_beanpol Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 13 Nov 2018 22:37, bartbutler=3D40protonmail.com@dmarc.ietf.org said: > "The key MUST carry a User ID packet ([RFC4880]) containing the email add= ress to which mail sent to the queried email address will be routed." You are talking about how mail is routed, the spec is about discovering the one and only key to be used for a given mail address. And by key I mean the OpenPGP keyblock, that is the public key plus one user ID (or several if they have the same addrspec part). A mail address is here considered as an identifier for an entity and not as an addressing scheme for mails. An entity may have several identifiers like Werner.Koch@foo, Werner_Koch@foo, wernerkoch@foo, wk@foo, koch@foo. That is a pretty normal but there is no way a sender can decide whether they are all the same; for example the last two of the list could also identify my brother. A sender gets hold of one mail address and that must have been relayed (direct or indirectly) to them by the owner of that mail address. The recipient needs to take care that a key exists for that very mail address. Sub-addresses are different and we can find a way to handle this common case.=20 Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=satellite_imagery_pre-emptive_spies_argus_ASDIC_arrangements_beanpol Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+v0WgAKCRD/gK6dHew1 jYBgAP4tkHJ7HwiVjBmsCuTt5R9DF1kwchGV2o7ouLx56PKZDwEAl2vtVlTJoyZ3 1pibI+ejqszuVfWP/MlSgKeXy2FQXgQ= =Ufwm -----END PGP SIGNATURE----- --=satellite_imagery_pre-emptive_spies_argus_ASDIC_arrangements_beanpol-- From nobody Wed Nov 14 07:27:14 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD000130E84 for ; Wed, 14 Nov 2018 07:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCrp0ryKX9eB for ; Wed, 14 Nov 2018 07:27:10 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C2A32130EA5 for ; Wed, 14 Nov 2018 07:27:06 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42w7dh1ykszKCH; Wed, 14 Nov 2018 16:27:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542209224; bh=0JqiXzhyxgS1fCKtWx7m3Ii7S4k2HH0gU07WJTWuQj0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Cn9QJJPwEiFAI6Fi0LK+F3KfIYLW5CN+5XVr3/0kkjsZEDzZmQQDnjLsV131kgNsv INDs4iA5jYeuamKsXmX0nlDYefuxZVONa3Ys1WhWooLJFgC1PEfgx2cXwc3+Ceidm4 EZclmVSdVDL8+TfR+VErEsVYvRVV2YHPhrxo6m18= 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 MMVCQZgiEH5H; Wed, 14 Nov 2018 16:26:59 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 14 Nov 2018 16:26:59 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D264A4392AC; Wed, 14 Nov 2018 10:26:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D264A4392AC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C5DC841C3B22; Wed, 14 Nov 2018 10:26:58 -0500 (EST) Date: Wed, 14 Nov 2018 10:26:58 -0500 (EST) From: Paul Wouters To: Bart Butler cc: "openpgp@ietf.org" In-Reply-To: <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> Message-ID: References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 15:27:13 -0000 On Tue, 13 Nov 2018, Bart Butler wrote: > I was wondering what you think about saying something like: > > The key MUST carry a > User ID packet ([RFC4880]) with what the server considers the canonical form of the requested mail address. > > So if I request from ProtonMail Bart.Butler@protonmail.com, I would get a key back with bartbutler@protonmail.com, and the clients could then prompt on unrecognized types of mismatches if desired because they would know that the server is returning the canonical form of the address. We went through this with OPENPGPKEY and SMIMEA. You will get the SMTP people blocking your draft when you try to interpret (or like above, even rewrite) addresses based on "common mail provider rewrites". Their firm believe is only receiving SMTP servers can interpret email addresses. Perhaps you want to take a look at the language used in those two RFCs with respcet to mapping email addresses to DNS. Some of it applies here too, and you will have some new ones with special characters in URL's. This took a year to resolve for RFC 7929 and RFC 8162. So I recommend you look at previous discussion on this topic on the openpgp and dane mailing lists. Paul > -Bart > > Sent from ProtonMail, encrypted email based in Switzerland. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, November 13, 2018 6:02 AM, Werner Koch wrote: > >> Hi! >> > >> A new revision of the Web Key Directory I-D has been published: >> > >> https://www.ietf.org/id/draft-koch-openpgp-webkey-service-07.txt >> > >> Changes since -06 are: >> > >> - Specify the advanced method with the openpgpkey sub-domain. >> > >> - Specify the l=LOCAL-PART query parameter. >> > >> - Require the provider to filter the key for publication. >> > >> - Drop the use of DNS SRV records. >> > >> See below for the gist of the change. GnuPG master implements the new >> advanced method. You may use my address for testing. For now the SRV >> method is still used as a fallback by GnuPG. >> > >> Note that the domain name is now also part of the file name if the >> openpgpkey sub-domain is used. This should make it easier to server the >> directory for several domains from a single server. This sub-domain >> approach is similar to Mozilla's mail auto configuration [1]. >> > >> Shalom-Salam, >> > >> Werner >> > >> --8<---------------cut here---------------start------------->8--- >> There are two variants on how to form the request URI: The advanced >> and the direct method. Implementations MUST first try the advanced >> method. Only if the required sub-domain does not exist, they SHOULD >> fall back to the direct method. >> > >> The advanced method requires a sub-domain with the fixed name >> "openpgpkey" is created and queried. It constructs the URI from the >> concatenation of these items: >> > >> o The scheme "https://", >> > >> o the domain-part, >> > >> o the string "/.well-known/openpgpkey/", >> > >> o the domain-part in lowercase, >> > >> o the string "/hu/", >> > >> o the above constructed 32 octet string, >> > >> o the unchanged local-part as a parameter with name "l" using proper >> percent escaping. >> > >> An example for such an advanced method URI to lookup the key for >> Joe.Doe@Example.ORG is: >> > >> https://openpgpkey.example.org/.well-known/openpgpkey/ >> example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe >> > >> (line has been wrapped for rendering purposes) >> > >> The direct method requires no additional DNS entries and constructs >> the URI from the concatenation of these items: >> > >> o The scheme "https://", >> > >> o the domain-part, >> > >> o the string "/.well-known/openpgpkey/hu/", >> > >> o the above constructed 32 octet string, >> > >> o the unchanged local-part as a parameter with name "l" using proper >> percent escaping. >> > >> Example for a direct method URI: >> > >> https://example.org/.well-known/openpgpkey/ >> hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe >> > >> (line has been wrapped for rendering purposes) >> > >> [...] >> The benefit of the advanced method is its greater flexibility in >> setting up the Web Key Directory in environments where more than one >> mail domain is hosted. DNS SRV resource records, as used in earlier >> specifications of this protocol, posed a problem for implementations >> which have only limited access to DNS resolvers. The direct method >> is kept for backward compatibility and to allow providing a Web Key >> Directory even with without DNS change requirements. >> --8<---------------cut here---------------end--------------->8--- >> > >> > >> [1]https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration >> > >> -- >> > >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > From nobody Wed Nov 14 19:03:30 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819512777C for ; Wed, 14 Nov 2018 19:03:28 -0800 (PST) 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=vSWTc+qs; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=349ebs2L Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBCDP2vZX5Rq for ; Wed, 14 Nov 2018 19:03:27 -0800 (PST) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (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 E3D1512426A for ; Wed, 14 Nov 2018 19:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201811; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZuQG3eJ2qve/BDrDgrBSNWXjOpEd3viYMqzHWKRi9/E=; b=vSWTc+qspNe48TWNIIOAfiTVF4 KdBPXXk5KidUf6ZfoRlkohYqp0U/0HmFJNpFF5aanXH52wUDsmoxEPWvgEzk80fbWmcaQgAZPnD3Q WGLtvwsgzwm1MjVxbo3PMeKcfZ3CykEVFZwLxPCBUwnhQo5VOA0kAnakdFebKNTfsfB3ZSWX/3ACO hykXoMSaANapYuwqZHxvle56C0IxvqWh7qFv8y8tGa94cFLe4OGzalMVJTAY0g0NEtn3J4jGHXpoQ hkdiz9wzAju7IgkNOj1JlKxT1TnU8k0TYQrYC1qaTdB6lzXV8gBcQFq4HIG/p0MSYbIfFZ+yuRmzQ 7s18p7HQ==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201811e2; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZuQG3eJ2qve/BDrDgrBSNWXjOpEd3viYMqzHWKRi9/E=; b=349ebs2Luuzu1m9Ltq5stHu7g w6Z7sW3DLzmu1FnUysYWHqgvzpEjlh4tVGVuRUBKmzOal/9wCSYp16VPcUhAw==; Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gN7w6-0008tq-Hk; Thu, 15 Nov 2018 03:03:19 +0000 Date: Wed, 14 Nov 2018 22:03:07 -0500 From: Phil Pennock To: openpgp@ietf.org Message-ID: <20181115030305.GA14179@osmium.pennocktech.home.arpa> Mail-Followup-To: openpgp@ietf.org References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 03:03:28 -0000 On 2018-11-14 at 10:26 -0500, Paul Wouters wrote: > On Tue, 13 Nov 2018, Bart Butler wrote: > > So if I request from ProtonMail Bart.Butler@protonmail.com, I would get a key back with bartbutler@protonmail.com, and the clients could then prompt on unrecognized types of mismatches if desired because they would know that the server is returning the canonical form of the address. > > We went through this with OPENPGPKEY and SMIMEA. You will get the SMTP > people blocking your draft when you try to interpret (or like above, > even rewrite) addresses based on "common mail provider rewrites". Their > firm believe is only receiving SMTP servers can interpret email addresses. Bart isn't suggesting encoding common rewrites into OpenPGP, although I believe that Werner might be. As an MTA maintainer, I think Bart's suggestion is entirely appropriate and inline with the ethos of federated SMTP. I'll proceed on the assumption that my analysis of Bart's intent is correct. Bart, please correct me if wrong. In Bart's suggestion, the WKD server, run within the same autonomous mail-system (or email administrative domain) as the SMTP servers, can decide to map addresses and return a key suitable for use for that email address. This does not change where the MUA should send email, but does adjust how a well-integrated MUA might choose an appropriate OpenPGP key for use for a given email address. This is entirely in line with the federated design and only the owner of the systems at that location getting to make such decisions. There are implications around caching, because such a rewrite becomes a long-term commitment if it's to be stored as ancillary data in the keyring for choosing the correct key. Thus if presented with a new address test+foo@spodhuis.org and needing to get a key for it, with Bart's proposal, the MUA and the OpenPGP client software can make no assumptions. It must not normalize anything to the left of the '@' sign. But the MUA can use WKD and get back a key for ; the software can then record a mapping of test+foo@spodhuis.org -> test@spodhuis.org in OpenPGP recipient key selection preferences. When later sending email to test+foo@spodhuis.org, the SMTP transaction proceeds unmodified: the MUA does not rewrite the recipient, you have to preserve the address as-given. The remapped OpenPGP key selection proceeds as suggested though. If sending email to test+bar@spodhuis.org then another WKD lookup needs to be made. (Future work might look at protocols for indicating patterns to avoid repeated lookups). Because server-side mapping decisions are being held elsewhere, and because people do change PGP keys (in particular: security teams which cycle their keys annually) this does suggest that the HTTP cache control expiration headers might play into SHOULD controls on how the OpenPGP client expires mappings and puts in place refresh checks. The spirit of Bart's proposal, as I read it, is a great fit for the autonomy of mail administrative domains. -Phil From nobody Wed Nov 14 20:57:56 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E155E12F295 for ; Wed, 14 Nov 2018 20:57:53 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 Tu2uJg4AEubr for ; Wed, 14 Nov 2018 20:57:51 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 26A941271FF for ; Wed, 14 Nov 2018 20:57:50 -0800 (PST) X-AuditID: 12074424-143ff70000002c2a-cf-5becfccb3c4a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 11.A7.11306.CCCFCEB5; Wed, 14 Nov 2018 23:57:48 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wAF4vkm7015261 for ; Wed, 14 Nov 2018 23:57:47 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAF4vhNs008789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 14 Nov 2018 23:57:46 -0500 Date: Wed, 14 Nov 2018 22:57:43 -0600 From: Benjamin Kaduk To: openpgp@ietf.org Message-ID: <20181115045743.GE70453@kduck.kaduk.org> References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <20181115030305.GA14179@osmium.pennocktech.home.arpa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181115030305.GA14179@osmium.pennocktech.home.arpa> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrXvmz5tog4XbrSwa/j1kd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtf3j+wFL8Qr3ky4wtTAOF+4i5GTQ0LAROJ37ybGLkYuDiGB NUwSnb/XMkM4Jxgl2tovskA4X5gkpqzZwgLSwiKgKtH86w8biM0moCLR0H2ZGcQWERCRaJu9 ix3EFhYwkJgy8x9YDS/QiqPLdjJBDOphkrh9/CMrREJQ4uTMJ2BDmQW0JG78ewlUxAFkS0ss /8cBEuYUcJLoOnsUbKaogLLE3r5D7BMY+Wch6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrF yYl5ealFuuZ6uZkleqkppZsYQcHH7qKyg7G7x/sQowAHoxIP7wmrN9FCrIllxZW5hxglOZiU RHnTwl5FC/El5adUZiQWZ8QXleakFh9ilOBgVhLhXVADVM6bklhZlVqUD5OS5mBREuf9I/I4 WkggPbEkNTs1tSC1CCYrw8GhJMH78zdQo2BRanpqRVpmTglCmomDE2Q4D9Dw+j8gw4sLEnOL M9Mh8qcYFaXEeWeBNAuAJDJK8+B6QclBInt/zStGcaBXhHmXgVTxABMLXPcroMFMQINPTH0N MrgkESEl1cCYbnRp7ZqjJu/2aW5bsi3KK1FJNLfi7fWtSp6eV324Ptyo2hgXdC3D8q+8x43X 5yMz64pKL4kGnvC/yu8Wrpnn9OzJRu75J1o3705UTH/y+qb1/WD3zZabKlnM3myLUOx2nGty m7PoWCazV/qFg/NK93WZXvrw+VzUurd+i+Yx7klUebqcf5ayEktxRqKhFnNRcSIABhlyVekC AAA= Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 04:57:54 -0000 On Wed, Nov 14, 2018 at 10:03:07PM -0500, Phil Pennock wrote: > On 2018-11-14 at 10:26 -0500, Paul Wouters wrote: > > On Tue, 13 Nov 2018, Bart Butler wrote: > > > So if I request from ProtonMail Bart.Butler@protonmail.com, I would get a key back with bartbutler@protonmail.com, and the clients could then prompt on unrecognized types of mismatches if desired because they would know that the server is returning the canonical form of the address. > > > > We went through this with OPENPGPKEY and SMIMEA. You will get the SMTP > > people blocking your draft when you try to interpret (or like above, > > even rewrite) addresses based on "common mail provider rewrites". Their > > firm believe is only receiving SMTP servers can interpret email addresses. > > Bart isn't suggesting encoding common rewrites into OpenPGP, although I > believe that Werner might be. As an MTA maintainer, I think Bart's > suggestion is entirely appropriate and inline with the ethos of > federated SMTP. I'll proceed on the assumption that my analysis of > Bart's intent is correct. Bart, please correct me if wrong. > > In Bart's suggestion, the WKD server, run within the same autonomous > mail-system (or email administrative domain) as the SMTP servers, can > decide to map addresses and return a key suitable for use for that email > address. This does not change where the MUA should send email, but does > adjust how a well-integrated MUA might choose an appropriate OpenPGP key > for use for a given email address. > > This is entirely in line with the federated design and only the owner of > the systems at that location getting to make such decisions. There are > implications around caching, because such a rewrite becomes a long-term > commitment if it's to be stored as ancillary data in the keyring for > choosing the correct key. > > Thus if presented with a new address test+foo@spodhuis.org and needing > to get a key for it, with Bart's proposal, the MUA and the OpenPGP > client software can make no assumptions. It must not normalize anything > to the left of the '@' sign. But the MUA can use WKD and get back a key > for ; the software can then record a mapping of > test+foo@spodhuis.org -> test@spodhuis.org in OpenPGP recipient key > selection preferences. When later sending email to > test+foo@spodhuis.org, the SMTP transaction proceeds unmodified: the MUA > does not rewrite the recipient, you have to preserve the address > as-given. The remapped OpenPGP key selection proceeds as suggested > though. If sending email to test+bar@spodhuis.org then another WKD > lookup needs to be made. (Future work might look at protocols for > indicating patterns to avoid repeated lookups). I'm probably confused, but is this implying that WKD would insert a new "lookup" operation such that a compromised WKD could cause me to encrypt a message to an attacker-controlled key (with different UID) when I am trying to encrypt to a non-attacker peer? Thanks, Ben From nobody Thu Nov 15 01:13:42 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9571277D2 for ; Thu, 15 Nov 2018 01:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDX8klClUjoM for ; Thu, 15 Nov 2018 01:13:38 -0800 (PST) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40639126BED for ; Thu, 15 Nov 2018 01:13:38 -0800 (PST) Received: from piha.riseup.net (piha-pn.riseup.net [10.0.1.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id E737B1A016D for ; Thu, 15 Nov 2018 01:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1542273217; bh=IdgjwGPcxMOic1nlO5XpWjrJELIKToGXPuHf8EnISU4=; h=To:References:From:Subject:Date:In-Reply-To:From; b=KZsjJda1oMDnboNFKlS9kfqHPtebqjAy0CBCbV6MqT1+bKf7ub8d37sxVQ6q/soir waMKCdXgOgryshHvPTlefs3RIxd8vmjpvwG61kdgCCkMdvCgcBR3Ewhyv0Dy7E/B2a kKNJMPmw/p+4QFwvzMAC6qeh0MIa2iJhckvPf3D8= X-Riseup-User-ID: 833EC5BB846701233525FB4419287739319F5004F75DED45E59E2DC4656556EE Received: from [127.0.0.1] (localhost [127.0.0.1]) by piha.riseup.net with ESMTPSA id 180A666C67 for ; Thu, 15 Nov 2018 01:13:35 -0800 (PST) To: openpgp@ietf.org References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <875zx0n0j9.fsf@wheatstone.g10code.de> <87sh04km1x.fsf@wheatstone.g10code.de> From: azul Openpgp: preference=signencrypt Autocrypt: addr=azul@riseup.net; prefer-encrypt=mutual; keydata= xsFNBE7u/F4BEADNkng1S+8C/llxQ7DP+pTr9DkYHt+e2zz2WthTgcRxZD7dPut1T2i/5gr7 BYuOqrJZVc7L5BwMt+xr6J+jovhbtvC6bpIC61WpCB66vrDgFb9lfb8gwKPAjvxsnei6SytU YPSYGzuuTofh7Zjc2J/uimhuEYz1BC0Nu9tIenyxCy9433rZWA+qfNL4F+ltGD+LJxlbu1TB qfmv7oPSZdlFGrwI1O/FsIVnObbWvj/gA9ahyxxFcFz0wffMwywpCcPO9H3HVpL20nFpTb5v j4NZ/HGHpGxxTssqJmY++MefrWDqpzVLRmGq87HWauUo+G3w2Gv6ZSrZHpllzi/YQXyPhcr8 a4U/TpXOyzAycMyiudcpWHGqBFHjp1P4YA9u3WIFVvlgSkFuie3Ypa3LL89hg9FxCclH3Zq3 GD3uKZIZkHoPCs6EbQDaVFriPKTUCixy139/U4FlEfMFV769h4KZoDECURaI+vEtBz9TzFU9 SS7xe5Fw+KTuu+VCoypL4pmQGCRol6IKfjp0LDZtMI6AZDPJFAaNIyVonEBm5T+yaflN9rqH WOyyMKP9cEKAxiDs1IlHHr9EMoZagxt4UaiaQS/Jx8RcSYUiOHgHruT6L+FN4nkHuhSDXh/j J2zNcn/oieeKkIffK0mF09hSQRiLp69tuVeBDE7Fu+B2CYA4gQARAQABzRdBenVsLiA8YXp1 bEByaXNldXAubmV0PsLBlwQTAQoAQQIbIwIeAQIXgAIZAQULCQgHAwUVCgkICwUWAgMBABYh BLtwsBYESQEKAK9J6Hhghawg00V9BQJbs4LRBQkOpbnzAAoJEHhghawg00V9FggP/0KWzd9R Lk7XZL2yZbLzlxyjM7bvkNjwHIoH2ko+axRFEtlsudFDpVfF7InZ6wZ8AI2L/OWBT7AEdTUX ig5IdUKtk5AI2hp5TycuQqxapJuXME/3hLxvuwHfKGFDj8CPf52CvAACGoN0hAaBO7ZUwKbQ hSB8lwYSsPxXvQMoU/Jyl2Dm5Wq4qGJaw829QGGIGgOKb8uZlR6Mk0Fmf/JGkuwEwHsCpsuF rxeSh8HtY32yDRtsRqd23IrYZpJ2tJpheWtKstOrzcGtFQ2m3/gsi8J03B1Oc5iIOJ223muE A1FOxVh1c5TTf7aP30EyQbe88M4tU3PTN/n9lfgtJAEFyeOlm7tYg2F1ZzyxiRC1Q4Xq1kdH Of3D/FqBR8OPbqDJY3eAnuUUI+DRLiCK+r2SMLcz15bZup1mHlxh0z9nKUDHbct7JAWFOpNz VFPZY0j4FWf3LXB3gvqrVbZ5JW3D+QDoIEgSOab4y/4t4M6FBRtkmu6PhZhuAoDBgmhV7zgd ieHAUjvbepLStimy4BqtCjgA07V+M33HYD07r9r4joGGlGwUwRz0DSGvgMSRO5P/fG7HewB3 X7Yl0XYCF1swIaUm/qy12Ar/NS3Bby+tGe/WYv/tlDYpsTZ8MmxE+/WMieXpYWNp/z1W9Jf6 1bxAstuB0QFE+24yaPKZPspWubNDzsFNBFn62gUBEAC4w0+lWkDqB3UdchGx3Y8jwDmWckbA 1AYlDEgkTP+FgIOJLdBP8gvI8S76DtDn6UMyFGFemTwL6S2BiWebMWORyrQWBblw9/QJn4g6 Fb8z920BsBxR/iIymww2HoY2CDC/4lyUEmbqVn1zYnYY2zLgLHq/z48vI9c3XxGW2miuBWfj m+rQmADyJ2nTFbQvgDYeoPTKm1ZAvuXt0gEOPRHExXXkiiWv6seBwjf9tTUq1GCuVqDN39L7 C/3jhm3ITeHIqyPYyLdLtAAf+ycm/2sP7i7Y7UqZlCtWgf/Gbt5vZuo5Oa6MCodrZzqH2gqh /fmzcChsVp8r9VsTol2LjWUKjBonwsqgXe4H5Rph6fWPE6SBm+c1fmBtUn9wvGpyuGklYWG2 jgtx/+Cg3ESh72M1sINnSyseSYJX5gB+4cCjPhs2DJhrByasyDBa1mXZZIuDZL01wJYeY2G3 pJjU/gDt7mg310dgPiChTL78cbji3cr1GrlDdiGoVTOZd/P3mueQ/p+8B+rwJklHWaWCVztX XYUduaneB5q9gpI43YCYBy/PzbEADreOTC9wcqcQC27oz1YB9zH27d1Z2rmsU6v79h1pyA8u jfsOy0vcdhcx6p/LvXnCpw9hy5sxFJgLJWLDsUt2n7celQaVM8wnkProsDXLIZDnyZqt5Aa0 D6GA5wARAQABwsF8BBgBCgAmAhsMFiEEu3CwFgRJAQoAr0noeGCFrCDTRX0FAluzgwUFCQOZ 3IAACgkQeGCFrCDTRX3i4Q/7B6pOSudvI8KKNqlYlazGcD0wDV5u15oU84FeesD82ONxY/7n 2CZCd/62vQyCj61kfPqcH7TE/ktBOw049uZzSQZO7xR1hPf55hAB4g/ZheygDtQWT48RI5Y+ QEMCLd4zXtIllv8WZHXU8SqTLUG0NdBj1stKM47tBpvoeAom4pmljH/88HCqM02BDrvu4wgr jTY8Qt5uuonlk2MTUrbWZEWTkJpyDSVsuSIKmPnbKhpkkjGu/+2aKjz4HHoV8XDQhLM45rxt 8NY4hGqbUUv7tnL/Rk45V0qv/QOG6b5DFywswGwR7NLwWI4g0jbgawXdUg8sg2IupP2MdW3u 5Hl2YEtV0wNS6A5hUsqnBWSZ79s0N4e2A5fy2uWgKyVV/ojN7mXwNDQR4urvdO2GL1pWqHvT Aiag807r3m9ioHq4YWK4QuDwuQT9kSLZq5ElCe0Goab6UDHukbqTJ+vF6FufSE5IOM0/P7ey 6ofT9kVbY6X6V7ozFC7WkmTp0fyA3YQIN75Xgo7SOfQKIqluyXo217aQ0g3ulSERtoJXliEu VR1TnZgweE9/V6anq7cIcOUwH6xbaEtIwvC48dLkp7Nl3QAwuRcoVoLi5Qft0OEFWfyEmiYP c9R3pR0HVlPQq4qMTbUpudmtzTvuIu04krwK2a+dGT+HYMLVek1rtKAiBv8= Message-ID: <0a788c9c-cd3f-76df-4f65-754b0e08eb24@riseup.net> Date: Thu, 15 Nov 2018 10:13:21 +0100 MIME-Version: 1.0 In-Reply-To: <87sh04km1x.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 09:13:41 -0000 Hello, Am 14.11.18 um 11:09 schrieb Werner Koch: > On Tue, 13 Nov 2018 22:37, bartbutler=3D40protonmail.com@dmarc.ietf.org= > said: > >> "The key MUST carry a User ID packet ([RFC4880]) containing the email = address to which mail sent to the queried email address will be routed." > You are talking about how mail is routed, the spec is about discovering= > the one and only key to be used for a given mail address. And by key I= > mean the OpenPGP keyblock, that is the public key plus one user ID (or > several if they have the same addrspec part). > > A mail address is here considered as an identifier for an entity and no= t > as an addressing scheme for mails. An entity may have several > identifiers like Werner.Koch@foo, Werner_Koch@foo, wernerkoch@foo, > wk@foo, koch@foo. That is a pretty normal but there is no way a sender= > can decide whether they are all the same; for example the last two of > the list could also identify my brother. > > A sender gets hold of one mail address and that must have been relayed > (direct or indirectly) to them by the owner of that mail address. The > recipient needs to take care that a key exists for that very mail > address. I think the last sentence exactly captures the difference between the two approaches. Who needs to take care that a key exists / pick an existing key for a different email address routed to the same mailbox. One of the use cases I have for the '+' syntax is registering to services with email addresses that allow me to remember where i used them and filter mails based on them. One example would be using 'azul+conference_name@riseup.net' to register to a conference. It's low overhead. I can just come up with a addition to my email address when filling in a web form. If I later receive spam to that address I know who leaked my email address. Providing a key for the new address or even publish all those addresses in my key do not seem like an option for me. Therefor the party I submitted the form to will not be able to get back to me with an encrypted email even if i have a key in the wkd. I don't quite understand the downside of relaxing the spec in this regard. As far as i understand it it would not require implementations to lookup which mailbox an address would route to. It would just allow it. For some providers / implementations this may be trivial and other may choose to not do it. Where does the need for the matching user_id come from? One downside I see is that the mechanism could be used to detect where an email address routes to. In the case of azul+conf this may be easy to guess. But for aliases users do not expect them to be linkable without any interaction on their side. Cheers, =C2=A0Azul From nobody Thu Nov 15 01:17:00 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4B712D4ED for ; Thu, 15 Nov 2018 01:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol12EOHlb4cA for ; Thu, 15 Nov 2018 01:16:58 -0800 (PST) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027D9126BED for ; Thu, 15 Nov 2018 01:16:57 -0800 (PST) Received: from piha.riseup.net (piha-pn.riseup.net [10.0.1.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id A4B1C1A0A69 for ; Thu, 15 Nov 2018 01:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1542273417; bh=AtJaTwgY7w5ouednhkAiJSeC6PRNfqEOA9bMGOUoqQw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GKK324KydChbci36OqK9VTFUcHc+wO1eDEtRBLtG7DUG5dofyzNmr5rfGXjiphopC CJlUf5GiZxl8vCBgNflBBcYeUEFVXsWeBexBGGJo+f9Bnk1KhcSK/Z286+0CF9EbM1 mDpFOyuXztSt+QxwMrZkUNsid+cvLruNiCiZOl4E= X-Riseup-User-ID: 9F590EA3A7C2BBAE7903A9013C72C0C262EE529B4EEF676BC7E79155C124BA21 Received: from [127.0.0.1] (localhost [127.0.0.1]) by piha.riseup.net with ESMTPSA id 1E18766C70 for ; Thu, 15 Nov 2018 01:16:56 -0800 (PST) To: openpgp@ietf.org References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <20181115030305.GA14179@osmium.pennocktech.home.arpa> <20181115045743.GE70453@kduck.kaduk.org> From: azul Openpgp: preference=signencrypt Autocrypt: addr=azul@riseup.net; prefer-encrypt=mutual; keydata= xsFNBE7u/F4BEADNkng1S+8C/llxQ7DP+pTr9DkYHt+e2zz2WthTgcRxZD7dPut1T2i/5gr7 BYuOqrJZVc7L5BwMt+xr6J+jovhbtvC6bpIC61WpCB66vrDgFb9lfb8gwKPAjvxsnei6SytU YPSYGzuuTofh7Zjc2J/uimhuEYz1BC0Nu9tIenyxCy9433rZWA+qfNL4F+ltGD+LJxlbu1TB qfmv7oPSZdlFGrwI1O/FsIVnObbWvj/gA9ahyxxFcFz0wffMwywpCcPO9H3HVpL20nFpTb5v j4NZ/HGHpGxxTssqJmY++MefrWDqpzVLRmGq87HWauUo+G3w2Gv6ZSrZHpllzi/YQXyPhcr8 a4U/TpXOyzAycMyiudcpWHGqBFHjp1P4YA9u3WIFVvlgSkFuie3Ypa3LL89hg9FxCclH3Zq3 GD3uKZIZkHoPCs6EbQDaVFriPKTUCixy139/U4FlEfMFV769h4KZoDECURaI+vEtBz9TzFU9 SS7xe5Fw+KTuu+VCoypL4pmQGCRol6IKfjp0LDZtMI6AZDPJFAaNIyVonEBm5T+yaflN9rqH WOyyMKP9cEKAxiDs1IlHHr9EMoZagxt4UaiaQS/Jx8RcSYUiOHgHruT6L+FN4nkHuhSDXh/j J2zNcn/oieeKkIffK0mF09hSQRiLp69tuVeBDE7Fu+B2CYA4gQARAQABzRdBenVsLiA8YXp1 bEByaXNldXAubmV0PsLBlwQTAQoAQQIbIwIeAQIXgAIZAQULCQgHAwUVCgkICwUWAgMBABYh BLtwsBYESQEKAK9J6Hhghawg00V9BQJbs4LRBQkOpbnzAAoJEHhghawg00V9FggP/0KWzd9R Lk7XZL2yZbLzlxyjM7bvkNjwHIoH2ko+axRFEtlsudFDpVfF7InZ6wZ8AI2L/OWBT7AEdTUX ig5IdUKtk5AI2hp5TycuQqxapJuXME/3hLxvuwHfKGFDj8CPf52CvAACGoN0hAaBO7ZUwKbQ hSB8lwYSsPxXvQMoU/Jyl2Dm5Wq4qGJaw829QGGIGgOKb8uZlR6Mk0Fmf/JGkuwEwHsCpsuF rxeSh8HtY32yDRtsRqd23IrYZpJ2tJpheWtKstOrzcGtFQ2m3/gsi8J03B1Oc5iIOJ223muE A1FOxVh1c5TTf7aP30EyQbe88M4tU3PTN/n9lfgtJAEFyeOlm7tYg2F1ZzyxiRC1Q4Xq1kdH Of3D/FqBR8OPbqDJY3eAnuUUI+DRLiCK+r2SMLcz15bZup1mHlxh0z9nKUDHbct7JAWFOpNz VFPZY0j4FWf3LXB3gvqrVbZ5JW3D+QDoIEgSOab4y/4t4M6FBRtkmu6PhZhuAoDBgmhV7zgd ieHAUjvbepLStimy4BqtCjgA07V+M33HYD07r9r4joGGlGwUwRz0DSGvgMSRO5P/fG7HewB3 X7Yl0XYCF1swIaUm/qy12Ar/NS3Bby+tGe/WYv/tlDYpsTZ8MmxE+/WMieXpYWNp/z1W9Jf6 1bxAstuB0QFE+24yaPKZPspWubNDzsFNBFn62gUBEAC4w0+lWkDqB3UdchGx3Y8jwDmWckbA 1AYlDEgkTP+FgIOJLdBP8gvI8S76DtDn6UMyFGFemTwL6S2BiWebMWORyrQWBblw9/QJn4g6 Fb8z920BsBxR/iIymww2HoY2CDC/4lyUEmbqVn1zYnYY2zLgLHq/z48vI9c3XxGW2miuBWfj m+rQmADyJ2nTFbQvgDYeoPTKm1ZAvuXt0gEOPRHExXXkiiWv6seBwjf9tTUq1GCuVqDN39L7 C/3jhm3ITeHIqyPYyLdLtAAf+ycm/2sP7i7Y7UqZlCtWgf/Gbt5vZuo5Oa6MCodrZzqH2gqh /fmzcChsVp8r9VsTol2LjWUKjBonwsqgXe4H5Rph6fWPE6SBm+c1fmBtUn9wvGpyuGklYWG2 jgtx/+Cg3ESh72M1sINnSyseSYJX5gB+4cCjPhs2DJhrByasyDBa1mXZZIuDZL01wJYeY2G3 pJjU/gDt7mg310dgPiChTL78cbji3cr1GrlDdiGoVTOZd/P3mueQ/p+8B+rwJklHWaWCVztX XYUduaneB5q9gpI43YCYBy/PzbEADreOTC9wcqcQC27oz1YB9zH27d1Z2rmsU6v79h1pyA8u jfsOy0vcdhcx6p/LvXnCpw9hy5sxFJgLJWLDsUt2n7celQaVM8wnkProsDXLIZDnyZqt5Aa0 D6GA5wARAQABwsF8BBgBCgAmAhsMFiEEu3CwFgRJAQoAr0noeGCFrCDTRX0FAluzgwUFCQOZ 3IAACgkQeGCFrCDTRX3i4Q/7B6pOSudvI8KKNqlYlazGcD0wDV5u15oU84FeesD82ONxY/7n 2CZCd/62vQyCj61kfPqcH7TE/ktBOw049uZzSQZO7xR1hPf55hAB4g/ZheygDtQWT48RI5Y+ QEMCLd4zXtIllv8WZHXU8SqTLUG0NdBj1stKM47tBpvoeAom4pmljH/88HCqM02BDrvu4wgr jTY8Qt5uuonlk2MTUrbWZEWTkJpyDSVsuSIKmPnbKhpkkjGu/+2aKjz4HHoV8XDQhLM45rxt 8NY4hGqbUUv7tnL/Rk45V0qv/QOG6b5DFywswGwR7NLwWI4g0jbgawXdUg8sg2IupP2MdW3u 5Hl2YEtV0wNS6A5hUsqnBWSZ79s0N4e2A5fy2uWgKyVV/ojN7mXwNDQR4urvdO2GL1pWqHvT Aiag807r3m9ioHq4YWK4QuDwuQT9kSLZq5ElCe0Goab6UDHukbqTJ+vF6FufSE5IOM0/P7ey 6ofT9kVbY6X6V7ozFC7WkmTp0fyA3YQIN75Xgo7SOfQKIqluyXo217aQ0g3ulSERtoJXliEu VR1TnZgweE9/V6anq7cIcOUwH6xbaEtIwvC48dLkp7Nl3QAwuRcoVoLi5Qft0OEFWfyEmiYP c9R3pR0HVlPQq4qMTbUpudmtzTvuIu04krwK2a+dGT+HYMLVek1rtKAiBv8= Message-ID: Date: Thu, 15 Nov 2018 10:16:55 +0100 MIME-Version: 1.0 In-Reply-To: <20181115045743.GE70453@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 09:16:59 -0000 Hi, >> Thus if presented with a new address test+foo@spodhuis.org and needing >> to get a key for it, with Bart's proposal, the MUA and the OpenPGP >> client software can make no assumptions. It must not normalize anything >> to the left of the '@' sign. But the MUA can use WKD and get back a key >> for ; the software can then record a mapping of >> test+foo@spodhuis.org -> test@spodhuis.org in OpenPGP recipient key >> selection preferences. When later sending email to >> test+foo@spodhuis.org, the SMTP transaction proceeds unmodified: the MUA >> does not rewrite the recipient, you have to preserve the address >> as-given. The remapped OpenPGP key selection proceeds as suggested >> though. If sending email to test+bar@spodhuis.org then another WKD >> lookup needs to be made. (Future work might look at protocols for >> indicating patterns to avoid repeated lookups). > I'm probably confused, but is this implying that WKD would insert a new > "lookup" operation such that a compromised WKD could cause me to encrypt a > message to an attacker-controlled key (with different UID) when I am trying > to encrypt to a non-attacker peer? As far as i understand the compromised WKD could easily send you an attacker controlled key with a valid UID as well. Why would the different UID make the attack any worse? Cheers,  Azul From nobody Thu Nov 15 03:25:14 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFAA126CC7 for ; Thu, 15 Nov 2018 03:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBNr2AIQjnXE for ; Thu, 15 Nov 2018 03:25:10 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 701E7124C04 for ; Thu, 15 Nov 2018 03:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=vrgSw7jSKGs2C9cwi1kd3rmn5bFZqOpljBE6oyG0OKU=; b=OwTorErWA9OkTuMILJCOx7yRGt 9+OjgBVsoQCHy8UnIsVgka7uxQKc7P3znXUaKVEDDUzfXSjmpAj+vab09hrScenJTixPJ19/fxD2I Cwk0/dC8AqrvxWvJYFcl6e3Y59CtH4w1CTHTWLr7RkbWM8ktFuO7hu2EDfC4J+gDY2vQ=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gNFlk-0000B0-VC for ; Thu, 15 Nov 2018 12:25:08 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gNFjO-0002oc-Jp; Thu, 15 Nov 2018 12:22:42 +0100 From: Werner Koch To: azul Cc: openpgp@ietf.org References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <875zx0n0j9.fsf@wheatstone.g10code.de> <87sh04km1x.fsf@wheatstone.g10code.de> <0a788c9c-cd3f-76df-4f65-754b0e08eb24@riseup.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: azul , openpgp@ietf.org Date: Thu, 15 Nov 2018 12:22:42 +0100 In-Reply-To: <0a788c9c-cd3f-76df-4f65-754b0e08eb24@riseup.net> (azul@riseup.net's message of "Thu, 15 Nov 2018 10:13:21 +0100") Message-ID: <8736s2inzx.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=STARLAN_Europol_warfare_ASIO_Craig_Livingstone_Skipjack_cracking_wir"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 11:25:13 -0000 --=STARLAN_Europol_warfare_ASIO_Craig_Livingstone_Skipjack_cracking_wir Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 15 Nov 2018 10:13, azul@riseup.net said: > One example would be using 'azul+conference_name@riseup.net' to register > to a conference. > It's low overhead. I can just come up with a addition to my email Right, and we more or less agreed that this is a good and useful extension. I merely don't think that it should go into the protocol, because it is a MUA thing. GnuPG will very likely help MUAs by taking care to strip of such sub-addresses when looking for keys in a remote directory [1]. Salam-Shalom, Werner [1] See for a start =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=STARLAN_Europol_warfare_ASIO_Craig_Livingstone_Skipjack_cracking_wir Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW+1XAgAKCRD/gK6dHew1 jXyOAP47U6W6sY43mZ9Wnb1O2qkUJH/OpnSjYoKNvTNRtTX7DgEAioKZvuRIBa8s 260CngzZqzg3AQQoqx4vodYlw9t4vAw= =w8A/ -----END PGP SIGNATURE----- --=STARLAN_Europol_warfare_ASIO_Craig_Livingstone_Skipjack_cracking_wir-- From nobody Thu Nov 15 05:25:11 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C909130E26 for ; Thu, 15 Nov 2018 05:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.652 X-Spam-Level: X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 diyq_3QnyZjl for ; Thu, 15 Nov 2018 05:24:59 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 79BA6130E5F for ; Thu, 15 Nov 2018 05:24:58 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gNHdg-0001lM-Iv for ; Thu, 15 Nov 2018 14:24:56 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gNHcV-0002rg-6l for ; Thu, 15 Nov 2018 14:23:43 +0100 Resent-To: openpgp@ietf.org Resent-From: Werner Koch Resent-Date: Thu, 15 Nov 2018 14:23:43 +0100 Resent-Message-ID: <87tvkih3ts.fsf@wheatstone.g10code.de> Received: from uucp by wheatstone.g10code.de with local-rmail (Exim 4.84 #3 (Debian)) id 1gNFc4-0003si-7k for ; Thu, 15 Nov 2018 12:15:08 +0100 Received: from mail.ietf.org ([4.31.198.44]) by kerckhoffs.g10code.com with esmtps (Exim 4.89 #1 (Debian)) id 1gNFYK-00006X-BB for ; Thu, 15 Nov 2018 12:11:16 +0100 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB971276D0; Thu, 15 Nov 2018 03:11:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Ronald Henry Tse" , "brian m. carlson" , "Ronald Tse" , "brian carlson" , "Werner Koch" , "Derek Atkins" X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154228027143.4279.15378974975872438430.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2018 03:11:11 -0800 X-Sender-Host: mail.ietf.org Archived-At: Subject: [openpgp] New Version Notification for draft-ietf-openpgp-rfc4880bis-06.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 13:25:03 -0000 A new version of I-D, draft-ietf-openpgp-rfc4880bis-06.txt has been successfully submitted by Werner Koch and posted to the IETF repository. Name: draft-ietf-openpgp-rfc4880bis Revision: 06 Title: OpenPGP Message Format Document date: 2018-11-15 Group: Individual Submission Pages: 125 URL: https://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc4880bis-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ Htmlized: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-rfc4880bis-06 Abstract: { Work in progress to update the OpenPGP specification from RFC4880 } This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Nov 15 11:42:59 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E4A130E5E for ; Thu, 15 Nov 2018 11:42:51 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 GHuzNSYTfgO2 for ; Thu, 15 Nov 2018 11:42:49 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 CF0DC130E97 for ; Thu, 15 Nov 2018 11:42:48 -0800 (PST) X-AuditID: 12074425-09fff700000031d0-71-5bedcc340a2b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id BA.40.12752.53CCDEB5; Thu, 15 Nov 2018 14:42:46 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id wAFJgfmN013725; Thu, 15 Nov 2018 14:42:42 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAFJga3q020980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Nov 2018 14:42:39 -0500 Date: Thu, 15 Nov 2018 13:42:36 -0600 From: Benjamin Kaduk To: azul Cc: openpgp@ietf.org Message-ID: <20181115194235.GH70453@kduck.kaduk.org> References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <20181115030305.GA14179@osmium.pennocktech.home.arpa> <20181115045743.GE70453@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nomt25m20waRFGhY7pq1mtGj495Dd gcljyZKfTB4/nixhCWCK4rJJSc3JLEst0rdL4MpYNfEFS8FfvorPK/8yNTC28nQxcnJICJhI HN5zlbGLkYtDSGANk8TD7avYIZyNjBJ/Dz1khnDuMklMnj2LHaSFRUBVYt7JaWA2m4CKREP3 ZWYQW0RASmJ271KWLkYODmYBEYnjO1JBwsICBhJTZv5jA7F5gbatenmUCWLmayaJf1tWQSUE JU7OfMICYjMLaEnc+PeSCWKOtMTyfxwgYU4BO4mmvTPAykUFlCX29h1in8AoMAtJ9ywk3bMQ uhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQIDlMX1R2Mc/56HWIU4GBU 4uE1KH8bLcSaWFZcmXuIUZKDSUmUd58fUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr1sdUI43 JbGyKrUoHyYlzcGiJM77R+RxtJBAemJJanZqakFqEUxWhoNDSYI36TRQo2BRanpqRVpmTglC momDE2Q4D9DwulMgw4sLEnOLM9Mh8qcYFaXEeS+AJARAEhmleXC9oDQikb2/5hWjONArwrx6 ICt4gCkIrvsV0GAmoMEnpr4GGVySiJCSamBMinp3zyIjeelf2QkGIW28913Sn5s8Y2x5b+3e 4cKSu1/I8p79a9tmc80r71mW9ec//brtgv/8s0cqJq1Pe+ZzSGxV/CHmfvFl/D+C5lSKdX/9 713Wp1R1rXdV5qFtP1Ob6gIzMstV/7ezi0y+fTv3UMecGCH2Pb5X3/SflahNiLjZPuHkFw8l luKMREMt5qLiRAD6QMV6/gIAAA== Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 19:42:58 -0000 On Thu, Nov 15, 2018 at 10:16:55AM +0100, azul wrote: > Hi, > > >> Thus if presented with a new address test+foo@spodhuis.org and needing > >> to get a key for it, with Bart's proposal, the MUA and the OpenPGP > >> client software can make no assumptions. It must not normalize anything > >> to the left of the '@' sign. But the MUA can use WKD and get back a key > >> for ; the software can then record a mapping of > >> test+foo@spodhuis.org -> test@spodhuis.org in OpenPGP recipient key > >> selection preferences. When later sending email to > >> test+foo@spodhuis.org, the SMTP transaction proceeds unmodified: the MUA > >> does not rewrite the recipient, you have to preserve the address > >> as-given. The remapped OpenPGP key selection proceeds as suggested > >> though. If sending email to test+bar@spodhuis.org then another WKD > >> lookup needs to be made. (Future work might look at protocols for > >> indicating patterns to avoid repeated lookups). > > I'm probably confused, but is this implying that WKD would insert a new > > "lookup" operation such that a compromised WKD could cause me to encrypt a > > message to an attacker-controlled key (with different UID) when I am trying > > to encrypt to a non-attacker peer? > As far as i understand the compromised WKD could easily send you > an attacker controlled key with a valid UID as well. > > Why would the different UID make the attack any worse? It seems like there's a transparency difference --if the WKD gives me a totally spoofed key (valid/expected UID but attacker-controlled key material) then that key could/should be on the keyservers, and the actual holder of that UID can notice it and take action. If I as the WKD consumer get wholly redirected to the attacker's real key/UID, the actual intended recipient doesn't have any way to discover that there was an attack. -Ben From nobody Thu Nov 15 12:46:08 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584DE130DE4 for ; Thu, 15 Nov 2018 12:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0boA1_t44t4C for ; Thu, 15 Nov 2018 12:46:03 -0800 (PST) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 7902C130DD8 for ; Thu, 15 Nov 2018 12:46:03 -0800 (PST) Date: Thu, 15 Nov 2018 20:45:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542314755; bh=zTCh6d77Jum1EgXHnzVHmncHus7MYtHlVCDmyoQen6o=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=SG9OM1punD9MQIt9L808/C9MNjh0O1vMnBuz0UlHaYMPAdQr/+gI2QhJwGGuJUWGt 8H2G4tk7zFmCXR3b3O0kAkeXIJ91PPpOHVHsQlfn6PLUVYIrm7nvoMVruddSClu7Ce BvMerWU3r/Mb7PMBeGIGNgvSd5ND1Mi0Mu0yBpNU= To: azul From: Bart Butler Cc: "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <0a788c9c-cd3f-76df-4f65-754b0e08eb24@riseup.net> References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <875zx0n0j9.fsf@wheatstone.g10code.de> <87sh04km1x.fsf@wheatstone.g10code.de> <0a788c9c-cd3f-76df-4f65-754b0e08eb24@riseup.net> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------7b86c40b8f1f55e79518daf7040f0012"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 20:46:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------7b86c40b8f1f55e79518daf7040f0012 Content-Type: multipart/mixed; boundary="---------------------8ebfcaf0e14a58dc5470be41886df57f" -----------------------8ebfcaf0e14a58dc5470be41886df57f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, November 15, 2018 1:13 AM, azul wrote: > One downside I see is that the mechanism could be used to detect where > an email address routes to. In the case of azul+conf this may be easy to > guess. But for aliases users do not expect them to be linkable without > any interaction on their side. If they use a shared key for this purpose they are theoretically linkable = via fingerprint anyway. In the case of things like catch-all addresses, I = think this can be left up to the MTA to implement how they see fit. I thin= k in most cases for catch-all the destination address is not sensitive. -----------------------8ebfcaf0e14a58dc5470be41886df57f-- -----------------------7b86c40b8f1f55e79518daf7040f0012 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvt2vwJEJkFRGXvMx5EAAAOawEA5pf2hDN6jIpxxFTrHYDj aEkqcIoq1VJMNEPYho3f2dwA+wWVKsEayXjz8VWd0j8Wr3dJy74alzjbK500 kt9DzwkJ =tYH/ -----END PGP SIGNATURE----- -----------------------7b86c40b8f1f55e79518daf7040f0012-- From nobody Thu Nov 15 12:48:44 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A38130DE4 for ; Thu, 15 Nov 2018 12:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ_OTZNs_VPf for ; Thu, 15 Nov 2018 12:48:40 -0800 (PST) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 68148130DD8 for ; Thu, 15 Nov 2018 12:48:39 -0800 (PST) Date: Thu, 15 Nov 2018 20:48:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542314911; bh=/+38hvPTMDWjK5/TMz4wb4X03MTd53LZEhmfy16atRk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=HkpSIo1v7aiCO1/W7ohnrGpJV5jNAGmmpwK95b7Zb3+wl0ef9xOt4anvce/X5b4pC 8K4wc8eDjXXYRgguotcB+nhnge8Jur22ptA7wxxoZVBzpzBDaaDfspmmA0SDM0JM3c ZcaR2OuwhI8P9DTZIwyve9Ytu/AB8dswwmaa8x6A= To: Phil Pennock From: Bart Butler Cc: "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <20181115030305.GA14179@osmium.pennocktech.home.arpa> References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <20181115030305.GA14179@osmium.pennocktech.home.arpa> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------11b35418b84f386bae34a49cc5462d04"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 20:48:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------11b35418b84f386bae34a49cc5462d04 Content-Type: multipart/mixed; boundary="---------------------a7782e5940b5e210d1c21792b61ad0f5" -----------------------a7782e5940b5e210d1c21792b61ad0f5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Phil, You got it spot on, and were much more articulate than I was able to be de= spite multiple attempts. Thank you! Yes, all I want to do is relax that one sentence in the spec so that no Us= erID match, however that is defined, is required in terms of the key retur= ned by the WKD server. We can still require a valid UserID packet of cours= e. I also like leveraging HTTP cache control headers in the way you suggested= , though that can be discussed separately at a later date. -Bart Sent from ProtonMail, encrypted email based in Switzerland. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, November 14, 2018 7:03 PM, Phil Pennock wrote: > On 2018-11-14 at 10:26 -0500, Paul Wouters wrote: > > > On Tue, 13 Nov 2018, Bart Butler wrote: > > > > > So if I request from ProtonMail Bart.Butler@protonmail.com, I would = get a key back with bartbutler@protonmail.com, and the clients could then = prompt on unrecognized types of mismatches if desired because they would k= now that the server is returning the canonical form of the address. > > > > We went through this with OPENPGPKEY and SMIMEA. You will get the SMTP > > people blocking your draft when you try to interpret (or like above, > > even rewrite) addresses based on "common mail provider rewrites". Thei= r > > firm believe is only receiving SMTP servers can interpret email addres= ses. > > Bart isn't suggesting encoding common rewrites into OpenPGP, although I > believe that Werner might be. As an MTA maintainer, I think Bart's > suggestion is entirely appropriate and inline with the ethos of > federated SMTP. I'll proceed on the assumption that my analysis of > Bart's intent is correct. Bart, please correct me if wrong. > > In Bart's suggestion, the WKD server, run within the same autonomous > mail-system (or email administrative domain) as the SMTP servers, can > decide to map addresses and return a key suitable for use for that email > address. This does not change where the MUA should send email, but does > adjust how a well-integrated MUA might choose an appropriate OpenPGP key > for use for a given email address. > > This is entirely in line with the federated design and only the owner of > the systems at that location getting to make such decisions. There are > implications around caching, because such a rewrite becomes a long-term > commitment if it's to be stored as ancillary data in the keyring for > choosing the correct key. > > Thus if presented with a new address test+foo@spodhuis.org and needing > to get a key for it, with Bart's proposal, the MUA and the OpenPGP > client software can make no assumptions. It must not normalize anything > to the left of the '@' sign. But the MUA can use WKD and get back a key > for test@spodhuis.org; the software can then record a mapping of > test+foo@spodhuis.org -> test@spodhuis.org in OpenPGP recipient key > selection preferences. When later sending email to > test+foo@spodhuis.org, the SMTP transaction proceeds unmodified: the MUA > does not rewrite the recipient, you have to preserve the address > as-given. The remapped OpenPGP key selection proceeds as suggested > though. If sending email to test+bar@spodhuis.org then another WKD > lookup needs to be made. (Future work might look at protocols for > indicating patterns to avoid repeated lookups). > > Because server-side mapping decisions are being held elsewhere, and > because people do change PGP keys (in particular: security teams which > cycle their keys annually) this does suggest that the HTTP cache control > expiration headers might play into SHOULD controls on how the OpenPGP > client expires mappings and puts in place refresh checks. > > The spirit of Bart's proposal, as I read it, is a great fit for the > autonomy of mail administrative domains. > > -Phil > > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------a7782e5940b5e210d1c21792b61ad0f5-- -----------------------11b35418b84f386bae34a49cc5462d04 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvt25kJEJkFRGXvMx5EAACfQQD+IxLDk1LcLkW0xU4HaUXM kvSHFMh+3agawJBu3ief7mYBAPHoYOSIt2IW84Eds4QarBb1Mqo4w43JuTpI mIQwqIcP =Spaa -----END PGP SIGNATURE----- -----------------------11b35418b84f386bae34a49cc5462d04-- From nobody Thu Nov 15 12:49:27 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD21130DE4 for ; Thu, 15 Nov 2018 12:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTIpy1doFXsJ for ; Thu, 15 Nov 2018 12:49:23 -0800 (PST) Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (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 2467B130DD8 for ; Thu, 15 Nov 2018 12:49:23 -0800 (PST) Date: Thu, 15 Nov 2018 20:49:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542314955; bh=0lLENDs9Ufj4SVqihaFqzMh5ihqvuPsYsQ1VQbqBMhs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=jVc7vkVWWVw/nGDGo/sk+aAkNMwGiM1awsqtVD1nh4fbC1HltOQEgw7CBsNp/+Q5E sHFpjXYcuM4IU/VhgniThRb4Zj1ZrxD6Dc4s/qPPeGhWnT7k1czvmRJ+5dO/WvBUZW JM6FqJ2L9tM4Fl9w1Y7Z9hitmMqTzeI0ktTSjKbE= To: Benjamin Kaduk From: Bart Butler Cc: azul , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <20181115194235.GH70453@kduck.kaduk.org> References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <20181115030305.GA14179@osmium.pennocktech.home.arpa> <20181115045743.GE70453@kduck.kaduk.org> <20181115194235.GH70453@kduck.kaduk.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------bc3ef92795a195af892783d4e3f352ee"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 20:49:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------bc3ef92795a195af892783d4e3f352ee Content-Type: multipart/mixed; boundary="---------------------12b2af3fef8ab2e3bccc0e535ec11e27" -----------------------12b2af3fef8ab2e3bccc0e535ec11e27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, November 15, 2018 11:42 AM, Benjamin Kaduk wr= ote: > On Thu, Nov 15, 2018 at 10:16:55AM +0100, azul wrote: > > > Hi, > > > > > > Thus if presented with a new address test+foo@spodhuis.org and nee= ding > > > > to get a key for it, with Bart's proposal, the MUA and the OpenPGP > > > > client software can make no assumptions. It must not normalize any= thing > > > > to the left of the '@' sign. But the MUA can use WKD and get back = a key > > > > for test@spodhuis.org; the software can then record a mapping of > > > > test+foo@spodhuis.org -> test@spodhuis.org in OpenPGP recipient ke= y > > > > selection preferences. When later sending email to > > > > test+foo@spodhuis.org, the SMTP transaction proceeds unmodified: t= he MUA > > > > does not rewrite the recipient, you have to preserve the address > > > > as-given. The remapped OpenPGP key selection proceeds as suggested > > > > though. If sending email to test+bar@spodhuis.org then another WKD > > > > lookup needs to be made. (Future work might look at protocols for > > > > indicating patterns to avoid repeated lookups). > > > > I'm probably confused, but is this implying that WKD would insert = a new > > > > "lookup" operation such that a compromised WKD could cause me to e= ncrypt a > > > > message to an attacker-controlled key (with different UID) when I = am trying > > > > to encrypt to a non-attacker peer? > > > > As far as i understand the compromised WKD could easily send you > > > > an attacker controlled key with a valid UID as well. > > > > Why would the different UID make the attack any worse? > > It seems like there's a transparency difference --if the WKD gives me a > totally spoofed key (valid/expected UID but attacker-controlled key > material) then that key could/should be on the keyservers, and the actua= l > holder of that UID can notice it and take action. If I as the WKD consum= er > get wholly redirected to the attacker's real key/UID, the actual intende= d > recipient doesn't have any way to discover that there was an attack. > > -Ben The MUA could always have some kind of warning in this situation if the Us= erID match isn't recognized ("recognized" matches could include subaddress= es, etc. but would be at the MUA's discretion). I'd leave this up to the M= UA implementation. -Bart > > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------12b2af3fef8ab2e3bccc0e535ec11e27-- -----------------------bc3ef92795a195af892783d4e3f352ee Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvt28IJEJkFRGXvMx5EAAA9aQD+M6SV1+IF6osxXRRWLvqZ SP5XCCcocUC7uzTej8v7LogBANDTS35EnVat9cZMivuTZV3vJE5MmdhOy715 9tQCotoB =sZeh -----END PGP SIGNATURE----- -----------------------bc3ef92795a195af892783d4e3f352ee-- From nobody Thu Nov 15 23:03:25 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F574130DC2 for ; Thu, 15 Nov 2018 23:03:24 -0800 (PST) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UTNprLfd-UC for ; Thu, 15 Nov 2018 23:03:22 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 DE9B2124D68 for ; Thu, 15 Nov 2018 23:03:21 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42x8MW3cVbzKKd; Fri, 16 Nov 2018 08:03:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1542351799; bh=xfMgOrcaa3WP3cGNyTK/jsitLM9citygRe+9aEfwzDE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PBejookT8kJziBjMMmUAo8R5pDoRqz6QIy7D1CfIVnq8K2e+s4jDh5fse6anu0QcP 7PcjalPxeCcJdf1iVzUO70/B8o5j1X5rvfFSk93vtjrPGUneRbM6bfgTgph82U1jl1 TBJTTtcxnWWLgEBUhC1fjhuSGRv9cN54ysQqsj0U= 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 toM3J9x6ucp5; Fri, 16 Nov 2018 08:03:15 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 16 Nov 2018 08:03:15 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D12723A3788; Fri, 16 Nov 2018 02:03:14 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D12723A3788 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C25A841C3B26; Fri, 16 Nov 2018 02:03:14 -0500 (EST) Date: Fri, 16 Nov 2018 02:03:14 -0500 (EST) From: Paul Wouters To: Bart Butler cc: Benjamin Kaduk , "openpgp@ietf.org" , azul In-Reply-To: Message-ID: References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <20181115030305.GA14179@osmium.pennocktech.home.arpa> <20181115045743.GE70453@kduck.kaduk.org> <20181115194235.GH70453@kduck.kaduk.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 07:03:24 -0000 On Thu, 15 Nov 2018, Bart Butler wrote: > The MUA could always have some kind of warning in this situation if the UserID match isn't recognized ("recognized" matches could include subaddresses, etc. but would be at the MUA's discretion). I'd leave this up to the MUA implementation. Requiring the MUA to do this is wrong. It will break many potential use cases. Take for example my phone mail client. It is hard to support PGP, but it is easy to send it over TLS to my MTA. My MTA can then do all the work to PGP encrypt it. But there are no humans in this process. Please ensure this feature works without humans. Paul From nobody Fri Nov 16 09:10:47 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2FE130ED1 for ; Fri, 16 Nov 2018 09:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBuZaNQdm8-M for ; Fri, 16 Nov 2018 09:10:39 -0800 (PST) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (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 18EE6130E4C for ; Fri, 16 Nov 2018 09:10:09 -0800 (PST) Date: Fri, 16 Nov 2018 17:09:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542388201; bh=UKPVsA9kwmY5FVM/Exn335/3twHWHl2XHFBj47ElFt4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=BbG7zKutnmZ8CbBJGV8NCu/Y6LDyHzLge9iTAyDesaryr+2WF+ZL3ZtPe4guyeKCu qfotN1A5NyjA07ii9Zva0N0Vx6hh7zjJ0znjQnKENHNFjiD/6VppdNAqTpoP2bheP3 JUcHgALTIpRF7c9+zPtdG54b97SmPsoPePQKHW8s= To: Paul Wouters From: Bart Butler Cc: Benjamin Kaduk , "openpgp@ietf.org" , azul Reply-To: Bart Butler Message-ID: In-Reply-To: References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <20181115030305.GA14179@osmium.pennocktech.home.arpa> <20181115045743.GE70453@kduck.kaduk.org> <20181115194235.GH70453@kduck.kaduk.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------de676bbe012f3a643eafd20f6fe49331"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory I-D -07 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 17:10:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------de676bbe012f3a643eafd20f6fe49331 Content-Type: multipart/mixed; boundary="---------------------414b65050f606adbb517b77c4e13a431" -----------------------414b65050f606adbb517b77c4e13a431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, November 15, 2018 11:03 PM, Paul Wouters wro= te: > On Thu, 15 Nov 2018, Bart Butler wrote: > = > > The MUA could always have some kind of warning in this situation if th= e UserID match isn't recognized ("recognized" matches could include subadd= resses, etc. but would be at the MUA's discretion). I'd leave this up to t= he MUA implementation. > = > Requiring the MUA to do this is wrong. It will break many potential use > cases. Take for example my phone mail client. It is hard to support PGP, > but it is easy to send it over TLS to my MTA. My MTA can then do all > the work to PGP encrypt it. But there are no humans in this process. > = > Please ensure this feature works without humans. > = > Paul I'm not proposing that we require the MUA to do anything. All I'm saying i= s the the MUA could implement such validation if they want to, otherwise t= he key returned by WKD could just be used, and either way, we don't make a= ny sort of UserID email address matching part of the WKD spec that the ser= ver has to enforce. -Bart -----------------------414b65050f606adbb517b77c4e13a431-- -----------------------de676bbe012f3a643eafd20f6fe49331 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKABAFAlvu+eAJEJkFRGXvMx5EAACdjAD9HZnwXEKq2DmN8LO4GKQ2 WWZOznLaycENpvoojvTfZz4A+wSrALn5ffBs8uucuGLr/3AZC22XX0qb5/v9 5RaI/hgO =yHty -----END PGP SIGNATURE----- -----------------------de676bbe012f3a643eafd20f6fe49331-- From nobody Tue Nov 27 09:39:49 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F06128766 for ; Tue, 27 Nov 2018 09:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV4QDCoTbJrO for ; Tue, 27 Nov 2018 09:39:45 -0800 (PST) Received: from KOR01-SL2-obe.outbound.protection.outlook.com (mail-eopbgr1290082.outbound.protection.outlook.com [40.107.129.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15D8128A6E for ; Tue, 27 Nov 2018 09:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ovzvdYHLydl/WAaTYkviSsjm/5vGahN5oiFD1H7x1k=; b=OeIf/5Snx43TTljiNn0+lYx/D1wzaRJxtswFAofekun+Hssu8Ps1vcy3l2ScmHCybPAqjIqHW7J+1GVon3RmbSduTwmVvfrAeWN2CIRbqeliZrJVGcGWuG+VOC0Vyrtob8I9MWUZg5cj2GylrQUAZYaLQn44BUJINhl7Ua3n4RY= Received: from SL2PR01MB2955.apcprd01.prod.exchangelabs.com (10.174.127.83) by SL2PR01MB2746.apcprd01.prod.exchangelabs.com (20.177.180.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.16; Tue, 27 Nov 2018 17:39:39 +0000 Received: from SL2PR01MB2955.apcprd01.prod.exchangelabs.com ([fe80::7025:e964:e4c:f73]) by SL2PR01MB2955.apcprd01.prod.exchangelabs.com ([fe80::7025:e964:e4c:f73%2]) with mapi id 15.20.1361.019; Tue, 27 Nov 2018 17:39:39 +0000 From: Ronald Tse To: "openpgp@ietf.org" , Werner Koch Thread-Topic: rfc4880bis and draft-openpgp-iana-registry-updates-01 Thread-Index: AQHUau5gREidRDRyVkybXZt3x9+Nn6VkGnkA Date: Tue, 27 Nov 2018 17:39:38 +0000 Message-ID: References: <87y3aosju2.fsf@wheatstone.g10code.de> In-Reply-To: <87y3aosju2.fsf@wheatstone.g10code.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-originating-ip: [112.120.148.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SL2PR01MB2746; 6:YQNt8o46s/YNJAHK6/Rlxr5FcmKda9SymwkOja1Ew4Jo8IkSBseo6l7LOOPMZ1DEfGXMkqFUBkLUB7nzH3a0pQuHRG1m9t50rnVtuWBR3w45Sth4rN9MUJf8IWsz1HBcqek0KQ2kLR9iiZ/6w4zhuePwaCYp9I61a8ELtAZavCp3OWs4PeF+r0LNZJfdRw3jaWG8KMBEpVh1EptjLzNeScnJjKExynNW13L0zzgYKbSpSHu5OnA/jCwtjTGszgO/1jenybDb2Ajx2yJ964e8K6KcmZeE38zGo8dzbM6TYW0zxVvBlqkhLj+TnF4pwjMBAFmz2129Fz/iSRp2QEED4bVhctmZCY6DNRCsKU9RDZGU4z7Y1JYxvLxKOW0oNq1lr0RRMaXjVvBjxDmvFze9LqpmSJ3cPVBP0kSNE8CwWWmY056meozVRHYR7A3NGFySj9TIVmH4B8ai+BpKSkebfg==; 5:Lfic7c5fuqt2pPpUQlvBZbq9jzTkFPTjm9E3mf6PvAWeDqp/x+0L4O6k2K3r8ovJde3k2KNLB64bofIs221rRZpbFAKPsXd98FP02Yxb8lXNdmObverjp5F/oTlurmsqQ1PrDXhk9gzVjdWN5AgwwDNUxDELJ3WksUIUOxgD9JM=; 7:7tWCzet3nGBVney6mY+x2Z4cHAECyTlg5e5u1typ3xCmXcLxhJMXrfGn65X6T38ahdGFkIxrJnFjMEdsNL/h4gIYvR7Gd/vKvCIb8yXp5oHVyshyyLefa6ymWYzN22ZHwulJaTLN5+vIl88MAwKsaA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8580381d-9be9-4fc5-55df-08d6548f4e5a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SL2PR01MB2746; x-ms-traffictypediagnostic: SL2PR01MB2746: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231443)(944501410)(52105112)(10201501046)(93006095)(93001095)(3002001)(148016)(149066)(150057)(6041310)(20161123564045)(2016111802025)(20161123562045)(20161123558120)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:SL2PR01MB2746; BCL:0; PCL:0; RULEID:; SRVR:SL2PR01MB2746; x-forefront-prvs: 086943A159 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(39830400003)(346002)(396003)(199004)(189003)(53936002)(102836004)(2906002)(81166006)(81156014)(99286004)(6246003)(8676002)(3846002)(6116002)(25786009)(186003)(6506007)(86362001)(8936002)(26005)(316002)(2501003)(76176011)(6512007)(53546011)(15650500001)(68736007)(82746002)(508600001)(14444005)(256004)(105586002)(71190400001)(97736004)(71200400001)(83716004)(66066001)(36756003)(5660300001)(33656002)(106356001)(486006)(6486002)(2616005)(6436002)(14454004)(11346002)(446003)(229853002)(7736002)(305945005)(476003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:SL2PR01MB2746; H:SL2PR01MB2955.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Rhz7cGzsk3MwAB/Fmsay30jnba6buEs2uz4RykxcjYiX0quj/NYZwvd36/GYu8jMtysp+cZhelPmCKXaTT78uj8MIsuz5BVNtjj4Jkh/M/RdYiPfD7k1N++izrqg60X3+c57IGkMh/WMWH/fzeHMj8lSMUHJ5gB4IIhuDrSF/xNk2l96HEC1HAI2dm2GCzK3fnXome+gHAPoNbc7RUq4BdPfK99Eg3FrHl10Dt6cIL9hTW4z2LKQSzYIYUJzJSdYaQYrgtp7P8xvqRqZz9J8Z6BOp7LmG9XfmDdSl6QngCjITrDCEnkfQqh7sy/8/6Ksz0bskMg2WRtPT2+2i1bTaW+oadyVSQPPvgfTcKicFog= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5B8711FF32E390459F53008EE30E1B9E@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8580381d-9be9-4fc5-55df-08d6548f4e5a X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2018 17:39:38.9072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SL2PR01MB2746 Archived-At: Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 17:39:48 -0000 SGkgV2VybmVyLA0KDQpBcG9sb2dpZXMgZm9yIHRoZSBsYXRlIHJlc3BvbnNlIHRvIHRoaXMuIEkg ZnVsbHkgYWdyZWUgd2l0aCB5b3VyIGNvbmNsdWRpbmcgc3RhdGVtZW50czoNCg0KPiBJIGRvdWJ0 IHRoYXQgaXQgaXMgYWR2aXNhYmxlIHRvIG1lcmdlIHRoaXMgaW50byBSRkMtNDg4MGJpcyBiZWNh dXNlIHRoaXMNCj4gaXMgYSByZXF1ZXN0IGZvciBvbmUgdGltZSBhY3Rpb24gb2YgdGhlIElBTkEu ICANCg0KVGhlIElBTkEgcmVnaXN0cmllcyBvbmx5IHJlcXVpcmUgYSBvbmUtdGltZSBjaGFuZ2Us IGFuZCBwZXJoYXBzIG9uZS10aW1lIGNoYW5nZXMgYXJlIGJlc3Qgbm90IG1peGVkIHdpdGggNDg4 MGJpcyBiZWNhdXNlIDQ4ODBiaXMgc2hvdWxkIChwcm9iYWJseSkgYmUgYSBsb25nIGxpdmluZyBk b2N1bWVudCB0aGF0IGhlbHBzIHBlb3BsZSBpbXBsZW1lbnQgT3BlblBHUC4gTW9zdCBvZiB0aGVt IHNob3VsZCBub3QgYmUgY29uY2VybmVkIHdpdGggcmVnaXN0cnkgcG9saWN5IGNoYW5nZXMuDQoN Cj4gSG93ZXZlciBhIHJlcXVlc3QgdG8NCj4gY2hhbmdlIGZyb20gSUVURiBSRVZJRVcgdG8gU1BF Q0lGSUNBVElPTiBSRVFVSVJFRCBpcyBhbiBhY3R1YWwgYWN0aW9uIHdlDQo+IGxpa2UgdG8gc2Vl IGFuZCB0aGF0IHNob3VsZCBnbyBpbnRvIGEgbmV3IFJGQ3MuDQoNClRoZSBwb2ludCBpcyB0aGF0 IHRoZXJlIG5lZWRzIHRvIGJlIGEgcGxhY2UgdG86DQoNCjEuIERldGFpbCB0aGUgcmVnaXN0cnkg cG9saWNpZXMgYW5kIHByb2NlZHVyZXMgZm9yIE9wZW5QR1AuIFRoZXNlIHdlcmUgcHJldmlvdXNs eSBpbiBSRkMgNDg4MCAoYW5kIGN1cnJlbnRseSBpbiA0ODgwYmlzKS4NCjIuIERldGFpbCB0aGUg Y2hhbmdlcyB0byB0aGUgT3BlblBHUCBJQU5BIHJlZ2lzdHJpZXMgcmVxdWVzdGVkIGJ5IDQ4ODBi aXMgKHN1Y2ggYXMgdGhlIGFkZGl0aW9uIG9mIHRoZSBBRUFEIGFsZ29yaXRobSByZWdpc3RyeSkN CjMuIERldGFpbCB0aGUgb25lLXRpbWUgY2hhbmdlcyB0byBPcGVuUEdQIElBTkEgcmVnaXN0cnkg KGFzIGdpdmVuIGluIGRyYWZ0LW9wZW5wZ3AtaWFuYS1yZWdpc3RyeS11cGRhdGVzLTAxKQ0KDQpJ 4oCZZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCB3ZSBrZWVwIDQ4ODBiaXMgc3RyYWlnaHRmb3J3YXJk IHRvIHJlYWQgZm9yIHBlb3BsZSB3aG8gaW1wbGVtZW50IE9wZW5QR1AsIHJhdGhlciB0aGFuIGJ1 cmRlbmluZyB0aGVtIHdpdGggSUFOQSByZWdpc3RyYXRpb24gcHJvY2VkdXJlcyBhbmQgb25lLXRp bWUgY2hhbmdlcyB0byB0aGUgcmVnaXN0cmllcy4NCg0KU3BlY2lmaWNhbGx5LA0KDQphKSBBIG5l dyBkb2N1bWVudCBzaGFsbCBkZXRhaWwgb3V0IGFsbCBwb2xpY2llcyBhbmQgcHJvY2VkdXJlcyBm b3IgdGhlIE9wZW5QR1AgcmVnaXN0cmllcyBhdCBJQU5BLiBUaGlzIGlzIGVhc2lseSBkb25lIGJ5 IGV4dHJhY3RpbmcgY29udGVudCBvZiAjMSBhbmQgIzIgdG8gdGhpcyBuZXcgZG9jdW1lbnQsIHdo aWxlIGtlZXBpbmcgNDg4MGJpcyBhYm91dCB0aGUgcHJvdG9jb2wgaXRzZWxmLiBUaGlzIGRvY3Vt ZW50IHdpbGwgZm9ybSBhIHBhaXIgd2l0aCA0ODgwYmlzIG1vdmluZyBmb3J3YXJkLg0KYikgZHJh ZnQtb3BlbnBncC1pYW5hLXJlZ2lzdHJ5LXVwZGF0ZXMgd2lsbCBoYW5kbGUgdGhlIG9uZS10aW1l IGNoYW5nZXMgKCMzKQ0KDQpUaG91Z2h0cz8NCg0KS2luZCByZWdhcmRzLA0KUm9uDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUm9uYWxkIFRzZQ0KUmlib3NlIElu Yy4NCg0KDQo+IE9uIE9jdCAyNCwgMjAxOCwgYXQgMTI6MzQgQU0sIFdlcm5lciBLb2NoIDx3a0Bn bnVwZy5vcmc+IHdyb3RlOg0KPiANCj4gSGkhDQo+IA0KPiBUaGUgcmVjZW50bHkgZXhwaXJlZCBk cmFmdC1vcGVucGdwLWlhbmEtcmVnaXN0cnktdXBkYXRlcy0wMSBzcGVjaWZpZXMNCj4gb25lIG9m IHRoZSBnb2FscyBvZiB0aGUgV0cgdG8gbWFrZSB0aGUgYXNzaWdubWVudCBvZiBuZXcgaWRlbnRp ZmllciBldGMNCj4gZWFzaWVyLiAgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoaXMgZHJhZnRzIGNh biBiZSBpbnRlZ3JhdGVkIGludG8NCj4gUkZDLTQ4ODBiaXMgYnV0IHRoZSBJQU5BIENvbnNpZGVy YXRpb25zIHNlY3Rpb24gaW4gUkZDLTQ4ODBiaXMgbmVlZHMNCj4gYW55d2F5IGEgcmV3b3JrIGJl Y2F1c2UgdGhlIGRlbWFuZGVkIHJlZ2lzdHJpZXMgYXJlIGV4aXN0ZW50IGFuZCBvbmx5DQo+IG5l ZWQgdG8gbGlzdCBuZXcgaXRlbXMuIA0KPiANCj4gSSBhbSBub3Qgc3VyZSBob3cgdG8gZG8gdGhp cy4gIEZvciBleGFtcGxlIFJGQy00ODgwIHJlYWRzDQo+IA0KPiAtLTg8LS0tLS0tLS0tLS0tLS0t Y3V0IGhlcmUtLS0tLS0tLS0tLS0tLS1zdGFydC0tLS0tLS0tLS0tLS0+OC0tLQ0KPiAgMTAuMS4g IE5ldyBTdHJpbmctdG8tS2V5IFNwZWNpZmllciBUeXBlcw0KPiANCj4gICBPcGVuUEdQIFMySyBz cGVjaWZpZXJzIGNvbnRhaW4gYSBtZWNoYW5pc20gZm9yIG5ldyBhbGdvcml0aG1zIHRvIHR1cm4N Cj4gICBhIHN0cmluZyBpbnRvIGEga2V5LiAgVGhpcyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBy ZWdpc3RyeSBvZiBTMksNCj4gICBzcGVjaWZpZXIgdHlwZXMuICBUaGUgcmVnaXN0cnkgaW5jbHVk ZXMgdGhlIFMySyB0eXBlLCB0aGUgbmFtZSBvZiB0aGUNCj4gICBTMkssIGFuZCBhIHJlZmVyZW5j ZSB0byB0aGUgZGVmaW5pbmcgc3BlY2lmaWNhdGlvbi4gIFRoZSBpbml0aWFsDQo+ICAgdmFsdWVz IGZvciB0aGlzIHJlZ2lzdHJ5IGNhbiBiZSBmb3VuZCBpbiBTZWN0aW9uIDMuNy4xLiAgQWRkaW5n IGEgbmV3DQo+ICAgUzJLIHNwZWNpZmllciBNVVNUIGJlIGRvbmUgdGhyb3VnaCB0aGUgSUVURiBD T05TRU5TVVMgbWV0aG9kLCBhcw0KPiAgIGRlc2NyaWJlZCBpbiBbUkZDMjQzNF0uDQo+IC0tODwt LS0tLS0tLS0tLS0tLS1jdXQgaGVyZS0tLS0tLS0tLS0tLS0tLWVuZC0tLS0tLS0tLS0tLS0tLT44 LS0tDQo+IA0KPiBXaGF0IEkgZGlkIHVudGlsIG5vdyB3YXMgdG8gcmVwbGFjZSBSRkMgUkVWSUVX IChha2EgSUVURiBDT05TRU5TVVMpIGJ5DQo+IFNQRUNJRklDQVRJT04gUkVRVUlSRUQgYW5kIHRv IHJlZmVyZW5jZSBSRkMtODEyNi4gIFNlZSB0aGUgZ2l0bGFiDQo+IHJlcG8uIFRoZSBkcmFmdC1v cGVucGdwLWlhbmEtcmVnaXN0cnktdXBkYXRlcy0wMSBoYXMgdGhpcyB0ZXh0DQo+IA0KPiAtLTg8 LS0tLS0tLS0tLS0tLS0tY3V0IGhlcmUtLS0tLS0tLS0tLS0tLS1zdGFydC0tLS0tLS0tLS0tLS0+ OC0tLQ0KPiAgNS4xLiAgUEdQIFN0cmluZy10by1LZXkgKFMySykgUmVnaXN0cnkNCj4gDQo+ICAg UHJvcG9zZWQgY2hhbmdlcyB0byB0aGUgcmVnaXN0cnk6DQo+IA0KPiAgIG8gIFJlbmFtZSB0aGUg cmVnaXN0cnkgdG8gIk9wZW5QR1AgU3RyaW5nLXRvLUtleSAoUzJLKSBBbGdvcml0aG1zIg0KPiAN Cj4gICBvICBDaGFuZ2UgcmVnaXN0cnkgcG9saWN5IHRvICpTcGVjaWZpY2F0aW9uIFJlcXVpcmVk Ki4NCj4gDQo+ICAgbyAgVXBkYXRlIGl0cyAiUmVmZXJlbmNlIiB0byBhbHNvIHJlZmVyIHRvIHRo aXMgZG9jdW1lbnQuDQo+IA0KPiAgIG8gIEEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IGlzIHJl cXVpcmVkIHRvIHJlZ2lzdGVyIGFuIFMySw0KPiAgICAgIGFsZ29yaXRobSB3aXRoIHRoZSB2YWx1 ZSAiWWVzIiBpbiBhbnkgcmVjb21tZW5kYXRpb24uDQo+IA0KPiAgIEFkZCB0aGUgZm9sbG93aW5n IG5vdGU6DQo+IA0KPiAgIE5vdGU6IEV4cGVydHMgYXJlIHRvIHZlcmlmeSB0aGF0IHRoZSBwcm9w b3NlZCByZWdpc3RyYXRpb24NCj4gICBwcm92aWRlcyBhIHB1YmxpY2x5LWF2YWlsYWJsZSBzdGFu ZGFyZCB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZA0KPiAgIGluIGFuIGludGVyb3BlcmFibGUgd2F5 LCB3aXRoIG5vdGFibGUgYmVuZWZpdHMgZm9yIHRoZSB3aWRlcg0KPiAgIE9wZW5QR1AgY29tbXVu aXR5Lg0KPiANCj4gICBVcGRhdGUgdGhlIGZvbGxvd2luZyByZWdpc3RyYXRpb25zOg0KPiANCj4g ICArLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLSsNCj4gICB8IElEICAgICAgfCBTMksgVHlwZSAgICAgICAgICAgfCBSRUMt UyB8IFJFQy1JIHwgUmVmZXJlbmNlICAgICAgICAgIHwNCj4gICArLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gICB8 IDAgICAgICAgfCBTaW1wbGUgUzJLICAgICAgICAgfCBObyAgICB8IFllcyAgIHwgU2VjdGlvbiAz LjcuMS4xIG9mIHwNCj4gICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8 ICAgICAgIHwgW1JGQzQ4ODBdICAgICAgICAgIHwNCj4gICB8IDEgICAgICAgfCBTYWx0ZWQgUzJL ICAgICAgICAgfCBObyAgICB8IFllcyAgIHwgU2VjdGlvbiAzLjcuMS4yIG9mIHwNCj4gICB8ICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgIHwgW1JGQzQ4ODBdICAg ICAgICAgIHwNCj4gICB8IDIgICAgICAgfCBSZXNlcnZlZCAgICAgICAgICAgfCAgICAgICB8ICAg ICAgIHwgU2VjdGlvbiAzLjcuMSBvZiAgIHwNCj4gICB8ICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgfCAgICAgICB8ICAgICAgIHwgW1JGQzQ4ODBdICAgICAgICAgIHwNCj4gICB8IDMgICAg ICAgfCBJdGVyYXRlZCBhbmQgICAgICAgfCBZZXMgICB8IFllcyAgIHwgU2VjdGlvbiAzLjcuMS4z IG9mIHwNCj4gICB8ICAgICAgICAgfCBTYWx0ZWQgUzJLICAgICAgICAgfCAgICAgICB8ICAgICAg IHwgW1JGQzQ4ODBdICAgICAgICAgIHwNCj4gICB8IDQtOTkgICAgfCBVbmFzc2lnbmVkICAgICAg ICAgfCAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCj4gICB8IDEwMC0xMTAg fCBQcml2YXRlIG9yICAgICAgICAgfCAgICAgICB8ICAgICAgIHwgU2VjdGlvbiAzLjcuMSBvZiAg IHwNCj4gICB8ICAgICAgICAgfCBFeHBlcmltZW50YWwgVXNlICAgfCAgICAgICB8ICAgICAgIHwg W1JGQzQ4ODBdICAgICAgICAgIHwNCj4gICB8IDExMS0yNTUgfCBVbmFzc2lnbmVkICAgICAgICAg fCAgICAgICB8ICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCj4gICArLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tDQo+IC0t ODwtLS0tLS0tLS0tLS0tLS1jdXQgaGVyZS0tLS0tLS0tLS0tLS0tLWVuZC0tLS0tLS0tLS0tLS0t LT44LS0tDQo+IA0KPiBJIGRvdWJ0IHRoYXQgaXQgaXMgYWR2aXNhYmxlIHRvIG1lcmdlIHRoaXMg aW50byBSRkMtNDg4MGJpcyBiZWNhdXNlIHRoaXMNCj4gaXMgYSByZXF1ZXN0IGZvciBvbmUgdGlt ZSBhY3Rpb24gb2YgdGhlIElBTkEuICBIb3dldmVyIGEgcmVxdWVzdCB0bw0KPiBjaGFuZ2UgZnJv bSBJRVRGIFJFVklFVyB0byBTUEVDSUZJQ0FUSU9OIFJFUVVJUkVEIGlzIGFuIGFjdHVhbCBhY3Rp b24gd2UNCj4gbGlrZSB0byBzZWUgYW5kIHRoYXQgc2hvdWxkIGdvIGludG8gYSBuZXcgUkZDcy4N Cj4gDQo+IEFueSBoaW50cyBvbiBob3cgdG8gcHJvY2VlZD8NCj4gDQo+IA0KPiBTaGFsb20tU2Fs YW0sDQo+IA0KPiAgIFdlcm5lcg0KPiANCj4gDQo+IC0tIA0KPiBEaWUgR2VkYW5rZW4gc2luZCBm cmVpLiAgQXVzbmFobWVuIHJlZ2VsdCBlaW4gQnVuZGVzZ2VzZXR6Lg0KDQoNCg== From nobody Tue Nov 27 10:22:31 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9AC126CC7 for ; Tue, 27 Nov 2018 10:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i28EGiPQx28x for ; Tue, 27 Nov 2018 10:22:27 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 EB2BB1200B3 for ; Tue, 27 Nov 2018 10:22:26 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wARIDjFL026245; Tue, 27 Nov 2018 10:22:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=nUwT0JSwFYmWneaGUFPpdLU7/WACBgptIt94yE2M7Po=; b=C8UZVzVNPQ8lR980YjUdU9fYX9b+pxIygIjGsSP+yR5xEpKTAr1E2ocki5SEiZE8s0iG O/bLhI+xXKRUSSE66Ex87YDBJpnO2aFRSRJychoITi/eJl/QqDzBp/Sg29NG2yj2Ib25 W9Hl0US75wjQ9FOEhLgRlUAe+UAhMsdahK3dcK4Tz/W/noj+iXJy16y8MQvjur81dlgH mKwA2u64R73zNc5vPxOXirWD7oXBrQ/x8hcggt8UwjRLsZAu+PaTxS3RKK7YjIXPHLxx eLSBlHkr1V7MIbdwAlC7lFx0W/qM/JLC6VUKH7Of90Q4qDBx0JjQEjQubGeo7rD+zPKQ UQ== Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp0114.outbound.protection.outlook.com [216.32.181.114]) by mx0a-00273201.pphosted.com with ESMTP id 2p19twg65u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Nov 2018 10:22:24 -0800 Received: from BYAPR05CA0082.namprd05.prod.outlook.com (2603:10b6:a03:e0::23) by BL0PR05MB4883.namprd05.prod.outlook.com (2603:10b6:208:57::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.12; Tue, 27 Nov 2018 18:22:12 +0000 Received: from CO1NAM05FT047.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::208) by BYAPR05CA0082.outlook.office365.com (2603:10b6:a03:e0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1382.6 via Frontend Transport; Tue, 27 Nov 2018 18:22:12 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender) Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by CO1NAM05FT047.mail.protection.outlook.com (10.152.96.162) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.1382.7 via Frontend Transport; Tue, 27 Nov 2018 18:22:12 +0000 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 27 Nov 2018 10:22:10 -0800 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 27 Nov 2018 10:22:10 -0800 Received: from contrail-ubm16-mdb.svec1.juniper.net ([10.163.18.199]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id wARIM83Y005117; Tue, 27 Nov 2018 10:22:08 -0800 (envelope-from mdb@juniper.net) To: Ronald Tse CC: "openpgp@ietf.org" , Werner Koch In-Reply-To: References: <87y3aosju2.fsf@wheatstone.g10code.de> Comments: In-reply-to: Ronald Tse message dated "Tue, 27 Nov 2018 17:39:38 +0000." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14035.1543342928.1@contrail-ubm16-mdb.svec1.juniper.net> Date: Tue, 27 Nov 2018 10:22:08 -0800 Message-ID: <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.13; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(346002)(396003)(2980300002)(199004)(189003)(2906002)(26005)(478600001)(6246003)(53936002)(23726003)(47776003)(69596002)(229853002)(6916009)(81166006)(8936002)(68736007)(7696005)(5660300001)(8676002)(46406003)(97756001)(77096007)(305945005)(97876018)(126002)(50466002)(446003)(426003)(186003)(316002)(336012)(16586007)(476003)(11346002)(54906003)(486006)(76176011)(106466001)(105596002)(117636001)(356004)(81156014)(97736004)(6306002)(966005)(86362001)(4326008)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR05MB4883; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT047; 1:aFa59Cj8GCpruhXX1ffbh1D4VjPH7lHVMmVyGtBmrXb02BShLeq2GAq3vCWrcua+vhkGMHDZQG0ZHB0smpGGWfxKju7U9ONISlf711W9MkuWeQUpNjjMBRQHugjjIRb2 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0f7e3c68-1920-4992-7762-08d65495401f X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:BL0PR05MB4883; X-Microsoft-Exchange-Diagnostics: 1; BL0PR05MB4883; 3:Td/5dm4Q+KFC4Y45LPsGya4wloWHvG1yWvkhuEBywGuCAesacVlQcbsnfNCpuhGjrK4qHB/JCA0D72Pq+XXhI7eaRqfY+J39vVAedvtbzqjYxgkMZ63rrPuOuFvS7ZwgAMXmn7ixe34NiH5av7UNwxvIgbAzOFB7Nq9HBmpxKxtAs/q4tqSYLDSQ/UJws44WakEIkhpLoRoD4Eb1gPpEyOTZuj4jy4T72A0jW+SfC3fCqX1DMPTc1yEAIIFdfjT5vB/0prZhtE4Zk7O/hgaiUNBQh2okU4/XyrqmI2AmyVUjV1zXSH0sU7Czueei8YjjyDrcBZ/YzF53yJeALeR5pAF/NmN8z/xuqbjJP89JbkI=; 25:NojiW/yEDYrwEhJJbURU7dNJaICnB7JaEF3q2UVLsjBVV2HjkdpA+F8yVPthehFZwSGVeajELaUuanuGftIk9IDknUv5gzYveB3JQCyf+10oghBVcDpJd7dC6XLXomjVPffajGUgphjZfyoSL2jIhgjWQlVlEXU2Hy7609mk8kxBMWwlZQ0p1RiaF/PaWdxt0Vr2e/55A07iUFO8f7Qm9r0yOYZ3zyIvjkhhgYvO8VCwWnOrgGYLRuhivD8lV7ybG+x8Hle1925uIV+Wxks/D8WKGI2+5VraHQG0a5gHlxNamuQcKn7f4yL+NZddv6TeYs9+PxXbs8RbjPm3sxiZGQ== X-MS-TrafficTypeDiagnostic: BL0PR05MB4883: X-Microsoft-Exchange-Diagnostics: 1; BL0PR05MB4883; 31:inioHfhoc4Y6KJIhUwnmJLcO4+XiuXW81wzGHNXQFxy2eI4pYUzb+1hRq9SeRUkOtRl8rIHgkM39p60OZQdEFxNPAzy8XoBZo3F7d2M0zDJvoWdQUWmmqm1pwQ/EECPhArWacb0fknaNRIK592eevNdulo716/lMJCGEaA/ZmOYB4jKTUUUiRYZOuof+WFyR74IQwIDWJRVLqImzddkFsau4WJTXJGbMBhszlAT873g=; 20:hbs8Si4G/wz79nONKSyvlzD9a5YfMCI4W3W7aVHPGFVVdvT3XWS0p3y13RH4YyH23FwGbWS+VWe0JyTE7xWsqqyjue/T3hX9QVrsXgAET7UpkA7hPDoM1qqYyzSVcjIW6gIAUa7vvVmYxoF6+ODmf27z6iqQaG+0uR8AtS7p2GFVZCJmyLwAc8aXt1rgi2uND9IAZkEESHpzH1hUDlCm+oxjoTlhYvUffb7HdbuMQPeBNyzIZxZN7KMSWS7QMEriIgUxO6GheZrlFBQBrGUuUlXma+LfKUwnoZw4i7i01kESN4AKioNoXxn3VImHthpxy/C9ESGt/h0CwQLIOXTjIhwaqcwqT51XzRDxwBQN1wVoAPoHh28Ur2yAqmwIuT2rK/174drS4bZ7fBekXXlk4hc8BPQTjtPXzUtn7VlrN1oajPjyE8v2L4ge/Tctf4JTpw2KG+ug7Lah/ryKRAVOhrzRjMK4eewRPZtv8e6P0CE5jEeB8uy71VDqkiJVN3ee X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93003095)(3231443)(944501410)(52105112)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:BL0PR05MB4883; BCL:0; PCL:0; RULEID:; SRVR:BL0PR05MB4883; X-Microsoft-Exchange-Diagnostics: 1; BL0PR05MB4883; 4:lmjYmc2R0ChzuKPi02AvHWHf7pa5fiwb+MOJtPC4EonDcTwNu7HbgDOddwXYR8/Z4ancDn/Rv/xJiHMRVDruOAbuZowKR42YK1P7e9lOQpRGp4LQfzR5Dde4b44y8shjg2sjlHPs1ruuusCnrkTlKGFk2DJ4GO16zB5R+4L9fzsKLuv7nNmNwzHFVtVEgG4USgXenABdVEWGJkJJxdAGOhLK/IpqpjcrjSQPcsL/G6XAN/tuzhEWbzVB+pFVUmB3Ey3ebu/2TbEEGBy8uT/x0g== X-Forefront-PRVS: 086943A159 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL0PR05MB4883; 23:+3/KZVtYS0YWtaIYEHU2Mo6ZfFMJOLDemZkR6O5wG?= =?us-ascii?Q?KPnSgwhSBsg13ubELAFeCeKUER9i3Qd6oM1ypSyb93n20o3KBhL5KmR5/0iL?= =?us-ascii?Q?7km2wupjGMcegRL1VPH3vfXHLYjnoUP8ngXg1bw+CWdSJCuVrjDUdNuIa/Ld?= =?us-ascii?Q?szbFn0jNGEg3BnwpJlaCtCEdf329N9qpn5po5ljgQOHN1LBiTMlO/IAicahP?= =?us-ascii?Q?wscqZVrggxzny9nQwa7aXNdTdEC2mHyD81ZPAnVfAefQFdr99MgrQvJx4tJV?= =?us-ascii?Q?cpn5VHKCBe4GmC1m+HJQW9PLwkHwWDGVBoKQYCWP8NirW0T5WdTvJMU4AB9g?= =?us-ascii?Q?m6KYqaCoilwONZCrGgiIP/49FzYh61kAePgEtxkZp00smTQI+zDKmTifY2o3?= =?us-ascii?Q?/lxmHMTDZIfurX2fDuuTmsQ5vtJ9DzM7sHXsoxRelhVa8eycQpWQGzX2Cc/K?= =?us-ascii?Q?dS3Ju5A8jDXFOHSLOCjkIaeu0LN0gR7QLEF4KMOI59hqHRw4M5sk/9pk7tN0?= =?us-ascii?Q?tEExYZuugUumeSFfhRhorQPXKeEJRPVTB1kG1+0dcujp9c1ym/Dwzce36+A3?= =?us-ascii?Q?c3CLH9190Q/d9ID2whfFCQFmEV6FVCvywFiGNcpTr6HSvq0SBg31feA4goyq?= =?us-ascii?Q?hJKGlMe3CPtN1k4XGG799TGxGxo6slIOfUYrYuLyl1ycJDmFLUsT8PM+0aES?= =?us-ascii?Q?aCqXkXo9xES5DiYIp1lYVZa3arzKNt561kf5C05TWjRF3zHaQnYGjma9XQEY?= =?us-ascii?Q?mMrTbM4Z3RysFAJia1gS3pDREUMdShkEt5Nj5Mt2hukmvntEDPLaSlOb5y0p?= =?us-ascii?Q?NY+u30tA52179RYH7eJN4RSQELDq845irsraGs1Y0TTyG65PRUWzxJ36rOkg?= =?us-ascii?Q?zjSKEMBV/dgMQrHMEOaMaps4MS5lZ5nxg6hZzZaZ1HFQ+Mv+lOWwxAqS7sJ5?= =?us-ascii?Q?f8/IMKfHoiFT25Fh5BG6yN5FderQjtzOJ3ZI0s6cLiAVlg73k+QSJwJXQyyw?= =?us-ascii?Q?QWNyi9MR7kx62K1vL0H9DHsLvVbG5VgmffIreKP4VOv50dkKPdICTzNt/aWI?= =?us-ascii?Q?tU7eTH4zW6lacBhrS09+RmaOKHoYpcTHa/IwFRtJIlYya+asIU1tmrosfWoC?= =?us-ascii?Q?ukz0hOqLzMecA9qPotMUuQw/J8VWKrEaoa8pshCMy2TL4MNUD8izGtWjMBt4?= =?us-ascii?Q?4+9uVybN0O/Bqpiaack78I3GFQ/fzXLnmzb?= X-Microsoft-Antispam-Message-Info: iwalJq5BIGkKaqAWbbH5E5jLICcu156vwNGVeY05aiCrKQ1G7WA/I9rUTO0LRj6P+eefWfI/SRcsd5mnVVD44X6dlLxc4GPE/lR1E0ha7dEZEBA/N7B6Ee76DNA40GZ1oN7Y5FHSBZ9XkMwNV2JzJ/dC31eAag7y2UlQj72tjtmFSJADstepG4Br+baFssJk44dXC0MmSKksQfbA73FCvNHF3QcHi52lbLtsp9+Vc3X49IJS8wVaIKJcANyFbxubQHo+Jk1tOCHKlNlroBGzdtsLnz6gX3cLLGunT5pk2sP1XnIorfAdDVnOMM9XCxe4EWH+fvX2CpykbVI8ZVVLtXoDSZKMJ1BDwF3kVR8evo8= X-Microsoft-Exchange-Diagnostics: 1; BL0PR05MB4883; 6:48PXXCFaqWPXiFVO5j3zFtKBBdg7xuuFB0OBVD1yN0xbGxB3Flw1tIFH4/ohwfv8Xii2UbT1GIPwRtUBCfc1Hn8LJIa3pacdPxVeLD5q8BfjdLCEQ5Mrqyb7g691CNy10W3fVqX5CLNaAGqiCRjFpjtpJ6IqtS6SynDY8K0/OW5en5wGsBQMXgO0ctnZDD87Oto2EXT45cFxtX0ZKUGzpdD1Rs6Cud23tcozLsAqwxJvvwsa1PKKi8Y1jUyDs/IIyhBUzWZCYFQM7L78mnhX+OHOpym1ml80I0lMx3Z/AzNcr/yg6FnOMxEadg0tz2NiMuETzxauglyOsfvAhgkgIBGX1bDhSXGdwjwI+DnKUZrobRdXkCzh4XI19hdgRZDZsbtknTz2VRjsh4oEt+YnW1G6ynXUVmnmXK7VNHp1cUdcx+DN5Ra0eE7gbSwZv5PoLttnS6ebj3paGYJV3DCKrg==; 5:v7gl8ayEFlPS0+vXFkmcrj7V+lmMOC9c0uUsQB51N8lVZSqVSehTCi+rxQ2vt+1fF52AcRppgt2jExHixoguZR9XETb/Q/4F6WNrTjjaoqJY5Fv9Rtq/lmfoa/QwCrZ8vfD+IlaC+0n4dHloljxQ9gp1fokSjknsRIldrPjmVOQ=; 7:0YpZsxVDuja24oORQczASnLDOTvsiaMcy+JfOQA8vZby07ZG92nnRgMU/lEiaZ4ZSxmfIaJTUmwx86QsVwlLAAAJvI4LljRzDvqNFNOyFY44LHjEWs0JKY94EYNMQkiiMIZd96aCtvze9UMrH/J13A== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Nov 2018 18:22:12.0449 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f7e3c68-1920-4992-7762-08d65495401f X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13]; Helo=[P-EXFEND-EQX-02.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4883 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-27_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=555 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811270155 Archived-At: Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 18:22:31 -0000 fwiw: IANA has a document: https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml which is used to identify items for Pretty Good Privacy which includes the RFC 4880 defined numbers as well as a few assigned numbers that do not have an RFC 4880 reference. Not that even an IETF Draft *might* end up adding to the pgp-parameters file if the number used is used in enough implementtions along the way. Yes, it is best to use the IETF CONSENSUS method for new identifiers a la RFC2434, but an informational RFC may be used to define de facto standards that have arisen and may otherwise cause interoperability problems if not defined. Creating an RFC to add a new identifer to that IANA pgp-parameters.xhtml file is not hard and makes sense to do. There will be a published RFC4880 successor eventually. However, it will not be a living document. It will be given a particular RFC number nnnn and then there will probably eventually be an RFCnnnnbis document... etc. In addition, there is no real problem with coming up with new things to add to the pgp umbrella as very simple short RFCs. Enjoy! -- Mark From nobody Tue Nov 27 21:00:35 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B58130F3C for ; Tue, 27 Nov 2018 21:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-LhmyVR1fY3 for ; Tue, 27 Nov 2018 21:00:31 -0800 (PST) Received: from KOR01-PS2-obe.outbound.protection.outlook.com (mail-ps2kor01on0611.outbound.protection.outlook.com [IPv6:2a01:111:f400:fead::611]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E55130E77 for ; Tue, 27 Nov 2018 21:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5kAttqV2beI0lDZ9Ia/MPd9sXvBufkH7/IRpvf0kRyE=; b=qfvY3iM/6sP3Aan+EJUFRU1o1nKwc6I55E1RXRVv5SmYITOhSargHpuhrR5eHB54cq98BW3Gi9vmgmg5tsvnctj2tjOb27H9cpYWrb8AcsRLm2Lash1GTkzEsD6G8F9P7N6+6/aMSJTAFB2zfpSC4mnFOje95G3qZiKjpA3kwwA= Received: from SL2PR01MB2955.apcprd01.prod.exchangelabs.com (10.174.127.83) by SL2PR01MB3258.apcprd01.prod.exchangelabs.com (20.178.162.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.16; Wed, 28 Nov 2018 05:00:25 +0000 Received: from SL2PR01MB2955.apcprd01.prod.exchangelabs.com ([fe80::7025:e964:e4c:f73]) by SL2PR01MB2955.apcprd01.prod.exchangelabs.com ([fe80::7025:e964:e4c:f73%2]) with mapi id 15.20.1361.019; Wed, 28 Nov 2018 05:00:25 +0000 From: Ronald Tse To: "openpgp@ietf.org" , "Mark D. Baushke" CC: Werner Koch Thread-Topic: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 Thread-Index: AQHUau5gREidRDRyVkybXZt3x9+Nn6VkGnkAgAAL4ACAALJSAA== Date: Wed, 28 Nov 2018 05:00:25 +0000 Message-ID: References: <87y3aosju2.fsf@wheatstone.g10code.de> <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> In-Reply-To: <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-originating-ip: [118.140.121.70] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SL2PR01MB3258; 6:3Rr/rxpPpVe1OZif7foA+o5ZQQOWBIJpMRG3po570yt+pXbdCY8dAEFfHt25j0ApXteSpyKmtwsgNDlsGf+45PTSNQOrHqLttbpdrnRK5IpgiyHb2EJftnaToTJflRuLyenb547sC3TBDhdwJsB4qCmUzL2jx8SvtD3jUQ6HpecT8+TiQFGGDnQ6OexZ/ARKyb+GmILj0g5yjxrEpTeRsOKKag7XrQ5MB1/E2sKBRZCqzxf3MUhLiTdoP7XSiL1aFP+eICE1pMqJNB7Jso0xS/AJIHnw0WKd5P+VOWzHdb4FNDG2VtzKJw9EdNoNQON5/omtcM9yvgFMimRTMnTiHLbsVlatgK/QwoZik2/Jr9y8psJQHBD6ETajTla03OSLBRvpoZW+pi+AAbH204ZBMErA1LRKb7M3CKq3VSqDxFr0TU4qkeArH23aGso2/3f6xXt+2kiCwIvwci/DWcmqUA==; 5:ov1NvyHaWj7QtPRXD5Icnup5DsB3/HKAEUxge9JtMo0KxnrwEHjPWKpObI7YWi0r38SJbU6iVhx7agzGK6IPcnz2jg7LtDGlRxbsI8xAmuTDPmxwtYHhBphTsyqBdI69w8CGT2U17zOqg+HFu1+CFpiFG3QDU6dXuhl7937HhZI=; 7:YJ/yAww+YwYuwfIwsG0xzk01hBUbCL/U66kO0JLTrY01a5mLKCloT0kofM+okq1CE5YFnW3M5MYo4J5if8435HOK+AH+akdb97cjyXImUdwX0HffkdQf2i9re1MCO2moA5tDmrZ7lxNhMw0uyB3u0A== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c72904ff-5e4c-49fb-f13d-08d654ee68c9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:SL2PR01MB3258; x-ms-traffictypediagnostic: SL2PR01MB3258: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231443)(944501410)(52105112)(10201501046)(3002001)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:SL2PR01MB3258; BCL:0; PCL:0; RULEID:; SRVR:SL2PR01MB3258; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(396003)(136003)(366004)(346002)(376002)(199004)(189003)(2906002)(508600001)(6116002)(54896002)(7736002)(99286004)(3846002)(105586002)(110136005)(97736004)(14444005)(256004)(106356001)(229853002)(102836004)(6246003)(6306002)(186003)(25786009)(236005)(83716004)(6512007)(316002)(71190400001)(71200400001)(33656002)(53936002)(2501003)(26005)(5660300001)(82746002)(6486002)(81166006)(81156014)(486006)(446003)(14454004)(606006)(8936002)(15650500001)(6506007)(4326008)(11346002)(2616005)(36756003)(53546011)(6436002)(476003)(966005)(1941001)(66066001)(76176011)(68736007)(86362001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:SL2PR01MB3258; H:SL2PR01MB2955.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: jpyPUE7oWnAbHKhR+uyhgoqe+gYUH9XK54zFlnOxIy8anLrPQz10/t6k9AERTVJwkdSQRHVcPwqtH4KpCUpivYKNmPvmtcnJI4HQ9CmLMc2ulUgzTPgFnvG+04ZV6zP8bzECVXbkMhOj8sgQGmAo2ivvioPB29fJI+Wdei+Ze9HL6UUV+5wUhq12ahoiOw6CzIXbScQhLjJg2vTFhmNDp3T8fhwFC5oUmDTGr3ApgnGsBtdF8wz6ZpGdmdPg6d5hqHlI2TMzvkF1gO59rU2B47hMUMuQjI+gCZINHOxAtE5xjmjw+r3bq2YF6IRgLGP2VmjSvgOVrID0QJkn5aHYKosJi1FBsSYn/9k0CTe2Lrs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B6F2B98AE9604189A579E29916079904ribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: c72904ff-5e4c-49fb-f13d-08d654ee68c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 05:00:25.4174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SL2PR01MB3258 Archived-At: Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 05:00:34 -0000 --_000_B6F2B98AE9604189A579E29916079904ribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KWW914oCZcmUgcmlnaHQuIElBTkEgaGFzIGEgcGFnZSBvZiBhbGwg4oCcUHJl dHR5IEdvb2QgUHJpdmFjeeKAnSByZWdpc3RyaWVzLCBidXQgZXZlbiB0aGUgbmFtZSBvZiB0aGF0 IGlzIG91dGRhdGVkIGFuZCBzaG91bGQgcmVmbGVjdCDigJxPcGVuUEdQ4oCdIGluc3RlYWQuDQoN ClRoZSBpbnRlbnRpb24gb2YgImRyYWZ0LW9wZW5wZ3AtaWFuYS1yZWdpc3RyeS11cGRhdGVz4oCd IHdhcyB0byBwZXJmb3JtIGEgb25lLXRpbWUgY2hhbmdlIGZvciB0aGUgd2hvbGUgc2V0IG9mIE9w ZW5QR1AgcmVnaXN0cmllcywgdG8gZ2V0IHRoZW0gdXAtdG8tZGF0ZSBhbmQgdG8gYnJpbmcgdGhl bSBpbmxpbmUgd2l0aCBkZXNpcmVkIHBvbGljaWVzIGFuZCBwcmFjdGljZXMuIEluIG9yZGVyIHRv IGRvIHNvIChmb3IgSUFOQSB0byB0YWtlIGFjdGlvbiBpbiBtb2RpZnlpbmcgdGhlIHJlZ2lzdHJ5 IG1ldGFkYXRhKSwgdGhpcyBkb2N1bWVudCBuZWVkcyB0byBiZSBwdWJsaXNoZWQgYXMgYW4gUkZD Lg0KDQpUaGUgcXVlc3Rpb24gcmFpc2VkIGJ5IFdlcm5lciAoYXMgSSB1bmRlcnN0b29kIGl0KSB3 YXMgbW9yZSBhYm91dCBob3cgdG8gYWxpZ24gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgZ2l2ZW4g aW4gNDg4MGJpcyB3aXRoIHRoaXMgZG9jdW1lbnQsIGFuZCB3aGV0aGVyIHRvIG1lcmdlIHRoZSBz YWlkIGRvY3VtZW50IGludG8gNDg4MGJpcy4gRm9yIHRoZSBpbnRlbmRlZCBhdWRpZW5jZSBvZiA0 ODgwYmlzLCBpdCBzZWVtcyBwcmVmZXJhYmxlIHRvIGtlZXAgb25lLXRpbWUgY2hhbmdlcyBpbiAi ZHJhZnQtb3BlbnBncC1pYW5hLXJlZ2lzdHJ5LXVwZGF0ZXPigJ0gKHN1Y2ggYXMgcmVnaXN0cnkg cG9saWN5IHVwZGF0ZXMsIHJlbmFtaW5nLCBldGMpLCBhbmQgbGV0IDQ4ODBiaXMgYmUgYSBkb2N1 bWVudCB0YXJnZXRlZCBmb3IgdGhlIGF1ZGllbmNlIG9mIGltcGxlbWVudGVycy4NCg0KSW5kZWVk IDQ4ODAgd2lsbCBoYXZlIGEgc3VjY2Vzc29yLCB0aGF0IGlzIG5vdCBhIOKAnHN0YW5kaW5nIGRv Y3VtZW504oCdIHRoYXQgaXMgcGVybWFuZW50bHkgYWN0aXZlLiBJdCBpcyBpbnNvZmFyIOKAnGxp dmluZyIsIGhvd2V2ZXIsIGNvbnNpZGVyaW5nIHRoZSB5ZWFycyBpdCB0b29rIGZvciA0ODgwIHRv IGJlIHJldmlzZWQg4oCUIDQ4ODBiaXMgd2lsbCBwcm9iYWJseSBiZSBhY3RpdmUgZm9yIGEgbG9u ZyB0aW1lIGJlZm9yZSBSRkNubm5uYmlzIGFwcGVhcnMgOi0pDQoNCkFuZCBmdWxseSBhZ3JlZSB3 aXRoIGFsbG93aW5nIHNpbXBsZSBzaG9ydCBSRkNzIHRvIGFkZCB0byB0aGUgUEdQIHVtYnJlbGxh Lg0KDQpSb24NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpSb25h bGQgVHNlDQpSaWJvc2UgSW5jLg0KDQpPbiBOb3YgMjgsIDIwMTgsIGF0IDI6MjIgQU0sIE1hcmsg RC4gQmF1c2hrZSA8bWRiQGp1bmlwZXIubmV0PG1haWx0bzptZGJAanVuaXBlci5uZXQ+PiB3cm90 ZToNCg0KZndpdzogSUFOQSBoYXMgYSBkb2N1bWVudDoNCg0KaHR0cHM6Ly93d3cuaWFuYS5vcmcv YXNzaWdubWVudHMvcGdwLXBhcmFtZXRlcnMvcGdwLXBhcmFtZXRlcnMueGh0bWwNCg0Kd2hpY2gg aXMgdXNlZCB0byBpZGVudGlmeSBpdGVtcyBmb3IgUHJldHR5IEdvb2QgUHJpdmFjeSB3aGljaCBp bmNsdWRlcw0KdGhlIFJGQyA0ODgwIGRlZmluZWQgbnVtYmVycyBhcyB3ZWxsIGFzIGEgZmV3IGFz c2lnbmVkIG51bWJlcnMgdGhhdCBkbw0Kbm90IGhhdmUgYW4gUkZDIDQ4ODAgcmVmZXJlbmNlLg0K DQpOb3QgdGhhdCBldmVuIGFuIElFVEYgRHJhZnQgKm1pZ2h0KiBlbmQgdXAgYWRkaW5nIHRvIHRo ZSBwZ3AtcGFyYW1ldGVycw0KZmlsZSBpZiB0aGUgbnVtYmVyIHVzZWQgaXMgdXNlZCBpbiBlbm91 Z2ggaW1wbGVtZW50dGlvbnMgYWxvbmcgdGhlIHdheS4NClllcywgaXQgaXMgYmVzdCB0byB1c2Ug dGhlIElFVEYgQ09OU0VOU1VTIG1ldGhvZCBmb3IgbmV3IGlkZW50aWZpZXJzIGENCmxhIFJGQzI0 MzQsIGJ1dCBhbiBpbmZvcm1hdGlvbmFsIFJGQyBtYXkgYmUgdXNlZCB0byBkZWZpbmUgZGUgZmFj dG8NCnN0YW5kYXJkcyB0aGF0IGhhdmUgYXJpc2VuIGFuZCBtYXkgb3RoZXJ3aXNlIGNhdXNlIGlu dGVyb3BlcmFiaWxpdHkNCnByb2JsZW1zIGlmIG5vdCBkZWZpbmVkLg0KDQpDcmVhdGluZyBhbiBS RkMgdG8gYWRkIGEgbmV3IGlkZW50aWZlciB0byB0aGF0IElBTkEgcGdwLXBhcmFtZXRlcnMueGh0 bWwNCmZpbGUgaXMgbm90IGhhcmQgYW5kIG1ha2VzIHNlbnNlIHRvIGRvLg0KDQpUaGVyZSB3aWxs IGJlIGEgcHVibGlzaGVkIFJGQzQ4ODAgc3VjY2Vzc29yIGV2ZW50dWFsbHkuIEhvd2V2ZXIsIGl0 IHdpbGwNCm5vdCBiZSBhIGxpdmluZyBkb2N1bWVudC4gSXQgd2lsbCBiZSBnaXZlbiBhIHBhcnRp Y3VsYXIgUkZDIG51bWJlciBubm5uDQphbmQgdGhlbiB0aGVyZSB3aWxsIHByb2JhYmx5IGV2ZW50 dWFsbHkgYmUgYW4gUkZDbm5ubmJpcyBkb2N1bWVudC4uLiBldGMuDQoNCkluIGFkZGl0aW9uLCB0 aGVyZSBpcyBubyByZWFsIHByb2JsZW0gd2l0aCBjb21pbmcgdXAgd2l0aCBuZXcgdGhpbmdzIHRv DQphZGQgdG8gdGhlIHBncCB1bWJyZWxsYSBhcyB2ZXJ5IHNpbXBsZSBzaG9ydCBSRkNzLg0KDQpF bmpveSENCi0tIE1hcmsNCg0K --_000_B6F2B98AE9604189A579E29916079904ribosecom_ Content-Type: text/html; charset="utf-8" Content-ID: <3052F4EA2D688E479195DF973D754F60@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIE1hcmssDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Zb3XigJlyZSByaWdodC4gSUFOQSBoYXMg YSBwYWdlIG9mIGFsbCDigJxQcmV0dHkgR29vZCBQcml2YWN54oCdIHJlZ2lzdHJpZXMsIGJ1dCBl dmVuIHRoZSBuYW1lIG9mIHRoYXQgaXMgb3V0ZGF0ZWQgYW5kIHNob3VsZCByZWZsZWN0IOKAnE9w ZW5QR1DigJ0gaW5zdGVhZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBpbnRlbnRpb24gb2YgJnF1b3Q7ZHJhZnQtb3BlbnBncC1p YW5hLXJlZ2lzdHJ5LXVwZGF0ZXPigJ0gd2FzIHRvIHBlcmZvcm0gYSBvbmUtdGltZSBjaGFuZ2Ug Zm9yIHRoZSB3aG9sZSBzZXQgb2YgT3BlblBHUCByZWdpc3RyaWVzLCB0byBnZXQgdGhlbSB1cC10 by1kYXRlIGFuZCB0byBicmluZyB0aGVtIGlubGluZSB3aXRoIGRlc2lyZWQgcG9saWNpZXMgYW5k IHByYWN0aWNlcy4gSW4gb3JkZXIgdG8gZG8gc28gKGZvciBJQU5BIHRvDQogdGFrZSBhY3Rpb24g aW4gbW9kaWZ5aW5nIHRoZSByZWdpc3RyeSBtZXRhZGF0YSksIHRoaXMgZG9jdW1lbnQgbmVlZHMg dG8gYmUgcHVibGlzaGVkIGFzIGFuIFJGQy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBxdWVzdGlvbiByYWlzZWQgYnkgV2VybmVy IChhcyBJIHVuZGVyc3Rvb2QgaXQpIHdhcyBtb3JlIGFib3V0IGhvdyB0byBhbGlnbiB0aGUgSUFO QSBjb25zaWRlcmF0aW9ucyBnaXZlbiBpbiA0ODgwYmlzIHdpdGggdGhpcyBkb2N1bWVudCwgYW5k IHdoZXRoZXIgdG8gbWVyZ2UgdGhlIHNhaWQgZG9jdW1lbnQgaW50byA0ODgwYmlzLiBGb3IgdGhl IGludGVuZGVkIGF1ZGllbmNlIG9mIDQ4ODBiaXMsIGl0IHNlZW1zIHByZWZlcmFibGUNCiB0byBr ZWVwIG9uZS10aW1lIGNoYW5nZXMgaW4gJnF1b3Q7ZHJhZnQtb3BlbnBncC1pYW5hLXJlZ2lzdHJ5 LXVwZGF0ZXPigJ0gKHN1Y2ggYXMgcmVnaXN0cnkgcG9saWN5IHVwZGF0ZXMsIHJlbmFtaW5nLCBl dGMpLCBhbmQgbGV0IDQ4ODBiaXMgYmUgYSBkb2N1bWVudCB0YXJnZXRlZCBmb3IgdGhlIGF1ZGll bmNlIG9mIGltcGxlbWVudGVycy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluZGVlZCA0ODgwIHdpbGwgaGF2ZSBhIHN1Y2Nlc3Nvciwg dGhhdCBpcyBub3QgYSDigJxzdGFuZGluZyBkb2N1bWVudOKAnSB0aGF0IGlzIHBlcm1hbmVudGx5 IGFjdGl2ZS4gSXQgaXMgaW5zb2ZhciDigJxsaXZpbmcmcXVvdDssIGhvd2V2ZXIsIGNvbnNpZGVy aW5nIHRoZSB5ZWFycyBpdCB0b29rIGZvciA0ODgwIHRvIGJlIHJldmlzZWQg4oCUIDQ4ODBiaXMg d2lsbCBwcm9iYWJseSBiZSBhY3RpdmUgZm9yIGEgbG9uZyB0aW1lIGJlZm9yZSBSRkNubm5uYmlz DQogYXBwZWFycyA6LSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkFuZCBmdWxseSBhZ3JlZSB3aXRoIGFsbG93aW5nIHNpbXBsZSBzaG9y dCBSRkNzIHRvIGFkZCB0byB0aGUgUEdQIHVtYnJlbGxhLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Um9uPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBj bGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpSb25hbGQgVHNlPGJyIGNsYXNzPSIiPg0KUmlib3NlIEluYy48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBOb3YgMjgsIDIw MTgsIGF0IDI6MjIgQU0sIE1hcmsgRC4gQmF1c2hrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1kYkBq dW5pcGVyLm5ldCIgY2xhc3M9IiI+bWRiQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+ZndpdzogSUFOQSBoYXMgYSBkb2N1bWVudDo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9w Z3AtcGFyYW1ldGVycy9wZ3AtcGFyYW1ldGVycy54aHRtbCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu aWFuYS5vcmcvYXNzaWdubWVudHMvcGdwLXBhcmFtZXRlcnMvcGdwLXBhcmFtZXRlcnMueGh0bWw8 L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0Kd2hpY2ggaXMgdXNlZCB0byBpZGVudGlm eSBpdGVtcyBmb3IgUHJldHR5IEdvb2QgUHJpdmFjeSB3aGljaCBpbmNsdWRlczxiciBjbGFzcz0i Ij4NCnRoZSBSRkMgNDg4MCBkZWZpbmVkIG51bWJlcnMgYXMgd2VsbCBhcyBhIGZldyBhc3NpZ25l ZCBudW1iZXJzIHRoYXQgZG88YnIgY2xhc3M9IiI+DQpub3QgaGF2ZSBhbiBSRkMgNDg4MCByZWZl cmVuY2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTm90IHRoYXQgZXZlbiBhbiBJRVRG IERyYWZ0ICptaWdodCogZW5kIHVwIGFkZGluZyB0byB0aGUgcGdwLXBhcmFtZXRlcnM8YnIgY2xh c3M9IiI+DQpmaWxlIGlmIHRoZSBudW1iZXIgdXNlZCBpcyB1c2VkIGluIGVub3VnaCBpbXBsZW1l bnR0aW9ucyBhbG9uZyB0aGUgd2F5LjxiciBjbGFzcz0iIj4NClllcywgaXQgaXMgYmVzdCB0byB1 c2UgdGhlIElFVEYgQ09OU0VOU1VTIG1ldGhvZCBmb3IgbmV3IGlkZW50aWZpZXJzIGE8YnIgY2xh c3M9IiI+DQpsYSBSRkMyNDM0LCBidXQgYW4gaW5mb3JtYXRpb25hbCBSRkMgbWF5IGJlIHVzZWQg dG8gZGVmaW5lIGRlIGZhY3RvPGJyIGNsYXNzPSIiPg0Kc3RhbmRhcmRzIHRoYXQgaGF2ZSBhcmlz ZW4gYW5kIG1heSBvdGhlcndpc2UgY2F1c2UgaW50ZXJvcGVyYWJpbGl0eTxiciBjbGFzcz0iIj4N CnByb2JsZW1zIGlmIG5vdCBkZWZpbmVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNy ZWF0aW5nIGFuIFJGQyB0byBhZGQgYSBuZXcgaWRlbnRpZmVyIHRvIHRoYXQgSUFOQSBwZ3AtcGFy YW1ldGVycy54aHRtbDxiciBjbGFzcz0iIj4NCmZpbGUgaXMgbm90IGhhcmQgYW5kIG1ha2VzIHNl bnNlIHRvIGRvLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZXJlIHdpbGwgYmUgYSBw dWJsaXNoZWQgUkZDNDg4MCBzdWNjZXNzb3IgZXZlbnR1YWxseS4gSG93ZXZlciwgaXQgd2lsbDxi ciBjbGFzcz0iIj4NCm5vdCBiZSBhIGxpdmluZyBkb2N1bWVudC4gSXQgd2lsbCBiZSBnaXZlbiBh IHBhcnRpY3VsYXIgUkZDIG51bWJlciBubm5uPGJyIGNsYXNzPSIiPg0KYW5kIHRoZW4gdGhlcmUg d2lsbCBwcm9iYWJseSBldmVudHVhbGx5IGJlIGFuIFJGQ25ubm5iaXMgZG9jdW1lbnQuLi4gZXRj LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkluIGFkZGl0aW9uLCB0aGVyZSBpcyBubyBy ZWFsIHByb2JsZW0gd2l0aCBjb21pbmcgdXAgd2l0aCBuZXcgdGhpbmdzIHRvPGJyIGNsYXNzPSIi Pg0KYWRkIHRvIHRoZSBwZ3AgdW1icmVsbGEgYXMgdmVyeSBzaW1wbGUgc2hvcnQgUkZDcy4gPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RW5qb3khPGJyIGNsYXNzPSIiPg0KPHNwYW4g Y2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LS0g TWFyazxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B6F2B98AE9604189A579E29916079904ribosecom_-- From nobody Tue Nov 27 23:40:15 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9E6130DEC for ; Tue, 27 Nov 2018 23:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LQNcaUJ2Mbn for ; Tue, 27 Nov 2018 23:40:11 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 212FB130DE8 for ; Tue, 27 Nov 2018 23:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=EQZVUB1vLKnaRglalBsiblgTVZWVO0Aa4CJFfc3lcwg=; b=IynrI/7vDVomcqeH4aj+erntjs a3nZpOLpCCpekTFuUpxseDxlOhArKAt0pAMOWa61Yv7IfmwbR2onwBDUQ2GWsTuaSYpTu1zJIMfNO 17Z6mVHC02Ouz7Om7NXq7bMCRblhFio/FO4KvFUPfeJHnOleNWmP4roRWbEiQ2O9XmLE=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gRuS8-00065n-TS for ; Wed, 28 Nov 2018 08:40:08 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gRuRq-0005o2-Es; Wed, 28 Nov 2018 08:39:50 +0100 From: Werner Koch To: Ronald Tse Cc: "openpgp\@ietf.org" , "Mark D. Baushke" References: <87y3aosju2.fsf@wheatstone.g10code.de> <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Ronald Tse , "openpgp\@ietf.org" , "Mark D. Baushke" Date: Wed, 28 Nov 2018 08:39:44 +0100 In-Reply-To: (Ronald Tse's message of "Wed, 28 Nov 2018 05:00:25 +0000") Message-ID: <875zwhvef3.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=S_Key_afsatcom_New_World_Order_JFK_Fedayeen_Chobetsu_virus_ANC_hacke"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 07:40:13 -0000 --=S_Key_afsatcom_New_World_Order_JFK_Fedayeen_Chobetsu_virus_ANC_hacke Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 28 Nov 2018 06:00, tse@ribose.com said: > The question raised by Werner (as I understood it) was more about how > to align the IANA considerations given in 4880bis with this document, > and whether to merge the said document into 4880bis. For the intended Right. I am not sure what is the right procedure here. Are the tables with the various ids in rfc4880bis normative or are the informational and the IANA registry is the normative reference for them. For practical point of view I would like to have the tables in rfc4880bis to be normative with the note that the IANA registry defines updates to these tables. I agree with Ron that the procedures on how to update the IANA registries do not belong into rfc4880bis. We need some advice from IETF procedures experienced people (or a pointer to an RFC describing these procedures). Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=S_Key_afsatcom_New_World_Order_JFK_Fedayeen_Chobetsu_virus_ANC_hacke Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW/5GQAAKCRD/gK6dHew1 jSncAQC1RMdEJTSY8tUhcZvhmdwKXvxe6iK8Dm4zS8x0xKqFagD/X3Kpc93J9mWM 5N+2jY2aCkyQO2ruJAYXXCaZ/VluSQ0= =P0VU -----END PGP SIGNATURE----- --=S_Key_afsatcom_New_World_Order_JFK_Fedayeen_Chobetsu_virus_ANC_hacke-- From nobody Wed Nov 28 10:09:47 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1927130E8B for ; Wed, 28 Nov 2018 10:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0mUhTN7yoGa for ; Wed, 28 Nov 2018 10:09:44 -0800 (PST) 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 3D44E130E27 for ; Wed, 28 Nov 2018 10:09:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 27910E2046; Wed, 28 Nov 2018 13:09:12 -0500 (EST) 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 21453-05; Wed, 28 Nov 2018 13:09:01 -0500 (EST) Received: from securerf.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 7A1CAE2042; Wed, 28 Nov 2018 13:09:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1543428541; bh=ISa0p58OSH9yBFdio/fOZeJi34qeWrS5hZGtKYbOMFM=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=H6ABk9+HDIx8AE5qJwyROJaOQsT1ZdiLMwx4jZAtn2JZV+USyG19CXmbU9lH86Rpv lGT5J4n4pUh9n8c2pXz8JuoM4vez7qqKEjOlVDqAgGl93mDOn2SKn+45Xs6EQrpZpY erAjNNAeh+QIkwjv7ongLyOTVi/AARec7IE9I2Zw= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id wASI90jF013652; Wed, 28 Nov 2018 13:09:00 -0500 From: Derek Atkins To: Ronald Tse Cc: "openpgp\@ietf.org" , "Mark D. Baushke" , Ronald Tse References: <87y3aosju2.fsf@wheatstone.g10code.de> <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> <875zwhvef3.fsf@wheatstone.g10code.de> Date: Wed, 28 Nov 2018 13:09:00 -0500 In-Reply-To: <875zwhvef3.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 28 Nov 2018 08:39:44 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 18:09:46 -0000 Hi, Werner Koch writes: > On Wed, 28 Nov 2018 06:00, tse@ribose.com said: > >> The question raised by Werner (as I understood it) was more about how >> to align the IANA considerations given in 4880bis with this document, >> and whether to merge the said document into 4880bis. For the intended > > Right. I am not sure what is the right procedure here. Are the tables > with the various ids in rfc4880bis normative or are the informational > and the IANA registry is the normative reference for them. For > practical point of view I would like to have the tables in rfc4880bis > to be normative with the note that the IANA registry defines updates to > these tables. > > I agree with Ron that the procedures on how to update the IANA registries > do not belong into rfc4880bis. We need some advice from IETF procedures > experienced people (or a pointer to an RFC describing these procedures). Speaking for myself (but with the knowledge of being a former chair of the OpenPGP WG), it's perfectly fine to put the one-time IANA process details into the 4880bis draft. What is often done is to add an RFC-Editor note to remove the IANA actions section(s) upon publication. What happens is that the draft will get approved with all the IANA actions in it, but when it gets edited into an actual RFC, the one-time IANA actions can be removed. There is still the historical record of the one-time actions in the i-d history, but it de-clutters the RFC. I recommend we take this approach, because getting TWO I-D through the process will be twice as much work for everyone involved than getting only one through the process. We have enough trouble with just the one. So I would recommend we integrate in the one-time actions with a note to remove it upon publication. > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Nov 30 16:19:52 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458F7130EF7 for ; Fri, 30 Nov 2018 16:19:51 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=ham autolearn_force=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 VmFTtn7P9Ypz for ; Fri, 30 Nov 2018 16:19:49 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 67CB3126F72 for ; Fri, 30 Nov 2018 16:19:49 -0800 (PST) X-AuditID: 1209190d-58fff70000005ec4-58-5c01d3a37037 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id CB.CF.24260.4A3D10C5; Fri, 30 Nov 2018 19:19:48 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wB10Jk5p031449; Fri, 30 Nov 2018 19:19:46 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB10JgMq032130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 19:19:44 -0500 Date: Fri, 30 Nov 2018 18:19:41 -0600 From: Benjamin Kaduk To: "openpgp@ietf.org" Cc: Ronald Tse , "Mark D. Baushke" , Derek Atkins Message-ID: <20181201001941.GE87441@kduck.kaduk.org> References: <87y3aosju2.fsf@wheatstone.g10code.de> <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> <875zwhvef3.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hRV1l1ymTHG4NNSAYuVk3awW3Tduc5m 0fDvIbtF67YjbA4sHkuW/GTyWP71AYvH9aar7B5X509hC2CJ4rJJSc3JLEst0rdL4MrobZUu +CBe0XBxM0sD4zmhLkZODgkBE4lVNy6ydDFycQgJrGGS6Hh2gwnC2cgo0bHgIBuEc5dJ4uqG GUBlHBwsAqoSs+bqgXSzCahINHRfZgaxRQQ0Jfp2LGcDsZkFciUeL78DZgsL+Ejcb90IVsML tG31uiaomUuYJHr7/7BDJAQlTs58wgLRrCVx499LJpBdzALSEsv/cYCEOQUMJX6d2wJWLiqg LLG37xD7BEaBWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrp JkZwMEvy7mD8d9frEKMAB6MSD++EHMYYIdbEsuLK3EOMkhxMSqK8fyWAQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4Sy8C5XhTEiurUovyYVLSHCxK4ry/RR5HCwmkJ5akZqemFqQWwWRlODiU JHgXXgJqFCxKTU+tSMvMKUFIM3FwggznARq+DKSGt7ggMbc4Mx0if4pRl+PFjI4ZzEIsefl5 qVLivDkgRQIgRRmleXBzQElIInt/zStGcaC3hHkFQKp4gAkMbtIroCVMQEtiev5HAy0pSURI STUw7jj85cLMX4nTJXbfm6f28ElAbYjVvc23Zy/uKz7ncDR37hnBxLwTjA6paQphL+8JaZQn RrQfVK3atu7AlkuXBa1O+apJPP6rHBj0pag/qj22X+6N16I70caC6t6CverXtAza/mf25Ias +DGjoGT577utsWwvbnxb3XRv7U5XDwOG3zrXeuV+KrEUZyQaajEXFScCAJY579odAwAA Archived-At: Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2018 00:19:51 -0000 On Wed, Nov 28, 2018 at 01:09:00PM -0500, Derek Atkins wrote: > Hi, > > Werner Koch writes: > > > On Wed, 28 Nov 2018 06:00, tse@ribose.com said: > > > >> The question raised by Werner (as I understood it) was more about how > >> to align the IANA considerations given in 4880bis with this document, > >> and whether to merge the said document into 4880bis. For the intended > > > > Right. I am not sure what is the right procedure here. Are the tables > > with the various ids in rfc4880bis normative or are the informational > > and the IANA registry is the normative reference for them. For > > practical point of view I would like to have the tables in rfc4880bis > > to be normative with the note that the IANA registry defines updates to > > these tables. Generally you want the IANA registry to be the single normative place to consult. It's fairly common to have a table in an RFC and have the initial IANA registry populated from that (also normative) table, and perhaps less common but still plausible to have an update document with a table and instructions for IANA to resync to that table at time of publication (but still be able to add/change things later). > > I agree with Ron that the procedures on how to update the IANA registries > > do not belong into rfc4880bis. We need some advice from IETF procedures > > experienced people (or a pointer to an RFC describing these procedures). > > Speaking for myself (but with the knowledge of being a former chair of > the OpenPGP WG), it's perfectly fine to put the one-time IANA process > details into the 4880bis draft. What is often done is to add an > RFC-Editor note to remove the IANA actions section(s) upon publication. > > What happens is that the draft will get approved with all the IANA > actions in it, but when it gets edited into an actual RFC, the one-time > IANA actions can be removed. > > There is still the historical record of the one-time actions in the i-d > history, but it de-clutters the RFC. > > I recommend we take this approach, because getting TWO I-D through the > process will be twice as much work for everyone involved than getting > only one through the process. We have enough trouble with just the > one. So I would recommend we integrate in the one-time actions with a > note to remove it upon publication. Derek is absolutely right, here. I'll note that for TLS 1.3 we did separate documents, RFCs 8446 and 8447, since there were a *lot* of registry changes and we did want a permanent record of them, but that split caused a lot of extra work to ensure things were synchronized during AUTH48. -Ben > > Salam-Shalom, > > > > Werner > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Fri Nov 30 23:21:53 2018 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89362128CF2 for ; Fri, 30 Nov 2018 23:21:52 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gamubHxht1vA for ; Fri, 30 Nov 2018 23:21:50 -0800 (PST) Received: from KOR01-SL2-obe.outbound.protection.outlook.com (mail-eopbgr1290043.outbound.protection.outlook.com [40.107.129.43]) (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 D9E8E12426E for ; Fri, 30 Nov 2018 23:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jlp3iAMZ+RZ2gkqfLDFYIf3u1UQfeztcJpp3i6ZTRQw=; b=ZWbmA3oRepGIg6X9nIOnNkYan40ACfs95k6LVBUh98daPc0v8e68nSSVrNzEdUOUYz0yR780+48dKN1UNdi3lbl81dSVQ1/RzoYxA72qvy5+o+r/BxcyOsm30NWdVnpxjd8Yw6ccF9PYOCUpa6IqGWkGEXA3Prbf7KVa1WBN0cs= Received: from SL2PR01MB2955.apcprd01.prod.exchangelabs.com (10.174.127.83) by SL2PR01MB2699.apcprd01.prod.exchangelabs.com (20.177.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.22; Sat, 1 Dec 2018 07:21:44 +0000 Received: from SL2PR01MB2955.apcprd01.prod.exchangelabs.com ([fe80::7d7f:f09d:4f80:aced]) by SL2PR01MB2955.apcprd01.prod.exchangelabs.com ([fe80::7d7f:f09d:4f80:aced%4]) with mapi id 15.20.1382.020; Sat, 1 Dec 2018 07:21:44 +0000 From: Ronald Tse To: Benjamin Kaduk CC: "openpgp@ietf.org" , "Mark D. Baushke" , Derek Atkins Thread-Topic: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 Thread-Index: AQHUau5gREidRDRyVkybXZt3x9+Nn6VkGnkAgAAL4ACAALJSAIAALK73gACv7+OAA4v1gIAAdeUA Date: Sat, 1 Dec 2018 07:21:43 +0000 Message-ID: <348B9107-4726-4899-A980-FD3BEB2A0BA5@ribose.com> References: <87y3aosju2.fsf@wheatstone.g10code.de> <14036.1543342928@contrail-ubm16-mdb.svec1.juniper.net> <875zwhvef3.fsf@wheatstone.g10code.de> <20181201001941.GE87441@kduck.kaduk.org> In-Reply-To: <20181201001941.GE87441@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [112.120.148.19] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SL2PR01MB2699; 6:Meu5RE30NdefGRkUOj+rxKiqD76MznjBNwcVHFLFjgfZowxkk8o6GyKwW7EfWUFxq9ilolDbSWB0Y8RJ7Diy9OUTriym6Nm37vf3KbSeTFhCVMltSRKZlP3x5/hVX+3W2K5QZ5exi0AxJrEy9DUxR4YSwanq0Ggjn7nuVV7Hl6/goZaD91G8AGzI+Fotvd0MqncmEcBH6n0Hj1odby4jRfG+hXviKbF/UaCNBQy9OenDpE7BXhG9JiotxTeEsOuS8QK1JwLmzsgdGbOJdCJlwglIRsY4onPAw+fKvw/R0mGHu3+iU19EPNNFHj6WxI5oJiL/XpC+h7H8U5JmuIl/XfqVivaaUjshFgkulY0TM+HS1nRYcqmXrmBOsupbKQDaQybMw0N4Bm7xSHyuxz/SsUgUax9+H9DFQZFb8Np9Wh1y+b7Cf4xSoNyhlqAdhEfnKb74BW7UfbyWYddB4f5W5g==; 5:lyVafcRPCebgS4k8Txdz26809VuuglO6Slb2qVPd9PJAJjTIPaRckT4Odl1e4MfJDdag+FZ8pyCSNegKFFsxouOe17ey0w5GkthsKbgCdg6pDf5g92OyIJjwEbL1AZ+zN8GKLX6fuA2+pbCe008f0S26/QW2ZwDMA4jzVUTBx9U=; 7:LGXoMZz7n5Gc4pSGVRl7SA5wLwr+65wUjm7z+wJ0QldmxjxHYbvxKv+xGH4i+QYsBabO6nzL4rYQ7PUek0PWnia8bHjP761dXv/JHTcm53eO0GYmb8PumOe0Wzgbmi/YhStcb+XNUIQC8LwUGHtcfg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5f2e1cea-3658-4f8a-2e42-08d6575da591 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SL2PR01MB2699; x-ms-traffictypediagnostic: SL2PR01MB2699: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231454)(999002)(944501474)(52105112)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(2016111802025)(20161123562045)(6043046)(201708071742011)(7699051)(76991095); SRVR:SL2PR01MB2699; BCL:0; PCL:0; RULEID:; SRVR:SL2PR01MB2699; x-forefront-prvs: 087396016C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39830400003)(346002)(396003)(376002)(199004)(189003)(26005)(86362001)(53936002)(6512007)(5660300001)(36756003)(102836004)(476003)(54896002)(6506007)(6246003)(486006)(76176011)(2906002)(33656002)(99286004)(446003)(97736004)(2616005)(6486002)(3846002)(6116002)(4326008)(6436002)(25786009)(229853002)(11346002)(14454004)(2171002)(508600001)(7736002)(256004)(6916009)(14444005)(316002)(71190400001)(83716004)(71200400001)(66066001)(186003)(68736007)(54906003)(93886005)(8676002)(82746002)(105586002)(15650500001)(106356001)(81156014)(8936002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:SL2PR01MB2699; H:SL2PR01MB2955.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: xYQ/FvrDxRufqPE29//Bvx9vSaPtvBbjEo2N//Uoy35+joVk72mX+FzbWW1ETohH8mie1GnYkXp1C4EBSr3LAJnovVumZjvu7wPgOEO6kYCkNxRrmfAt9JLZkYbCsQXXmBUBw7DeflO2z2xH8YEoWxw/AMCkUYyYCEEtNu1mvj7imFsHTmH10V52lahBe5Eix6cuDET9Zz15cYy9/zfjoB9NgV86J20bz2Mw8T5kc3YGyEcBf3lcpSO2Wr1+v+p1WE0/EwlrVdGU6Rh3K/9lzGsoSxnudljOg1nV8F0gU5Uao9i2+gLiTdmrWbxBdGtKjBFamaq6H+xgRJnsaKKMBxlfzbOb8SFnX7CoewkuDd4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_348B910747264899A980FD3BEB2A0BA5ribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f2e1cea-3658-4f8a-2e42-08d6575da591 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2018 07:21:43.8802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SL2PR01MB2699 Archived-At: Subject: Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2018 07:21:52 -0000 --_000_348B910747264899A980FD3BEB2A0BA5ribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVuLCBEZXJlaywNCg0KRGVyZWsgaXMgYWJzb2x1dGVseSByaWdodCwgaGVyZS4NCg0KSSBm dWxseSBhZ3JlZSB0aGF0IG1hbmFnaW5nIHR3byBkb2N1bWVudHMgaXMgbW9yZSBjb21wbGV4IHRo YW4gaGFuZGxpbmcgb25lLg0KDQpJJ2xsIG5vdGUgdGhhdCBmb3IgVExTIDEuMyB3ZSBkaWQgc2Vw YXJhdGUgZG9jdW1lbnRzLCBSRkNzIDg0NDYgYW5kIDg0NDcsDQpzaW5jZSB0aGVyZSB3ZXJlIGEg KmxvdCogb2YgcmVnaXN0cnkgY2hhbmdlcyBhbmQgd2UgZGlkIHdhbnQgYSBwZXJtYW5lbnQNCnJl Y29yZCBvZiB0aGVtLCBidXQgdGhhdCBzcGxpdCBjYXVzZWQgYSBsb3Qgb2YgZXh0cmEgd29yayB0 byBlbnN1cmUgdGhpbmdzDQp3ZXJlIHN5bmNocm9uaXplZCBkdXJpbmcgQVVUSDQ4Lg0KDQpIb3dl dmVyLCB0aGUgT3BlblBHUCBJQU5BIHVwZGF0ZSBkb2N1bWVudCB3YXMgY3JlYXRlZCBmcm9tIGEg c3VnZ2VzdGlvbiBieSB0aGUgU2VjdXJpdHkgQUQsIHdoZXJlIHRoZSBUTFMgcmVnaXN0cnkgdXBk YXRlIG1vZGVsIHdhcyB0aGUgYWNjZXB0YWJsZSByb2xlIG1vZGVsIHRvIGZvbGxvdy4gUkZDIDg0 NDcgaXMgYXQgMTcgcGFnZXM7IHRoaXMgZG9jdW1lbnQgaXMgY2xvc2UgdG8gMzAg4oCUIHRoZSBP cGVuUEdQIElBTkEgcmVnaXN0cmllcyBhcmUgbnVtZXJvdXMgYW5kIGNoYW5nZXMgdG8gdGhlbSBt YW55LCBzaW5jZSBhIGxvdCBvZiB0aGVtIGhhdmUgYmVlbiBkaWxhcGlkYXRlZCBzaW5jZSB0aGUg ZGF5cyBvZiAyNDQwLg0KDQpJZiB3ZSBtZXJnZSB0aGlzIGludG8gNDg4MGJpcyBhbmQgcmVtb3Zl IHRoZW0gYXQgcHVibGljYXRpb24sIHdl4oCZcmUgYWRkaW5nIDMwIHBhZ2VzICh0ZW1wb3Jhcmls eSkgYW5kIHRoZW4gbWF5YmUgcmVtb3ZpbmcgMjUgYXQgcHVibGljYXRpb24uIEFuZCB3ZSBsb3Nl IHRoZSBwZXJtYW5lbnQgcmVjb3JkIHRoYXQgUkZDIDg0NDcgcHJvdmlkZXMgZm9yIFRMUy4gUGVy aGFwcyB0aGVyZSBpcyBhbiBhcmd1bWVudCB0aGF0IHRoZSByZWdpc3RyaWVzIG9mIE9wZW5QR1Ag YXJlbid0IGFzIGltcG9ydGFudCAoISkgYXMgVExT4oCZcyBmb3IgcGVybWFuZW50IHJlY29yZCBr ZWVwaW5nLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBiZSByZWxlZ2F0ZWQgdG8gYW4gSW50ZXJuZXQt RHJhZnQsIGJ1dCBpdCBkb2VzbuKAmXQgc291bmQgbGlrZSBhIGdvb2QgcmVhc29uIHRvIGZvcmdv IHRoYXQuDQoNCkdpdmVuIHRoYXQgdGhlIElFVEYgcHJvY2VzcyBoYXMgYWxyZWFkeSBwcm9jZXNz ZWQgdGhlIHBhaXIgb2YgODQ0Ni84NDQ3IHN1Y2Nlc3NmdWxseSBpbiBhIHN5bmNocm9uaXplZCB3 YXksIHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRoYXQgaXTigJlzIGV2ZW4gZWFzaWVyIHRoaXMgdGlt ZSByb3VuZD8NCg0KUm9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KUm9uYWxkIFRzZQ0KUmlib3NlIEluYy4NCg== --_000_348B910747264899A980FD3BEB2A0BA5ribosecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIEJlbiwgRGVyZWssDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPkRlcmVrIGlzIGFic29sdXRlbHkgcmlnaHQsIGhlcmUuPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkkgZnVsbHkgYWdyZWUgdGhhdCBtYW5hZ2luZyB0d28gZG9jdW1lbnRzIGlzIG1vcmUgY29tcGxl eCB0aGFuIGhhbmRsaW5nIG9uZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5JJ2xsIG5vdGUgdGhhdCBmb3IgVExTIDEuMyB3ZSBkaWQg c2VwYXJhdGUgZG9jdW1lbnRzLCBSRkNzIDg0NDYgYW5kIDg0NDcsPGJyIGNsYXNzPSIiPg0Kc2lu Y2UgdGhlcmUgd2VyZSBhICpsb3QqIG9mIHJlZ2lzdHJ5IGNoYW5nZXMgYW5kIHdlIGRpZCB3YW50 IGEgcGVybWFuZW50PGJyIGNsYXNzPSIiPg0KcmVjb3JkIG9mIHRoZW0sIGJ1dCB0aGF0IHNwbGl0 IGNhdXNlZCBhIGxvdCBvZiBleHRyYSB3b3JrIHRvIGVuc3VyZSB0aGluZ3M8YnIgY2xhc3M9IiI+ DQp3ZXJlIHN5bmNocm9uaXplZCBkdXJpbmcgQVVUSDQ4LjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+SG93ZXZlciwgdGhlIE9wZW5QR1AgSUFOQSB1cGRhdGUgZG9jdW1lbnQgd2FzIGNyZWF0ZWQg ZnJvbSBhIHN1Z2dlc3Rpb24gYnkgdGhlIFNlY3VyaXR5IEFELCB3aGVyZSB0aGUgVExTIHJlZ2lz dHJ5IHVwZGF0ZSBtb2RlbCB3YXMgdGhlIGFjY2VwdGFibGUgcm9sZSBtb2RlbCB0byBmb2xsb3cu IFJGQyA4NDQ3IGlzIGF0IDE3IHBhZ2VzOyB0aGlzIGRvY3VtZW50IGlzIGNsb3NlIHRvIDMwIOKA lCB0aGUgT3BlblBHUCBJQU5BIHJlZ2lzdHJpZXMNCiBhcmUgbnVtZXJvdXMgYW5kIGNoYW5nZXMg dG8gdGhlbSBtYW55LCBzaW5jZSBhIGxvdCBvZiB0aGVtIGhhdmUgYmVlbiBkaWxhcGlkYXRlZCBz aW5jZSB0aGUgZGF5cyBvZiAyNDQwLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgd2UgbWVyZ2UgdGhpcyBpbnRvIDQ4ODBiaXMgYW5k IHJlbW92ZSB0aGVtIGF0IHB1YmxpY2F0aW9uLCB3ZeKAmXJlIGFkZGluZyAzMCBwYWdlcyAodGVt cG9yYXJpbHkpIGFuZCB0aGVuIG1heWJlIHJlbW92aW5nIDI1IGF0IHB1YmxpY2F0aW9uLiBBbmQg d2UgbG9zZSB0aGUgcGVybWFuZW50IHJlY29yZCB0aGF0IFJGQyA4NDQ3IHByb3ZpZGVzIGZvciBU TFMuIFBlcmhhcHMgdGhlcmUgaXMgYW4gYXJndW1lbnQgdGhhdCB0aGUNCiByZWdpc3RyaWVzIG9m IE9wZW5QR1AgYXJlbid0IGFzIGltcG9ydGFudCAoISkgYXMgVExT4oCZcyBmb3IgcGVybWFuZW50 IHJlY29yZCBrZWVwaW5nLCBhbmQgdGhlcmVmb3JlIHNob3VsZCBiZSByZWxlZ2F0ZWQgdG8gYW4g SW50ZXJuZXQtRHJhZnQsIGJ1dCBpdCBkb2VzbuKAmXQgc291bmQgbGlrZSBhIGdvb2QgcmVhc29u IHRvIGZvcmdvIHRoYXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkdpdmVuIHRoYXQgdGhlIElFVEYgcHJv Y2VzcyBoYXMgYWxyZWFkeSBwcm9jZXNzZWQgdGhlIHBhaXIgb2YgODQ0Ni84NDQ3IHN1Y2Nlc3Nm dWxseSBpbiBhIHN5bmNocm9uaXplZCB3YXksIHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRoYXQgaXTi gJlzIGV2ZW4gZWFzaWVyIHRoaXMgdGltZSByb3VuZD88L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NClJvbjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSb25hbGQgVHNlPGJyIGNsYXNzPSIi Pg0KUmlib3NlIEluYy48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_348B910747264899A980FD3BEB2A0BA5ribosecom_--