From nobody Thu Feb 7 01:34:24 2019 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 BCF6A12F19D for ; Thu, 7 Feb 2019 01:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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 SwSayFo64yyw for ; Thu, 7 Feb 2019 01:34:18 -0800 (PST) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 A5A65128CF2 for ; Thu, 7 Feb 2019 01:34:18 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id t200so5915131wmt.0 for ; Thu, 07 Feb 2019 01:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fluidkeys-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version; bh=RQKFruIB1li0+gFDLnF3l0ziUFF2tznTs1mvNjBAtD8=; b=u2UQWgo36gG1Q0ZYJswmrwRefm/yuTccuv06ceV29b7I8zbaesVhzGN27XfUMLoHJ+ YljStjlFK5tTmmj+QNIa+bp4PnuXGvJDf9taNApNmoUtljczAfQsmascgtIhpRafokBB U1+uiPMMOjFzYneybmJm/9t7nM/AX8TOXfF3Q6Qr+MRMRfou+NMRYTD+kzWtkXu1FYOP OHp4mieXxpTJ4NvJmVJ7Y59hm6IhQUoVFqlLnPfKLgLukf09I79hx8B9CWlTaQ3im1Z4 9rF2VRl4PNg+53Hw8HPtkzG6l40RFlwoPfu1Nr7LmS/RwkpeL1POiNwqCJ8xx6csRL6u 9mBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version; bh=RQKFruIB1li0+gFDLnF3l0ziUFF2tznTs1mvNjBAtD8=; b=C1JC4Hzx3UQmushmg1jshAetaeclLJMv4rEiqo2cUDG6b7cbSM9JG6g/t0IIe/s0sp lL2NSzDPixzgBZC343e3IIW3dFNJGotrxLjaRUS0H7detyEta7lY0ZrC5mNLFvsPo31v jivlCvKUEs/QUItjOinfUnl1EkZVLvbZH7eyprsNSuZdcGDVZq17ojVEpnkaH5tqQz4l 5MAeliMkaq5XzyDS/uLN6kbRKc0/UdpdCoo3ewM1GdZ19Nq/U9Bt5v7dQluzwgEeQyOA MZ6h3q39/VhXx5Kem5hd9PNv/xDe5yE2rauN7FvLU/GHHHTBKGj3EI755WxhV9qNgB2P /fjg== X-Gm-Message-State: AHQUAubpJIy1Y9J1fTzCOstaCWaVKj6/h2MpDmbbCNIuoRUP44UU+igB +s0i7F4uOUW6oEY/qD9MEcO86Oz+3w== X-Google-Smtp-Source: AHgI3IYFcEyBtXOFIrwcWUzxDITwlyLlogXt2Wc/gjl/phTF7B1PlEI+oUEJkN+OcGpxvJtja87FNA== X-Received: by 2002:a1c:2501:: with SMTP id l1mr6921434wml.102.1549532056687; Thu, 07 Feb 2019 01:34:16 -0800 (PST) Received: from [10.0.2.15] (191.93.2.81.in-addr.arpa. [81.2.93.191]) by smtp.gmail.com with ESMTPSA id j33sm50959967wre.91.2019.02.07.01.34.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 01:34:15 -0800 (PST) To: openpgp@ietf.org From: Paul Fawkesley Openpgp: preference=signencrypt Autocrypt: addr=paul@fluidkeys.com; keydata= mQINBFuOr7IBEADj5wnhRc07sX1rNNqEvMEZIXYZgElhxNRpN4qc4ES4Xp9rlckLIgqARyiY 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 GShxBb8XI7zriY6Bgmn4OaMJUB9vj3dNjjj7Cvic5gwGzEJWdQARAQABtBQ8cGF1bEBmbHVp ZGtleXMuY29tPokCOQQTAQoALQUCXFQKqgkQcyekTCFXp1gCGwMFCQERU04CGQEFCwkIBwMF FQoJCAsEFgIBAAAArn0QAMD6yzmb3Hf1ShpwDM15ITVCYuDPmEWut3ERCs2E2TbD56VM1BTx 5tyXMsVaee7N5WhkbkqoUy7O0wv53gatJoyoKLgklAPgPd0+bcWORiRJn7Nr+QFGAtg5gm9U W1wofX5QTLWqk2KmumoA86JQ3hp/ElLlmS+fwpqpxGMbs79+6t4xhkIJ7/UMTmA6RsPvFhsX L5uD5upkS84sOzGsoK9fB6UPss3bNbHa5E/g/VEu1x3UUzXmZ4gRcV2gQawRyRaVHKh+WOVE A8Qn0WTzmuH5/RG44/Ls6Lx+xAmqsqSIZt0TUMG555gkC3xjB3vtNk+VUo54ah9b8IUd8nBC TvOJF7DYGrQIP5kYirfx61ahgEjXD5hC86LCJn4JKM9EptHQYEwdZbYBW9HZCtpwjwYvAA9i cYQypcx0QpkkG57UzzX4yEg91h7ZZFJXe89e9eX2ht0f3cvRUox04bvzj6jg6nalCC/P+E5q N7+CfVjCw0vbnRDMDf2F1DvtRCVHExKfbjiGSg0ZqOyzvfPp7/PEdTILeBAv9NQ5XXbUVeD/ NxTi02YdiUoaNV87vgX4ntPDUE/uhThPv1B96mUEGRbSOHNajUEkwol/z9EMIfxlwhlGI8Sm VGr2EIaQgw8qtYn5mgvhco6yzdkJg0ijjErWf+jxPWnlx9tYjIuFxu5/uQENBFxUCqoBCADC Vp6rApf3qrOA9qE4em09OCMcOk87+P+to6fzO0v9YUM6bkpL5rAUdP8h5TPfTIQ2U0h6EKPs lY07Um7NlZ1I4GaQELmRoPRP+u8Nbxy31kBThodceM2yt6qVUrwYN02uU9hVJAMdbFYBiBzj FiZtmWOkWdrr2UG1Rcxyt8cBqJ8DupbsDSIxvpIWFpO0wUad/XHsPQxFIH3sopB4j8yci6p/ +T3ZSL13Gm44eBKVpiiGvao2PoKMq0ivs1pKTyFgp72VWObm54qgB8TGuZlGeVLSA3la5C8k oYlX7f8BjP6xFPz0Cs5oHTYpNi7xQpZqBkeaFPKIqdi9oJ9n1ajTABEBAAGJAiUEGAEKABkF AlxUCqoJEHMnpEwhV6dYAhsMBQkAS/hVAADdQxAAn3hTuna3vK7GDzTKlR6CCcgGgIeOWTEg 1sQoDiA/Rii0UKNp6S4sdQ3TdYkQq0jFYWtmN2cvW+TSSx6OEGfAQY22rJLuhw2OsMTo3TY4 8AgcZOPDg6oZv1YgR4rEMa26xtuRa5kQCPb4n8Zc3zHTlX0HGcbL05NXAzSN2agMmXU8I9u3 ORyAlRztbPdLEIQ2vsXLLAtMWAZxzyxC6pOPQAQ8482tem/JU9hGwat+8p+e4s05fgfCMdUJ 7Ro+9vmEUpAhfQZBvubPTjhtwL2+9OlHrx+5y2q2w5c+gqGJNEwGGIT3Ghee0Dn/hZ2Hkrj8 M9wWLeHF0NUDmv3EjeQHTjpYI4f3Z0qcWMUVaTvvCc50E4ypel24PNqpQW1TzprY7RPWSjUT u3mg5N+/5vj75KJzkcObQORn55iY9l+vmvuWfNovG25ER6PmiS6IPvHISRZNz2YUDR/RVUH2 RpWeseSnhZ7Oq8qyPmZ7n963AhB79B5zwgIRL2nmSxgnzx/yCXrlBUISavkiKz83P2wWdJ3n 6tzYIn+TKsy9PTnKynYOdAVv7jtzlMpWnvqLA22jVq7ZHZ4cfnId+QLNUgtXEdAE8qJHrzHx EqpX7bZz2+RPHTIiWR+SBjWpq/zRPrG9DNSYwIB02Bs5+Q6iHKc/lLxKAL3jXtgebXivl5UX cts= Message-ID: <0be845d0-bd98-d021-7bc9-5f6562323cd4@fluidkeys.com> Date: Thu, 7 Feb 2019 09:34:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WnqZaHVnH5TVbJNw7VTdeNrWiEqdNhLbX" Archived-At: Subject: [openpgp] Clarification: calculation of key expiration time 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, 07 Feb 2019 09:34:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WnqZaHVnH5TVbJNw7VTdeNrWiEqdNhLbX Content-Type: multipart/mixed; boundary="3yiL26dTxh1hfsC2Y3SSiX2JAkItoZJU8"; protected-headers="v1" From: Paul Fawkesley To: openpgp@ietf.org Message-ID: <0be845d0-bd98-d021-7bc9-5f6562323cd4@fluidkeys.com> Subject: Clarification: calculation of key expiration time --3yiL26dTxh1hfsC2Y3SSiX2JAkItoZJU8 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi all, There's an open issue[1] on Golang's openpgp library about calculating key expiration time. I believe it is currently calculated incorrectly and would appreciate a second opinion. The code[2] currently reads: ``` // KeyExpired returns whether sig is a self-signature of a key that has // expired. func (sig *Signature) KeyExpired(currentTime time.Time) bool { if sig.KeyLifetimeSecs =3D=3D nil { return false } expiry :=3D sig.CreationTime.Add(time.Duration(*sig.KeyLifetimeSecs) * time.Second) return currentTime.After(expiry) } ``` So they're using _signature creation time_ + key expiration time (seconds= ) The spec[3] seems pretty clear that you should use _key creation time_ + key expiration time (seconds): > 5.2.3.6. Key Expiration Time >=20 > (4-octet time field) >=20 > The validity period of the key. This is the number of seconds after= > the key creation time that the key expires. If this is not present > or has a value of zero, the key never expires. This is found only o= n > a self-signature. So it seems to me it's a bug, unless I'm missing something? Kind regards, Paul [1]: https://github.com/golang/go/issues/22312 [2]: https://github.com/golang/crypto/blob/7e6ffbd038512da5ae7ce06c196764f3939= 90be1/openpgp/packet/signature.go#L459 [3]: https://tools.ietf.org/html/rfc4880#section-5.2.3.6 --3yiL26dTxh1hfsC2Y3SSiX2JAkItoZJU8-- --WnqZaHVnH5TVbJNw7VTdeNrWiEqdNhLbX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEt58IQN7xLrunL/ctcyekTCFXp1gFAlxb+5UACgkQcyekTCFX p1iCyhAArlKaw0FLfTb73CM8tJ3xB8lWdsgAdJknAcFai8MTN3o1ANsoUrvWE62U IpW1YnMzMZAg5PPx4wXn/B2hp/BYZ7aDqvDKzmS7+jTjhYqrE2IT8SBG25o+ZUT8 RygkVf0W48QZj7OfALgVjP8r/LYzG3q+0GSlvMcuVfAWC8MHFJP9g+AWcrCGLfuM BscOeVLiMSofztY0x15my9SkzviXOeF+fZRrbrJttKhoQ19Pt7TMNrkTLsJWXC/P nmWVsnCkte2V9/Pbd5IctqxmesfkkCNB8hGtDrf2u0Mq0rLNUNaV3lX6OMXPwNi+ u1/eXZNQgJk96xKazyOVCmZPzjEaTTKb/aCumjDtabZUxuCTQ3ZyRhIegFJIdfMH 5ug3dCLvuPtqNLrZZ0ZG5BwGe0RHFP+p4HL76WWhh+sqZA8LMwuq48dmJyMvUtUZ buhvz7G+bqmMWoa78mIo6KamNyIUrdQAye9gwjT5RObzt79zfIxmiMEgtn8lYRqz 4B26Abzi1ajEta16AUCnhW5JZW7jh8aUuXq6UkGTFpsvvQ5JMYtlY55z8xmjdgX+ /NpvTUbLuPiFecd93/+AY+NqEXwqkGcl+ZNI9DQXvDpZMhkVZlVA9Fd7usE96Ei4 LjlEgOEBwzGJucSmu24rpDAY/Ib8o0r590qFdo03LpcOvx9PkLc= =JdKj -----END PGP SIGNATURE----- --WnqZaHVnH5TVbJNw7VTdeNrWiEqdNhLbX-- From nobody Fri Feb 8 12:50:41 2019 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 96078130FF3 for ; Fri, 8 Feb 2019 12:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] 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 vvqs4qeSNXLp for ; Fri, 8 Feb 2019 12:50:36 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A1B130FF2 for ; Fri, 8 Feb 2019 12:50:36 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 298A0F99A; Fri, 8 Feb 2019 15:50:35 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A94B2204ED; Fri, 8 Feb 2019 14:49:17 -0600 (CST) From: Daniel Kahn Gillmor To: Paul Fawkesley , openpgp@ietf.org In-Reply-To: <0be845d0-bd98-d021-7bc9-5f6562323cd4@fluidkeys.com> References: <0be845d0-bd98-d021-7bc9-5f6562323cd4@fluidkeys.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 08 Feb 2019 15:49:17 -0500 Message-ID: <87r2cixaya.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Clarification: calculation of key expiration time 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, 08 Feb 2019 20:50:39 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2019-02-07 09:34:13 +0000, Paul Fawkesley wrote: > There's an open issue[1] on Golang's openpgp library about calculating > key expiration time. > > I believe it is currently calculated incorrectly and would appreciate a > second opinion. > > The code[2] currently reads: > > ``` > // KeyExpired returns whether sig is a self-signature of a key that has > // expired. > func (sig *Signature) KeyExpired(currentTime time.Time) bool { > if sig.KeyLifetimeSecs =3D=3D nil { > return false > } > expiry :=3D sig.CreationTime.Add(time.Duration(*sig.KeyLifetimeSecs) * > time.Second) > return currentTime.After(expiry) > } > ``` > > So they're using _signature creation time_ + key expiration time (seconds) > > The spec[3] seems pretty clear that you should use _key creation time_ + > key expiration time (seconds): > >> 5.2.3.6. Key Expiration Time >>=20 >> (4-octet time field) >>=20 >> The validity period of the key. This is the number of seconds after >> the key creation time that the key expires. If this is not present >> or has a value of zero, the key never expires. This is found only on >> a self-signature. > > So it seems to me it's a bug, unless I'm missing something? I agree with you that this is a bug in Golang's openpgp library. I've followed up on https://github.com/golang/go/issues/22312 accordingly. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXF3rTQAKCRB2GBllKa5f +LsfAP9IVS0OHqHomuhdMXDYlbS9jRQlTayO1ohrh7GfD8Qd2wEAxdTZj5i7Uw09 o4ivPp7O2HcZ6Mr3I2upC5Xdji682ww= =FSih -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 11 20:08:41 2019 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 6AE8D12D4E9 for ; Mon, 11 Feb 2019 20:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no 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 FieLg1qU2SRY for ; Mon, 11 Feb 2019 20:08:39 -0800 (PST) Received: from devious.adversary.org (ec2-52-29-175-128.eu-central-1.compute.amazonaws.com [52.29.175.128]) by ietfa.amsl.com (Postfix) with ESMTP id BC90B12426E for ; Mon, 11 Feb 2019 20:08:38 -0800 (PST) Received: from adversary.org (localhost [127.0.0.1]) by devious.adversary.org (Postfix) with ESMTP id 2AC7448440; Tue, 12 Feb 2019 04:08:35 +0000 (UTC) Date: Tue, 12 Feb 2019 15:09:14 +1100 From: Ben McGinnes To: cryptography@metzdowd.com Cc: openpgp@ietf.org Message-ID: <20190212040914.23kkncp2fptccwp6@adversary.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xq3wct3wmu25zsh5" Content-Disposition: inline OpenPGP: "id=DB4724E6FA4286C92B4E55C4321E4E2373590E5D; url=http://www.adversary.org/ben-key.asc; preference=signencrypt" Codes-of-Conduct-policy: "url=https://gitlab.com/Hasimir/project-participation-policy" User-Agent: NeoMutt/20180716 Archived-At: Subject: [openpgp] AS2+OpenPGP protocol extension review request 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, 12 Feb 2019 04:08:40 -0000 --xq3wct3wmu25zsh5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, For those of you either not subscribed to gnupg-devel or who may not have paid as much attention to it over the new year period; I've been working on a little thing which is ready for some form of peer review. Essentially it's a design for extending the W3C's ActivityStream version 2.0 (AS2) and ActivityPub (AP) protocols for federated social networks (e.g. Mastodon and Pleroma) with OpenPGP in order to provide a host of features not inherently built into AS2 and AP. The AS2 and AP designers considered it, but realised that they didn't have enough cryptographic knowledge to design it in a way that wouldn't shoot someone in the foot; and so they did the responsible thing in not making assumptions. Instead leaving things open for that void to be filled later. I found their work early last year and, upon reading the specs, realised that I was looking at a transport protocol. Not only that, but all the most essential cryptographic functions which needed filling were already thoroughly addressed by another existing protocol: OpenPGP. My post on this thing to the gnupg-devel mailing list is here: https://lists.gnupg.org/pipermail/gnupg-devel/2019-January/034167.html The W3C AS2 and AP specifications are here: https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitypub/ My extension proposal is the second draft and the first draft that has been posted publicly (the actual first draft was sent to the W3C AS2 designers, a couple of GnuPG developers and a handful of others). My design document is available here: https://files.de.adversary.org/crypto/ac/index.html The supplemental files (including public and private keys used in the examples) are here: https://files.de.adversary.org/crypto/ac/supplemental.zip Note: files.de.adversary.org is an AWS S3 bucket, so it will trigger an SSL cert error. Ignore it or drop back to HTTP at your own preference. Anyway, there are a number of people on this list in particular who I think could make sure that I haven't catastrophically cocked the whole thing up. I don't think I have, but that's precisely when you should double-check to be sure. So if as many of you as can spare the time could please weigh in and try to pick it apart; that'd be greatly appreciated. It'll help make it stronger. Those of you who've already been down the protocol design path are amongst those I'm particularly keen on checking this thing. I do realise there are still matters to discuss and finalise with regards to transmission of keys; currently there are multiple options included and I expect some discussion around that. There's also two versions of the Encrypted Note and I'm inclined to favour the second, slightly more complex version for a number of reasons; including working with other functions (like nesting a Signed Note inside it in a similar manner to signed & encrypted PGP/MIME emails). Regards, Ben P.S. I'm cross-posting this to the IETF OpenPGP WG mailing list on the off chance that there might be subscribers to that who are not also subscribed here or to gnupg-devel. That may not be very likely, but it is possible and so a copy there doesn't hurt. Apologies to those who will see it twice as result, though. Especially since you're the ones I'm most keen to want reviewing this work. --xq3wct3wmu25zsh5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABEKAB0WIQSkiyjzmoPmPFW48w5Icjp1eQQexgUCXGJG6gAKCRBIcjp1eQQe xvzvAQCoGbjACSWErg3QXqaLqoxfWeqjsV+aQDk66s8JiHcgiAD+MLdbvHYroiEO nSY+s4yiUqczXWsXpSULKkugekfv3X0= =uJTL -----END PGP SIGNATURE----- --xq3wct3wmu25zsh5-- From nobody Mon Feb 11 22:47:09 2019 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 1DBEE12DD85 for ; Mon, 11 Feb 2019 22:47:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 XkPpv7miz8ts for ; Mon, 11 Feb 2019 22:47:03 -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 2CFDB1274D0 for ; Mon, 11 Feb 2019 22:47:02 -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=1549954023; x=1581490023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Jy8PYyRHP3pg+VOlzZg2aGKXLiq0EHD7aooK8YF55y4=; b=aX8ndzAKPbxgE8hrYyjHjBqjhgSGPK34K05uvTHHUUr+oqLUA0ceAvU4 SSrlv1jFoUvCvfr9gBsv4mt0ofGdeyey8MB6Af/wlze9i89teg2J4KhrZ 61C2YC8IQE3o36eU7G55rG9PUnGFr/+3itbctkPSNR2zY9VhXbx9NxgD7 JZrf17irg6wnWfud8fKUyHPwk4KOkmJiXOxELXIzJzea+wBDbuLtpKxEu T6uTCwS3NggatnczmXFfSpQocYnll/UUmMojz5GeFxUsE8Wcj0hHureZS 9d3PFzIs80N57t+N4SnA2G2cxZ3m0we0wm2kkT7aHlvsqv00RrgiPNfzW w==; X-IronPort-AV: E=Sophos;i="5.58,361,1544439600"; d="scan'208";a="48198868" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Feb 2019 19:46:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Feb 2019 19:46:57 +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; Tue, 12 Feb 2019 19:46:57 +1300 From: Peter Gutmann To: Ben McGinnes , "cryptography@metzdowd.com" CC: "openpgp@ietf.org" Thread-Topic: [openpgp] AS2+OpenPGP protocol extension review request Thread-Index: AQHUwoiv62BAIg+Iek6VzSUkD8s0YaXbt90W Date: Tue, 12 Feb 2019 06:46:57 +0000 Message-ID: <1549954014509.38591@cs.auckland.ac.nz> References: <20190212040914.23kkncp2fptccwp6@adversary.org> In-Reply-To: <20190212040914.23kkncp2fptccwp6@adversary.org> 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] AS2+OpenPGP protocol extension review request 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, 12 Feb 2019 06:47:06 -0000 Ben McGinnes writes:=0A= =0A= >Essentially it's a design for extending the W3C's ActivityStream version 2= .0=0A= >(AS2) and ActivityPub (AP) protocols for federated social networks (e.g.= =0A= >Mastodon and Pleroma) with OpenPGP in order to provide a host of features = not=0A= >inherently built into AS2 and AP.=0A= =0A= Just a note on this, I don't know what the W3C's AS2 is but whatever it is= =0A= it's nothing like the real AS2, which is a secure EDI standard that's been= =0A= around for close to twenty years (there are actually several AS standards, = but=0A= the most widely-used one is AS2). So if anyone goes looking for AS2 securi= ty=0A= information, they're going to get a very different AS2...=0A= =0A= Peter.=0A= From nobody Tue Feb 12 03:52:20 2019 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 7681912DF71 for ; Tue, 12 Feb 2019 03:52:18 -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 mn612l8sCKJD for ; Tue, 12 Feb 2019 03:52:15 -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 67DB412D826 for ; Tue, 12 Feb 2019 03:52:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B8031BE39; Tue, 12 Feb 2019 11:52:11 +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 F5RwrHUGuAMQ; Tue, 12 Feb 2019 11:52:06 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 48191BE4D; Tue, 12 Feb 2019 11:52:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1549972326; bh=PmnG9+C8v0sPzhwbak5hpOgGt7X21Ib4UKp41Ul9Epg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zieeOoe5wSEitKEvCHBHXUKtAbP7jYwXhxUONfb1b3VYxyZ9PYDl7vCsZRcroCHne /GAVAu4Uz0TDZ4igt3MVuXcs04jzsL1gv6SdT8GJR9GJhyj0J6RBjrE4T9XKoqn5vt uDzqej9D1paVw4i6aiLLpVlf4VbBUI/lOh11HMW4= To: Ben McGinnes , cryptography@metzdowd.com Cc: openpgp@ietf.org References: <20190212040914.23kkncp2fptccwp6@adversary.org> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ 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+2RuFnxLkCDQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <79420544-da84-6c1b-5c3a-f2d2e3a10184@cs.tcd.ie> Date: Tue, 12 Feb 2019 11:52:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190212040914.23kkncp2fptccwp6@adversary.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wIGdo9lpJZ41zHNEEoLAWQoIF1EabK36y" Archived-At: Subject: Re: [openpgp] AS2+OpenPGP protocol extension review request 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, 12 Feb 2019 11:52:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wIGdo9lpJZ41zHNEEoLAWQoIF1EabK36y Content-Type: multipart/mixed; boundary="uDDNU4oEEvq7CD7r8JvlaYpa95zpHRg3B"; protected-headers="v1" From: Stephen Farrell To: Ben McGinnes , cryptography@metzdowd.com Cc: openpgp@ietf.org Message-ID: <79420544-da84-6c1b-5c3a-f2d2e3a10184@cs.tcd.ie> Subject: Re: [openpgp] AS2+OpenPGP protocol extension review request References: <20190212040914.23kkncp2fptccwp6@adversary.org> In-Reply-To: <20190212040914.23kkncp2fptccwp6@adversary.org> --uDDNU4oEEvq7CD7r8JvlaYpa95zpHRg3B Content-Type: multipart/mixed; boundary="------------84E37103645E89A1553D51D1" Content-Language: en-GB This is a multi-part message in MIME format. --------------84E37103645E89A1553D51D1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I just had a quick peek (will try read more later) but wondered why PGP is a better primitive here than MLS? [1] (Or one of the IM security schemes that motivated MLS, if dealing with a work- in-progress like MLS is problematic.) Ta, S. [1] https://tools.ietf.org/wg/mls/charters On 12/02/2019 04:09, Ben McGinnes wrote: > Hi all, > For those of you either not subscribed to gnupg-devel or who > may not have paid as much attention to it over the new year period; > I've been working on a little thing which is ready for some form of > peer review. >=20 > Essentially it's a design for extending the W3C's ActivityStream > version 2.0 (AS2) and ActivityPub (AP) protocols for federated social > networks (e.g. Mastodon and Pleroma) with OpenPGP in order to provide > a host of features not inherently built into AS2 and AP. >=20 > The AS2 and AP designers considered it, but realised that they didn't > have enough cryptographic knowledge to design it in a way that > wouldn't shoot someone in the foot; and so they did the responsible > thing in not making assumptions. Instead leaving things open for that > void to be filled later. >=20 > I found their work early last year and, upon reading the specs, > realised that I was looking at a transport protocol. Not only that, > but all the most essential cryptographic functions which needed > filling were already thoroughly addressed by another existing > protocol: OpenPGP. >=20 > My post on this thing to the gnupg-devel mailing list is here: >=20 > https://lists.gnupg.org/pipermail/gnupg-devel/2019-January/034167.html >=20 > The W3C AS2 and AP specifications are here: >=20 > https://www.w3.org/TR/activitystreams-core/ > https://www.w3.org/TR/activitypub/ >=20 > My extension proposal is the second draft and the first draft that has > been posted publicly (the actual first draft was sent to the W3C AS2 > designers, a couple of GnuPG developers and a handful of others). My > design document is available here: >=20 > https://files.de.adversary.org/crypto/ac/index.html >=20 > The supplemental files (including public and private keys used in the > examples) are here: >=20 > https://files.de.adversary.org/crypto/ac/supplemental.zip >=20 > Note: files.de.adversary.org is an AWS S3 bucket, so it will trigger > an SSL cert error. Ignore it or drop back to HTTP at your own > preference. >=20 > Anyway, there are a number of people on this list in particular who I > think could make sure that I haven't catastrophically cocked the whole > thing up. I don't think I have, but that's precisely when you should > double-check to be sure. >=20 > So if as many of you as can spare the time could please weigh in and > try to pick it apart; that'd be greatly appreciated. It'll help make > it stronger. Those of you who've already been down the protocol > design path are amongst those I'm particularly keen on checking this > thing. >=20 > I do realise there are still matters to discuss and finalise with > regards to transmission of keys; currently there are multiple options > included and I expect some discussion around that. There's also two > versions of the Encrypted Note and I'm inclined to favour the second, > slightly more complex version for a number of reasons; including > working with other functions (like nesting a Signed Note inside it in > a similar manner to signed & encrypted PGP/MIME emails). >=20 >=20 > Regards, > Ben >=20 > P.S. I'm cross-posting this to the IETF OpenPGP WG mailing list on > the off chance that there might be subscribers to that who are > not also subscribed here or to gnupg-devel. That may not be > very likely, but it is possible and so a copy there doesn't > hurt. Apologies to those who will see it twice as result, > though. Especially since you're the ones I'm most keen to want > reviewing this work. >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --------------84E37103645E89A1553D51D1 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----- --------------84E37103645E89A1553D51D1-- --uDDNU4oEEvq7CD7r8JvlaYpa95zpHRg3B-- --wIGdo9lpJZ41zHNEEoLAWQoIF1EabK36y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxis2UACgkQWrL68XsX K+qUNQ/8DG7naKdy0RmJT7mYI6XZIiF0tH9eqBnQk5bEfvSEjegcZTdMADNmIjG4 riZtjzq2VrbDiPL60v2hLQM0uKBG64+Jymbb26rx53Ebc8tof7i2RDuyO5AqN7yR JlBOFUKW1wefq2kkJnbzupK6NrnFcfrjD69B1P0zkr6ZcE7N1zWe9BVOfz909dDy WuPXR8Ly93GEQp78k+YjI+15ed4uZRvQSpX4E76XFImhxfKMM+YIkYMx1iZ/h6Vy ISfQLpDt2MmAxjuHwIFyK6ItVc3lc05mVWPY1dKn8fXk3mJFFtDUvrxsPgUYISaH q/4Kmh3G7ThwV5sNpU5hAyplma83ywg/WFVuZ7+HHk46MbfAgU/Szu9SVhkHn2ni 2cgzgo8TXBhG2DT9S8UZuVFqwweZOwLKmQ739KaJ+tmx9RQ6/CBUyPVvSFtBMHBo U6pkMD9EnYLPyWzW6bwSvI2k/qP6zjgL+iC8w4DOfXZHnvnIKpCv4W4IXOD+JY0t JppmSSZFuWY3ww+Ebke9e8v9K6PlAzBDqsD9VXWDl2Gzs0QiSWFGt8X3XJyXXua0 HE14WqotwVey7gUkgaQd/Eun+R/jIlWEVtS6QpUcg0tLW1StdRotF+U4gsEfkPXB j4Rbif35UEmLhKSM9k8dXENc1PWQ/9vayCoL1gjEI7uq2nlXG1E= =bafz -----END PGP SIGNATURE----- --wIGdo9lpJZ41zHNEEoLAWQoIF1EabK36y-- From nobody Tue Feb 12 18:33:05 2019 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 C3DD9130F0D for ; Tue, 12 Feb 2019 18:33:03 -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 jz0RJnY7-MCq for ; Tue, 12 Feb 2019 18:33:01 -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 EC9CC130F09 for ; Tue, 12 Feb 2019 18:33:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43zk8V21hmz2DP; Wed, 13 Feb 2019 03:32:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550025178; bh=uWZdk7SjKp+2y5IWgjkN2zkx3govtOV+1DT3utgBA0o=; h=Date:From:To:cc:Subject; b=PpbNWaRCI6aFZwOBCOHLmMXYoGdAMttm1czluymKrYEVs2wa3xNfShTDwuNN+D6M1 93eWWI46N/NiWSe5Hp449A98wpkJFlC7DXCYDu4Xmity4IyLyMzaDo8CYmpTdtiQ7G glZ907kXRhEG3CqWlX70UvkZ4eZ24UcCfAYCcGdc= 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 NrJzxyQpXAL1; Wed, 13 Feb 2019 03:32:56 +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, 13 Feb 2019 03:32:55 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 63A04A7E0C; Tue, 12 Feb 2019 21:32:54 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 63A04A7E0C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 57ADD40D358A; Tue, 12 Feb 2019 21:32:54 -0500 (EST) Date: Tue, 12 Feb 2019 21:32:54 -0500 (EST) From: Paul Wouters To: openpgp@ietf.org cc: micah.lee@theintercept.com, nat.welch@firstlook.media Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [openpgp] comments on draft-mccain-keylist-02 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, 13 Feb 2019 02:33:04 -0000 Via twitter I noticed this draft: https://tools.ietf.org/html/draft-mccain-keylist-02 I have some comments on the draft. I've added the authors to the CC: since I'm not sure if they are on this list. First a procedural item. Section 1.3 states: 1.3. Note to Readers RFC Editor: please remove this section prior to publication. Development of this Internet draft takes place on GitHub at Keylist- RFC [1]. A mailing list is available for discussion at Keylists mailing list [2]. I just wanted to share with the authors that this is not the way one writes RFCs. RFC's and the IETF are covered by rules, such as the Note Well. Please see https://www.ietf.org/about/note-well/ This is important because everyone discussing this draft on this list is expected to fall under the rules of the Note Well, meaning they cannot go out and get a patent and not mention anything until this document is an RFC, and then start charging money. And discussion at an external site as the draft authors suggest, is not protected by this mechanism. Furthermore, IETF carefully archives all mailinglist messages which can later also be used in discovery but also for late-comers to the discussion. If an outside website suddenly vanishes, all this information is lost. Finally, IETF has Chairs and a Sergant-at-arms to guide any on-list discussion. elsewhere, we fall under other possibly arbitrary rules. I'm not saying your suggested locations are (I didn't go there) but as a rule discussions on internet drafts happen on internet lists. Work elsewhere is brought back to the IETF. Eg you can make a pull request on github but you discuss this on an IETF list. Now to the draft itself, Section 2 talks about subscribing to "key lists", where a "key list" is defined as an URI to something and a fingerprint of a public key that is authorative for this list. Section 2.2 talks about regularly updating the key list, and performing daily checks at the URI. I think this could be a privacy issue, and one could track a traveling journalist based on their key list sync checks. section 3. The key list is a JSON format that can contain a reference to an external key server. This also sounds a bit dangerous to me. Instead of all clients forking out to possibly many key server locations, why isn't the "key list" simply an openpgp format public keyring, with trust attributes set properly by the "management key" ? Clients can HEAD the file and if there is an update, GET the file via HTTP and import the updates. I don't understand why there is indirection allowed or required in this idea. Because no openpg keyring format is used, this "key list" needs to be separately signed by the management pgp key. It adds another level of indirection that could be avoided. If I have sufficient "trust" set in my personal keyring to trust updates from the manager key, then I can get the updated in openpgp format without further new protocols already. The "key list" contains comments such as an signature_uri that allows the key list URI and the signature to be located on different systems? Why would that ever be useful or more secure than doing a cleartext signature on the file itself hosted on the same server as the key list file itself? A key list entry contains a fingerprint, name and email field? So in essence, this becomes a meta key-server. Why give participants all these indirections, instead of just providing the openpgp keyring itself? Why is the key list not optionally (but hopefully) encryped to the participants to avoid a privacy leak to anyone who obtains the key list URI ? A key list entry has concept of a last updated time stamp. Does this mean that every "sync" I go out to all individual key servers to get keys from all participants just in case they might have updated their keys on the keyserver / fileserver of their choice? It seems this process is an ideal process for the centralized manager key to perform, instead of all participants? Section 4. The "in practise" section is usually called the Impliementation Status section. Please see https://tools.ietf.org/html/rfc7942 on how to write these. (for example, to avoid publishing it in the final RFC) Section 5. The security considerations usually does not contain the benefits. Those are the features offered and described in the document itself. This section deals more with the concerns or practical issues or general safe practises one has to keep in mind. Usually with a focus on implementors more than endusers. For guidelines on how to write a Security Consideration section, see https://tools.ietf.org/html/rfc3552 The three benefits listed do not convey to me why this solution with a level on indirection is better suited that using a openpgp keyring at the location. I would rewrite 5.2 a bit. Yes the security of this system is only as strong as the security of the manager key. But how does one convey this management key? How is this key verified? What to do when the key IDs are different? What to do when the key list can be obtained but not the individual key servers listed for some participants. How often to retry? when to warn the user? How does one recover from a management key loss or compromise? How does the manager / key talk to its users about anything? The biggest problem though is that I see no attempt at providing confidentiality for a key list. Anyone with the URI can get the list of participants. Why not introduce a .well-known location that any organisation can use, so we could try and find key lists for organisations we never talked to before. Perhaps specify a mechanism on how to verify an organisational management key? What to do when the email on the key list points to a key lacking that key ID ? Why not use https://wiki.gnupg.org/WKD ? Why not use OPENPGPKEY DNS records? While automatic sync is a nice feature, over-syncing is a privacy risk, especially for people who are trying to remain anonymous. All in all, this seems like an interesting application, and worth further discussion (on this list). I am not yet convinced this is an protocol issue and not an application issue. Paul From nobody Wed Feb 13 03:11:10 2019 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 EF14212D84D for ; Wed, 13 Feb 2019 03:11: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nlrQSjuGGjiC for ; Wed, 13 Feb 2019 03:11:05 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 49B04128CB7 for ; Wed, 13 Feb 2019 03:11:03 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id g2so1431409lfh.11 for ; Wed, 13 Feb 2019 03:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H3HaoI+z5Q/XsCokUYN8lP3HKWQcAhWyt9XlBi+TtsI=; b=Pk8YsrwH/a6TJBUYOav7DwXmG9MrB1x8/IRluXp6PPoTnDYsZQBzjeXrmyGfkXYkFX mlJUYUUqn/kbct0A4gbBLj1rwlq+LrTNcG+cWfz6VpJXKehfv2c0WjY0AlPGEfZAE3oW 46uw2F/XbvX3X4UsBxiJKY9Yhmx632wgl0Wd3AUzqpjuIdzAVRblnby7tN14TcaG7Ztz Mdn7q/N53QUi8MRNMcJhgMblOtDcIM0cD7sImEZZROgZOINVsh9En2O0n+OcN0I4Nep7 goDhwYpz0WdxIIKBMRMBcXkhqzAsB5yrrUwLRPVX5oah245v+UCzRmxiIBxeo5Fs0sDT 3HTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=H3HaoI+z5Q/XsCokUYN8lP3HKWQcAhWyt9XlBi+TtsI=; b=DRu43myvKVh6KVVNEvA6GcuSfC88jw/x0jVsHrFQ66Nk7GyF00pEpl2KpE8jjxDTaS +xUR9WkjuwZVt+hz/2Ucir0iAZTbzxGWbrtx5u1X/Yo86o9MvkJ8BRZcAP55+B+aCg19 RoWF4Arcxv/Mr+XEmK5ersf8OngF5tPgyBZbxmYFOP9R/yN8uZ4jX1JM3Cq4M+/ZzEWQ CVWjvPwESjJMOrGH4XHWvJ/jt33NSrgxs9fRlv5MyerzV0eDBOnSfPzg7XizXFJEpJ5p ojUT3iIAZWTs21H/F4btQVwrqO4RU/HWNq1Km2ONdPNMFeNz+5wYAPIQgekSn7BKREV2 o6Cw== X-Gm-Message-State: AHQUAuYr7nYxpVCZiDf00XXE+K168a7DZ1/eZftlFR0+YFY0xZmaRroc O5QubJKIFqzrLSjGLd80eyf9aw== X-Google-Smtp-Source: AHgI3IbCeAcZLToaBLFthizStdzrtzIJuaWkzxsYd5kVCyeKnEaxXi6FntuKgqBME00GfNZbHCszCg== X-Received: by 2002:a19:645e:: with SMTP id b30mr5439772lfj.15.1550056261832; Wed, 13 Feb 2019 03:11:01 -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 l12-v6sm3354850lja.13.2019.02.13.03.11.00 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 03:11:01 -0800 (PST) To: Paul Wouters Cc: openpgp@ietf.org, micah.lee@theintercept.com, nat.welch@firstlook.media References: From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/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/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: Date: Wed, 13 Feb 2019 12:10:50 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] comments on draft-mccain-keylist-02 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, 13 Feb 2019 11:11:09 -0000 Hello, Excellent points and I'm glad that the draft has been published on this ML for a discussion in a wider audience. As far as I understood draft-mccain-keylist-02 its goals can already be achieved with a combination of already existing features: 1. Discovering keys for company employees - using "e-mail to key" lookup (e.g. WKD) 2. Trusting that these keys are authentic - by signing an Authority Key and setting ownertrust to full. This can be done only once and it works for all future keys. Even with draft-mccain-keylist-02 one needs to do that to know which keys are trusted. There is one variation of this scheme - by using Trust Signatures one can trust Authority Key to keys from the company domain only. 3. Keeping keys up to date - why not just refresh all keys in the local keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will refresh expired keys over WKD if they were fetched with WKD [0]). [0]: https://dev.gnupg.org/T2917 If the problem is that people verify signatures and the keys are not present I think applications have appropriate options to fetch keys automatically (e.g. `gpg --auto-key-retrieve`). I like the point of using .well-known for a keyring of all people but from what I've heard on GitHub the ability to host keylist on a different domain is desired: > There's no reason to trust the server that hosts the keylist file. We already don't trust it -- FLM hosts our keylist on GitHub. Source: https://github.com/firstlookmedia/keylist-rfc/issues/8#issuecomment-426846582 Kind regards, Wiktor -- https://metacode.biz/@wiktor From micah.lee@theintercept.com Wed Feb 13 12:31:40 2019 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 0B48E128B01 for ; Wed, 13 Feb 2019 12:31:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=theintercept.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 Zr-wV64zvinS for ; Wed, 13 Feb 2019 12:31:35 -0800 (PST) Received: from mail.newconews.org (central-mail01.newconews.org [8.25.220.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34601200B3 for ; Wed, 13 Feb 2019 12:31:35 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.newconews.org (Postfix) with ESMTP id 7A08B3FEC23; Wed, 13 Feb 2019 20:31:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=theintercept.com; s=ticom20140908; t=1550089894; bh=G7rLBBU6Se5NgdoOI9GzDB61a/Aaygtagq28lZP+hm4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=zfjq7Um2Lu+JX7pKUzJm09j3qFsoT2lESsD0OiqFQ6fpqWZWu1JJCo22XjWDgPQqW dxUszdbChO73b3Y1Z66ksxWPuAE/E0r0eehLwqUVCp6E4Z46ZuOGnzyHS8POS+QlKJ 3Y6fZtAMvcxxlOxlKse6Q2Ubx86amdZzTdaL9nI0= Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.newconews.org (Postfix) with ESMTPSA id 10DA03FDC44; Wed, 13 Feb 2019 20:31:34 +0000 (UTC) To: Paul Wouters , openpgp@ietf.org, keylists@freelists.org Cc: nat.welch@firstlook.media, miles@rmrm.io References: From: Micah Lee Openpgp: preference=signencrypt Message-ID: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> Date: Wed, 13 Feb 2019 12:31:33 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [openpgp] comments on draft-mccain-keylist-02 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, 13 Feb 2019 20:42:39 -0000 Hello, I'm adding Miles McCain to this email, who is one of the authors you left out. And I'm also adding the keylists@freelists.org mailing list. On 2/12/19 6:32 PM, Paul Wouters wrote: > Via twitter I noticed this draft: > > https://tools.ietf.org/html/draft-mccain-keylist-02 Note that a new draft has since been published, however the changes are minor: https://tools.ietf.org/html/draft-mccain-keylist-03 > I have some comments on the draft. I've added the authors to the CC: > since I'm not sure if they are on this list. > > First a procedural item. Section 1.3 states: > >    1.3.  Note to Readers > >    RFC Editor: please remove this section prior to publication. > >    Development of this Internet draft takes place on GitHub at Keylist- >    RFC [1]. > >    A mailing list is available for discussion at Keylists mailing list >    [2]. > > > I just wanted to share with the authors that this is not the way one > writes RFCs. RFC's and the IETF are covered by rules, such as the Note > Well. Please see https://www.ietf.org/about/note-well/ > > This is important because everyone discussing this draft on this list is > expected to fall under the rules of the Note Well, meaning they cannot > go out and get a patent and not mention anything until this document is > an RFC, and then start charging money. And discussion at an external > site as the draft authors suggest, is not protected by this mechanism. > > Furthermore, IETF carefully archives all mailinglist messages which can > later also be used in discovery but also for late-comers to the > discussion. If an outside website suddenly vanishes, all this > information is lost. Finally, IETF has Chairs and a Sergant-at-arms to > guide any on-list discussion. elsewhere, we fall under other possibly > arbitrary rules. I'm not saying your suggested locations are (I didn't > go there) but as a rule discussions on internet drafts happen on > internet lists. Work elsewhere is brought back to the IETF. Eg you can > make a pull request on github but you discuss this on an IETF list. It's good to understand how RFCs are supposed to get discussed and written. I, as well as the other two authors, are new to the IETF process. However I don't see how the Note Well is especially relevant to this draft RFC, as there has been no talk about patents. We have a mailing list for this project (keylists@freelists.org) though admittedly we haven't been using it. Instead we've been using a chat room hosted by a third party. Can you point to a document that describes the policy you're referencing about where discussion of the RFC should take place, and also where collaboration of writing the actual document should take place? We definitely want to be transparent about the whole process. > Now to the draft itself, > > > Section 2 talks about subscribing to "key lists", where a "key list" is > defined as an URI to something and a fingerprint of a public key that is > authorative for this list. > > > Section 2.2 talks about regularly updating the key list, and performing > daily checks at the URI. I think this could be a privacy issue, and one > could track a traveling journalist based on their key list sync checks. It's true that there's a potential privacy issue with regularly fetching updates, but it's the same issue that all subscription systems have, such as Atom feeds (RFC 4287). It's also the same issue if you configure gpg to refresh your keyring on a regularly interval. This privacy issue is more of a fundamental problem with how networking works than with any specific standard that relies on subscribing to a regularly-changing document, so I don't think it's in scope for this specific RFC to tackle. However, GPG Sync, software that already implements the draft keylist RFC, supports an option mitigate this issue by making it simple to fetch updates over Tor: https://github.com/firstlookmedia/gpgsync/wiki/Using-GPG-Sync-with-Tor > section 3. > > The key list is a JSON format that can contain a reference to an > external key server. This also sounds a bit dangerous to me. Instead of > all clients forking out to possibly many key server locations, why isn't > the "key list" simply an openpgp format public keyring, with trust > attributes set properly by the "management key" ? Clients can HEAD the > file and if there is an update, GET the file via HTTP and import the > updates. I don't understand why there is indirection allowed or required > in this idea. > > Because no openpg keyring format is used, this "key list" needs to be > separately signed by the management pgp key. It adds another level of > indirection that could be avoided. If I have sufficient "trust" set > in my personal keyring to trust updates from the manager key, then > I can get the updated in openpgp format without further new protocols > already. > > The "key list" contains comments such as an signature_uri that allows > the key list URI and the signature to be located on different systems? > Why would that ever be useful or more secure than doing a cleartext > signature on the file itself hosted on the same server as the key > list file itself? > > A key list entry contains a fingerprint, name and email field? So in > essence, this becomes a meta key-server. Why give participants all > these indirections, instead of just providing the openpgp keyring > itself? > > > Why is the key list not optionally (but hopefully) encryped to the > participants to avoid a privacy leak to anyone who obtains the key list > URI ? > > A key list entry has concept of a last updated time stamp. Does this > mean that every "sync" I go out to all individual key servers to get > keys from all participants just in case they might have updated their > keys on the keyserver / fileserver of their choice? It seems this > process is an ideal process for the centralized manager key to perform, > instead of all participants? GnuPG keyrings are not defined by an internet standard. They're a custom format that GPG developers made up, and have changed over time (for example gpg2 keyrings aren't compatible with gpg1). Having keylists rely on GPG keyrings would make it unfeasible for non-GPG OpenPGP users to subscribe to an organization's keylist. The relevant standard you're probably thinking of is RFC 4880 which defines the OpenPGP message format, basically the "-----BEGIN PGP PUBLIC KEY BLOCK-----"-type blocks. But that format isn't appropriate for keylist subscriptions. Keylists don't include full public keys, they only include fingerprints. Information in public keys themselves change frequently -- the owner of the key might add a UID, update their expiration date, or otherwise modify their key. If keylists included actual full public keys, then the person maintaining the keylist would have to update it not just when a new key is added, but every single time anyone in the the organization modifies their key. One of the main purposes of keylists is to reduce the amount of work required to ensure that everyone in an organization (or anyone who wishes to communicate with members of that organization) has the correct public key for everyone else. Including full public keys in the keylist would be counterproductive. The keylist that my company relies on currently has 228 fingerprints on it, and it would add a ridiculous amount of pointless work to maintain it if we had to keep track of minor changes in each key (and get copies of those changed public keys from their owners), when instead we can just keep track of fingerprints. > Section 4. > > The "in practise" section is usually called the Impliementation Status > section. Please see https://tools.ietf.org/html/rfc7942 on how to write > these. (for example, to avoid publishing it in the final RFC) This is good feedback. > Section 5. > > The security considerations usually does not contain the benefits. Those > are the features offered and described in the document itself. This > section deals more with the concerns or practical issues or general > safe practises one has to keep in mind. Usually with a focus on > implementors more than endusers. For guidelines on how to write a > Security Consideration section, see https://tools.ietf.org/html/rfc3552 > > The three benefits listed do not convey to me why this solution with a > level on indirection is better suited that using a openpgp keyring > at the location. > > I would rewrite 5.2 a bit. Yes the security of this system is only as > strong as the security of the manager key. But how does one convey this > management key? How is this key verified? What to do when the key IDs > are different? What to do when the key list can be obtained but not > the individual key servers listed for some participants. How often to > retry? when to warn the user? How does one recover from a management > key loss or compromise? How does the manager / key talk to its users > about anything? Interesting, I'll take a look at the Security Considerations document. > The biggest problem though is that I see no attempt at providing > confidentiality for a key list. Anyone with the URI can get the list > of participants. Keylists are public documents, and anyone can subscribe to them even if they're not a member of the organization. It might be worth considering the case where people wish to have private keylists, but it's not something we have considered yet. > Why not introduce a .well-known location that any organisation can > use, so we could try and find key lists for organisations we never > talked to before. Perhaps specify a mechanism on how to verify an > organisational management key? We considered introducing a .well-known location, but, as described in the draft: To subscribe to a keylist, the client must be aware of the keylist URI (see [RFC3986]), and the fingerprint of the authority key used to sign the keylist. A client must have both the keylist URI and the fingerprint of the authority key to subscribe to it -- just the keylist URI is not enough, which means a .well-known location would have to also include the authority key fingerprint. Doing this would ultimately make the trust of the entire system rely on the security of the organization's web server, and on HTTPS, as opposed to on the authority key. And there's a further issue related to domains names which I describe below. > What to do when the email on the key list points to a key lacking that > key ID ? As described in the draft, only the "fingerprint" field of the key is required, and all other fields (name, email, comments, and any other arbitrary metadata) are optional, and only there for the sake of the organization maintaining the keylist. Clients simply fetch the fingerprint. > Why not use https://wiki.gnupg.org/WKD ? > > Why not use OPENPGPKEY DNS records? The members of an organization frequently don't have email addresses at the same domain name. For example, my organization includes email addresses at firstlook.org, firstlook.media, theintercept.com, fieldofvision.org, topic.com, among other domains, not to mention we frequently add personal email addresses hosted at gmail.com or other email services, as well as university email servers, for interns, freelancers, or other temporary workers. And some organizational keys contain UIDs that don't include email addresses at all. Still, we want to include all of these fingerprints on our keylist. A keylist contains a list of fingerprints for public keys everyone in the organization should have. It would add more pointless work to maintain this system if we chose to arbitrarily require that they all keys contain UIDs with email addresses for the same domain name. Also, not all organizations even have a domain name of their own (for example, a free software project where the code and releases are hosted on GitLab.com, and members of the project use personal email addresses). > While automatic sync is a nice feature, over-syncing is a privacy risk, > especially for people who are trying to remain anonymous. This is outside the scope of this RFC. Like I described above, Atom feeds, and existing automated use of key servers, have always had this problem. (Also, people trying to remain anonymous need to do quite a bit more than just not automatically fetch PGP keys. It requires using an operating system designed for such a use-case, like Tails, in which case subscribing to keylists would be perfect fine, and would not compromise anonymity.) > All in all, this seems like an interesting application, and worth > further discussion (on this list). I am not yet convinced this is > an protocol issue and not an application issue. > > Paul > And finally, I'll also reply to Wiktor's feedback. (Quoting in full for Miles' sake.) On 2/13/19 3:10 AM, Wiktor Kwapisiewicz wrote:> Hello, > > Excellent points and I'm glad that the draft has been published on this > ML for a discussion in a wider audience. > > As far as I understood draft-mccain-keylist-02 its goals can already be > achieved with a combination of already existing features: > > 1. Discovering keys for company employees - using "e-mail to key" lookup > (e.g. WKD) > > 2. Trusting that these keys are authentic - by signing an Authority Key > and setting ownertrust to full. This can be done only once and it works > for all future keys. Even with draft-mccain-keylist-02 one needs to do > that to know which keys are trusted. There is one variation of this > scheme - by using Trust Signatures one can trust Authority Key to keys > from the company domain only. > > 3. Keeping keys up to date - why not just refresh all keys in the local > keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will > refresh expired keys over WKD if they were fetched with WKD [0]). > > [0]: https://dev.gnupg.org/T2917 > > If the problem is that people verify signatures and the keys are not > present I think applications have appropriate options to fetch keys > automatically (e.g. `gpg --auto-key-retrieve`). > > I like the point of using .well-known for a keyring of all people but > from what I've heard on GitHub the ability to host keylist on a > different domain is desired: > >> There's no reason to trust the server that hosts the keylist file. We >> already don't trust it -- FLM hosts our keylist on GitHub. > > Source: > https://github.com/firstlookmedia/keylist-rfc/issues/8#issuecomment-426846582 > > > Kind regards, > Wiktor I've already addresses some of this, but: It's important for my company's use-case, and probably that of many other organizations, to not tie a keylist to one specific domain name, and to allow the keylist to include keys for personal email address (e.g. gmail.com) as well as keys with UIDs that don't contain email addresses at all. WKD is simply insufficient for this use-case. (It also has the problem where if a member of the organization updates their key, they can't push their updated key into the WKD like they can to a key server.) It's true that we could bootstrap a system like `gpg --refresh-keys` combined with cron (or more realistically launchd on macOS) to keep keys up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we don't necessarily want to update all keys in every user's keychain, only the keys on the keylists they're subscribed to. Only refreshing keys listed on a keylist leaks less information to key servers than refreshing all keys -- it leaks what keylists you're subscribed to. But, most importantly, and in fact the reason we developed GPG Sync to begin with (which ultimately lead to writing this draft RFC), what isn't possible with existing tools is to get everyone in an organization to automatically fetch *new* keys that they otherwise wouldn't be aware of. For example, lets say we hire a new intern, and they generate a PGP key for their mit.edu email address. How do we get hundreds of people's computers to automatically fetch that key so they can email this intern without having to do manually fetch it and verify it first? Or, let's say an employee loses their Yubikey, so they publish their revocation certificate and generate a new key. How do we get those hundreds of computers to fetch the revoked key, as well as the new key, so that the next time someone sends an encrypted email to that person, it just works? From nobody Wed Feb 13 12:50:46 2019 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 C8C3712E7C1 for ; Wed, 13 Feb 2019 12:50:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rmrm.io Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vfSGH6jJyuw for ; Wed, 13 Feb 2019 12:50:33 -0800 (PST) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 39A621200D7 for ; Wed, 13 Feb 2019 12:50:32 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id q128so3214312ljb.11 for ; Wed, 13 Feb 2019 12:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rmrm.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6KsmghrISfpz/YyjjpXdXZsgv4LkrgVAx1WAzMMfdBw=; b=cEq5DXgOIg55LV97Wq6GmY1cgzSFHWzbAuAN1waVV+nBB8RcfVwwG1eV1bGEX3GTEt AkESkglBgn1i80mk15iR2Vdu0f2kFXPOlvxjWNljXGzFf6wvXKvLavH6biXyCAqwyLPw LukGosY6skffZvO/0UjiQGkPRrnQLsKRPsPTeV8OgNJ1b65VGFf+48ax8ILhauKwUcku ufsRBZ3qVD8BiE0FWy207S99W78mdqvHXqWd94InaQdL/mj1Y/RXlwkmoEwp1T868ZFj GgVglSX3U4/YdgkVeXZDAGRYae/4gAU3p9P6okbkbMYq/0NesrAbaJ4cWDoZQ/WirNZC UKHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6KsmghrISfpz/YyjjpXdXZsgv4LkrgVAx1WAzMMfdBw=; b=ba78BxZNGGWpKyiliJPFwXalzgiEnfnhD3blAml/uxcQoIJ1RFPaMWPFeTXmxjmskJ JS0gtjhfKN8bXwpWcsTsdLMphL4KVUiWaUHTG0W9mLxaZyNbHsOd4ViR8EesyL18xWH7 JZAsukEhmvjZ7ObVevKNjCYRizmGzJsTPG4KO2uOGBlMSOhT0dRW1n664Kh0Gdk4sMl1 Vptqh6Iw++dWQn9QfpQkJspGi4cXLsK9SHvTstN6sVfjGaMQF3MGBdbd0zSTiZmSP9Md CQc5vm88OJHtZ16K9g2E6/mLmpsHdGyNpbwYnSU2yz9KzHMmIvVX/HmhAFRnDepJM0cm KAaA== X-Gm-Message-State: AHQUAuaocvVx1SVkfhCTlHvFoHugAImAwYxx4liibRnvBJDj/48b39RV 6bgv9/rhhr8+t3AfXUbGRcMQsmELJJmVlXvnoL2T0g== X-Google-Smtp-Source: AHgI3IaT2nJB1kwUALC1MRfTr6KZicYTDm5QhtwUfPNOQ4OnanjwHsN4FP0adH204vyLt1dmXSBz0o7PamtQjiNbuKw= X-Received: by 2002:a2e:6109:: with SMTP id v9-v6mr54538ljb.126.1550091029367; Wed, 13 Feb 2019 12:50:29 -0800 (PST) MIME-Version: 1.0 References: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> In-Reply-To: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> From: "R. Miles McCain" Date: Wed, 13 Feb 2019 15:50:18 -0500 Message-ID: To: Micah Lee Cc: Paul Wouters , openpgp@ietf.org, keylists@freelists.org, nat.welch@firstlook.media Content-Type: multipart/alternative; boundary="0000000000002ce81f0581ccb100" Archived-At: Subject: Re: [openpgp] comments on draft-mccain-keylist-02 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, 13 Feb 2019 20:50:42 -0000 --0000000000002ce81f0581ccb100 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Micah, for adding me to this email. I would like to just add here that our freelists.org mailing list has yet to be meaningfully used, and we would be absolutely willing to move discussion to an appropriate IETF-managed mailing list. (Because our draft has yet to be assigned to/adopted by any working group, we didn't have an IETF mailing list we could use for discussion.) That being said, we have made our best efforts to encourage discussion within the IETF community=E2=80=94including announcing our draft to SecDisp= atch. Thank you for the useful comments so far; we will work to incorporate this feedback in future versions of the draft. Miles On Wed, Feb 13, 2019 at 3:31 PM Micah Lee wrote: > Hello, > > I'm adding Miles McCain to this email, who is one of the authors you > left out. And I'm also adding the keylists@freelists.org mailing list. > > On 2/12/19 6:32 PM, Paul Wouters wrote: > > Via twitter I noticed this draft: > > > > https://tools.ietf.org/html/draft-mccain-keylist-02 > > Note that a new draft has since been published, however the changes are > minor: https://tools.ietf.org/html/draft-mccain-keylist-03 > > > I have some comments on the draft. I've added the authors to the CC: > > since I'm not sure if they are on this list. > > > > First a procedural item. Section 1.3 states: > > > > 1.3. Note to Readers > > > > RFC Editor: please remove this section prior to publication. > > > > Development of this Internet draft takes place on GitHub at Keylist- > > RFC [1]. > > > > A mailing list is available for discussion at Keylists mailing list > > [2]. > > > > > > I just wanted to share with the authors that this is not the way one > > writes RFCs. RFC's and the IETF are covered by rules, such as the Note > > Well. Please see https://www.ietf.org/about/note-well/ > > > > This is important because everyone discussing this draft on this list i= s > > expected to fall under the rules of the Note Well, meaning they cannot > > go out and get a patent and not mention anything until this document is > > an RFC, and then start charging money. And discussion at an external > > site as the draft authors suggest, is not protected by this mechanism. > > > > Furthermore, IETF carefully archives all mailinglist messages which can > > later also be used in discovery but also for late-comers to the > > discussion. If an outside website suddenly vanishes, all this > > information is lost. Finally, IETF has Chairs and a Sergant-at-arms to > > guide any on-list discussion. elsewhere, we fall under other possibly > > arbitrary rules. I'm not saying your suggested locations are (I didn't > > go there) but as a rule discussions on internet drafts happen on > > internet lists. Work elsewhere is brought back to the IETF. Eg you can > > make a pull request on github but you discuss this on an IETF list. > > It's good to understand how RFCs are supposed to get discussed and > written. I, as well as the other two authors, are new to the IETF > process. However I don't see how the Note Well is especially relevant to > this draft RFC, as there has been no talk about patents. > > We have a mailing list for this project (keylists@freelists.org) though > admittedly we haven't been using it. Instead we've been using a chat > room hosted by a third party. > > Can you point to a document that describes the policy you're referencing > about where discussion of the RFC should take place, and also where > collaboration of writing the actual document should take place? We > definitely want to be transparent about the whole process. > > > Now to the draft itself, > > > > > > Section 2 talks about subscribing to "key lists", where a "key list" is > > defined as an URI to something and a fingerprint of a public key that i= s > > authorative for this list. > > > > > > Section 2.2 talks about regularly updating the key list, and performing > > daily checks at the URI. I think this could be a privacy issue, and one > > could track a traveling journalist based on their key list sync checks. > > It's true that there's a potential privacy issue with regularly fetching > updates, but it's the same issue that all subscription systems have, > such as Atom feeds (RFC 4287). It's also the same issue if you configure > gpg to refresh your keyring on a regularly interval. > > This privacy issue is more of a fundamental problem with how networking > works than with any specific standard that relies on subscribing to a > regularly-changing document, so I don't think it's in scope for this > specific RFC to tackle. > > However, GPG Sync, software that already implements the draft keylist > RFC, supports an option mitigate this issue by making it simple to fetch > updates over Tor: > > https://github.com/firstlookmedia/gpgsync/wiki/Using-GPG-Sync-with-Tor > > > section 3. > > > > The key list is a JSON format that can contain a reference to an > > external key server. This also sounds a bit dangerous to me. Instead of > > all clients forking out to possibly many key server locations, why isn'= t > > the "key list" simply an openpgp format public keyring, with trust > > attributes set properly by the "management key" ? Clients can HEAD the > > file and if there is an update, GET the file via HTTP and import the > > updates. I don't understand why there is indirection allowed or require= d > > in this idea. > > > > Because no openpg keyring format is used, this "key list" needs to be > > separately signed by the management pgp key. It adds another level of > > indirection that could be avoided. If I have sufficient "trust" set > > in my personal keyring to trust updates from the manager key, then > > I can get the updated in openpgp format without further new protocols > > already. > > > > The "key list" contains comments such as an signature_uri that allows > > the key list URI and the signature to be located on different systems? > > Why would that ever be useful or more secure than doing a cleartext > > signature on the file itself hosted on the same server as the key > > list file itself? > > > > A key list entry contains a fingerprint, name and email field? So in > > essence, this becomes a meta key-server. Why give participants all > > these indirections, instead of just providing the openpgp keyring > > itself? > > > > > > Why is the key list not optionally (but hopefully) encryped to the > > participants to avoid a privacy leak to anyone who obtains the key list > > URI ? > > > > A key list entry has concept of a last updated time stamp. Does this > > mean that every "sync" I go out to all individual key servers to get > > keys from all participants just in case they might have updated their > > keys on the keyserver / fileserver of their choice? It seems this > > process is an ideal process for the centralized manager key to perform, > > instead of all participants? > > GnuPG keyrings are not defined by an internet standard. They're a custom > format that GPG developers made up, and have changed over time (for > example gpg2 keyrings aren't compatible with gpg1). Having keylists rely > on GPG keyrings would make it unfeasible for non-GPG OpenPGP users to > subscribe to an organization's keylist. > > The relevant standard you're probably thinking of is RFC 4880 which > defines the OpenPGP message format, basically the "-----BEGIN PGP PUBLIC > KEY BLOCK-----"-type blocks. But that format isn't appropriate for > keylist subscriptions. > > Keylists don't include full public keys, they only include fingerprints. > Information in public keys themselves change frequently -- the owner of > the key might add a UID, update their expiration date, or otherwise > modify their key. If keylists included actual full public keys, then the > person maintaining the keylist would have to update it not just when a > new key is added, but every single time anyone in the the organization > modifies their key. > > One of the main purposes of keylists is to reduce the amount of work > required to ensure that everyone in an organization (or anyone who > wishes to communicate with members of that organization) has the correct > public key for everyone else. > > Including full public keys in the keylist would be counterproductive. > The keylist that my company relies on currently has 228 fingerprints on > it, and it would add a ridiculous amount of pointless work to maintain > it if we had to keep track of minor changes in each key (and get copies > of those changed public keys from their owners), when instead we can > just keep track of fingerprints. > > > Section 4. > > > > The "in practise" section is usually called the Impliementation Status > > section. Please see https://tools.ietf.org/html/rfc7942 on how to write > > these. (for example, to avoid publishing it in the final RFC) > > This is good feedback. > > > Section 5. > > > > The security considerations usually does not contain the benefits. Thos= e > > are the features offered and described in the document itself. This > > section deals more with the concerns or practical issues or general > > safe practises one has to keep in mind. Usually with a focus on > > implementors more than endusers. For guidelines on how to write a > > Security Consideration section, see https://tools.ietf.org/html/rfc3552 > > > > The three benefits listed do not convey to me why this solution with a > > level on indirection is better suited that using a openpgp keyring > > at the location. > > > > I would rewrite 5.2 a bit. Yes the security of this system is only as > > strong as the security of the manager key. But how does one convey this > > management key? How is this key verified? What to do when the key IDs > > are different? What to do when the key list can be obtained but not > > the individual key servers listed for some participants. How often to > > retry? when to warn the user? How does one recover from a management > > key loss or compromise? How does the manager / key talk to its users > > about anything? > > Interesting, I'll take a look at the Security Considerations document. > > > The biggest problem though is that I see no attempt at providing > > confidentiality for a key list. Anyone with the URI can get the list > > of participants. > > Keylists are public documents, and anyone can subscribe to them even if > they're not a member of the organization. > > It might be worth considering the case where people wish to have private > keylists, but it's not something we have considered yet. > > > Why not introduce a .well-known location that any organisation can > > use, so we could try and find key lists for organisations we never > > talked to before. Perhaps specify a mechanism on how to verify an > > organisational management key? > > We considered introducing a .well-known location, but, as described in > the draft: > > To subscribe to a keylist, the client must be aware of the keylist > URI (see [RFC3986]), and the fingerprint of the authority key used to > sign the keylist. > > A client must have both the keylist URI and the fingerprint of the > authority key to subscribe to it -- just the keylist URI is not enough, > which means a .well-known location would have to also include the > authority key fingerprint. Doing this would ultimately make the trust of > the entire system rely on the security of the organization's web server, > and on HTTPS, as opposed to on the authority key. > > And there's a further issue related to domains names which I describe > below. > > > What to do when the email on the key list points to a key lacking that > > key ID ? > > As described in the draft, only the "fingerprint" field of the key is > required, and all other fields (name, email, comments, and any other > arbitrary metadata) are optional, and only there for the sake of the > organization maintaining the keylist. Clients simply fetch the fingerprin= t. > > > Why not use https://wiki.gnupg.org/WKD ? > > > > Why not use OPENPGPKEY DNS records? > > The members of an organization frequently don't have email addresses at > the same domain name. For example, my organization includes email > addresses at firstlook.org, firstlook.media, theintercept.com, > fieldofvision.org, topic.com, among other domains, not to mention we > frequently add personal email addresses hosted at gmail.com or other > email services, as well as university email servers, for interns, > freelancers, or other temporary workers. And some organizational keys > contain UIDs that don't include email addresses at all. Still, we want > to include all of these fingerprints on our keylist. > > A keylist contains a list of fingerprints for public keys everyone in > the organization should have. It would add more pointless work to > maintain this system if we chose to arbitrarily require that they all > keys contain UIDs with email addresses for the same domain name. > > Also, not all organizations even have a domain name of their own (for > example, a free software project where the code and releases are hosted > on GitLab.com, and members of the project use personal email addresses). > > > While automatic sync is a nice feature, over-syncing is a privacy risk, > > especially for people who are trying to remain anonymous. > > This is outside the scope of this RFC. Like I described above, Atom > feeds, and existing automated use of key servers, have always had this > problem. > > (Also, people trying to remain anonymous need to do quite a bit more > than just not automatically fetch PGP keys. It requires using an > operating system designed for such a use-case, like Tails, in which case > subscribing to keylists would be perfect fine, and would not compromise > anonymity.) > > > All in all, this seems like an interesting application, and worth > > further discussion (on this list). I am not yet convinced this is > > an protocol issue and not an application issue. > > > > Paul > > > > And finally, I'll also reply to Wiktor's feedback. (Quoting in full for > Miles' sake.) > > On 2/13/19 3:10 AM, Wiktor Kwapisiewicz wrote:> Hello, > > > > Excellent points and I'm glad that the draft has been published on this > > ML for a discussion in a wider audience. > > > > As far as I understood draft-mccain-keylist-02 its goals can already be > > achieved with a combination of already existing features: > > > > 1. Discovering keys for company employees - using "e-mail to key" looku= p > > (e.g. WKD) > > > > 2. Trusting that these keys are authentic - by signing an Authority Key > > and setting ownertrust to full. This can be done only once and it works > > for all future keys. Even with draft-mccain-keylist-02 one needs to do > > that to know which keys are trusted. There is one variation of this > > scheme - by using Trust Signatures one can trust Authority Key to keys > > from the company domain only. > > > > 3. Keeping keys up to date - why not just refresh all keys in the local > > keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will > > refresh expired keys over WKD if they were fetched with WKD [0]). > > > > [0]: https://dev.gnupg.org/T2917 > > > > If the problem is that people verify signatures and the keys are not > > present I think applications have appropriate options to fetch keys > > automatically (e.g. `gpg --auto-key-retrieve`). > > > > I like the point of using .well-known for a keyring of all people but > > from what I've heard on GitHub the ability to host keylist on a > > different domain is desired: > > > >> There's no reason to trust the server that hosts the keylist file. We > >> already don't trust it -- FLM hosts our keylist on GitHub. > > > > Source: > > > > https://github.com/firstlookmedia/keylist-rfc/issues/8#issuecomment-42684= 6582 > > > > > > Kind regards, > > Wiktor > > I've already addresses some of this, but: > > It's important for my company's use-case, and probably that of many > other organizations, to not tie a keylist to one specific domain name, > and to allow the keylist to include keys for personal email address > (e.g. gmail.com) as well as keys with UIDs that don't contain email > addresses at all. WKD is simply insufficient for this use-case. (It also > has the problem where if a member of the organization updates their key, > they can't push their updated key into the WKD like they can to a key > server.) > > It's true that we could bootstrap a system like `gpg --refresh-keys` > combined with cron (or more realistically launchd on macOS) to keep keys > up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we > don't necessarily want to update all keys in every user's keychain, only > the keys on the keylists they're subscribed to. Only refreshing keys > listed on a keylist leaks less information to key servers than > refreshing all keys -- it leaks what keylists you're subscribed to. > > But, most importantly, and in fact the reason we developed GPG Sync to > begin with (which ultimately lead to writing this draft RFC), what isn't > possible with existing tools is to get everyone in an organization to > automatically fetch *new* keys that they otherwise wouldn't be aware of. > > For example, lets say we hire a new intern, and they generate a PGP key > for their mit.edu email address. How do we get hundreds of people's > computers to automatically fetch that key so they can email this intern > without having to do manually fetch it and verify it first? Or, let's > say an employee loses their Yubikey, so they publish their revocation > certificate and generate a new key. How do we get those hundreds of > computers to fetch the revoked key, as well as the new key, so that the > next time someone sends an encrypted email to that person, it just works? > --0000000000002ce81f0581ccb100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Wed, Feb 13, 2019 at 3:31 PM M= icah Lee <micah.lee@theint= ercept.com> wrote:
Hello,

I'm adding Miles McCain to this email, who is one of the authors you left out. And I'm also adding the keylists@freelists.org mailing list.

On 2/12/19 6:32 PM, Paul Wouters wrote:
> Via twitter I noticed this draft:
>
> https://tools.ietf.org/html/draft-mccain-key= list-02

Note that a new draft has since been published, however the changes are
minor: https://tools.ietf.org/html/draft-mccain-= keylist-03

> I have some comments on the draft. I've added the authors to the C= C:
> since I'm not sure if they are on this list.
>
> First a procedural item. Section 1.3 states:
>
> =C2=A0=C2=A0 1.3.=C2=A0 Note to Readers
>
> =C2=A0=C2=A0 RFC Editor: please remove this section prior to publicati= on.
>
> =C2=A0=C2=A0 Development of this Internet draft takes place on GitHub = at Keylist-
> =C2=A0=C2=A0 RFC [1].
>
> =C2=A0=C2=A0 A mailing list is available for discussion at Keylists ma= iling list
> =C2=A0=C2=A0 [2].
>
>
> I just wanted to share with the authors that this is not the way one > writes RFCs. RFC's and the IETF are covered by rules, such as the = Note
> Well. Please see https://www.ietf.org/about/note-well/=
>
> This is important because everyone discussing this draft on this list = is
> expected to fall under the rules of the Note Well, meaning they cannot=
> go out and get a patent and not mention anything until this document i= s
> an RFC, and then start charging money. And discussion at an external > site as the draft authors suggest, is not protected by this mechanism.=
>
> Furthermore, IETF carefully archives all mailinglist messages which ca= n
> later also be used in discovery but also for late-comers to the
> discussion. If an outside website suddenly vanishes, all this
> information is lost. Finally, IETF has Chairs and a Sergant-at-arms to=
> guide any on-list discussion. elsewhere, we fall under other possibly<= br> > arbitrary rules. I'm not saying your suggested locations are (I di= dn't
> go there) but as a rule discussions on internet drafts happen on
> internet lists. Work elsewhere is brought back to the IETF. Eg you can=
> make a pull request on github but you discuss this on an IETF list.
It's good to understand how RFCs are supposed to get discussed and
written. I, as well as the other two authors, are new to the IETF
process. However I don't see how the Note Well is especially relevant t= o
this draft RFC, as there has been no talk about patents.

We have a mailing list for this project (keylists@freelists.org) though
admittedly we haven't been using it. Instead we've been using a cha= t
room hosted by a third party.

Can you point to a document that describes the policy you're referencin= g
about where discussion of the RFC should take place, and also where
collaboration of writing the actual document should take place? We
definitely want to be transparent about the whole process.

> Now to the draft itself,
>
>
> Section 2 talks about subscribing to "key lists", where a &q= uot;key list" is
> defined as an URI to something and a fingerprint of a public key that = is
> authorative for this list.
>
>
> Section 2.2 talks about regularly updating the key list, and performin= g
> daily checks at the URI. I think this could be a privacy issue, and on= e
> could track a traveling journalist based on their key list sync checks= .

It's true that there's a potential privacy issue with regularly fet= ching
updates, but it's the same issue that all subscription systems have, such as Atom feeds (RFC 4287). It's also the same issue if you configur= e
gpg to refresh your keyring on a regularly interval.

This privacy issue is more of a fundamental problem with how networking
works than with any specific standard that relies on subscribing to a
regularly-changing document, so I don't think it's in scope for thi= s
specific RFC to tackle.

However, GPG Sync, software that already implements the draft keylist
RFC, supports an option mitigate this issue by making it simple to fetch updates over Tor:

https://github.com/firstlookme= dia/gpgsync/wiki/Using-GPG-Sync-with-Tor

> section 3.
>
> The key list is a JSON format that can contain a reference to an
> external key server. This also sounds a bit dangerous to me. Instead o= f
> all clients forking out to possibly many key server locations, why isn= 't
> the "key list" simply an openpgp format public keyring, with= trust
> attributes set properly by the "management key" ? Clients ca= n HEAD the
> file and if there is an update, GET the file via HTTP and import the > updates. I don't understand why there is indirection allowed or re= quired
> in this idea.
>
> Because no openpg keyring format is used, this "key list" ne= eds to be
> separately signed by the management pgp key. It adds another level of<= br> > indirection that could be avoided. If I have sufficient "trust&qu= ot; set
> in my personal keyring to trust updates from the manager key, then
> I can get the updated in openpgp format without further new protocols<= br> > already.
>
> The "key list" contains comments such as an signature_uri th= at allows
> the key list URI and the signature to be located on different systems?=
> Why would that ever be useful or more secure than doing a cleartext > signature on the file itself hosted on the same server as the key
> list file itself?
>
> A key list entry contains a fingerprint, name and email field? So in > essence, this becomes a meta key-server. Why give participants all
> these indirections, instead of just providing the openpgp keyring
> itself?
>
>
> Why is the key list not optionally (but hopefully) encryped to the
> participants to avoid a privacy leak to anyone who obtains the key lis= t
> URI ?
>
> A key list entry has concept of a last updated time stamp. Does this > mean that every "sync" I go out to all individual key server= s to get
> keys from all participants just in case they might have updated their<= br> > keys on the keyserver / fileserver of their choice? It seems this
> process is an ideal process for the centralized manager key to perform= ,
> instead of all participants?

GnuPG keyrings are not defined by an internet standard. They're a custo= m
format that GPG developers made up, and have changed over time (for
example gpg2 keyrings aren't compatible with gpg1). Having keylists rel= y
on GPG keyrings would make it unfeasible for non-GPG OpenPGP users to
subscribe to an organization's keylist.

The relevant standard you're probably thinking of is RFC 4880 which
defines the OpenPGP message format, basically the "-----BEGIN PGP PUBL= IC
KEY BLOCK-----"-type blocks. But that format isn't appropriate for=
keylist subscriptions.

Keylists don't include full public keys, they only include fingerprints= .
Information in public keys themselves change frequently -- the owner of
the key might add a UID, update their expiration date, or otherwise
modify their key. If keylists included actual full public keys, then the person maintaining the keylist would have to update it not just when a
new key is added, but every single time anyone in the the organization
modifies their key.

One of the main purposes of keylists is to reduce the amount of work
required to ensure that everyone in an organization (or anyone who
wishes to communicate with members of that organization) has the correct public key for everyone else.

Including full public keys in the keylist would be counterproductive.
The keylist that my company relies on currently has 228 fingerprints on
it, and it would add a ridiculous amount of pointless work to maintain
it if we had to keep track of minor changes in each key (and get copies
of those changed public keys from their owners), when instead we can
just keep track of fingerprints.

> Section 4.
>
> The "in practise" section is usually called the Impliementat= ion Status
> section. Please see https://tools.ietf.org/html/rfc7942 = on how to write
> these. (for example, to avoid publishing it in the final RFC)

This is good feedback.

> Section 5.
>
> The security considerations usually does not contain the benefits. Tho= se
> are the features offered and described in the document itself. This > section deals more with the concerns or practical issues or general > safe practises one has to keep in mind. Usually with a focus on
> implementors more than endusers. For guidelines on how to write a
> Security Consideration section, see https://tools.ietf.org/h= tml/rfc3552
>
> The three benefits listed do not convey to me why this solution with a=
> level on indirection is better suited that using a openpgp keyring
> at the location.
>
> I would rewrite 5.2 a bit. Yes the security of this system is only as<= br> > strong as the security of the manager key. But how does one convey thi= s
> management key? How is this key verified? What to do when the key IDs<= br> > are different? What to do when the key list can be obtained but not > the individual key servers listed for some participants. How often to<= br> > retry? when to warn the user? How does one recover from a management > key loss or compromise? How does the manager / key talk to its users > about anything?

Interesting, I'll take a look at the Security Considerations document.<= br>
> The biggest problem though is that I see no attempt at providing
> confidentiality for a key list. Anyone with the URI can get the list > of participants.

Keylists are public documents, and anyone can subscribe to them even if
they're not a member of the organization.

It might be worth considering the case where people wish to have private keylists, but it's not something we have considered yet.

> Why not introduce a .well-known location that any organisation can
> use, so we could try and find key lists for organisations we never
> talked to before. Perhaps specify a mechanism on how to verify an
> organisational management key?

We considered introducing a .well-known location, but, as described in
the draft:

=C2=A0 =C2=A0To subscribe to a keylist, the client must be aware of the key= list
=C2=A0 =C2=A0URI (see [RFC3986]), and the fingerprint of the authority key = used to
=C2=A0 =C2=A0sign the keylist.

A client must have both the keylist URI and the fingerprint of the
authority key to subscribe to it -- just the keylist URI is not enough,
which means a .well-known location would have to also include the
authority key fingerprint. Doing this would ultimately make the trust of the entire system rely on the security of the organization's web server= ,
and on HTTPS, as opposed to on the authority key.

And there's a further issue related to domains names which I describe b= elow.

> What to do when the email on the key list points to a key lacking that=
> key ID ?

As described in the draft, only the "fingerprint" field of the ke= y is
required, and all other fields (name, email, comments, and any other
arbitrary metadata) are optional, and only there for the sake of the
organization maintaining the keylist. Clients simply fetch the fingerprint.=

> Why not use https://wiki.gnupg.org/WKD ?
>
> Why not use OPENPGPKEY DNS records?

The members of an organization frequently don't have email addresses at=
the same domain name. For example, my organization includes email
addresses at firstlook.org, firstlook.media, theintercept.com,
f= ieldofvision.org, topic.com, among other domains, not to mention we
frequently add personal email addresses hosted at gmail.com or other
email services, as well as university email servers, for interns,
freelancers, or other temporary workers. And some organizational keys
contain UIDs that don't include email addresses at all. Still, we want<= br> to include all of these fingerprints on our keylist.

A keylist contains a list of fingerprints for public keys everyone in
the organization should have. It would add more pointless work to
maintain this system if we chose to arbitrarily require that they all
keys contain UIDs with email addresses for the same domain name.

Also, not all organizations even have a domain name of their own (for
example, a free software project where the code and releases are hosted
on GitLab.com, and members of the project use personal email addresses).
> While automatic sync is a nice feature, over-syncing is a privacy risk= ,
> especially for people who are trying to remain anonymous.

This is outside the scope of this RFC. Like I described above, Atom
feeds, and existing automated use of key servers, have always had this
problem.

(Also, people trying to remain anonymous need to do quite a bit more
than just not automatically fetch PGP keys. It requires using an
operating system designed for such a use-case, like Tails, in which case subscribing to keylists would be perfect fine, and would not compromise
anonymity.)

> All in all, this seems like an interesting application, and worth
> further discussion (on this list). I am not yet convinced this is
> an protocol issue and not an application issue.
>
> Paul
>

And finally, I'll also reply to Wiktor's feedback. (Quoting in full= for
Miles' sake.)

On 2/13/19 3:10 AM, Wiktor Kwapisiewicz wrote:> Hello,
>
> Excellent points and I'm glad that the draft has been published on= this
> ML for a discussion in a wider audience.
>
> As far as I understood draft-mccain-keylist-02 its goals can already b= e
> achieved with a combination of already existing features:
>
> 1. Discovering keys for company employees - using "e-mail to key&= quot; lookup
> (e.g. WKD)
>
> 2. Trusting that these keys are authentic - by signing an Authority Ke= y
> and setting ownertrust to full. This can be done only once and it work= s
> for all future keys. Even with draft-mccain-keylist-02 one needs to do=
> that to know which keys are trusted. There is one variation of this > scheme - by using Trust Signatures one can trust Authority Key to keys=
> from the company domain only.
>
> 3. Keeping keys up to date - why not just refresh all keys in the loca= l
> keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will=
> refresh expired keys over WKD if they were fetched with WKD [0]).
>
> [0]: https://dev.gnupg.org/T2917
>
> If the problem is that people verify signatures and the keys are not > present I think applications have appropriate options to fetch keys > automatically (e.g. `gpg --auto-key-retrieve`).
>
> I like the point of using .well-known for a keyring of all people but<= br> > from what I've heard on GitHub the ability to host keylist on a > different domain is desired:
>
>> There's no reason to trust the server that hosts the keylist f= ile. We
>> already don't trust it -- FLM hosts our keylist on GitHub.
>
> Source:
>
https://github.com/firs= tlookmedia/keylist-rfc/issues/8#issuecomment-426846582
>
>
> Kind regards,
> Wiktor

I've already addresses some of this, but:

It's important for my company's use-case, and probably that of many=
other organizations, to not tie a keylist to one specific domain name,
and to allow the keylist to include keys for personal email address
(e.g. gma= il.com) as well as keys with UIDs that don't contain email
addresses at all. WKD is simply insufficient for this use-case. (It also has the problem where if a member of the organization updates their key, they can't push their updated key into the WKD like they can to a key server.)

It's true that we could bootstrap a system like `gpg --refresh-keys` combined with cron (or more realistically launchd on macOS) to keep keys up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we
don't necessarily want to update all keys in every user's keychain,= only
the keys on the keylists they're subscribed to. Only refreshing keys listed on a keylist leaks less information to key servers than
refreshing all keys -- it leaks what keylists you're subscribed to.

But, most importantly, and in fact the reason we developed GPG Sync to
begin with (which ultimately lead to writing this draft RFC), what isn'= t
possible with existing tools is to get everyone in an organization to
automatically fetch *new* keys that they otherwise wouldn't be aware of= .

For example, lets say we hire a new intern, and they generate a PGP key
for their m= it.edu email address. How do we get hundreds of people's
computers to automatically fetch that key so they can email this intern
without having to do manually fetch it and verify it first? Or, let's say an employee loses their Yubikey, so they publish their revocation
certificate and generate a new key. How do we get those hundreds of
computers to fetch the revoked key, as well as the new key, so that the
next time someone sends an encrypted email to that person, it just works?
--0000000000002ce81f0581ccb100-- From nobody Wed Feb 13 13:22:42 2019 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 079CA12E7C1 for ; Wed, 13 Feb 2019 13:22:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MXoq9-np_L_B for ; Wed, 13 Feb 2019 13:22:37 -0800 (PST) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 163291200B3 for ; Wed, 13 Feb 2019 13:22:37 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id g80so3318060ljg.6 for ; Wed, 13 Feb 2019 13:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=lPDj1Mjhuqu+a96nMQKLw5KPSkt8nmpZ1vI/B22JwD8=; b=kYC6K00aDVWGX3IuE3hapEFXN80zsIMBW5UH8Gu0/S2woJPeH1S879tPvHdVHA0HVn nmFPGkJ9Kn5Jl2f6JKHoKeh6328vlxiYd6BMwXdRCVigYHuR4KLNy/3AuwH6xl6p+7Iw 0u40yfq/docrGmyYRApP5GIHntUEDbG6XfzdCNQW1q1TNFh/BL9WWLYeNwdK6low9EzV J27W6w41X95RtBkP/C7RTmx1ioGeJKQSf2qItsAzisl1b9ZDUj3pYDlSAHCOCAVzAew/ JmWj46oFzVVKgJLpjwqOPyn1TqhJ8J9CENCxWIPIpjgDP/5u2F9RmbkCwcR4ZUUSMYrU h+Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=lPDj1Mjhuqu+a96nMQKLw5KPSkt8nmpZ1vI/B22JwD8=; b=h2yldE2V6/k6DWahHwRolCy8bTZN2+Uu+KXWyeCQH4X+uRcPaAl0WZAgA89dJla4xD 2UPmMn7R005DfIRMFYC0Nbq1/eKxcG7dS9EVAAkh6CFek28HGavcLB1jSiZkLz23w9XP fDFei5znIW7PcJ+xlqefjfQ479JBD3SFZuXm2vD+AictpbCwlnPPfpR2SCiVXqsW6HuZ rG9I64vLCBS3+TOXZ/JcQ3buUo7sxwr6j0OaufLUr8OMT+YDg8g49BDT4ESGo6r3R/Lu TWNMNtMXBkyTKn0+rmaNMmq+5aNga7oIK3Fn67H3izdrZ2/Q6FXyDR0uIUEcw0830xiJ Nf1g== X-Gm-Message-State: AHQUAuZmmwZexD/sYFENXBAfqYP9NILMuqNOaoDmOTtp8Ue84QUXWHMJ o892yzUYo4d5tL1chYQKEHPvlQ== X-Google-Smtp-Source: AHgI3IZzjatcbPD0x1QKEK7MKT8z1/T3wT8SeiY7TyN3YJbGMJEJg9awN2b9FW6IUh6ykVIs42l7FA== X-Received: by 2002:a2e:587:: with SMTP id 129mr118587ljf.25.1550092955013; Wed, 13 Feb 2019 13:22:35 -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 i21sm77331lfj.60.2019.02.13.13.22.33 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 13:22:34 -0800 (PST) To: Micah Lee Cc: Paul Wouters , openpgp@ietf.org, keylists@freelists.org, nat.welch@firstlook.media, miles@rmrm.io References: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/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/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: <8cf86e32-2dd8-6708-c376-183f18165907@metacode.biz> Date: Wed, 13 Feb 2019 22:22:23 +0100 MIME-Version: 1.0 In-Reply-To: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [openpgp] comments on draft-mccain-keylist-02 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, 13 Feb 2019 21:22:40 -0000 Hi Micah, Thanks a lot for the explanation. I was about to ask you these questions = previously on keylist ML but it never happened... I'll skip parts that I don't have any comments for. On 13.02.2019 21:31, Micah Lee wrote: > It's true that we could bootstrap a system like `gpg --refresh-keys` > combined with cron (or more realistically launchd on macOS) to keep key= s > up-to-date. But 1) Not all OpenPGP users use gpg and cron, I think one of the strengths of GpgSync, as an application, is that it=20 does the key refresh in the background, has a nice, simple UI and is=20 cross platform. I wouldn't definitely advise setting up crons but rather = having GpgSync do something like that (maybe not exactly invoking `gpg=20 --refresh-sync` but see my next point). > and 2) we > don't necessarily want to update all keys in every user's keychain, onl= y > the keys on the keylists they're subscribed to. Only refreshing keys > listed on a keylist leaks less information to key servers than > refreshing all keys -- it leaks what keylists you're subscribed to. Parcimonie [0] addresses that problem by using fresh Tor circuit for=20 each key. [0]: https://github.com/EtiennePerot/parcimonie.sh#parcimoniesh Not refreshing all keys may leave some other keys (for example people=20 that the journalist communicate with) stale. I don't have a problem with = that but I think it'd be good be aware of this. > But, most importantly, and in fact the reason we developed GPG Sync to > begin with (which ultimately lead to writing this draft RFC), what isn'= t > possible with existing tools is to get everyone in an organization to > automatically fetch*new* keys that they otherwise wouldn't be aware of= =2E Yes, but WKD keys are downloaded on demand when they are needed, e.g.=20 when you type a new message, or verify an unknown signature. Unless you=20 want to have the keys locally because someone is encrypting the file=20 while being offline and only later sends it out, then keys locally are a = nice thing to have. > For example, lets say we hire a new intern, and they generate a PGP key= > for their mit.edu email address. How do we get hundreds of people's > computers to automatically fetch that key so they can email this intern= > without having to do manually fetch it and verify it first? As I said, the key could be fetched on demand. As for authorization it=20 already happens via Authority Key (that is lsigned by each user) signing = other users keys and that doesn't change regardless of how the key got=20 into local keyring in the first place. > Or, let's > say an employee loses their Yubikey, so they publish their revocation > certificate and generate a new key. How do we get those hundreds of > computers to fetch the revoked key, as well as the new key, so that the= > next time someone sends an encrypted email to that person, it just work= s? You can deliver both keys, revoked and new, also over WKD (see [1]).=20 That'll revoke the old key and make the new one active. [1]: https://lists.gnupg.org/pipermail/gnupg-users/2019-January/061439.ht= ml Of course, getting correct keys for unsupported or not controlled=20 domains (mit.edu/gmail.com) is a problem that having an official,=20 organization keylist solves quite nicely. I think emphasizing this in=20 the keylist abstract may be a good idea. Thank you for your time! Kind regards, Wiktor --=20 https://metacode.biz/@wiktor From nobody Wed Feb 13 22:23:11 2019 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 35295130FEC for ; Wed, 13 Feb 2019 22:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZBBZYwtX_2og for ; Wed, 13 Feb 2019 22:23:07 -0800 (PST) Received: from devious.adversary.org (ec2-52-29-175-128.eu-central-1.compute.amazonaws.com [52.29.175.128]) by ietfa.amsl.com (Postfix) with ESMTP id 909EC130FDC for ; Wed, 13 Feb 2019 22:23:07 -0800 (PST) Received: from adversary.org (localhost [127.0.0.1]) by devious.adversary.org (Postfix) with ESMTP id BAA7448344; Thu, 14 Feb 2019 06:23:04 +0000 (UTC) Date: Thu, 14 Feb 2019 17:23:03 +1100 From: Ben McGinnes To: Peter Gutmann Cc: "cryptography@metzdowd.com" , "openpgp@ietf.org" Message-ID: <20190214062303.jlokrdgqduptteyp@adversary.org> References: <20190212040914.23kkncp2fptccwp6@adversary.org> <1549954014509.38591@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rovkpdqyp63irf2w" Content-Disposition: inline In-Reply-To: <1549954014509.38591@cs.auckland.ac.nz> OpenPGP: "id=DB4724E6FA4286C92B4E55C4321E4E2373590E5D; url=http://www.adversary.org/ben-key.asc; preference=signencrypt" Codes-of-Conduct-policy: "url=https://gitlab.com/Hasimir/project-participation-policy" User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [openpgp] AS2+OpenPGP protocol extension review request 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, 14 Feb 2019 06:23:09 -0000 --rovkpdqyp63irf2w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2019 at 06:46:57AM +0000, Peter Gutmann wrote: > Ben McGinnes writes: >=20 > >Essentially it's a design for extending the W3C's ActivityStream > >version 2.0 (AS2) and ActivityPub (AP) protocols for federated > >social networks (e.g. Mastodon and Pleroma) with OpenPGP in order > >to provide a host of features not inherently built into AS2 and AP. >=20 > Just a note on this, I don't know what the W3C's AS2 is but whatever > it is it's nothing like the real AS2, which is a secure EDI standard > that's been around for close to twenty years (there are actually > several AS standards, but the most widely-used one is AS2). So if > anyone goes looking for AS2 security information, they're going to > get a very different AS2... Ah, oops; well there's a good reason to drop initialisms and acronyms =66rom draft #3. The W3C's thing is a protocol for social networking and micro-blogging which is implemented largely in JSON format. It grew out of the GNU StatusNet thing, except it's clearly defined (StatusNet was a bit hodge-podge). Since it's federated, it's beginning to pick up a fair bit of traction amongst the growing number of social network users who have become disatisfied with the likes of Twitter and FarceBook. Well, I'm not overly fussed about needing to use a short term for these things beyond just for my own quick references during drafting; so I'm quite happy to drop it in order to avoid future confusion. Regards, Ben --rovkpdqyp63irf2w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABEKAB0WIQSkiyjzmoPmPFW48w5Icjp1eQQexgUCXGUJRwAKCRBIcjp1eQQe xi9WAP97AtWPvAS9C7+mxsUGJRdAUYxqjowxVQX0RycPuNbVOAD/UafWmVSMj3G4 l2kprYBNhIdTizOK6Q20FtzrctOH9uo= =GR19 -----END PGP SIGNATURE----- --rovkpdqyp63irf2w-- From nobody Wed Feb 13 22:50:19 2019 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 77C75130FFC for ; Wed, 13 Feb 2019 22:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 KFRveatWxJEc for ; Wed, 13 Feb 2019 22:50:15 -0800 (PST) Received: from devious.adversary.org (ec2-52-29-175-128.eu-central-1.compute.amazonaws.com [52.29.175.128]) by ietfa.amsl.com (Postfix) with ESMTP id AFC0C130F30 for ; Wed, 13 Feb 2019 22:50:15 -0800 (PST) Received: from adversary.org (localhost [127.0.0.1]) by devious.adversary.org (Postfix) with ESMTP id C866048346; Thu, 14 Feb 2019 06:50:10 +0000 (UTC) Date: Thu, 14 Feb 2019 17:49:43 +1100 From: Ben McGinnes To: Stephen Farrell Cc: cryptography@metzdowd.com, openpgp@ietf.org Message-ID: <20190214064943.ebb34zchzc5ddhke@adversary.org> References: <20190212040914.23kkncp2fptccwp6@adversary.org> <79420544-da84-6c1b-5c3a-f2d2e3a10184@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u4c3vpes73ea5rzg" Content-Disposition: inline In-Reply-To: <79420544-da84-6c1b-5c3a-f2d2e3a10184@cs.tcd.ie> OpenPGP: "id=DB4724E6FA4286C92B4E55C4321E4E2373590E5D; url=http://www.adversary.org/ben-key.asc; preference=signencrypt" Codes-of-Conduct-policy: "url=https://gitlab.com/Hasimir/project-participation-policy" User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [openpgp] AS2+OpenPGP protocol extension review request 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, 14 Feb 2019 06:50:18 -0000 --u4c3vpes73ea5rzg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2019 at 11:52:05AM +0000, Stephen Farrell wrote: >=20 > Hiya, >=20 > I just had a quick peek (will try read more later) but wondered > why PGP is a better primitive here than MLS? [1] (Or one of the > IM security schemes that motivated MLS, if dealing with a work- > in-progress like MLS is problematic.) I was about to say MLS is *way* overkill, but then realised you were referring to the more recent MLS[1] and not this MLS.[2] Anyway, there were several reasons; including, but not limited to, these: 1. Responding to frequent requests of users of Mastodon and Pleroma servers who have been requesting specific software solutions of those platform (most commonly citing Mailvelope or Keybase). =20 I wanted to get the thing out of the realm of vendor or language lock-in. =20 2. ActivityStreams 2.0, in spite of the name, does not actually use live streamed data in the same way as various IM protocols do, it really is a transport protocol only. =20 3. OpenPGP provides an existing and proven means of meeting all the cryptographic shortfalls of ActivityStreams and the fediverse. =20 4. I've deliberately designed this extension in a way which would enable an alternative cryptosystem to be designed for it or adapted to it in the future. So no protocol lock-in either. =20 5. None of the IM cryptosystems I thought of would meet all the needs of various people whose requests I read and most of them are solely dependent on either SSL or libsodium to the exclusion of all else. The former tends towards mis-implementation and various exploits, the latter tends towards trying to make the one thing it does do fit everything. =20 It could be argued that that latter criticism is also true of OpenPGP, but on the other hand OpenPGP and, particularly GnuPG, can do an awful lot more too. =20 6. I've spent far more time delving into GnuPG's innards than most of the other systems, so there was a little bias there. Still, that's another reason for defining the spec in such a way that an alternative cryptographic protocol could be used instead. =20 Regards, Ben 1: https://tools.ietf.org/wg/mls/ 2: https://en.wikipedia.org/wiki/Multilevel_security --u4c3vpes73ea5rzg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABEKAB0WIQSkiyjzmoPmPFW48w5Icjp1eQQexgUCXGUPhwAKCRBIcjp1eQQe xtYiAP405SxSKjPj9AaVdmvCjft4RP0ovnrAGbvNz9WkQmT6kQEAyngd5J2rbbuh WnteSehIfNzqR/5KuRf6ulaM0nVaTIs= =7dLK -----END PGP SIGNATURE----- --u4c3vpes73ea5rzg-- From nobody Thu Feb 14 19:19:14 2019 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 2FD55130E92 for ; Thu, 14 Feb 2019 19:19:13 -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 3uK7vnkPspZs for ; Thu, 14 Feb 2019 19:19:12 -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 9D643130E7D for ; Thu, 14 Feb 2019 19:19:11 -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=1550200751; x=1581736751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TBpa2onzfJc3vivfcEaAcw32iat/OG4QvLKn0xsF7sw=; b=CEsmo70FnkvbtsieND8HAZeIUGPHCokuMMaJ9Gp17nGgjy3AXsNQ7WZK yA4KpBfRfMhb1ScW1iBzJP91waIqVeSWiXzkPEhHFgROy1HZ1amsI333n 7kQStoWwKKVJrRcG6mKKy/solttGAvvC2vLeK6XehACdbBZkECWttxVar v41+MTRe2Lh19HDUY1J8+dz1UNIJle7Lx4KVgFjUY0xnpqK3OtKqp76Gd 2y45zmH0I/nwSjoBpghxLcniRqNKnD31Wj2AzZKVtVak6azZ6Ubui/K9Z GjyUJvJq5ZH5NjF9mndrUvWRkV+BZbD1Gpr2+0s0gOv42filzK0NeUiWO g==; X-IronPort-AV: E=Sophos;i="5.58,371,1544439600"; d="scan'208";a="48538370" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Feb 2019 16:19:09 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Feb 2019 16:19:09 +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, 15 Feb 2019 16:19:09 +1300 From: Peter Gutmann To: Ben McGinnes CC: "cryptography@metzdowd.com" , "openpgp@ietf.org" Thread-Topic: [openpgp] AS2+OpenPGP protocol extension review request Thread-Index: AQHUwoiv62BAIg+Iek6VzSUkD8s0YaXbt90WgAJEnoCAAjjSZQ== Date: Fri, 15 Feb 2019 03:19:08 +0000 Message-ID: <1550200739858.62111@cs.auckland.ac.nz> References: <20190212040914.23kkncp2fptccwp6@adversary.org> <1549954014509.38591@cs.auckland.ac.nz>, <20190214062303.jlokrdgqduptteyp@adversary.org> In-Reply-To: <20190214062303.jlokrdgqduptteyp@adversary.org> 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] AS2+OpenPGP protocol extension review request 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, 15 Feb 2019 03:19:13 -0000 Ben McGinnes writes:=0A= =0A= >Ah, oops; well there's a good reason to drop initialisms and acronyms from= =0A= >draft #3.=0A= =0A= Yeah, I think both AS2 and MLS, which someone else pointed out, have such a= =0A= long history of use in the security community that it'd be better to look f= or=0A= non-conflicting terms.=0A= =0A= Peter.=0A= From nobody Fri Feb 15 12:11:41 2019 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 A3361131026 for ; Fri, 15 Feb 2019 12:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 OmZPRdi_iMna for ; Fri, 15 Feb 2019 12:11:38 -0800 (PST) Received: from devious.adversary.org (ec2-52-29-175-128.eu-central-1.compute.amazonaws.com [52.29.175.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD8B13100F for ; Fri, 15 Feb 2019 12:11:38 -0800 (PST) Received: from adversary.org (localhost [127.0.0.1]) by devious.adversary.org (Postfix) with ESMTP id 3406648482; Fri, 15 Feb 2019 20:11:35 +0000 (UTC) Date: Sat, 16 Feb 2019 07:11:35 +1100 From: Ben McGinnes To: Peter Gutmann Cc: "openpgp@ietf.org" , "cryptography@metzdowd.com" Message-ID: <20190215201135.tgy6xrlm6mggy7ud@adversary.org> References: <20190212040914.23kkncp2fptccwp6@adversary.org> <1549954014509.38591@cs.auckland.ac.nz> <20190214062303.jlokrdgqduptteyp@adversary.org> <1550200739858.62111@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hq7fbfqto5kwfrmm" Content-Disposition: inline In-Reply-To: <1550200739858.62111@cs.auckland.ac.nz> OpenPGP: "id=DB4724E6FA4286C92B4E55C4321E4E2373590E5D; url=http://www.adversary.org/ben-key.asc; preference=signencrypt" Codes-of-Conduct-policy: "url=https://gitlab.com/Hasimir/project-participation-policy" User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [openpgp] AS2+OpenPGP protocol extension review request 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, 15 Feb 2019 20:11:40 -0000 --hq7fbfqto5kwfrmm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 15, 2019 at 03:19:08AM +0000, Peter Gutmann wrote: > Ben McGinnes writes: >=20 > >Ah, oops; well there's a good reason to drop initialisms and acronyms fr= om > >draft #3. >=20 > Yeah, I think both AS2 and MLS, which someone else pointed out, have > such a long history of use in the security community that it'd be > better to look for non-conflicting terms. Indeed; and as a Pythonista I am reminded of the second line in the Zen of Python, =E2=80=9CExplicit is better than implicit.=E2=80=9D That certainly applies here. Now, if that and a final decision on key sharing within the protocol's scope are the only real issues here, I'll be very happy (and somewhat amazed with myself). I'd rather be sure, though, so if you could find the time for a bit of a closer look, I'd greatly appreciate it. No doubt eventual end users would appreciate it more, albeit without the concious recognition of that (in most cases). Regards, Ben --hq7fbfqto5kwfrmm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABEKAB0WIQSkiyjzmoPmPFW48w5Icjp1eQQexgUCXGcc7QAKCRBIcjp1eQQe xlgmAQCVSWDVBAGsgvBAGdWTBx95REMqEoZHY3sGBgDEq1q90QD+JYdokMZkP55/ 6PVtFD9M7HXGBWeZ6Eb65JPBcXOEb4s= =wZtQ -----END PGP SIGNATURE----- --hq7fbfqto5kwfrmm-- From nobody Sun Feb 17 18:17:37 2019 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 AEE46130EAB for ; Sun, 17 Feb 2019 18:17:35 -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 oZOICU1iVJlh for ; Sun, 17 Feb 2019 18:17:32 -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 3AF2D130F0E for ; Sun, 17 Feb 2019 18:17:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 442nZJ1fs6zWY; Mon, 18 Feb 2019 03:17:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550456248; bh=hn/86MErD57vOzu7MXX7rbjew1UNGPMkLQzaE7EnBZo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=u8u6qnMhbQ7phmFwaGZgfTw3jDGVBKSTPMWDFE3Rp6f87IeGHAWgDEpHqOmCjwkOf a+NT0tzCKD4oVD4ycBKgsAfVU/Z13w0ZwITFpDPUAxR9UK12hJGFCtFOmYrfWouP7l RnPIKQvfaEDN9LZAGN8TTXtIKpPpTybz4zsupMf4= 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 TISKDEqtOaDA; Mon, 18 Feb 2019 03:17:26 +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; Mon, 18 Feb 2019 03:17:25 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 918F15C854; Sun, 17 Feb 2019 21:17:24 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 918F15C854 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8A67140D358A; Sun, 17 Feb 2019 21:17:24 -0500 (EST) Date: Sun, 17 Feb 2019 21:17:24 -0500 (EST) From: Paul Wouters To: Micah Lee cc: openpgp@ietf.org, keylists@freelists.org, nat.welch@firstlook.media, miles@rmrm.io In-Reply-To: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> Message-ID: References: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [openpgp] comments on draft-mccain-keylist-02 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, 18 Feb 2019 02:17:36 -0000 On Wed, 13 Feb 2019, Micah Lee wrote: > I'm adding Miles McCain to this email, who is one of the authors you > left out. Oops. sorry about that. > It's good to understand how RFCs are supposed to get discussed and > written. I, as well as the other two authors, are new to the IETF > process. However I don't see how the Note Well is especially relevant to > this draft RFC, as there has been no talk about patents. > Can you point to a document that describes the policy you're referencing > about where discussion of the RFC should take place, and also where > collaboration of writing the actual document should take place? We > definitely want to be transparent about the whole process. An overview can be found at https://www6.ietf.org/tao See also: https://datatracker.ietf.org/meeting/103/materials/slides-103-edu-sessj-newcomers-overview-for-ietf-103-00 > It's true that there's a potential privacy issue with regularly fetching > updates, but it's the same issue that all subscription systems have, > such as Atom feeds (RFC 4287). It's also the same issue if you configure > gpg to refresh your keyring on a regularly interval. > > This privacy issue is more of a fundamental problem with how networking > works than with any specific standard that relies on subscribing to a > regularly-changing document, so I don't think it's in scope for this > specific RFC to tackle. If one would implement the RFC, what advise would you have to implementors to reduce this risk? That's the text I'm looking for. > However, GPG Sync, software that already implements the draft keylist > RFC, supports an option mitigate this issue by making it simple to fetch > updates over Tor: So that would be good to mention in the draft! > The relevant standard you're probably thinking of is RFC 4880 which > defines the OpenPGP message format, basically the "-----BEGIN PGP PUBLIC > KEY BLOCK-----"-type blocks. But that format isn't appropriate for > keylist subscriptions. Yeah I was thinking of that. > Keylists don't include full public keys, they only include fingerprints. I guess that was a big point of my confusion. I was thinking of the keylist having keys, not key pointers. So perhaps the term "key list" is not the right term for this? > Information in public keys themselves change frequently -- the owner of > the key might add a UID, update their expiration date, or otherwise > modify their key. If keylists included actual full public keys, then the > person maintaining the keylist would have to update it not just when a > new key is added, but every single time anyone in the the organization > modifies their key. But what scales better? An automated central way of pulling those updates, and everyone else mirroring that, or everyone pulling all these updates themselves? From a privacy point of view, the first would be better. From an operational point of view I think the first would give the best results too. But of course, there is a management issue on how or what is responsible for this. > One of the main purposes of keylists is to reduce the amount of work > required to ensure that everyone in an organization (or anyone who > wishes to communicate with members of that organization) has the correct > public key for everyone else. Just a note, when you say organization, I mapped that in my mind to be within a single (DNS) domain, or at least within the same administrative control group. After reading your email, I understand things are meant to work a lot more informal or scattered over dozens of domains. > Including full public keys in the keylist would be counterproductive. > The keylist that my company relies on currently has 228 fingerprints on > it, and it would add a ridiculous amount of pointless work to maintain > it if we had to keep track of minor changes in each key (and get copies > of those changed public keys from their owners), when instead we can > just keep track of fingerprints. But wouldn't it be a simple cron job to refresh those keys every day? And for your members to pull it all from the same location daily? The additional burden you say you want to avoid is exactly te burden you put on everyone who wants to use the key list? >> The biggest problem though is that I see no attempt at providing >> confidentiality for a key list. Anyone with the URI can get the list >> of participants. > > Keylists are public documents, and anyone can subscribe to them even if > they're not a member of the organization. I did not realise all keylists are public. Especially not reading the opening sentence of the abstract: This document specifies a system by which an OpenPGP client may subscribe to an organization's keylist to keep its internal keystore up-to-date. Note it specifically says "internal keystore". It would be better to rephrase that to be the organisations public keystore? > It might be worth considering the case where people wish to have private > keylists, but it's not something we have considered yet. That's worth mentioning somewhere then, possibly the Security Considerations section. >> Why not introduce a .well-known location that any organisation can >> use, so we could try and find key lists for organisations we never >> talked to before. Perhaps specify a mechanism on how to verify an >> organisational management key? > > We considered introducing a .well-known location, but, as described in > the draft: > > To subscribe to a keylist, the client must be aware of the keylist > URI (see [RFC3986]), and the fingerprint of the authority key used to > sign the keylist. > > A client must have both the keylist URI and the fingerprint of the > authority key to subscribe to it -- just the keylist URI is not enough, > which means a .well-known location would have to also include the > authority key fingerprint. Doing this would ultimately make the trust of > the entire system rely on the security of the organization's web server, > and on HTTPS, as opposed to on the authority key. So that is an important point. It would be great if we can somehow make it so they keylists can be trusted via some way. So that if I want to contact a journalist at firstmedia, I don't need to first somehow contact the owner of the key that signed the keylist to confirm this is the real key list (especially with references on members outside of the actual domain name used by the organization). We recently had a very similar discussion in SAAG about security.txt, see: https://tools.ietf.org/html/draft-foudil-securitytxt-05 https://mailarchive.ietf.org/arch/msg/saag/WoVRqcqmWdbE4mZo42XHBCKb9vg Note that I'm myself not in favour of the current security.txt proposal, but it seems that it might be worthwhile to see if your key list idea and their universal pointer to contact information could work together. > As described in the draft, only the "fingerprint" field of the key is > required, and all other fields (name, email, comments, and any other > arbitrary metadata) are optional, and only there for the sake of the > organization maintaining the keylist. Clients simply fetch the fingerprint. Ahh fair point. I'm still a little uneasy at keys changing and getting new IDs and implying trust, but I guess that's out of scope for this. Could you mention that fingerprints must be only in the long form, and not the old short form that is no longer secure enough? >> Why not use https://wiki.gnupg.org/WKD ? >> >> Why not use OPENPGPKEY DNS records? > > The members of an organization frequently don't have email addresses at > the same domain name. This is another important point that I completely missed after reading the text. I assumed "an organisation" meant that only a very few number of domains were involved. Perhaps clarify that in the draft? > A keylist contains a list of fingerprints for public keys everyone in > the organization should have. To be fair here, you don't just want them to have a keylist. You want them to have the public keys. And the keylist is a directory service to get them. And I still think it might as well do the work and present it all together. > It would add more pointless work to > maintain this system if we chose to arbitrarily require that they all > keys contain UIDs with email addresses for the same domain name. I agree. As I mentioned I hadn't thought of that scenario. >> While automatic sync is a nice feature, over-syncing is a privacy risk, >> especially for people who are trying to remain anonymous. > > This is outside the scope of this RFC. Like I described above, Atom > feeds, and existing automated use of key servers, have always had this > problem. But the point of a Privacy Considerations section is to give important information to implementors on issues that could pose a privacy risk, and might be partially mitigated. So, instead of waving it out of scope, try to give advise to implementors on how to mitigate this as much as possible. > (Also, people trying to remain anonymous need to do quite a bit more > than just not automatically fetch PGP keys. It requires using an > operating system designed for such a use-case, like Tails, in which case > subscribing to keylists would be perfect fine, and would not compromise > anonymity.) I don't believe it would be fine. Better sure, but there would still be risks. A dissident could be announcing their presence as a coffee shop if _any_ IP address queries for the updated key list. Tor does not help that. Now I agree some of this is out of scope for your document, but again think about what you'd want to advise implementors. > It's true that we could bootstrap a system like `gpg --refresh-keys` > combined with cron (or more realistically launchd on macOS) to keep keys > up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we > don't necessarily want to update all keys in every user's keychain, only > the keys on the keylists they're subscribed to. That sounds like an argument for the key list to have the updated keys for easy import by subscribers :) > Only refreshing keys > listed on a keylist leaks less information to key servers than > refreshing all keys -- it leaks what keylists you're subscribed to. Sure, though let's hope that people only fetch keys over TLS so that at least it is not known which keys are fetched? > But, most importantly, and in fact the reason we developed GPG Sync to > begin with (which ultimately lead to writing this draft RFC), what isn't > possible with existing tools is to get everyone in an organization to > automatically fetch *new* keys that they otherwise wouldn't be aware of. Right. But wouldn't a non-gpg specific standards based keyring format not be a better and more universal solution? Paul From nobody Wed Feb 20 01:39:45 2019 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 4C8C7130DD3 for ; Wed, 20 Feb 2019 01:39:43 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 0E0uFyxdmEfo for ; Wed, 20 Feb 2019 01:39:41 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 803C6124B0C for ; Wed, 20 Feb 2019 01:39:41 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id b20so19244870edw.11 for ; Wed, 20 Feb 2019 01:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BYG4S4xjAR54GOVg3kyhrqg0Fzwc14hKEs9lXINkG/U=; b=j4S+n5DiQXoBxEXnMOr2BOM9UI/FcgiuX6aGfl+ufYLtRz0+x+AUWIwHBEvVGV6P5j ZdStAq/0uLPn6DWIDIfg3oRK0nTnhBlwBveFC8viD6nxJ+kdQShJMQwLSHvF3epK1msJ tCu+NG3+n+wMfXb8hOJaQBsSw86hoeWW1DAnqhE7/q65pVAdYjT8C/E2agMCjpvBWeoq glUpya+43C5unsyQqAI9bMLlJOjmYVr1ZDMOXNOQXtGnJ4QJmw7GNA1nav5QEjMXWJpD 9aoFMavI1ZrpVD5uunWVdvO1giqqotiB0J7ME5NmBY3mDx0X4II9K7g7RoOGfcunDYVC oOww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BYG4S4xjAR54GOVg3kyhrqg0Fzwc14hKEs9lXINkG/U=; b=eMBmWk/zBrkje/oumdhNJ3K23QJbO2Dd9eg3NTTzwEdpAvaO3Czto7RjKkMCm2vqE2 8a10L8xe8HqACvlUlSTvnjhoHbiQoGClc7dM22tnM7o53oDQriDrS8VYfNhHVrfUVccl 25f98zbxyI/7kV9EIt+m9sqjjRrxFW+7VnvO5+ajeLYfng8AZXcByaoEGG00PGO1+qmc 6NkycJcchCuTkwJ1BybxGPi7BXyhMyV13IiUAmdhWXyJQ4Yg8+s9LiyGvTvJDLe4Q0R/ c3b1rAFk2Q2ZfTo0Bc+iYuji+hQO40d26kflQGiRp75UV5POj/a48s9ZFX8bvZEceV7b ATXg== X-Gm-Message-State: AHQUAuZqW6bykDqGvE9xPN3uatLo2bv9mfKTDmmyRwU4jCU/kH6qm7hw KWv/cdDBL6IiQwXBWdptu7s4KfG9wd6jPXvn8TBVl4OK X-Google-Smtp-Source: AHgI3IZd9AV0m5UwhN2+O9UUTx2iypLuZW5ij/S1pRDXTpjSWhukvEwSBW7cxMzEZI7GanGUTkGFEC8AcfXF0iIC3PM= X-Received: by 2002:a50:9063:: with SMTP id z32mr2591998edz.164.1550655579902; Wed, 20 Feb 2019 01:39:39 -0800 (PST) MIME-Version: 1.0 From: Justus Winter Date: Wed, 20 Feb 2019 10:39:29 +0100 Message-ID: To: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [openpgp] User ID Attribute Subpacket 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, 20 Feb 2019 09:39:43 -0000 Hello, draft 6 of RFC4880bis proposes a "User ID Attribute Subpacket", but it does not motivate that addition in any way. What is the purpose of it, and what is the advantage over using the userid packet? Thanks, Justus From nobody Wed Feb 20 01:57:26 2019 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 121D5130DC9 for ; Wed, 20 Feb 2019 01:57: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 3scCWJprGTSv for ; Wed, 20 Feb 2019 01:57:21 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 AC9E0124B0C for ; Wed, 20 Feb 2019 01:57:20 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id m11so17084496lfc.6 for ; Wed, 20 Feb 2019 01:57:20 -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=jXwewrTj9itgWDe5rVe7/8CFaGiXZB4YMxXOeYlSdGs=; b=h8mFAOWItPmCNKwoslsBtajym+D0aXpDrGeGje6TcvF9IENWmykFNAqTvO2Lm2uEZK tU3+u4fFADXWagWJFSBUkSzYPWuqSmkAfdqj9s22J8tOlCcMmwivJDFNXafpWj3B9X/4 s1OjlNnxmBQcJa8rLyj+EjSHzfizGGCLmQPyRGM787N1yKAZlW3xCzjmagKITWP5klTS Ua+9uKsBr1xoEWw4VXb7PIKNQDQIGzbxgPZT1pDpRNXWSdKe7nVNnXrY7kUnYR/5Le6M 6fQsLcBWQ3BacTDTjUhh25ye7jY9wIZaTmjkHXVtjxqP4FdreBYP0IDEwX5KF6mUe2VE LZdA== 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=jXwewrTj9itgWDe5rVe7/8CFaGiXZB4YMxXOeYlSdGs=; b=YPhbWn3Yh0QFsJbnTqRaCjQjQ1arGuEqTDAhpuU8KTye5E2kqcgMHkMHE7BUvjlubm bygr42y9DlCQuGtoufdS684vKbNUONWozPvegztBamj66cgEVfk9phr1G77TO7Tu2oMr RT84bqnMiB4i8VuEPpUhtoDLuRodSwuZugU1vSf72c54ceCzQtP4sa2uh9+Tl72vGq3k qK2Q8/wCFo8DZtJJbHlv5CPtyRpzaMyFUPhNwpSlhDpNqlnwOr+GoajEL+YeKlNpz+i8 zXF96bQHanBmwV0U0IHJXbbXlWK4JhTPKkFAKb9UCq98Mc8L+qpG3APuOSqw54rXTwAI EovQ== X-Gm-Message-State: AHQUAubDWnjkGkZq5N21MCfmhz9kG7ocSq5AEFLqEHWTFGFtWsCD7Kxc dBS/YKfsz3EIXuitC4nHdMGB2XzvAw4= X-Google-Smtp-Source: AHgI3IbAU4OIL6zftwjsPM2QCyCKceiMZWhYLk+pzPDxI80ZQmb0+Py2SlOqefgWf6oAdM/7/eHq9Q== X-Received: by 2002:ac2:510e:: with SMTP id q14mr17870950lfb.106.1550656638531; Wed, 20 Feb 2019 01:57:18 -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 e9-v6sm4779653ljk.92.2019.02.20.01.57.17 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 01:57:17 -0800 (PST) To: Justus Winter References: Cc: openpgp@ietf.org From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/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/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: Date: Wed, 20 Feb 2019 10:57:07 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 20 Feb 2019 09:57:24 -0000 Hi Justus, On 20.02.2019 10:39, Justus Winter wrote: > Hello, > > draft 6 of RFC4880bis proposes a "User ID Attribute Subpacket", but it > does not motivate that addition in any way. What is the purpose of > it, and what is the advantage over using the userid packet? From what I can see it comes from "draft-atkins-openpgp-device-certificates" that was merged in to RFC4880bis. For details see this thread: https://mailarchive.ietf.org/arch/msg/openpgp/Ma3P-yM2vTrfx2_Pqf_sq31SruY (Message-ID: ) Kind regards, Wiktor -- https://metacode.biz/@wiktor From nobody Wed Feb 20 02:31:12 2019 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 DB00812DDA3 for ; Wed, 20 Feb 2019 02:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6ylwhtbKvD25 for ; Wed, 20 Feb 2019 02:31:09 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 D6EE612D4EB for ; Wed, 20 Feb 2019 02:31:08 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id m35so15439284ede.10 for ; Wed, 20 Feb 2019 02:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LGvkfUQkmkCzy5nsSNJTTN44DHe73oS4+mwf1Tm8wBY=; b=VZ5YgWc8L2R5LjarX0i5LMXhrzUjlHM7cV4WUvkRrlx091He0Neb36+G6JyymVHnpw LeI8C3xFbkDXPCRhb63rhIviS4Gl0likNd1+8OlHydyHo1B88PzlZlCte6LeNutF7VoR f36yZtStzpiwpQpk90tPnJwoFBpH/tR+XxhhTMMqgOl3obwf9BEOhBaiPfKxj/Wvajcs mTfLes+m96UDSAIK5vzlyxXK8jiF2RXGkfaTbEEZrsV5BaEWU8OI9T1hw6zVM7MSaBjk dgN0FA/QjdjLl5Mqf76z0gso3DRjxkHbEG8Z+jSfY+9o9knbnHAg4jQnsSGG2YMF5t/L gnSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LGvkfUQkmkCzy5nsSNJTTN44DHe73oS4+mwf1Tm8wBY=; b=ZSE/Lju2K87dEcNCK4doCjEE9i1emIIPv7YmMihmjHQ6o2RTW9b697V0qZSWKnWorP GenYnL5dhPnb8+Xzyx2l4MSXmLwf8ikFCrNUVOMXq7GUJ6DA6ecgRRC0TYIWwmxk0ZDi FrITiaVqwMXxNUQjglt2lgmmqhZ+WxTXyIQ0aKNV+vum2QJMcXxylO63VVM6XTblCNom 3Idbm1jop5d6i/55A1AZof10GWrLf1G8LkEsK0DwVmEbllonpVmCW77rEc/ohlgS9Edu 6Ojz1qn+bMJ69c9LBkh/yhHXY9+7DtG7GTGjBEAmxdn5ZHDNI90nMZVSIImdxxIQZyl5 mADQ== X-Gm-Message-State: AHQUAuaSNUwWlVLzgGQwHeddIcjSX6xw5JrQY4K4PPB8FrR8olH5p02l 48xJr67UvqnLJh7+nsw0KShKuE4D+qc2ZkvqhNpXYf6i X-Google-Smtp-Source: AHgI3IbFIdwtoUDF5KnSI6yGG0IuCeabqHp4XZRmP29mKHiaQgMW4tls/ngZ5emMHpMoYZOm7biLnD0RJlSZ2ONSqG0= X-Received: by 2002:a50:a55d:: with SMTP id z29mr19731385edb.269.1550658667212; Wed, 20 Feb 2019 02:31:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justus Winter Date: Wed, 20 Feb 2019 11:30:56 +0100 Message-ID: To: Wiktor Kwapisiewicz Cc: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 20 Feb 2019 10:31:12 -0000 On Wed, Feb 20, 2019 at 10:57 AM Wiktor Kwapisiewicz wrote: > On 20.02.2019 10:39, Justus Winter wrote: > > draft 6 of RFC4880bis proposes a "User ID Attribute Subpacket", but it > > does not motivate that addition in any way. What is the purpose of > > it, and what is the advantage over using the userid packet? > > From what I can see it comes from > "draft-atkins-openpgp-device-certificates" that was merged in to RFC4880bis. > > For details see this thread: > > https://mailarchive.ietf.org/arch/msg/openpgp/Ma3P-yM2vTrfx2_Pqf_sq31SruY > > (Message-ID: ) Interesting. I skimmed the thread trying to introduce a more structured kind of user ids [0], but I'm still not convinced that the "User ID Attribute Subpacket" as proposed in -06 adds any value over the user id packet. 0: id:c2e6bbe7-0694-8193-bb76-dd50fde7d967@leo.gaspard.ninja For reference, here is the proposed attribute: > 5.13.2. User ID Attribute Subpacket > > A User ID Attribute subpacket has type #[IANA -- assignment TBD1]. > > A User ID Attribute subpacket, just like a User ID packet, consists > of UTF-8 text that is intended to represent the name and email > address of the key holder. By convention, it includes an RFC 2822 > [RFC2822] mail name-addr, but there are no restrictions on its > content. For devices using OpenPGP for device certificates, it may > just be the device identifier. The packet length in the header > specifies the length of the User ID. > > Because User Attribute subpackets can be used anywhere a User ID > packet can be used, implementations MAY choose to trust a signed User > Attribute subpacket that includes a User ID Attribute subpacket. And this is the user id packet: > 5.12. User ID Packet (Tag 13) > > A User ID packet consists of UTF-8 text that is intended to represent > the name and email address of the key holder. By convention, it > includes an RFC 2822 [RFC2822] mail name-addr, but there are no > restrictions on its content. The packet length in the header > specifies the length of the User ID. As you can see, the text is almost identical, and the text for the proposed subpacket even admits that it is just like a user id packet. Furthermore, "[...] User Attribute packets are not a required part of the OpenPGP standard [...]". Based on these observations I challenge the claim that the proposed subpacket adds any value to the standard, and propose to remove it. Cheers, Justus From nobody Wed Feb 20 02:39:51 2019 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 7F741130DE5 for ; Wed, 20 Feb 2019 02:39:49 -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 gAgnW82_ywad for ; Wed, 20 Feb 2019 02:39:47 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9F112DDA3 for ; Wed, 20 Feb 2019 02:39:46 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id j13-v6so20391669ljc.2 for ; Wed, 20 Feb 2019 02:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HgpwijP2Co8L+LRwlQy48k8ufW+BMwAUhlcKYojyZ9c=; b=talAGI2Pd4TP0sKB1TtS5c3COEHWUFYkhNLmBn1dibVWM9JwtuwGnKjc6InTBtCEQX buJkG1NQKy0ohUrRjowQgwPiFY6tPOt3lpxreMM99XbWptHEHEs0lSEAbxHm5TmTkUcU C+I5JedyFhZPMrx4Dwy66oP1iHscqrHdvg39coJy6XgCnwlKK1rPR8FWPw9iLmxD+dbf rbtUdAa+OOv9inmco53rbN0Mw0JVJOGcMwE6l8RWX94xjLMicAwP7Ln7nArTOiXPH2uz 0pkblgNAWFp1OaebG/Yt9B1vK0yJYiLzfqcyMUG8uQ5zIqOFMzMN8CNUOpoyNtGatQsH z47g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=HgpwijP2Co8L+LRwlQy48k8ufW+BMwAUhlcKYojyZ9c=; b=tYTGZoSgfrhCjDgj/H68qpBjNqemUhgqgZULGtq5dm5v0RmtarjTH9JALQ6VsJt3Yp gcTv7fDKDXXtAjSTdSVt2Blgx8vbODlsYeN2FwgrQNL6PImA6KRzK+Y4YWgCPHcDXz2R UKD+3j+Hs5HyycR2cmoDjQ8+em2TjJES8U8gXn+dgouINyl7rhp/xbnZXFN5QaOTRr4W cne8Mv793Jkf9UL/Ibk6Sb8zcFFN7VVcFdJ+k3QGdi4FWDOQU5baC0EqQ7Fj8KsqO65V PFLlyO8On1B5AZ0iSCqESk9ZN0YKqgWw1SrRJv+d2+mBwnTta4tsicDUbuzqYq76lcr/ bpLw== X-Gm-Message-State: AHQUAubXgw2vEEtt6971bx2rppUMyl8ogpMG2aaU3zIkGE90/HG91Gkd gl4fRe//ShoGVvQV8RC3LpnwZMS6d0o= X-Google-Smtp-Source: AHgI3IYiTa6lPkMMRk3Sj8inWprcorzsFAIEtgnbIifMmeB/rT4ipC9ueBqHqmDQZ20cbNwCftq0nA== X-Received: by 2002:a2e:97ce:: with SMTP id m14mr20317798ljj.162.1550659184630; Wed, 20 Feb 2019 02:39:44 -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 u3sm3086180lje.61.2019.02.20.02.39.43 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 02:39:43 -0800 (PST) To: Justus Winter Cc: openpgp@ietf.org References: From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/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/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: Date: Wed, 20 Feb 2019 11:39:33 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 20 Feb 2019 10:39:49 -0000 Hi Justus, On 20.02.2019 11:30, Justus Winter wrote: > Based on these observations I challenge the claim that the proposed > subpacket adds any value to the standard, and propose to remove it. I agree. Actually from my casual skimming of the device certifications draft I see most of the changes can be implemented over what is already in OpenPGP. As you've said - User IDs are quite flexible [0] and the other change of device certifications - standard notations (that is notation names that doesn't contain "@") could just use regular notation names (e.g. 'manu' Notation could be 'manu@device-certs.example'). That would keep OpenPGP as small as possible without parts that most implementations would basically omit. Having said that I wasn't around when it was conceived so probably there is some rationale for its inclusion. Kind regards, Wiktor [0] I did experiment with putting URIs in User IDs for extended info (https://github.com/wiktor-k/distributed-ids#distributed-ids) -- https://metacode.biz/@wiktor From nobody Wed Feb 20 08:08:56 2019 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 4AF2F130ED0 for ; Wed, 20 Feb 2019 08:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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] autolearn=ham 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 XwFMqId3Y0Cm for ; Wed, 20 Feb 2019 08:08:50 -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 02C23130EF1 for ; Wed, 20 Feb 2019 08:08:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 87A4BE2044; Wed, 20 Feb 2019 11:08:48 -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 16261-08; Wed, 20 Feb 2019 11:08:44 -0500 (EST) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (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 8F926E2042; Wed, 20 Feb 2019 11:08:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1550678924; bh=HrVUoXO5vAsTHVZgrsoffoI/NtC2+WyywHzszlm84/Q=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=i6l39lWxJo584rQxG0C1rL41Xf91rQuTugal5u9nENfhjyyW3y3lVstHyY9qfaeNA 23CPcaZ26MuDtP/2+yOAPj3J/fsWGebvo3KRigYIMq/gwTJRiN4+LK2W1s74+GghrY sv3mVBqR8Hvz4jucbLeRCbSA/CkQF82pte60BSsk= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x1KG8eTp016817; Wed, 20 Feb 2019 11:08:40 -0500 From: Derek Atkins To: Wiktor Kwapisiewicz Cc: Justus Winter , openpgp@ietf.org References: Date: Wed, 20 Feb 2019 11:08:39 -0500 In-Reply-To: (Wiktor Kwapisiewicz's message of "Wed, 20 Feb 2019 11:39:33 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 20 Feb 2019 16:08:55 -0000 Hi, Wiktor Kwapisiewicz writes: > Hi Justus, > > On 20.02.2019 11:30, Justus Winter wrote: >> Based on these observations I challenge the claim that the proposed >> subpacket adds any value to the standard, and propose to remove it. > > I agree. Obviously I don't ;) > Actually from my casual skimming of the device certifications draft I > see most of the changes can be implemented over what is already in > OpenPGP. *CAN*, yes, but there are reasons to minimize. See below. > As you've said - User IDs are quite flexible [0] and the other change > of device certifications - standard notations (that is notation names > that doesn't contain "@") could just use regular notation names > (e.g. 'manu' Notation could be 'manu@device-certs.example'). > > That would keep OpenPGP as small as possible without parts that most > implementations would basically omit. Yes, most of what was in the draft could have been implemented using standard OpenPGP mechanisms. Indeed, the device-certs draft was not intended at the time to be incorporated into 4880bis but rather to be a standalone document that lived along side it. The main purpose was to enable the smallest certificate possible, but really the purpose of the device-certs draft was multi-fold: 1) Allow a PGP Key Certificate without a signature key. The idea here is that some small devices may only have a key-agreement key available so may not be able to create a signature. However, 4880 did not allow this configuration and required a top-level signature key and relegated other keys to sub-usage. 2) The reason for the User ID Attribute subpacket was that we wanted to have multiple Attribute subpackets included in the certificate in a primary signature, but this was not possible with 4880. My memory is hazy on what the exact issue was, but IIRC you could EITHER have a UserID packet OR a set of Attribute packets, but not both. Because I wanted both a UserID *AND* additional attributes in a single signature, this seemed the best way to do it. 3) Yes, we could have just used FQDN-based notations, but then we're litterally adding at least 13 bytes PER NOTATION. Given the number of notations in use, that was adding on the order of 65-130 BYTES to the certificate, or about 10-15%! > Having said that I wasn't around when it was conceived so probably > there is some rationale for its inclusion. Indeed. Honestly, at the time the intent was to progress the device-certs draft on its own and register those notations that way. But then the WG stalled, and Werner kindly incorporated those definitions into 4880bis. Still, adding these to 4880bis does not add significant complexity to the draft but DOES make a marked difference in its usability. Please do not remove these improvements. > Kind regards, > Wiktor > > [0] I did experiment with putting URIs in User IDs for extended info > (https://github.com/wiktor-k/distributed-ids#distributed-ids) Cool. But not useful to me ;) -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Feb 20 11:23:27 2019 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 DEF7F130E7B for ; Wed, 20 Feb 2019 11:23:25 -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 PG1ut2PJR6z2 for ; Wed, 20 Feb 2019 11:23:23 -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 2655C130E58 for ; Wed, 20 Feb 2019 11:23:22 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id z20so20781125ljj.10 for ; Wed, 20 Feb 2019 11:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:cc:references:from:openpgp:autocrypt:organization:subject :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=32i8FS6NmxnQVfFSdln1/6+Q6eN3KOOIseM+WvWl++s=; b=AvUWYqjdiVEUaK/1RvpXPwZHvqUsC2Ere/njuoXYSBJ5dAQ5sba9iiFE6jKX7GdDwm 11/pW2PET5cKwVe+dEvzW2dVl6onKrMhLM2CCiyzhH5Ss+5czLs6+kxPkbPMc19sdoeA ItSk1p+RsgxkF4XLZghU5V0zl5I0j8dtOWtSa8U8KcLSq+9LrGxeFUXHt3ovgdDL7dIc 29ctMNdr+uN1+O9ZCDlFOBHPBEDYNUHgG/deiCNkx+tCPRvzvTDtVdDEM+fiHYSY6Nmq rkTc8J7BIN9uuT0HtdljR75y7POccnEHpl/MnTqIjUubCwGwiRZB5R2dQHqaiN7Jr6cI BoQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:openpgp:autocrypt :organization:subject:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=32i8FS6NmxnQVfFSdln1/6+Q6eN3KOOIseM+WvWl++s=; b=OFITLnFTPfbs2rRHvxnvNC6vkTGIUdCv2a4ga+zetl8LGNzlNaqGe7ROWXbfLgRZ2u 892yOkp0IChrpaQnbx0yHFUZVuui90Xr3ca1r/4iBgSQzLdY43IaEoVbFXTHOPX1TINE zB9ZbuYGocgU/rrFzh5zVsuEHqoocVPWMyciM+3opgra7aPmb2iAN5n0gynFbk+660+0 XfoiFDCcHtx0Z1szAGD6mXpSwOFIIcWeD3d8fBq3FPnit+iAK3zjbGQiZlqVHbQKz4WI Gahtbn5rImGuJYaFAovbSUk+cYzstTyCFEO/wL3LbLM2RmhAeHQaMtC7VspqjuRB2JEv xwJg== X-Gm-Message-State: AHQUAuYhny/SZjMHPdWw3ugfIxSoMrhAHbsKkb7fGNHJaTDzlvzmacYk kLLEijIoZUcsxc7hgpA1D3YZ6+5XdKo= X-Google-Smtp-Source: AHgI3IZX5mrlqt8p600oqZmnyuLdBYezdGuM+WeAx0ph3bmgSQ+WZEgC3tJpontYHFsZ5N6OVA099A== X-Received: by 2002:a05:651c:112:: with SMTP id a18mr21795212ljb.45.1550690600579; Wed, 20 Feb 2019 11:23:20 -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 d23sm5587316lfc.11.2019.02.20.11.23.18 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 11:23:19 -0800 (PST) To: Derek Atkins Cc: Justus Winter , openpgp@ietf.org References: From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/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/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: Date: Wed, 20 Feb 2019 20:23:07 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 20 Feb 2019 19:23:26 -0000 Hi Derek, On 20.02.2019 17:08, Derek Atkins wrote: > Yes, most of what was in the draft could have been implemented using > standard OpenPGP mechanisms. Indeed, the device-certs draft was not > intended at the time to be incorporated into 4880bis but rather to be a > standalone document that lived along side it. > > The main purpose was to enable the smallest certificate possible, but > really the purpose of the device-certs draft was multi-fold: > > 1) Allow a PGP Key Certificate without a signature key. The idea here > is that some small devices may only have a key-agreement key > available so may not be able to create a signature. However, 4880 > did not allow this configuration and required a top-level signature > key and relegated other keys to sub-usage. By "signature key" do you mean "certification key"? Because as far as I can see RFC 4880 definitely allows having the primary key being certification only: "In a V4 key, the primary key MUST be a key capable of certification" [0] [0]: https://tools.ietf.org/html/rfc4880#section-12.1 (I'm using C-only primary key, it's available via WKD). > 2) The reason for the User ID Attribute subpacket was that we wanted to > have multiple Attribute subpackets included in the certificate in a > primary signature, but this was not possible with 4880. My memory is > hazy on what the exact issue was, but IIRC you could EITHER have a > UserID packet OR a set of Attribute packets, but not both. Because I > wanted both a UserID *AND* additional attributes in a single > signature, this seemed the best way to do it. What would you store in these User ID Attributes that would not be possible in regular User IDs? > 3) Yes, we could have just used FQDN-based notations, but then we're > litterally adding at least 13 bytes PER NOTATION. Given the number > of notations in use, that was adding on the order of 65-130 BYTES to > the certificate, or about 10-15%! This depends on the FQDN, e.g. using '@ihtfp.com' adds only 10 bytes, and there are shorter domains. This can be coupled with shortening of the keys (e.g. 'prodid' -> 'p') although I admit they look shortened already :) Are all of them needed and used at the same time? >> Having said that I wasn't around when it was conceived so probably >> there is some rationale for its inclusion. > > Indeed. Honestly, at the time the intent was to progress the > device-certs draft on its own and register those notations that way. > But then the WG stalled, and Werner kindly incorporated those > definitions into 4880bis. > > Still, adding these to 4880bis does not add significant complexity to > the draft but DOES make a marked difference in its usability. Please do > not remove these improvements. I don't know what are the criteria for inclusion but when reading the rest of the RFC device-certs strike me as something with a narrow focus. A stark contrast to otherwise generic and versatile constructs. >> Actually from my casual skimming of the device certifications draft I >> see most of the changes can be implemented over what is already in >> OpenPGP. > > *CAN*, yes, but there are reasons to minimize. See below. Could you share what's the rationale for keys being minimal? From what I have seen it has something to do with devices of limited memory but I'm eager to know details, are there any implementations of device-certs in the wild? For example what would the User ID Attribute look like? >> [0] I did experiment with putting URIs in User IDs for extended info >> (https://github.com/wiktor-k/distributed-ids#distributed-ids) > > Cool. But not useful to me ;) Hard to recommend something if I don't know what you're after :) Kind regards, Wiktor -- https://metacode.biz/@wiktor From nobody Thu Feb 21 06:41:02 2019 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 BB50C12F18C for ; Thu, 21 Feb 2019 06:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 rHshjF3m5VCh for ; Thu, 21 Feb 2019 06:40:57 -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 7DEAA12D7F8 for ; Thu, 21 Feb 2019 06:40:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 55FCCE2042; Thu, 21 Feb 2019 09:40:55 -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 13927-02; Thu, 21 Feb 2019 09:40:45 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 9C3CAE2044; Thu, 21 Feb 2019 09:40:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1550760045; bh=7OrUhAr3z4dIfNxAMzT/TIB5zf2hzsg0BDLoCtb3hxU=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=DLogMStUQ0HFPYvnPbN641WAw2gRo4r4eBJi2N2E+FNf+Dwj/ppcFprHUo//K9Ikm 5v0pxi/Vu+hDIXCvH2boQLCEJ81rmD1gAszVNyE0CXtoAwyb1sVgw/16qqyO3QO26m cQDctoJwWv5qdF+4mOrUT9tJGKSN0ugWJ0SPLc9Q= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 21 Feb 2019 09:40:45 -0500 Message-ID: <1741f774aa08d0df4a3ca481339bb733.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Thu, 21 Feb 2019 09:40:45 -0500 From: "Derek Atkins" To: "Wiktor Kwapisiewicz" Cc: "Derek Atkins" , openpgp@ietf.org, "Justus Winter" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 21 Feb 2019 14:41:01 -0000 Hi Wiktor, On Wed, February 20, 2019 2:23 pm, Wiktor Kwapisiewicz wrote: > Hi Derek, > [snip] >> 1) Allow a PGP Key Certificate without a signature key. The idea here >> is that some small devices may only have a key-agreement key >> available so may not be able to create a signature. However, 4880 >> did not allow this configuration and required a top-level signature >> key and relegated other keys to sub-usage. > > By "signature key" do you mean "certification key"? Yes.. > Because as far as I can see RFC 4880 definitely allows having the > primary key being certification only: > > "In a V4 key, the primary key MUST be a key capable of certification" [0] > > [0]: https://tools.ietf.org/html/rfc4880#section-12.1 > > (I'm using C-only primary key, it's available via WKD). I think you misunderstood my issue. My issue is exactly what you state here, that the primary key MUST be a key capable of certification. That's exactly what I DO NOT want. The keys I'm using are NOT capable of certification, but I still want them to be the primary key. Hence, I needed to modify that requirement. >> 2) The reason for the User ID Attribute subpacket was that we wanted to >> have multiple Attribute subpackets included in the certificate in a >> primary signature, but this was not possible with 4880. My memory >> is >> hazy on what the exact issue was, but IIRC you could EITHER have a >> UserID packet OR a set of Attribute packets, but not both. Because >> I >> wanted both a UserID *AND* additional attributes in a single >> signature, this seemed the best way to do it. > > What would you store in these User ID Attributes that would not be > possible in regular User IDs? This was from 3-4 years ago, so like I said, memory hazy, and project long turned over to others.. But my recollection was not just about what was being stored in the UserID,, but what ELSE was being stored in the same signature. Like I said above, my recollection is that I could not store both a UserID *AND* additional attributes at the same time, so the best workaround was to add a UserID Attribute so I could. In short, the specification did not allow us to do what we wanted to do, which is why I suggested this change. I do not recall exactly what it was, and frankly I don't have the time to go dig up the project and see how we were using it. >> 3) Yes, we could have just used FQDN-based notations, but then we're >> litterally adding at least 13 bytes PER NOTATION. Given the number >> of notations in use, that was adding on the order of 65-130 BYTES to >> the certificate, or about 10-15%! > > This depends on the FQDN, e.g. using '@ihtfp.com' adds only 10 bytes, > and there are shorter domains. This can be coupled with shortening of > the keys (e.g. 'prodid' -> 'p') although I admit they look shortened > already :) This is not for ihtfp.com -- The 13 bytes is the actual number. I chose the registrations to be as short as reasonable. I didn't want to use 'p' because I knew in 5-10 years someone would come along and go "what the F is 'p' for?". Whereas "prodid" is a bit more self-descriptive. > Are all of them needed and used at the same time? Yes. Hence my 10-15% increase in size! Indeed, some of them are even used more than once in a single certificate. >>> Having said that I wasn't around when it was conceived so probably >>> there is some rationale for its inclusion. >> >> Indeed. Honestly, at the time the intent was to progress the >> device-certs draft on its own and register those notations that way. >> But then the WG stalled, and Werner kindly incorporated those >> definitions into 4880bis. >> >> Still, adding these to 4880bis does not add significant complexity to >> the draft but DOES make a marked difference in its usability. Please do >> not remove these improvements. > > I don't know what are the criteria for inclusion but when reading the > rest of the RFC device-certs strike me as something with a narrow focus. > A stark contrast to otherwise generic and versatile constructs. True -- which is why it was originally proposed as a separate document. I'm fine with it continuing to be a separate document if that's the desire of the group, but I DO want to make these IANA registrations and I DO want to make the change to allow for a non-certification primary key. I'm fine either way, either the registrations being in 4880bis or resurrecting the device-certs draft and progressing that alongside 4880bis. The process just got muddied when the WG was shut down. > Could you share what's the rationale for keys being minimal? From what I > have seen it has something to do with devices of limited memory but I'm > eager to know details, are there any implementations of device-certs in > the wild? This is exactly it -- we are storing a certificate on an NFC (or even UHF RFID) chip that would be presented to a verifier -- and then the chip would perform a key exchange using the key in the certificate for a proof-of-possession authentication. Every byte matters, which is exactly why we went with OpenPGP and not X509! > For example what would the User ID Attribute look like? See above; I don't recall -- I'd have to go dig it up from this 3-4 year old project. However, it wasn't the content but the co-existence that was the issue IIRC. >>> [0] I did experiment with putting URIs in User IDs for extended info >>> (https://github.com/wiktor-k/distributed-ids#distributed-ids) >> >> Cool. But not useful to me ;) > > Hard to recommend something if I don't know what you're after :) Sure, but I'm not looking for you to recommend something. :) Thanks, > Kind regards, > Wiktor -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Feb 21 06:46:51 2019 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 9B4D012DDA3 for ; Thu, 21 Feb 2019 06:46:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9xFCy2NqXyOL for ; Thu, 21 Feb 2019 06:46:46 -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 E96DA12D7F8 for ; Thu, 21 Feb 2019 06:46:45 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id v16so24186824ljg.13 for ; Thu, 21 Feb 2019 06:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:cc:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XqP1mZ5aXS7HGMPwDl/z22oc7yAb3DlkEWgOLETccEs=; b=vcyeMmRFue7+FZ/Gx5LAabhLzsz1G9Hjt/bHBkAMPPD8/N6gwRBUWWdpzk68OfYzlu p+NYcnCP8t/YgVPe0+dMkg0y+BWrHEAPDHWxS2LGSgcRhlF/DH11qGC1VMt1Vgj8CaW9 XpnHEURvi22vcwBMLFMp8eGPKyELCUUzcWY+3snCIP3CWr94fNRsK4zP+KfnKT3qhPg3 ID9wjpYE90ypKZfcU7b5Zm1V1msHy9x3mOdKRwYWbLXVLQUnEddNyE2PYecjDQM25ue6 nUj0bs0TZUUTx7mLPX+cLJUAZEdwrcqTvEjCYEOoDq6IcJxNvHe1IWFbRa+G4IMSR7A2 YAyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XqP1mZ5aXS7HGMPwDl/z22oc7yAb3DlkEWgOLETccEs=; b=rG3A0kbumJh3A4frY6bktQr26aJ7SQKiKZ5bQuhIekilyX15g0P9ecoJMU7/en79M+ xi6Y6fLPJDZKLFf2O2XD9/zKA1QELzjE1OaGY7PoEr1+WwPPEPa53bk3Rk17bw2kcj/P omutT6NuM6Wpegt3p0Ee6a6qfuFjRVzZ9X1O4ESkUFslEUpJVTY1Y+bRN307rMg4ArkO WrNqxYN3HqhG0amroi6DQTo3lVPzUx0uqGIOfWYY8V5wq2XZ5OiFwALqN2veYp9Fyqpw 6J3i1FDxXwJZ7vgHKv7BqW2icyNp/KNRKXMF+8Y33hJSJG9C2xNQxzRaLrI/0OhsyBqE /BSw== X-Gm-Message-State: AHQUAuatBsY+ahqv/ejsPNNjkVHEu5y3Ug0OcQRoXqOCgmNpG9pxgYVl ggz2s93+xh+kLnWKDRIs5w4hmUulzHg= X-Google-Smtp-Source: AHgI3IZSJ6zJFziFXbmXTcrR4s3cnssExgJXpzCE0pJDUm/iELvD4GFYD38JBhfhf2UgRwREehEQKw== X-Received: by 2002:a2e:8847:: with SMTP id z7mr21968662ljj.99.1550760403357; Thu, 21 Feb 2019 06:46:43 -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 b18sm5680743lfj.97.2019.02.21.06.46.42 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 06:46:42 -0800 (PST) To: Derek Atkins Cc: openpgp@ietf.org References: <1741f774aa08d0df4a3ca481339bb733.squirrel@mail2.ihtfp.org> From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/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/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode Message-ID: Date: Thu, 21 Feb 2019 15:46:31 +0100 MIME-Version: 1.0 In-Reply-To: <1741f774aa08d0df4a3ca481339bb733.squirrel@mail2.ihtfp.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 21 Feb 2019 14:46:50 -0000 Hi Derek, On 21.02.2019 15:40, Derek Atkins wrote: > This is exactly it -- we are storing a certificate on an NFC (or even UHF > RFID) chip that would be presented to a verifier -- and then the chip > would perform a key exchange using the key in the certificate for a > proof-of-possession authentication. Every byte matters, which is exactly > why we went with OpenPGP and not X509! Sounds interesting, too bad it's not public, I'd gladly check out the implementation details :) Thanks for taking the time to describe it all! Kind regards, Wiktor -- https://metacode.biz/@wiktor From nobody Thu Feb 21 07:22:38 2019 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 733DC130DE3 for ; Thu, 21 Feb 2019 07:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 nG08riIBRGPX for ; Thu, 21 Feb 2019 07:22:35 -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 A60D91279E6 for ; Thu, 21 Feb 2019 07:22:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7D09DE2044; Thu, 21 Feb 2019 10:22:30 -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 13927-10; Thu, 21 Feb 2019 10:22:29 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 95ABCE2045; Thu, 21 Feb 2019 10:22:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1550762549; bh=GnKYFeDoFRTvyt5VsZDPR1oAQcb/8mWdGywsZSTnphk=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=bIHwH8Qgy8ZzNpjBk0w3Ho45zpZLHcGiHMJ60wZYvLYRYniF/BO7pOSxJ4XCMcTBo SumYrpJORmi/46TrJ9fB/Q9pxdSUx1/TSH2oXYdVajSbNB+4F8dHAuBhsXk9IJA2YM OqFTtO1F27wKeG0UjIU+1txSxiMMHF5pt6jN5KkE= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 21 Feb 2019 10:22:29 -0500 Message-ID: <080f25061d197cf222f7b47786c04fe7.squirrel@mail2.ihtfp.org> In-Reply-To: References: <1741f774aa08d0df4a3ca481339bb733.squirrel@mail2.ihtfp.org> Date: Thu, 21 Feb 2019 10:22:29 -0500 From: "Derek Atkins" To: "Wiktor Kwapisiewicz" Cc: "Derek Atkins" , openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket 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, 21 Feb 2019 15:22:37 -0000 Hi, On Thu, February 21, 2019 9:46 am, Wiktor Kwapisiewicz wrote: > Hi Derek, > > On 21.02.2019 15:40, Derek Atkins wrote: >> This is exactly it -- we are storing a certificate on an NFC (or even >> UHF >> RFID) chip that would be presented to a verifier -- and then the chip >> would perform a key exchange using the key in the certificate for a >> proof-of-possession authentication. Every byte matters, which is >> exactly >> why we went with OpenPGP and not X509! > > Sounds interesting, too bad it's not public, I'd gladly check out the > implementation details :) I will see what I can do about that. But no promises. :-) > Thanks for taking the time to describe it all! You're welcome. Thanks for listening :) > Kind regards, > Wiktor -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Feb 27 02:51:59 2019 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 7EBCB130ED8 for ; Wed, 27 Feb 2019 02:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 6QONaMreyB3e for ; Wed, 27 Feb 2019 02:51:54 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 76786130EB4 for ; Wed, 27 Feb 2019 02:51:54 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gywoZ-0007AI-MG for openpgp@ietf.org; Wed, 27 Feb 2019 10:51:51 +0000 Date: Wed, 27 Feb 2019 11:51:51 +0100 Message-ID: <87mumh33nc.wl-neal@walfield.org> From: "Neal H. Walfield" To: openpgp@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [openpgp] AEAD Chunk Size 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, 27 Feb 2019 10:51:58 -0000 The current version of 4880bis has a chunk size parameter for AEAD: ## AEAD Encrypted Data Packet (Tag 20) ... The body of this packet consists of: ... * A one-octet chunk size. ... The chunk size octet specifies the size of chunks using the following formula (in C), where c is the chunk size octet: chunk_size =3D ((uint64_t)1 << (c + 6)) An implementation MUST support chunk size octets with values from 0 to 56. Chunk size octets with other values are reserved for future extensions. Implementations SHOULD NOT create data with a chunk size octet value larger than 21 (128 MiB chunks) to facilitate buffering of not yet authenticated plaintext. https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05#section-5.16 In other words, chunks can be up to 1 << (56 + 6) =3D 2^62 bytes large (4 exbibytes). According to RFC 5116, an AEAD algorithm must not output partially decrypted data: If a particular implementation of an AEAD algorithm is requested to process an input that is outside the range of admissible lengths, or an input that is outside the range of lengths supported by that implementation, it MUST return an error code and it MUST NOT output any other information. In particular, partially encrypted or partially decrypted data MUST NOT be returned. https://tools.ietf.org/html/rfc5116#section-2.1 Because it is hard to know the context (i.e., the available resources) in which a message will be decrypted, it is difficult for an implementation to make a reasonable choice when doing the encryption. Actually, I'm not aware of any advantages for chunk sizes that are larger than a few kilobytes. Consequently, I propose not only imposing a reasonable ceiling on the chunk size that even small embedded devices with a cortex M0 could handle, but to simply fix the parameter to 16 KiB. It's not clear to me that a variable size offers any advantages. But, there is a clear disadvantage: it's unjustified complexity, which is a breeding ground for bugs. Unless someone can justify this added complexity, I see no reason to parameterize this. (If it is needed, the size could be a function of the actually AEAD algorithm, e.g., EAX, OCB, etc.) I've attached a patch that makes the proposed change. I've spoken with several people including Vincent Breitmoser (Open Keychain), Justus Winter & Kai Michaelis (also Sequoia), Phil Zimmermann, and Hanno B=F6ck and they all support this proposal. Thanks, :) Neal =46rom efd12443c2da194fdb40eb6f606c9d9bb9c46ddc Mon Sep 17 00:00:00 2001 From: "Neal H. Walfield" Date: Wed, 27 Feb 2019 11:32:11 +0100 Subject: [PATCH] Fix the AEAD chunk size to 16 kiByte. --- middle.mkd | 21 +++++---------------- 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/middle.mkd b/middle.mkd index 44d1246..4437df7 100644 --- a/middle.mkd +++ b/middle.mkd @@ -2694,8 +2694,6 @@ The body of this packet consists of: =20 * A one-octet AEAD algorithm. =20 - * A one-octet chunk size. - * A starting initialization vector of size specified by the AEAD algorithm. =20 @@ -2716,11 +2714,11 @@ a full authentication tag. =20 For each chunk, the AEAD construction is given the Packet Tag in new format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), -version number, cipher algorithm octet, AEAD algorithm octet, chunk -size octet, and an eight-octet, big-endian chunk index as additional +version number, cipher algorithm octet, AEAD algorithm octet, +and an eight-octet, big-endian chunk index as additional data. The index of the first chunk is zero. For example, the -additional data of the first chunk using EAX and AES-128 with a chunk -size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01, 0x10, +additional data of the first chunk using EAX and AES-128 +consists of the octets 0xD4, 0x01, 0x07, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00. =20 After the final chunk, the AEAD algorithm is used to produce a final @@ -2729,16 +2727,7 @@ given the additional data specified above, plus an e= ight-octet, big-endian value specifying the total number of plaintext octets encrypted. This allows detection of a truncated ciphertext. =20 -The chunk size octet specifies the size of chunks using the following -formula (in C), where c is the chunk size octet: - - chunk_size =3D ((uint64_t)1 << (c + 6)) - -An implementation MUST support chunk size octets with values from 0 to -56. Chunk size octets with other values are reserved for future -extensions. Implementations SHOULD NOT create data with a chunk size -octet value larger than 21 (128 MiB chunks) to facilitate buffering of -not yet authenticated plaintext. +The chunk size is 16 kiByte. =20 A new random initialization vector MUST be used for each message. Failure to do so for each message will lead to a catastrophic failure --=20 2.11.0 From nobody Wed Feb 27 03:25:44 2019 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 0272D130EBB for ; Wed, 27 Feb 2019 03:25:44 -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 cVIfGeT2BmVv for ; Wed, 27 Feb 2019 03:25:41 -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 6BAC5130EB4 for ; Wed, 27 Feb 2019 03:25:41 -0800 (PST) Received: from localhost (dhcp251-23.wlan.rz.tu-bs.de [134.169.251.23]) by mail.mugenguild.com (Postfix) with ESMTPSA id A47285FB11; Wed, 27 Feb 2019 12:25:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1551266738; bh=UeWWbzLG/Jiiv0yjSVHAWIX9OrDrIMqB5zdYYeEKmY4=; h=Date:From:To:Subject:Autocrypt:From; b=fWqJD28sZaO51lJYvHgQoxtSz3SEYFS6dPl7nbx/KOWRGklG4eugbceGhL3aq6UHW AQyV6O8fENCfH6tZg2MeZw4ybRoBfJwC4bON4+Trzaf1xG0gw9/5sqezQHRXdQjYSt 3bvoBfi4HOZArRefNF2zNRdjdpnU1bzkiVYn72Qw= Message-Id: In-Reply-To: <87mumh33nc.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> Date: Wed, 27 Feb 2019 12:25:38 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Breitmoser To: "Neal H. Walfield" 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] AEAD Chunk Size 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, 27 Feb 2019 11:25:44 -0000 Thanks for bringing this up, Neal. I do support this motion. For the record, related merge request is here: https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/16 - V "Neal H. Walfield" wrote: > The current version of 4880bis has a chunk size parameter for AEAD: > > ## AEAD Encrypted Data Packet (Tag 20) > > ... > > The body of this packet consists of: > > ... > > * A one-octet chunk size. > > ... > > The chunk size octet specifies the size of chunks using the > following formula (in C), where c is the chunk size octet: > > chunk_size = ((uint64_t)1 << (c + 6)) > > An implementation MUST support chunk size octets with values from 0 > to 56. Chunk size octets with other values are reserved for future > extensions. Implementations SHOULD NOT create data with a chunk > size octet value larger than 21 (128 MiB chunks) to facilitate > buffering of not yet authenticated plaintext. > > https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05#section-5.16 > > In other words, chunks can be up to 1 << (56 + 6) = 2^62 bytes large > (4 exbibytes). > > According to RFC 5116, an AEAD algorithm must not output partially > decrypted data: > > If a > particular implementation of an AEAD algorithm is requested to > process an input that is outside the range of admissible lengths, or > an input that is outside the range of lengths supported by that > implementation, it MUST return an error code and it MUST NOT output > any other information. In particular, partially encrypted or > partially decrypted data MUST NOT be returned. > > https://tools.ietf.org/html/rfc5116#section-2.1 > > Because it is hard to know the context (i.e., the available resources) > in which a message will be decrypted, it is difficult for an > implementation to make a reasonable choice when doing the encryption. > Actually, I'm not aware of any advantages for chunk sizes that are > larger than a few kilobytes. > > Consequently, I propose not only imposing a reasonable ceiling on the > chunk size that even small embedded devices with a cortex M0 could > handle, but to simply fix the parameter to 16 KiB. It's not clear to > me that a variable size offers any advantages. But, there is a clear > disadvantage: it's unjustified complexity, which is a breeding ground > for bugs. Unless someone can justify this added complexity, I see no > reason to parameterize this. > > (If it is needed, the size could be a function of the actually AEAD > algorithm, e.g., EAX, OCB, etc.) > > I've attached a patch that makes the proposed change. > > I've spoken with several people including Vincent Breitmoser (Open > Keychain), Justus Winter & Kai Michaelis (also Sequoia), Phil > Zimmermann, and Hanno Böck and they all support this proposal. > > Thanks, > > :) Neal > > > > From efd12443c2da194fdb40eb6f606c9d9bb9c46ddc Mon Sep 17 00:00:00 2001 > From: "Neal H. Walfield" > Date: Wed, 27 Feb 2019 11:32:11 +0100 > Subject: [PATCH] Fix the AEAD chunk size to 16 kiByte. > > --- > middle.mkd | 21 +++++---------------- > 1 file changed, 5 insertions(+), 16 deletions(-) > > diff --git a/middle.mkd b/middle.mkd > index 44d1246..4437df7 100644 > --- a/middle.mkd > +++ b/middle.mkd > @@ -2694,8 +2694,6 @@ The body of this packet consists of: > > * A one-octet AEAD algorithm. > > - * A one-octet chunk size. > - > * A starting initialization vector of size specified by the AEAD > algorithm. > > @@ -2716,11 +2714,11 @@ a full authentication tag. > > For each chunk, the AEAD construction is given the Packet Tag in new > format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), > -version number, cipher algorithm octet, AEAD algorithm octet, chunk > -size octet, and an eight-octet, big-endian chunk index as additional > +version number, cipher algorithm octet, AEAD algorithm octet, > +and an eight-octet, big-endian chunk index as additional > data. The index of the first chunk is zero. For example, the > -additional data of the first chunk using EAX and AES-128 with a chunk > -size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01, 0x10, > +additional data of the first chunk using EAX and AES-128 > +consists of the octets 0xD4, 0x01, 0x07, 0x01, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00. > > After the final chunk, the AEAD algorithm is used to produce a final > @@ -2729,16 +2727,7 @@ given the additional data specified above, plus an eight-octet, > big-endian value specifying the total number of plaintext octets > encrypted. This allows detection of a truncated ciphertext. > > -The chunk size octet specifies the size of chunks using the following > -formula (in C), where c is the chunk size octet: > - > - chunk_size = ((uint64_t)1 << (c + 6)) > - > -An implementation MUST support chunk size octets with values from 0 to > -56. Chunk size octets with other values are reserved for future > -extensions. Implementations SHOULD NOT create data with a chunk size > -octet value larger than 21 (128 MiB chunks) to facilitate buffering of > -not yet authenticated plaintext. > +The chunk size is 16 kiByte. > > A new random initialization vector MUST be used for each message. > Failure to do so for each message will lead to a catastrophic failure From nobody Wed Feb 27 13:34:29 2019 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 6226513114F for ; Wed, 27 Feb 2019 13:34:27 -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 6WI2v-uFRpg1 for ; Wed, 27 Feb 2019 13:34: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 5504B13113F for ; Wed, 27 Feb 2019 13:34:23 -0800 (PST) Date: Wed, 27 Feb 2019 21:34:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1551303255; bh=7bEvdgWNU0FZeA/cONgFurus8xdtgOfOaD/DIeY7shI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=E9UVacGcMysHIrJiTtIMXYKtfo6oCD4GICwyy4CRhmfjUX/8+g+QajdBXCGPZ5WjS TC+vEryFs/e2XIpCtA7xyvNOxrN3hQEhXeMvJQ5dcsgGfw7NugWoDwG75ABqKpbuEn ttxr8Slp+5SQYva0l7BnTsps/33eDMDkB/BaohHA= To: Vincent Breitmoser From: Bart Butler Cc: "Neal H. Walfield" , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------48837a3e2626b71821bdf16ecb2de6f0"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 27 Feb 2019 21:34:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------48837a3e2626b71821bdf16ecb2de6f0 Content-Type: multipart/mixed;boundary=---------------------228d40c8dc266073a0d692ad50ab45e7 -----------------------228d40c8dc266073a0d692ad50ab45e7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi all, We (Sunny Rajan and I) definitely agree with reducing the range of allowed= sizes, because both 4 exabyte chunks and large messages composed of 64-by= te chunks are clearly not optimal. In our AEAD implementation for OpenPGP.js we settled on a default `c` of 1= 2 rather than 8 after some performance benchmarking showed that 256 kiB ch= unks were more performant for the most common message sizes. Our result wa= s specific to the web crypto API, and therefore specific to OpenPGP.js, bu= t in general libraries may want to use different default sizes depending o= n implementation details like this. So ideally we=E2=80=99d prefer to keep the size byte, but to shrink its ra= nge in both directions. For example, the RFC could state that the chunk SH= OULD be 16 kiB (or 256 kiB, hint hint), but decryption MUST be available f= or `c` values between 8-12 inclusive. This would also allow us to be backw= ards-compatible with messages that have already been created following the= current version of the draft, which do exist given the benefit that AEAD = provides and that OpenPGP.js has supported the current draft in experiment= al mode for most of the last year. = Regards, Bart and Sunny =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, February 27, 2019 3:25 AM, Vincent Breitmoser wrote: > = > = > Thanks for bringing this up, Neal. I do support this motion. > = > For the record, related merge request is here: > https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/16 > = > - V > = > "Neal H. Walfield" neal@walfield.org wrote: > = > = > > The current version of 4880bis has a chunk size parameter for AEAD: > > = > > AEAD Encrypted Data Packet (Tag 20) > > = > > ------------------------------------ > > = > > ... > > The body of this packet consists of: > > ... > > = > > * A one-octet chunk size. > > = > > = > > ... > > The chunk size octet specifies the size of chunks using the > > following formula (in C), where c is the chunk size octet: > > = > > chunk_size =3D ((uint64_t)1 << (c + 6)) > > = > > = > > An implementation MUST support chunk size octets with values from 0 > > to 56. Chunk size octets with other values are reserved for future > > extensions. Implementations SHOULD NOT create data with a chunk > > size octet value larger than 21 (128 MiB chunks) to facilitate > > buffering of not yet authenticated plaintext. > > https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05#section-5= .16 > > In other words, chunks can be up to 1 << (56 + 6) =3D 2^62 bytes large > > (4 exbibytes). > > According to RFC 5116, an AEAD algorithm must not output partially > > decrypted data: > > If a > > particular implementation of an AEAD algorithm is requested to > > process an input that is outside the range of admissible lengths, or > > an input that is outside the range of lengths supported by that > > implementation, it MUST return an error code and it MUST NOT output > > any other information. In particular, partially encrypted or > > partially decrypted data MUST NOT be returned. > > https://tools.ietf.org/html/rfc5116#section-2.1 > > Because it is hard to know the context (i.e., the available resources) > > in which a message will be decrypted, it is difficult for an > > implementation to make a reasonable choice when doing the encryption. > > Actually, I'm not aware of any advantages for chunk sizes that are > > larger than a few kilobytes. > > Consequently, I propose not only imposing a reasonable ceiling on the > > chunk size that even small embedded devices with a cortex M0 could > > handle, but to simply fix the parameter to 16 KiB. It's not clear to > > me that a variable size offers any advantages. But, there is a clear > > disadvantage: it's unjustified complexity, which is a breeding ground > > for bugs. Unless someone can justify this added complexity, I see no > > reason to parameterize this. > > (If it is needed, the size could be a function of the actually AEAD > > algorithm, e.g., EAX, OCB, etc.) > > I've attached a patch that makes the proposed change. > > I've spoken with several people including Vincent Breitmoser (Open > > Keychain), Justus Winter & Kai Michaelis (also Sequoia), Phil > > Zimmermann, and Hanno B=C3=B6ck and they all support this proposal. > > Thanks, > > :) Neal > > From efd12443c2da194fdb40eb6f606c9d9bb9c46ddc Mon Sep 17 00:00:00 2001 > > From: "Neal H. Walfield" neal@gnu.org > > Date: Wed, 27 Feb 2019 11:32:11 +0100 > > Subject: [PATCH] Fix the AEAD chunk size to 16 kiByte. > > = > > middle.mkd | 21 +++++---------------- > > 1 file changed, 5 insertions(+), 16 deletions(-) > > diff --git a/middle.mkd b/middle.mkd > > index 44d1246..4437df7 100644 > > --- a/middle.mkd > > +++ b/middle.mkd > > @@ -2694,8 +2694,6 @@ The body of this packet consists of: > > = > > - A one-octet AEAD algorithm. > > = > > - - A one-octet chunk size. > > - - A starting initialization vector of size specified by the AEAD > > algorithm. > > = > > = > > @@ -2716,11 +2714,11 @@ a full authentication tag. > > For each chunk, the AEAD construction is given the Packet Tag in new > > format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), > > -version number, cipher algorithm octet, AEAD algorithm octet, chunk > > -size octet, and an eight-octet, big-endian chunk index as additional > > +version number, cipher algorithm octet, AEAD algorithm octet, > > +and an eight-octet, big-endian chunk index as additional > > data. The index of the first chunk is zero. For example, the > > -additional data of the first chunk using EAX and AES-128 with a chunk > > -size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01, 0x10= , > > +additional data of the first chunk using EAX and AES-128 > > +consists of the octets 0xD4, 0x01, 0x07, 0x01, > > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00. > > After the final chunk, the AEAD algorithm is used to produce a final > > @@ -2729,16 +2727,7 @@ given the additional data specified above, plus= an eight-octet, > > big-endian value specifying the total number of plaintext octets > > encrypted. This allows detection of a truncated ciphertext. > > = > > -The chunk size octet specifies the size of chunks using the following > > -formula (in C), where c is the chunk size octet: > > = > > ----------------------------------------------------------------------= --------------------------------------------------- > > = > > - chunk_size =3D ((uint64_t)1 << (c + 6)) > > = > > = > > - = > > = > > -An implementation MUST support chunk size octets with values from 0 t= o > > -56. Chunk size octets with other values are reserved for future > > -extensions. Implementations SHOULD NOT create data with a chunk size > > -octet value larger than 21 (128 MiB chunks) to facilitate buffering o= f > > -not yet authenticated plaintext. > > +The chunk size is 16 kiByte. > > A new random initialization vector MUST be used for each message. > > Failure to do so for each message will lead to a catastrophic failure > = > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------228d40c8dc266073a0d692ad50ab45e7-- -----------------------48837a3e2626b71821bdf16ecb2de6f0 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 wl4EARYKAAYFAlx3AkUACgkQmQVEZe8zHkSLywD+J4PtWBNKXyONQht1wrE4 exmPn/UhJ/d5t8NwlLg0VGYA/i06cwPg4wfUziwa6XxixfY7L5/KutiCLP4V tHF+UKsE =CE6l -----END PGP SIGNATURE----- -----------------------48837a3e2626b71821bdf16ecb2de6f0-- From nobody Wed Feb 27 14:37:24 2019 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 B8DEA1311A4 for ; Wed, 27 Feb 2019 14:37:23 -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 (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 um1zrF-pbWDq for ; Wed, 27 Feb 2019 14:37:22 -0800 (PST) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE95C1311A3 for ; Wed, 27 Feb 2019 14:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1551307041; bh=AWoaPfUcSrMuZyLmnoxWh74zZ3I9z8gB1mt9BaPI9O0=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=gOteEXmrOxkVUcboxRpAaUV+DBTxqj6ydrJtB4U1xvz+PiHKGZLTUkbV8Lqnoo8Pz cdEk5ZRUZ/3xQ0iJSik0o5ruSa1wEWZyrHN/qzOPVbiZupMlv0TeHWwNvr9gDECLZ/ l9rcuyfthiiMfQAoVoguT5JASj5RgLvk9HrjWy3s8rWl6o49qLBTQfel0UlxO2qLYD Mgo0eLMr4BJ36vJvwPGH0KSgWUOeqe39HdA/eDizHuNpAviR5QmV6BMK8JWXX8Yjly 41beXpZCKbfJzQN/IFpHuK8J+pl64ZpbM+EhcY5LhEawQVH+EIAG/E0OwapIgfI6yQ qD24gF4i7RB+g== Received: from [10.125.12.153] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id 2B63C7200E7; Wed, 27 Feb 2019 22:37:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> Date: Wed, 27 Feb 2019 14:37:20 -0800 Cc: Jon Callas , Vincent Breitmoser , "openpgp@ietf.org" , "Neal H. Walfield" Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> To: Bart Butler X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-27_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1902270147 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 27 Feb 2019 22:37:24 -0000 > On Feb 27, 2019, at 1:34 PM, Bart Butler = wrote: >=20 > Hi all, >=20 > We (Sunny Rajan and I) definitely agree with reducing the range of = allowed sizes, because both 4 exabyte chunks and large messages composed = of 64-byte chunks are clearly not optimal. >=20 > In our AEAD implementation for OpenPGP.js we settled on a default `c` = of 12 rather than 8 after some performance benchmarking showed that 256 = kiB chunks were more performant for the most common message sizes. Our = result was specific to the web crypto API, and therefore specific to = OpenPGP.js, but in general libraries may want to use different default = sizes depending on implementation details like this. >=20 > So ideally we=E2=80=99d prefer to keep the size byte, but to shrink = its range in both directions. For example, the RFC could state that the = chunk SHOULD be 16 kiB (or 256 kiB, hint hint), but decryption MUST be = available for `c` values between 8-12 inclusive. This would also allow = us to be backwards-compatible with messages that have already been = created following the current version of the draft, which do exist given = the benefit that AEAD provides and that OpenPGP.js has supported the = current draft in experimental mode for most of the last year.=20 I think this is a reasonable way to have it to put an upper limit with a = SHOULD. I believe that if we limit it to 16K, we *will* regret that, for = performance or other reasons. And while some of the upper sizes are = presently absurdly large, one never knows what happens a couple decades = from now.=20 Moreover, forbidding it says that we state now that no one could ever = have a reasonable use; my experience is that categorical statements like = that are just asking the fates to bite us in an uncomfortable place. = Amazon S3 increased their max object size to 5TB a few years ago. I=E2=80=99= m not saying it should be that large, but I think this is a pretty = convincing argument that 16K is too small. So I think that a SHOULD is the right way to put it. I care less about = what the SHOULD limit should be, but a small hard limit sounds like a = bad idea. Jon= From nobody Wed Feb 27 15:00:26 2019 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 CAC8A1311AF for ; Wed, 27 Feb 2019 15:00:25 -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 fOgWBoBP7yaY for ; Wed, 27 Feb 2019 15:00:22 -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 E81FF130EDA for ; Wed, 27 Feb 2019 15:00:21 -0800 (PST) Date: Wed, 27 Feb 2019 23:00:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1551308419; bh=RSBgNFpHPgXQA/JhqoC8OfAr96q0h3zPkHTB4CUdY9g=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=BXLZOY7a0ZfcW5isolROLM3hQdUI8gCAqMr/7BIHljN59rlqXiiGIVh/f/Zt8qHIk eaTbxokLgk1DNKM9JySGokWlPdkgDp4dGFs0Ju2ix6G1oHy8bvv0dA7QAhkBij04Us erkjfyV/om0tYivZyumhO6z7zXzC4zzw9joAlnS8= To: Jon Callas From: Bart Butler Cc: Vincent Breitmoser , "openpgp@ietf.org" , "Neal H. Walfield" Reply-To: Bart Butler Message-ID: In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------da08421dbe4b7742f26d29181b853236"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 27 Feb 2019 23:00:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------da08421dbe4b7742f26d29181b853236 Content-Type: multipart/mixed;boundary=---------------------8b5acec33160e7f690abe8e12e1395b4 -----------------------8b5acec33160e7f690abe8e12e1395b4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Jon, Do I understand correctly that you oppose shrinking the allowable range wi= th MUST at all too? I think the argument for this is fairly convincing fro= m a usage perspective to ensure that someone decrypting a large message is= not obligated to download a huge amount of data before finding out that i= t is corrupted or otherwise has been tampered with. Likewise, we had to ad= dress unanticipated performance issues in OpenPGP.js with very small chunk= s which could have allowed a bad actor to essentially DoS the library with= a strangely-constructed message. In other words, I'm not really swayed by the implementation simplification= argument but I do think that very small or very large chunk size, in addi= tion to *probably* being useless, pose a real threat in terms of abuse. So I think having a MUST for the range, maybe 16kiB to 256 kiB, or 16 kiB = to 1024 kiB is a reasonable thing to do. And as long as we keep the size b= yte, we can always increase the upper limit of the range in the future if = needed. Bart =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, February 27, 2019 2:37 PM, Jon Callas = wrote: > = > = > > On Feb 27, 2019, at 1:34 PM, Bart Butler bartbutler=3D40protonmail.com= @dmarc.ietf.org wrote: > > Hi all, > > We (Sunny Rajan and I) definitely agree with reducing the range of all= owed sizes, because both 4 exabyte chunks and large messages composed of 6= 4-byte chunks are clearly not optimal. > > In our AEAD implementation for OpenPGP.js we settled on a default `c` = of 12 rather than 8 after some performance benchmarking showed that 256 ki= B chunks were more performant for the most common message sizes. Our resul= t was specific to the web crypto API, and therefore specific to OpenPGP.js= , but in general libraries may want to use different default sizes dependi= ng on implementation details like this. > > So ideally we=E2=80=99d prefer to keep the size byte, but to shrink it= s range in both directions. For example, the RFC could state that the chun= k SHOULD be 16 kiB (or 256 kiB, hint hint), but decryption MUST be availab= le for `c` values between 8-12 inclusive. This would also allow us to be b= ackwards-compatible with messages that have already been created following= the current version of the draft, which do exist given the benefit that A= EAD provides and that OpenPGP.js has supported the current draft in experi= mental mode for most of the last year. > = > I think this is a reasonable way to have it to put an upper limit with a= SHOULD. > = > I believe that if we limit it to 16K, we will regret that, for performan= ce or other reasons. And while some of the upper sizes are presently absur= dly large, one never knows what happens a couple decades from now. > = > Moreover, forbidding it says that we state now that no one could ever ha= ve a reasonable use; my experience is that categorical statements like tha= t are just asking the fates to bite us in an uncomfortable place. Amazon S= 3 increased their max object size to 5TB a few years ago. I=E2=80=99m not = saying it should be that large, but I think this is a pretty convincing ar= gument that 16K is too small. > = > So I think that a SHOULD is the right way to put it. I care less about w= hat the SHOULD limit should be, but a small hard limit sounds like a bad i= dea. > = > Jon -----------------------8b5acec33160e7f690abe8e12e1395b4-- -----------------------da08421dbe4b7742f26d29181b853236 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 wl4EARYKAAYFAlx3FnoACgkQmQVEZe8zHkQPoQD+N5WHyCzxeN7Kx57heHZ/ t3h+GjdPi5352euRb7+LEJEBAMMbrqH65Lq5LSpEjqewZRTtw0BkDwdQ2n5s aRUVbmkL =b6Rv -----END PGP SIGNATURE----- -----------------------da08421dbe4b7742f26d29181b853236-- From nobody Wed Feb 27 16:03:16 2019 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 8EE3D131102 for ; Wed, 27 Feb 2019 16:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 n9MphPyam-_F for ; Wed, 27 Feb 2019 16:03:12 -0800 (PST) Received: from mr85p00im-zteg06011501.me.com (mr85p00im-zteg06011501.me.com [17.58.23.182]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC786130EA7 for ; Wed, 27 Feb 2019 16:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1551312191; bh=vemk2J30kpT+EnAMtN8xMtKaWWUZEoTVKcM1tTnI+Ic=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=P5msR2nSvDsPe4gpTcEMU7ROTxNrxPL3PL4ne17M528fq0lsH9HFe2/yypJYhy2aA 1OPFfQAw7ara4K+PYr3zWXBjZbKTsnIGUE5Ba0IPDmgs3zYel4/kZtyXUDgBsUG5yj 7SuuPdDXJ+sUOjl4kYyDI5vxpgy+oGNQ9VmYOtrAXW8x4WJn854xv79SfA1NZ3r7k2 W8eBL7eF3hBwQ3Vg57xRNOYftYrd9yQ0KZW6FZzM2IWPB4eH9QUYxbyZUVe88yHjzO MEd5tDjEGT/THNfFYz1lcOG6yo7ydUARGawsE/17XqSodzSQz5tQAzuHs8jP/nGS9R l6moEgpjMdPyA== Received: from [10.125.12.153] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-zteg06011501.me.com (Postfix) with ESMTPSA id 78C6D2A00C7; Thu, 28 Feb 2019 00:03:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: Date: Wed, 27 Feb 2019 16:03:10 -0800 Cc: Jon Callas , Vincent Breitmoser , "openpgp@ietf.org" , "Neal H. Walfield" Content-Transfer-Encoding: quoted-printable Message-Id: <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> To: Bart Butler X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-27_15:, , signatures=0 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=783 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1902270155 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 00:03:15 -0000 > On Feb 27, 2019, at 3:00 PM, Bart Butler = wrote: >=20 > Hi Jon, >=20 > Do I understand correctly that you oppose shrinking the allowable = range with MUST at all too? I think the argument for this is fairly = convincing from a usage perspective to ensure that someone decrypting a = large message is not obligated to download a huge amount of data before = finding out that it is corrupted or otherwise has been tampered with. = Likewise, we had to address unanticipated performance issues in = OpenPGP.js with very small chunks which could have allowed a bad actor = to essentially DoS the library with a strangely-constructed message. >=20 > In other words, I'm not really swayed by the implementation = simplification argument but I do think that very small or very large = chunk size, in addition to *probably* being useless, pose a real threat = in terms of abuse. >=20 > So I think having a MUST for the range, maybe 16kiB to 256 kiB, or 16 = kiB to 1024 kiB is a reasonable thing to do. And as long as we keep the = size byte, we can always increase the upper limit of the range in the = future if needed. My warning is against shooting someone else in the foot, or forcing them = to use some other protocol. Thus, saying (e.g.) that the range MUST be between 1K and 16K is a bad = idea; we even know now that 256K has in some cases an efficiency = advantage. You can say, MUST support 1K to 16K, SHOULD support up to = 256K and MAY support larger sizes. There can also be a couple of = paragraphs to explain that there are good reasons neither to be very = small nor very large. My concern is someone saying something like, =E2=80=9CGosh, I=E2=80=99d = like to have OpenPGP AEAD encryption for S3 Objects, but I can=E2=80=99t = =E2=80=98cause those go up to 5TB.=E2=80=9D Anyone who=E2=80=99s going = to use 5TB objects probably knows the headaches they inherit and yeah, = you aren=E2=80=99t going to do that on a Cortex M0. Does this make sense? Jon From nobody Wed Feb 27 16:34:51 2019 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 BB9B01311D7 for ; Wed, 27 Feb 2019 16:34:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 CFItUeh6m-QS for ; Wed, 27 Feb 2019 16:34:47 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300080.outbound.protection.outlook.com [40.107.130.80]) (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 CB36E130EEC for ; Wed, 27 Feb 2019 16:34:46 -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=oU4KY0UbqGboKboLWgicurhH+FSkNo2Z0eH+k3+rqII=; b=mpv3oKOrz+bmdmUxzkEs0w4dMzrM8ovbbtTguUiyt2QyiojJrwNQCOruORJkkKl8FUF3P3Sn6E63R6OQ7udDVDg4FyUG4piZ8sAZGziU3R95eDRd8Ihp9MJ6lUW+5SvZZ2mZJvBqngyTNMiJaTSuM9kFWIyXKfxnNrWUQlwV3y8= Received: from SG2PR01MB2776.apcprd01.prod.exchangelabs.com (20.177.169.82) by SG2PR01MB2743.apcprd01.prod.exchangelabs.com (20.177.170.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Thu, 28 Feb 2019 00:34:42 +0000 Received: from SG2PR01MB2776.apcprd01.prod.exchangelabs.com ([fe80::79b5:927d:1203:98cc]) by SG2PR01MB2776.apcprd01.prod.exchangelabs.com ([fe80::79b5:927d:1203:98cc%4]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 00:34:42 +0000 From: Ronald Tse To: Jon Callas CC: "openpgp@ietf.org" Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHUzop/kFDDrLByAk23BDwcx/qYg6XzgT4AgACqBYCAABGnAIAABmWAgAARlgCAAAjQ7g== Date: Thu, 28 Feb 2019 00:34:42 +0000 Message-ID: <2C8450F0-76D2-4EE7-934C-546C5131FF1F@ribose.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> , <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> In-Reply-To: <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> 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: [124.217.189.165] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5453d80b-7faf-4d73-15bd-08d69d148806 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(7168020)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SG2PR01MB2743; x-ms-traffictypediagnostic: SG2PR01MB2743: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtTRzJQUjAxTUIyNzQzOzIzOllwczhxNm9mMG9TYVI0N1FjU0Y4OE85MVZw?= =?utf-8?B?OE1IZFJsckx5NUduSGtvUlBDTFZYZHRIWmRFZmJ4dUdxdlc1TjBkQWpXaEgr?= =?utf-8?B?R3FIMHVHcC9WUG5tL1doVEJualZENU8zOUtocnF2MWlCWWM5YjE0M0pMS21H?= =?utf-8?B?U0xEMHp0VE5aT3loMzNpcDJLQ1Qra2pGK1NHeVplT3hVQS8rME5KRU1EWWpX?= =?utf-8?B?YkN5YW5ZOTQ3dHdkWmFHRWorazEzUWp2Q0JxZWlaV0hadkl1QjlDSkpVVFZ6?= =?utf-8?B?NEt0cDh4eUI4c3Mxa2hTYUFVUW11anJRc1lvVXFGL3VVWTByTUlybDE0Zy9z?= =?utf-8?B?dXp3ZkMzalpLd3FmZGVRcXJwK3RDU0h3MzBaV2xpUmVMN2gwbzRHSk5tYzJq?= =?utf-8?B?dlkwNGJ3TFNEYVBVeXZwdVNuV0o5b3hZQ3JzSWhKRkR6MDZaaUpkNjJhQ1Jk?= =?utf-8?B?T2p1ZGFmRFE0QU9RVmRvN1I3VnFyNVpGMDFGYXRZdzhQY2xQdFBOQlVuNTcy?= =?utf-8?B?aFp4VGw2eCt0eGRnOUNsYmlMMU5LUWk5S3FtcHZDNmJER3hQd1kvNW1QdmE1?= =?utf-8?B?YjJ2VmRUNnN5N2lPKzFxSno2TGl5d2YzYWE4WndWVVBPQnVjd3hwcWR5N3d1?= =?utf-8?B?WldZUEtlSThzOUR3WUtObFRLcm9LeWxyUlgvYm5OcTJJQjIzTXpyL3EyNGNS?= =?utf-8?B?V2wvWjEzYngwKzNTZ0pmRDVMQmN2Nm02K1FnZEhRTklPak9tTGwzOE1vVTV5?= =?utf-8?B?QW5WY3RXN2hLNnZHYVljQnB3a0g3WWg5T2FGWWR0b0lQVUV0dGZJdEtUT2lP?= =?utf-8?B?KzB5RFVweWVicll4aUJyM1NvQW1FR2V6dllwQU95MEMrcXBjYi9LVWRBeEVP?= =?utf-8?B?WEpLZlJuNWdLSHdlM3AyYkRNSnJ4Qmg3OUJUQVZOWmJmemprL1RNb2t1QWV3?= =?utf-8?B?WjUwQitTVmNEdVhpSGhVVUZyelJuM2pLZWJvZ3kvMGpjNkxxZDhNakxjSHl1?= =?utf-8?B?S2ZlV21EYzJCN1RGZmJFUVhJbHlNN2J6bmdJU1dOYkFZalU1SHVmdE80aUI0?= =?utf-8?B?aG54eXdXL0V2QzVaNTRxSkRDNGdGcGt4UnNnZEVGMGVVRElocVlXTTByaDBJ?= =?utf-8?B?ZlBGRE9FejBzbys4SHBxM0FhWnJDVXR4NXdUOXVRZ2IzSHFtdmlIK21wK0RS?= =?utf-8?B?MkZkMFpDeEtiZjFmdGU4OWdNYVNrRXdPNWp5dFQxVEpjb2lrVTJXSHo3ZWxT?= =?utf-8?B?ODZsN2JKZ29RVWJTVHVCYkRVQWF3UWFyTDl1NnFydFpnaUE1WnpuRUhVSUw5?= =?utf-8?B?ZHkzUEluNGFqTzd0d2txY1NUWHBnWkxMdTVjQmlJcjVTVHRTdjZES3pIWkht?= =?utf-8?B?OTUvemhaN3FPWlA2eW45YzBKTlM4ZVRnbjBuakpmMDdadkNGWXBRTVZQNXYv?= =?utf-8?B?dTNkaHJqTndueitXVktTTVk4WTROTm5RWVRwSWRFQ2Q2WlZJdUtXRHVWcU0y?= =?utf-8?B?ajYxTllKbmVrbS9sVTRLbXBMd3VVb1NhcCtWMXBzNDJRMTJyWjFWbHIrVWxP?= =?utf-8?B?SENlSlY4WUZES2FiNGJTYXFrUUtkS3dmaUZsNFdyNlp0bXZTeHYwSEhneWFm?= =?utf-8?B?cG5KUE5tSitkTUpMQ2NETXF2T2xHakxFWDlZNWlUM0Jka1hUZTJPNGRQaDQw?= =?utf-8?Q?lRn/QPLii6/QD7RDtWOLF2Ex04qh3FgKDakHQpA?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39830400003)(376002)(346002)(136003)(396003)(189003)(199004)(86362001)(446003)(4326008)(6116002)(66066001)(486006)(229853002)(14444005)(68736007)(2616005)(256004)(36756003)(71190400001)(11346002)(3846002)(83716004)(105586002)(8936002)(106356001)(476003)(25786009)(71200400001)(186003)(6486002)(6436002)(8676002)(5660300002)(236005)(97736004)(81166006)(2906002)(33656002)(508600001)(81156014)(54896002)(53936002)(6246003)(55236004)(6506007)(99286004)(14454004)(76176011)(7736002)(82746002)(26005)(102836004)(316002)(6512007)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:SG2PR01MB2743; H:SG2PR01MB2776.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ncCDpAfmWhBUFPQJd3jq764k1aUI3+jW0+BdWS64rN9r3dfqYzpPKfBwtkla4m6dc41URwyTv4bJzXeCWkKGR0FUQMUSHqpel9X/ZhQPoTcavUHZoX1PWXcXZ/0BpJz2RWaVeCvnTIRJR+np8nTIBHrAtgSIr8aCE8Z/PSR9H3exVxScqaIHv/J1zvgtndkNvZITnXd+tKfkG1WsQaHVnydkFvx9mrDc/aQHS0pmKTZr57uFY7x3yzAHH9haJBA0x4G/br5UYrvjm8wWO0hmWx0ogV0m/9mY91JXiXK00tyAG8dg6lkiKfp6sNnGgbUuF8263aHdi+glJdf3uEcazKYybl1jv9qSwfni4O+U1rG3T0ajyqw0Lt0FrheV6Kl+9TAz/TqL2+FZ5Ibs01GH2YUEt0cfJoFQw+aJo+Ze6zs= Content-Type: multipart/alternative; boundary="_000_2C8450F076D24EE7934C546C5131FF1Fribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5453d80b-7faf-4d73-15bd-08d69d148806 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 00:34:42.4759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR01MB2743 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 00:34:50 -0000 --_000_2C8450F076D24EE7934C546C5131FF1Fribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIHRoaXMgaXMgYSB2ZXJ5IHJlYXNvbmFibGUgYXBwcm9hY2guIEkgc3VwcG9ydCBKb27igJlz IHRha2Ugb24gdGhpcy4NCg0KVGh1cywgc2F5aW5nIChlLmcuKSB0aGF0IHRoZSByYW5nZSBNVVNU IGJlIGJldHdlZW4gMUsgYW5kIDE2SyBpcyBhIGJhZCBpZGVhOyB3ZSBldmVuIGtub3cgbm93IHRo YXQgMjU2SyBoYXMgaW4gc29tZSBjYXNlcyBhbiBlZmZpY2llbmN5IGFkdmFudGFnZS4gWW91IGNh biBzYXksIE1VU1Qgc3VwcG9ydCAxSyB0byAxNkssIFNIT1VMRCBzdXBwb3J0IHVwIHRvIDI1Nksg YW5kIE1BWSBzdXBwb3J0IGxhcmdlciBzaXplcy4gVGhlcmUgY2FuIGFsc28gYmUgYSBjb3VwbGUg b2YgcGFyYWdyYXBocyB0byBleHBsYWluIHRoYXQgdGhlcmUgYXJlIGdvb2QgcmVhc29ucyBuZWl0 aGVyIHRvIGJlIHZlcnkgc21hbGwgbm9yIHZlcnkgbGFyZ2UuDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KUm9uYWxkIFRzZQ0KUmlib3NlIEluYy4NCg0KKz09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSsNClRo aXMgbWVzc2FnZSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQNCmlu Zm9ybWF0aW9uLiAgSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3NlZSBvciBhdXRob3JpemVkIHRv DQpyZWNlaXZlIHRoaXMgZm9yIHRoZSBhZGRyZXNzZWUsIHlvdSBtdXN0IG5vdCB1c2UsIGNvcHks DQpkaXNjbG9zZSBvciB0YWtlIGFueSBhY3Rpb24gYmFzZWQgb24gdGhpcyBtZXNzYWdlIG9yIGFu eQ0KaW5mb3JtYXRpb24gaGVyZWluLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdl IGluDQplcnJvciwgcGxlYXNlIGFkdmlzZSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IHJlcGx5 IGUtbWFpbA0KYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UuICBUaGFuayB5b3UgZm9yIHlvdXIgY29v cGVyYXRpb24uDQorPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Kw0KDQpPbiBGZWIgMjgsIDIwMTksIGF0IDg6MDMgQU0sIEpvbiBDYWxsYXMg PGpvbmNhbGxhcz00MGljbG91ZC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmpvbmNhbGxhcz00 MGljbG91ZC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQo= --_000_2C8450F076D24EE7934C546C5131FF1Fribosecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpB bmQgdGhpcyBpcyBhIHZlcnkgcmVhc29uYWJsZSBhcHByb2FjaC4gSSBzdXBwb3J0IEpvbuKAmXMg dGFrZSBvbiB0aGlzLiZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3Bh biBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdi YSgyNTUsIDI1NSwgMjU1LCAwKTsiPlRodXMsIHNheWluZyAoZS5nLikgdGhhdCB0aGUgcmFuZ2Ug TVVTVCBiZSBiZXR3ZWVuIDFLIGFuZCAxNksgaXMgYSBiYWQgaWRlYTsgd2UgZXZlbiBrbm93IG5v dyB0aGF0IDI1NksgaGFzIGluIHNvbWUgY2FzZXMgYW4gZWZmaWNpZW5jeSBhZHZhbnRhZ2UuDQog WW91IGNhbiBzYXksIE1VU1Qgc3VwcG9ydCAxSyB0byAxNkssIFNIT1VMRCBzdXBwb3J0IHVwIHRv IDI1NksgYW5kIE1BWSBzdXBwb3J0IGxhcmdlciBzaXplcy4gVGhlcmUgY2FuIGFsc28gYmUgYSBj b3VwbGUgb2YgcGFyYWdyYXBocyB0byBleHBsYWluIHRoYXQgdGhlcmUgYXJlIGdvb2QgcmVhc29u cyBuZWl0aGVyIHRvIGJlIHZlcnkgc21hbGwgbm9yIHZlcnkgbGFyZ2UuPC9zcGFuPjwvZm9udD48 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0 dXJlIiBkaXI9Imx0ciI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAy NTUsIDI1NSwgMCk7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUm9uYWxkIFRzZTxiciBjbGFzcz0iIj4NClJpYm9zZSBJ bmMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJiM0Mzs9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0mIzQzOzxiciBjbGFzcz0iIj4N ClRoaXMgbWVzc2FnZSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQ8 YnIgY2xhc3M9IiI+DQppbmZvcm1hdGlvbi4gJm5ic3A7SWYgeW91IGFyZSBub3QgdGhlIGFkZHJl c3NlZSBvciBhdXRob3JpemVkIHRvPGJyIGNsYXNzPSIiPg0KcmVjZWl2ZSB0aGlzIGZvciB0aGUg YWRkcmVzc2VlLCB5b3UgbXVzdCBub3QgdXNlLCBjb3B5LDxiciBjbGFzcz0iIj4NCmRpc2Nsb3Nl IG9yIHRha2UgYW55IGFjdGlvbiBiYXNlZCBvbiB0aGlzIG1lc3NhZ2Ugb3IgYW55PGJyIGNsYXNz PSIiPg0KaW5mb3JtYXRpb24gaGVyZWluLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IG1lc3NhZ2UgaW48YnIgY2xhc3M9IiI+DQplcnJvciwgcGxlYXNlIGFkdmlzZSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGJ5IHJlcGx5IGUtbWFpbDxiciBjbGFzcz0iIj4NCmFuZCBkZWxldGUgdGhp cyBtZXNzYWdlLiAmbmJzcDtUaGFuayB5b3UgZm9yIHlvdXIgY29vcGVyYXRpb24uPGJyIGNsYXNz PSIiPg0KJiM0Mzs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0mIzQzOzwvc3Bhbj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCk9uIEZl YiAyOCwgMjAxOSwgYXQgODowMyBBTSwgSm9uIENhbGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpv bmNhbGxhcz00MGljbG91ZC5jb21AZG1hcmMuaWV0Zi5vcmciPmpvbmNhbGxhcz00MGljbG91ZC5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2C8450F076D24EE7934C546C5131FF1Fribosecom_-- From nobody Wed Feb 27 16:35:26 2019 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 5E8B4131200 for ; Wed, 27 Feb 2019 16:35:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 rEGGjFbd9pz2 for ; Wed, 27 Feb 2019 16:35:23 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300089.outbound.protection.outlook.com [40.107.130.89]) (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 0CF571311FF for ; Wed, 27 Feb 2019 16:35:22 -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=Zp0Jo4Iz1RRbWVZtxzB16/VFadn7eluznHUdwn6debI=; b=u3h7vwz6p6zgFtHIUe5jm/gbaeNMUlQwQ0nbgAEoiyzG2QFKrnzNAke4ZLemxRlg+M5Gw0uDixfh7VbaAbE2WfL/8yZ7B3ddBlZi8zuGDTGprGOSVuE0RArr1QOIxcUxFRyDpnL0wqFgNQs+gLgv5M6D+akoT3gI0Dd67tGWrhM= Received: from SG2PR01MB2776.apcprd01.prod.exchangelabs.com (20.177.169.82) by SG2PR01MB2743.apcprd01.prod.exchangelabs.com (20.177.170.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Thu, 28 Feb 2019 00:35:20 +0000 Received: from SG2PR01MB2776.apcprd01.prod.exchangelabs.com ([fe80::79b5:927d:1203:98cc]) by SG2PR01MB2776.apcprd01.prod.exchangelabs.com ([fe80::79b5:927d:1203:98cc%4]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 00:35:19 +0000 From: Ronald Tse To: "openpgp@ietf.org" Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHUzop/kFDDrLByAk23BDwcx/qYg6XzgT4AgACqBYCAABGnAIAABmWAgAARlgCAAAj9Yg== Date: Thu, 28 Feb 2019 00:35:19 +0000 Message-ID: <6A3FD8B9-7957-42CA-A704-A2C983A52BB3@ribose.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> , <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> In-Reply-To: <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> 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: [124.217.189.165] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec666a87-03ed-4336-7e88-08d69d149e48 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(7168020)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SG2PR01MB2743; x-ms-traffictypediagnostic: SG2PR01MB2743: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtTRzJQUjAxTUIyNzQzOzIzOld4MGpJQWZGZzlOU0dhNEhIMFc2OFpKVFVa?= =?utf-8?B?TUsrT0d2cVY5YzNGdGFLSjA2ZmJMTE1oUnA2STk5OU56YVVJU1ZlWWtEQURX?= =?utf-8?B?dWlkWVJmWWNtK2ZObVA0MWNtTmE5bzBsZTNIUS8vOUpzdWNsU2tRdHhGbU1J?= =?utf-8?B?SDQ3aXp2cWg1TzBYY21TejZWYXlBVlc4dmxib0NueGdoUUNLeWZtMmlFQ3k5?= =?utf-8?B?eG55dXlwc29OdEVBVkJrU0pwWlQ2RzJKM2dMTC9RaGM1dWxZQ2JvZDI5ZnVh?= =?utf-8?B?R0dCUG1rYWFEQmNBR2xhOEVxZkJFRldtWm5NNC95YzVSZCtyOENnVXFjQm90?= =?utf-8?B?bHVFMnVadXl2bnpHQTVJR3RNcFJRak9kT2tXV2t5RnhhWEhrekN4VTBuVjU5?= =?utf-8?B?TkxIUE13WjB4czBOSnVmSGpDQ2l5RVk2MW5jSU03bG9YVmJwQzZlREhyR29R?= =?utf-8?B?Zys4M2RiNVBiLy9MUkpzb1RtWmxzQ1RMV0VBbTNLMnBoZHA3cnZGUEh0dGU0?= =?utf-8?B?NGtqNUxCU1NRY3k3MzJnUHRpckRycGtwTGxMNGxhWmxxSHBNUXN5S1BTSE5q?= =?utf-8?B?aEsxbGVZYnFXYTBxS21vNFFncmh1QzBRNTJKTUw2aHN0R1RqSjVWaUdIS1NI?= =?utf-8?B?L3kvdVN4dHpTVlBEckJHNHFTNGRVU2JLYzB1dmpMbnNLcksreXlPSjc2ekxJ?= =?utf-8?B?R0kzWW5BQ3FiN1dkeTNDSmVseHU5V0M5Qmt4ZXpoWlh5T3YvTVBxdHZrYWh5?= =?utf-8?B?RTErSU1ZVnVrZnlNc2VzMGVJblo2NGFHRlpCdk1lL2pxN0FVU01jUkthWmlp?= =?utf-8?B?UG1kOWVORkt6eFlmMWN5U1lYcndMMFdzOXB6RE04dk9GZFk5T0pjRW1nRDRB?= =?utf-8?B?RWQ2WGZ6blQvZzdzc3VqVHA3bnBwVE9IMFRQUlI0eWNwMHRhUnVtRk1USm0r?= =?utf-8?B?bXlKeEhJbWNpRDRNSlpQME5OMDBGeWVNaTRmTEVGTTUzb1hPazVNa1c0WEM0?= =?utf-8?B?eFV5M29ldHpMUWRxYnVIb0ZqVFA4anprbW9yaTAzd0ZiY0xLUnU4SjZzVnVG?= =?utf-8?B?b0hxdTNyY1ZUMVlwaVhCTCtvZU5OVWlGUHJSV0RzMWYxcTFaZUpla1FoL0ZH?= =?utf-8?B?L3l2VEdyUFJyRXk5RnBNOTlVTjNISzZBbGw5M2p1OXRnYjJoZm1RSjBlNTF0?= =?utf-8?B?VDJWdWVhQVA4dlFVR0RyWkRSMm4rN2xKQkwzU2JRSzhLUnpDMm8vTEsrblVR?= =?utf-8?B?SGVLUld2elFCMjlIWHZrK09PcnlzQU9GcmIrRUNicG1ZU3ZLajBVVWVkNFlI?= =?utf-8?B?OHNoeWZ0NFgrb0IybDA2WmUyMDNLalptK2w5Z2FxM2p5QXdqTVdOUHJ1dlJ4?= =?utf-8?B?K01pOXZJZitEdE9OZjVKK0tsd2lwdUFJZ3Eyb1grSmEyd3JSZEQ3K0h2bXU1?= =?utf-8?B?UGlNNWFDLzJBdUxiWWk2MU5lM1l5KzVJdVhkY2V4NHFXQnJuT2dEWDdDY2Er?= =?utf-8?B?LytXNjgzeWtDMWdmVXNwakRhTHg1S1N2UWpLSVYyeThQNW5kMmczK3pJZ3VZ?= =?utf-8?B?K2N1ZXNSRmpaK3BHMDlHMElhWnphV21WbGFMUTBpcmI3TkJUbVcydmh0WGsy?= =?utf-8?B?R1lRTGFCZUo2c3duMzFVMjcwbmdMSjZyekt1NndoNTJyZGJIUk5jckpacmNU?= =?utf-8?B?eERoUDh3Y3owaGk3eWxBNll2V3JkV3Boc1B3dW1uR3VzYUdUY09ubDJ0ak56?= =?utf-8?B?bm1RSnRTTitZMk85R1NWREJ1VzhXekVHRzUzQTVLRkNuL0VRNnRRNjEzemk4?= =?utf-8?B?UXVZVFQ3RUxsQW5TOFFSaXg4SXpFR2VqTEtwMktCMU41L3I0RmwzT0hHMm4v?= =?utf-8?Q?PioyG12pWL8n62e4nfj8GYw2oXUh5Sox?= x-microsoft-antispam-prvs: x-forefront-prvs: 0962D394D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39830400003)(376002)(346002)(136003)(396003)(189003)(199004)(86362001)(446003)(6116002)(66066001)(486006)(229853002)(14444005)(68736007)(2616005)(256004)(36756003)(71190400001)(11346002)(5640700003)(2351001)(3846002)(6916009)(83716004)(105586002)(8936002)(106356001)(476003)(25786009)(71200400001)(186003)(6486002)(6436002)(966005)(8676002)(5660300002)(53546011)(97736004)(81166006)(2906002)(33656002)(508600001)(81156014)(2501003)(6306002)(53936002)(6246003)(55236004)(6506007)(305945005)(99286004)(14454004)(76176011)(7736002)(82746002)(26005)(102836004)(316002)(1730700003)(6512007)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:SG2PR01MB2743; H:SG2PR01MB2776.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nZMc1ljv23VJYI73V76O1xYos0gJ3SsoYUhYuMP5ti2jFNDR9b2ZSctKL/2AzAdukus33pt4G8tpnGzMztW5kPQHZ3XCPdZokUk/1Vd+h7PgBaGFXfFjetPUp5xAEDyYQuT0ufsVy3Hzzlp8PQG0Wj0VykPsmjNL7wZm4BhI3zmIlu978XQpaw785X7t6qC0P/Bjeo7OX0D3RJiBgzfBzOAZadkoBWD588UEwlEEfcg6TejIVxJ9Eb+sRx74/vUE2PDclk5cblby5aRJnUyM1zQswh7noIQo0Xhq6BKyO8p+5TfveZpyKem/uj1je+jzGJdOFkzmk9ob3uLnJI4lqFpn2X8PUGD3DpkY/MfBLygYg8xsZd/A6Yh4gaOAg2aw1QGEmgrmkWVZFwNA3UfQRAigzEjA24wv2WTGYe1KC14= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec666a87-03ed-4336-7e88-08d69d149e48 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 00:35:19.9561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR01MB2743 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 00:35:25 -0000 QW5kIHRoYW5rcyBOZWFsIGZvciB0aGUgc3VnZ2VzdGlvbiENCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpSb25hbGQgVHNlDQpSaWJvc2UgSW5jLg0KDQo+IE9uIEZl YiAyOCwgMjAxOSwgYXQgODowMyBBTSwgSm9uIENhbGxhcyA8am9uY2FsbGFzPTQwaWNsb3VkLmNv bUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+IA0KPiANCj4gDQo+PiBPbiBGZWIgMjcsIDIwMTks IGF0IDM6MDAgUE0sIEJhcnQgQnV0bGVyIDxiYXJ0YnV0bGVyQHByb3Rvbm1haWwuY29tPiB3cm90 ZToNCj4+IA0KPj4gSGkgSm9uLA0KPj4gDQo+PiBEbyBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IHRo YXQgeW91IG9wcG9zZSBzaHJpbmtpbmcgdGhlIGFsbG93YWJsZSByYW5nZSB3aXRoIE1VU1QgYXQg YWxsIHRvbz8gSSB0aGluayB0aGUgYXJndW1lbnQgZm9yIHRoaXMgaXMgZmFpcmx5IGNvbnZpbmNp bmcgZnJvbSBhIHVzYWdlIHBlcnNwZWN0aXZlIHRvIGVuc3VyZSB0aGF0IHNvbWVvbmUgZGVjcnlw dGluZyBhIGxhcmdlIG1lc3NhZ2UgaXMgbm90IG9ibGlnYXRlZCB0byBkb3dubG9hZCBhIGh1Z2Ug YW1vdW50IG9mIGRhdGEgYmVmb3JlIGZpbmRpbmcgb3V0IHRoYXQgaXQgaXMgY29ycnVwdGVkIG9y IG90aGVyd2lzZSBoYXMgYmVlbiB0YW1wZXJlZCB3aXRoLiBMaWtld2lzZSwgd2UgaGFkIHRvIGFk ZHJlc3MgdW5hbnRpY2lwYXRlZCBwZXJmb3JtYW5jZSBpc3N1ZXMgaW4gT3BlblBHUC5qcyB3aXRo IHZlcnkgc21hbGwgY2h1bmtzIHdoaWNoIGNvdWxkIGhhdmUgYWxsb3dlZCBhIGJhZCBhY3RvciB0 byBlc3NlbnRpYWxseSBEb1MgdGhlIGxpYnJhcnkgd2l0aCBhIHN0cmFuZ2VseS1jb25zdHJ1Y3Rl ZCBtZXNzYWdlLg0KPj4gDQo+PiBJbiBvdGhlciB3b3JkcywgSSdtIG5vdCByZWFsbHkgc3dheWVk IGJ5IHRoZSBpbXBsZW1lbnRhdGlvbiBzaW1wbGlmaWNhdGlvbiBhcmd1bWVudCBidXQgSSBkbyB0 aGluayB0aGF0IHZlcnkgc21hbGwgb3IgdmVyeSBsYXJnZSBjaHVuayBzaXplLCBpbiBhZGRpdGlv biB0byAqcHJvYmFibHkqIGJlaW5nIHVzZWxlc3MsIHBvc2UgYSByZWFsIHRocmVhdCBpbiB0ZXJt cyBvZiBhYnVzZS4NCj4+IA0KPj4gU28gSSB0aGluayBoYXZpbmcgYSBNVVNUIGZvciB0aGUgcmFu Z2UsIG1heWJlIDE2a2lCIHRvIDI1NiBraUIsIG9yIDE2IGtpQiB0byAxMDI0IGtpQiBpcyBhIHJl YXNvbmFibGUgdGhpbmcgdG8gZG8uIEFuZCBhcyBsb25nIGFzIHdlIGtlZXAgdGhlIHNpemUgYnl0 ZSwgd2UgY2FuIGFsd2F5cyBpbmNyZWFzZSB0aGUgdXBwZXIgbGltaXQgb2YgdGhlIHJhbmdlIGlu IHRoZSBmdXR1cmUgaWYgbmVlZGVkLg0KPiANCj4gTXkgd2FybmluZyBpcyBhZ2FpbnN0IHNob290 aW5nIHNvbWVvbmUgZWxzZSBpbiB0aGUgZm9vdCwgb3IgZm9yY2luZyB0aGVtIHRvIHVzZSBzb21l IG90aGVyIHByb3RvY29sLg0KPiANCj4gVGh1cywgc2F5aW5nIChlLmcuKSB0aGF0IHRoZSByYW5n ZSBNVVNUIGJlIGJldHdlZW4gMUsgYW5kIDE2SyBpcyBhIGJhZCBpZGVhOyB3ZSBldmVuIGtub3cg bm93IHRoYXQgMjU2SyBoYXMgaW4gc29tZSBjYXNlcyBhbiBlZmZpY2llbmN5IGFkdmFudGFnZS4g WW91IGNhbiBzYXksIE1VU1Qgc3VwcG9ydCAxSyB0byAxNkssIFNIT1VMRCBzdXBwb3J0IHVwIHRv IDI1NksgYW5kIE1BWSBzdXBwb3J0IGxhcmdlciBzaXplcy4gVGhlcmUgY2FuIGFsc28gYmUgYSBj b3VwbGUgb2YgcGFyYWdyYXBocyB0byBleHBsYWluIHRoYXQgdGhlcmUgYXJlIGdvb2QgcmVhc29u cyBuZWl0aGVyIHRvIGJlIHZlcnkgc21hbGwgbm9yIHZlcnkgbGFyZ2UuDQo+IA0KPiBNeSBjb25j ZXJuIGlzIHNvbWVvbmUgc2F5aW5nIHNvbWV0aGluZyBsaWtlLCDigJxHb3NoLCBJ4oCZZCBsaWtl IHRvIGhhdmUgT3BlblBHUCBBRUFEIGVuY3J5cHRpb24gZm9yIFMzIE9iamVjdHMsIGJ1dCBJIGNh buKAmXQg4oCYY2F1c2UgdGhvc2UgZ28gdXAgdG8gNVRCLuKAnSBBbnlvbmUgd2hv4oCZcyBnb2lu ZyB0byB1c2UgNVRCIG9iamVjdHMgcHJvYmFibHkga25vd3MgdGhlIGhlYWRhY2hlcyB0aGV5IGlu aGVyaXQgYW5kIHllYWgsIHlvdSBhcmVu4oCZdCBnb2luZyB0byBkbyB0aGF0IG9uIGEgQ29ydGV4 IE0wLg0KPiANCj4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQo+IA0KPiAgICBKb24NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG9wZW5wZ3Ag bWFpbGluZyBsaXN0DQo+IG9wZW5wZ3BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vcGVucGdwDQo= From nobody Wed Feb 27 16:46:06 2019 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 E8F51131238 for ; Wed, 27 Feb 2019 16:46:02 -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 v59XJuV1dFZH for ; Wed, 27 Feb 2019 16:45:59 -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 06CD4131230 for ; Wed, 27 Feb 2019 16:45:56 -0800 (PST) Date: Thu, 28 Feb 2019 00:45:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1551314753; bh=Q6CcqgZQN8CHP0ThUfPzkSGkbrWsaHrNHoJsoOoK8gI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=G3xCZOokuLtJuHyQ+p/lWjblQy8pCNIxtoNhe3Xd2Ptx+GqVFKOXWmxM4OAWNRNYo ZXveO+YfEJdR0XDme9x3B/B7ZKuF9tn98PkIRMqUmBPpZizGfM89sPswHlxmcXKJeo 2lDTiVsf1BEFqgop5eRLGudvkeos2EtWfjT9vGrM= To: Jon Callas From: Bart Butler Cc: Vincent Breitmoser , "openpgp@ietf.org" , "Neal H. Walfield" Reply-To: Bart Butler Message-ID: In-Reply-To: <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------1886749762836d19a5057839f60c6503"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 00:46:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------1886749762836d19a5057839f60c6503 Content-Type: multipart/mixed;boundary=---------------------5b2bb3225a184e6a67772837b00b3397 -----------------------5b2bb3225a184e6a67772837b00b3397 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 Wednesday, February 27, 2019 4:03 PM, Jon Callas = wrote: > = > = > > On Feb 27, 2019, at 3:00 PM, Bart Butler bartbutler@protonmail.com wro= te: > > Hi Jon, > > Do I understand correctly that you oppose shrinking the allowable rang= e with MUST at all too? I think the argument for this is fairly convincing= from a usage perspective to ensure that someone decrypting a large messag= e is not obligated to download a huge amount of data before finding out th= at it is corrupted or otherwise has been tampered with. Likewise, we had t= o address unanticipated performance issues in OpenPGP.js with very small c= hunks which could have allowed a bad actor to essentially DoS the library = with a strangely-constructed message. > > In other words, I'm not really swayed by the implementation simplifica= tion argument but I do think that very small or very large chunk size, in = addition to probably being useless, pose a real threat in terms of abuse. > > So I think having a MUST for the range, maybe 16kiB to 256 kiB, or 16 = kiB to 1024 kiB is a reasonable thing to do. And as long as we keep the si= ze byte, we can always increase the upper limit of the range in the future= if needed. > = > My warning is against shooting someone else in the foot, or forcing them= to use some other protocol. > = > Thus, saying (e.g.) that the range MUST be between 1K and 16K is a bad i= dea; we even know now that 256K has in some cases an efficiency advantage.= You can say, MUST support 1K to 16K, SHOULD support up to 256K and MAY su= pport larger sizes. There can also be a couple of paragraphs to explain th= at there are good reasons neither to be very small nor very large. The problem is that MAY for either very small or very large chunks sizes i= n some ways forces library maintainers to have support for these chunk siz= es because they WILL appear in the wild, and then there will be complaints= if they do not decrypt. If they are technically legal then everyone has t= o account for these edge cases in their apps--i.e., a 1-chunk AEAD multi-g= igabyte movie which you technically can't start playback until the whole t= hing has been downloaded and buffered because the authentication is only a= t the end. > = > My concern is someone saying something like, =E2=80=9CGosh, I=E2=80=99d = like to have OpenPGP AEAD encryption for S3 Objects, but I can=E2=80=99t =E2= =80=98cause those go up to 5TB.=E2=80=9D Anyone who=E2=80=99s going to u= se 5TB objects probably knows the headaches they inherit and yeah, you are= n=E2=80=99t going to do that on a Cortex M0. > = > Does this make sense? > = > Jon It does, and normally on this kind of thing I would completely agree with = you, but in this case I think there are two mitigating factors: 1. AEAD chunk size does not limit message/file size in any meaningful way = assuming we set the upper limit chunk size to something reasonable like 10= 24 kiB, you just use multiple chunks, which is the idea anyway. 2. Abuse potential in an open standard It's #2 which is really compelling for me for exactly the reason that we D= O want this to be usable for arbitrary uses and message sizes in federated= contexts, and for that to be possible we need to try to set reasonable li= mits to prevent malicious or careless users from creating bad-but-legal pa= yloads. -----------------------5b2bb3225a184e6a67772837b00b3397-- -----------------------1886749762836d19a5057839f60c6503 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 wl4EARYKAAYFAlx3Lz0ACgkQmQVEZe8zHkTW6wEAoy0EEivLnakhjIMP4u7Z LpfS/7rHjoy9CcFzyL2LRAkA/3cRMpqt3ysYQRP7x7OfVwmCy7AKq5Kd9iZ2 ir8+OzAG =E81Z -----END PGP SIGNATURE----- -----------------------1886749762836d19a5057839f60c6503-- From nobody Thu Feb 28 00:19:07 2019 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 30D1E130DF6 for ; Thu, 28 Feb 2019 00:19:06 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 44XIcMOUO1RG for ; Thu, 28 Feb 2019 00:19:03 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AC912D4E7 for ; Thu, 28 Feb 2019 00:19:02 -0800 (PST) Received: from computer (ipb218ef6d.dynamic.kabel-deutschland.de [::ffff:178.24.239.109]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1.3, 256bits, TLS_AES_256_GCM_SHA384) by zucker.schokokeks.org with ESMTPSA id 000000000000007C.000000005C779974.00003985; Thu, 28 Feb 2019 09:19:00 +0100 Date: Thu, 28 Feb 2019 09:18:59 +0100 From: Hanno =?iso-8859-1?q?B=F6ck?= To: openpgp@ietf.org Message-ID: <20190228091859.49b903b2@computer> In-Reply-To: <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 08:19:06 -0000 On Wed, 27 Feb 2019 16:03:10 -0800 Jon Callas wrote: > Thus, saying (e.g.) that the range MUST be between 1K and 16K is a > bad idea; we even know now that 256K has in some cases an efficiency > advantage. You can say, MUST support 1K to 16K, SHOULD support up to > 256K and MAY support larger sizes. There can also be a couple of > paragraphs to explain that there are good reasons neither to be very > small nor very large. This sounds like a recipe to create multiple incompatible implementations. That is certainly not what anyone should want. > My concern is someone saying something like, =E2=80=9CGosh, I=E2=80=99d l= ike to have > OpenPGP AEAD encryption for S3 Objects, but I can=E2=80=99t =E2=80=98caus= e those go > up to 5TB.=E2=80=9D Sorry, I don't understand the comparison here. We're talking about encryption chunk sizes, not sizes of total encrypted content. Nothing here's going to limit the size of the objects you can encrypt. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Thu Feb 28 00:38:55 2019 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 7D743130EFC for ; Thu, 28 Feb 2019 00:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 xSf26cJtB6YJ for ; Thu, 28 Feb 2019 00:38:40 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 34B05130E68 for ; Thu, 28 Feb 2019 00:38:40 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gzHDB-00089F-Ae; Thu, 28 Feb 2019 08:38:37 +0000 Date: Thu, 28 Feb 2019 09:38:36 +0100 Message-ID: <87k1hk2tpv.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bart Butler Cc: Vincent Breitmoser , "openpgp@ietf.org" In-Reply-To: <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] AEAD Chunk Size - Performance 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, 28 Feb 2019 08:38:53 -0000 Hi Bart, Thanks for your feedback. On Wed, 27 Feb 2019 22:34:09 +0100, Bart Butler wrote: > In our AEAD implementation for OpenPGP.js we settled on a default > `c` of 12 rather than 8 after some performance benchmarking showed > that 256 kiB chunks were more performant for the most common message > sizes. Our result was specific to the web crypto API, and therefore > specific to OpenPGP.js, but in general libraries may want to use > different default sizes depending on implementation details like > this. I don't need exact numbers, but I'd appreciate it if you could you comment on the approximate performance of 256 kiB chunks relative to 16 kiB chunks (e.g., factor 1.2 speedup). Of course, if you still have the numbers lying around, that would be even better! There are two reasons that I find 16 kiB *intuitively* appealing from a performance perspective: a typical L2 cache is about 256 kiB these days. So a 16 kiB buffer has a good chance of staying completely in L2. Second, on all desktop and mobile operating systems, it is almost always reasonable to stack allocate a 16 kiB buffer whereas 256 kiB is a bit big. =46rom a robustness perspective, I'd like to avoid introducing a threshold and having to do something brittle like: void *buffer; if size > 16 kiB { buffer =3D malloc(size); } else { buffer =3D alloca(size); } ... if size > 16 kiB { free(buffer); } Unfortunately, I haven't benchmarked this type of thing in the context of AEAD so this is just drawing from my limited prior experience with sizing these sorts of things. :) Neal From nobody Thu Feb 28 00:42:40 2019 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 D65F7130E2E for ; Thu, 28 Feb 2019 00:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 CBsPOOJRcZXH for ; Thu, 28 Feb 2019 00:42:37 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 5104312870E for ; Thu, 28 Feb 2019 00:42:37 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gzHH1-0008Bb-9n; Thu, 28 Feb 2019 08:42:35 +0000 Date: Thu, 28 Feb 2019 09:42:34 +0100 Message-ID: <87imx42tj9.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bart Butler Cc: Vincent Breitmoser , "openpgp@ietf.org" In-Reply-To: <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 08:42:39 -0000 On Wed, 27 Feb 2019 22:34:09 +0100, Bart Butler wrote: > So ideally we=A2d prefer to keep the size byte, but to shrink its > range in both directions. For example, the RFC could state that the > chunk SHOULD be 16 kiB (or 256 kiB, hint hint), but decryption MUST > be available for `c` values between 8-12 inclusive. This would also > allow us to be backwards-compatible with messages that have already > been created following the current version of the draft, which do > exist given the benefit that AEAD provides and that OpenPGP.js has > supported the current draft in experimental mode for most of the > last year. Could you please comment on the approximate number of messages that have been sent with AEAD? Is protonmail doing AEAD exclusively these days? As a compromise, I'd be willing to leave the byte, but have it be a magic value whose value must be X (where X is say, 8 or 12). Then you can detect X=3D12 and not error out for your users. But, I'm not yet convinced that a range is a good idea. From nobody Thu Feb 28 00:51:20 2019 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 5DD83130E66 for ; Thu, 28 Feb 2019 00:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 rYaEl747VjlQ for ; Thu, 28 Feb 2019 00:51:16 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 444B7130E89 for ; Thu, 28 Feb 2019 00:51:16 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gzHPN-0008GT-2d; Thu, 28 Feb 2019 08:51:13 +0000 Date: Thu, 28 Feb 2019 09:51:12 +0100 Message-ID: <87h8co2t4v.wl-neal@walfield.org> From: "Neal H. Walfield" To: Jon Callas Cc: Bart Butler , "openpgp@ietf.org" , Vincent Breitmoser , Jon Callas In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 08:51:19 -0000 On Wed, 27 Feb 2019 23:37:20 +0100, Jon Callas wrote: > Moreover, forbidding it says that we state now that no one could > ever have a reasonable use; my experience is that categorical > statements like that are just asking the fates to bite us in an > uncomfortable place. Amazon S3 increased their max object size to > 5TB a few years ago. I=A2m not saying it should be that large, but I > think this is a pretty convincing argument that 16K is too small. I think you misunderstand the point of the chunk size parameter. Modulo perhaps performance, the chunk size is not visible to the application. That is, messages encrypted using AEAD can (theoretically) still be 4 exibyte large when using a 16 kiB chunk size; a message can consist of any number of chunks. Chunk size is like HTTP's chunked transfer encoding or OpenPGP's partial body lengths. The reason that we don't want large chunk sizes is that when decrypting a chunk, the chunk MUST (RFC 5116) be buffered. Since the encryptor generally doesn't know the context in which the decryption will occur, it must be conservative and choose a small chunk size. Otherwise, a decryptor will inevitably encounter a chunk size that it can't buffer and gratuitously fail. Alternatively, it violates the must and outputs the decrypted data without first verifying it thereby resulting in the next EFAIL. > So I think that a SHOULD is the right way to put it. I care less > about what the SHOULD limit should be, but a small hard limit sounds > like a bad idea. Do you still think a hard upper limit is a bad idea? From nobody Thu Feb 28 00:54:00 2019 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 6F015130E74 for ; Thu, 28 Feb 2019 00:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 291ovSAbODVB for ; Thu, 28 Feb 2019 00:53:57 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 2F88B130E66 for ; Thu, 28 Feb 2019 00:53:57 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gzHRx-0008HW-NA; Thu, 28 Feb 2019 08:53:53 +0000 Date: Thu, 28 Feb 2019 09:53:53 +0100 Message-ID: <87fts82t0e.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bart Butler Cc: Jon Callas , "openpgp@ietf.org" , Vincent Breitmoser In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 08:53:59 -0000 On Thu, 28 Feb 2019 00:00:13 +0100, Bart Butler wrote: > So I think having a MUST for the range, maybe 16kiB to 256 kiB, or > 16 kiB to 1024 kiB is a reasonable thing to do. And as long as we > keep the size byte, we can always increase the upper limit of the > range in the future if needed. If we keep the size byte with the justification that we might increase the range in the future, some implementations will decide to support other chunk sizes to be future compatible. I think this is a disastrous idea. If we need to change the chunk size in the future, let's just create a new packet, AEADv2. :) Neal From nobody Thu Feb 28 00:56:09 2019 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 8BCE0130E74 for ; Thu, 28 Feb 2019 00:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 OJ_NuMfIBJmu for ; Thu, 28 Feb 2019 00:56:05 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 BD0BE130DE4 for ; Thu, 28 Feb 2019 00:56:05 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gzHU2-0008JC-P8; Thu, 28 Feb 2019 08:56:02 +0000 Date: Thu, 28 Feb 2019 09:56:02 +0100 Message-ID: <87ef7s2swt.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bart Butler Cc: Jon Callas , "openpgp@ietf.org" , Vincent Breitmoser In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 08:56:07 -0000 On Thu, 28 Feb 2019 01:45:52 +0100, Bart Butler wrote: > It does, and normally on this kind of thing I would completely agree with you, but in this case I think there are two mitigating factors: > > 1. AEAD chunk size does not limit message/file size in any meaningful way assuming we set the upper limit chunk size to something reasonable like 1024 kiB, you just use multiple chunks, which is the idea anyway. > 2. Abuse potential in an open standard > > It's #2 which is really compelling for me for exactly the reason that we DO want this to be usable for arbitrary uses and message sizes in federated contexts, and for that to be possible we need to try to set reasonable limits to prevent malicious or careless users from creating bad-but-legal payloads. I fully agree with #2. I am convinced that it is imperative that we avoid introducing potential attack surfaces that have no value. From nobody Thu Feb 28 10:39:23 2019 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 97007130EE0 for ; Thu, 28 Feb 2019 10:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xP88kOl292qW for ; Thu, 28 Feb 2019 10:39:20 -0800 (PST) Received: from mr85p00im-zteg06021601.me.com (mr85p00im-zteg06021601.me.com [17.58.23.187]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CD012F1AB for ; Thu, 28 Feb 2019 10:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1551379159; bh=FPa/8K9Vs269PBEwkQ/uouIMY7fXYbYM8yrnWCxrmnw=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=dkd9vVd7bJ+m2Azh3D3ANROMS8z/4oBe3VXIQJ5pbousPd6eqGRbabgF7h8yQZnrq Pr6/phixsBQnyR5+pkS07tYANs0D13/wWlWNBqnpxz828+R4eatWohX41hxyhV7w7Z KVH/gzqAgKSPrQiivtaH4Bd0JRiNrtMXHHZR6qOJp+70/lrhsx0WYScR0HsSGKUi8r C+yFNbBLzgj5Fcf30W4o01Fw24NJm9ktAG/RAl5EjSx90bYQgCxAuiyiKu/ReKt0uO a1QlNstlz2cpfB21Lsg/oq3xLaOtnfytQjFDliTMs3OHPm3bcSHHW2LOWLfoxrIsPw d1CK+XWD3A++g== Received: from [192.168.1.5] (173.sub-174-214-23.myvzw.com [174.214.23.173]) by mr85p00im-zteg06021601.me.com (Postfix) with ESMTPSA id E8124400244; Thu, 28 Feb 2019 18:39:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <87h8co2t4v.wl-neal@walfield.org> Date: Thu, 28 Feb 2019 10:39:17 -0800 Cc: Jon Callas , Jon Callas , Bart Butler , "openpgp@ietf.org" , Vincent Breitmoser Content-Transfer-Encoding: quoted-printable Message-Id: <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-28_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1902280124 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 18:39:23 -0000 > On Feb 28, 2019, at 12:51 AM, Neal H. Walfield = wrote: >=20 > I think you misunderstand the point of the chunk size parameter. >=20 > Modulo perhaps performance, the chunk size is not visible to the > application. That is, messages encrypted using AEAD can > (theoretically) still be 4 exibyte large when using a 16 kiB chunk > size; a message can consist of any number of chunks. Chunk size is > like HTTP's chunked transfer encoding or OpenPGP's partial body > lengths. >=20 > The reason that we don't want large chunk sizes is that when > decrypting a chunk, the chunk MUST (RFC 5116) be buffered. Since the > encryptor generally doesn't know the context in which the decryption > will occur, it must be conservative and choose a small chunk size. > Otherwise, a decryptor will inevitably encounter a chunk size that it > can't buffer and gratuitously fail. Alternatively, it violates the > must and outputs the decrypted data without first verifying it thereby > resulting in the next EFAIL. Perhaps I do misunderstand, but that=E2=80=99s kinda what I was = expecting; an equivalent to the old streaming chunks. >=20 >> So I think that a SHOULD is the right way to put it. I care less >> about what the SHOULD limit should be, but a small hard limit sounds >> like a bad idea. >=20 > Do you still think a hard upper limit is a bad idea? No, I don=E2=80=99t think a hard upper limit is a bad idea. In the text = you quote above, I said a *small* hard upper limit. And no, I don=E2=80=99= t know what small means. I think 16K is small. 256K might be small. = AES-GCM has issues about 64G. One might argue that=E2=80=99s a = reasonable large upper limit. Me, I think anything in the few megabytes = to a gigabyte-ish is just fine. Let me rewind a bit and get to my real point which I don=E2=80=99t think = I=E2=80=99m making well. When one creates a standard, one needs to be careful with parameters, = particularly the MUSTs. Seemingly sensible things can have downstream = effects that convince people to use some other protocol. Worse, = someone=E2=80=99s angry blog post about something can quickly go into = =E2=80=9Cnot even wrong=E2=80=9D territory and embed itself into = folklore and you can=E2=80=99t get it out. There are plenty of bad ideas = that someone else has a really reasonable use case for. The Partial Body Lengths that OpePGP has had from the beginning have no = restrictions on them. There=E2=80=99s non-normative guidance that pretty = much says you shouldn=E2=80=99t even use them, but there=E2=80=99s no = restriction on size. This has never caused a problem that I=E2=80=99m = aware of. I=E2=80=99m sure it caused a problem that none of us are aware = of, and the implementors just solved it on their own. It is this = experience that has me wondering about what the restrictions out to be. The best way to deal with it in a standard is to have non-normative = guidance. It is non-normative guidance that I was suggesting. Let me = write an example bit of non-normative guidance below: - - - - - Implementations should pick a chunk size with care. Depending on the = AEAD algorithm, large chunk sizes may limit the ability to process = chunks, particularly with an AEAD algorithm that is not single-pass, and = thus the system decrypting it must hold the entire chunk as it decrypts = it. In general, the chunk size is irrelevant to any code outside of the = chunk handling code, so smaller is better. An implementation SHOULD pick a chunk size of 256KiB or less. An = implementation MAY use larger sizes, but this could limit = interoperability with resource-limited systems and should be done with = care. - - - - - I don=E2=80=99t think that=E2=80=99s perfect, but it=E2=80=99s okay as a = first draft. I would completely support something like the text above. = I=E2=80=99d support it if it said 16KiB too. I=E2=80=99ll also support = hard limits, but my intuition is that that decision will come with = frustration for someone else. Does this make more sense? Jon From nobody Thu Feb 28 11:11:20 2019 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 6A6B712D4F2 for ; Thu, 28 Feb 2019 11:11:18 -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 uZ2MMSUDF1ms for ; Thu, 28 Feb 2019 11:11:15 -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 E8F341289FA for ; Thu, 28 Feb 2019 11:11:14 -0800 (PST) Date: Thu, 28 Feb 2019 19:11:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1551381072; bh=fplQ0kS9Nv7ai+rhKy2zCPGPt+zV18FEbHCQKJ2wh3o=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=txpNRhfkZjHBhG1xQAwVp9ecIcZfcKIEE7TKotPtqqSBah1fl67DBeAX4Fpi6HfYV cwTmfrbWAZ49zV+2A/DNs+IpMTCyLfKIvjm3Vp1YiYKpoPnmsnyDbSrXmRs+/emL0W nXTqJb1uu1UXN22gh7z/xcc+dSYOz5xUVO7bgB44= To: "Neal H. Walfield" From: Bart Butler Cc: Vincent Breitmoser , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <87k1hk2tpv.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87k1hk2tpv.wl-neal@walfield.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------7f714e1f4702dbb3e94c8d439e90f45f"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size - Performance 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, 28 Feb 2019 19:11:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------7f714e1f4702dbb3e94c8d439e90f45f Content-Type: multipart/mixed;boundary=---------------------0c7112be098168b8c2be0c5ed2163c3b -----------------------0c7112be098168b8c2be0c5ed2163c3b 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, February 28, 2019 12:38 AM, Neal H. Walfield wrote: > Hi Bart, > = > Thanks for your feedback. > = > On Wed, 27 Feb 2019 22:34:09 +0100, > Bart Butler wrote: > = > > In our AEAD implementation for OpenPGP.js we settled on a default > > `c` of 12 rather than 8 after some performance benchmarking showed > > that 256 kiB chunks were more performant for the most common message > > sizes. Our result was specific to the web crypto API, and therefore > > specific to OpenPGP.js, but in general libraries may want to use > > different default sizes depending on implementation details like > > this. > = > I don't need exact numbers, but I'd appreciate it if you could you > comment on the approximate performance of 256 kiB chunks relative to > 16 kiB chunks (e.g., factor 1.2 speedup). Of course, if you still > have the numbers lying around, that would be even better! > = > There are two reasons that I find 16 kiB intuitively appealing from > a performance perspective: a typical L2 cache is about 256 kiB these > days. So a 16 kiB buffer has a good chance of staying completely in > L2. Second, on all desktop and mobile operating systems, it is almost > always reasonable to stack allocate a 16 kiB buffer whereas 256 kiB is > a bit big. > = > From a robustness perspective, I'd like to avoid introducing a > threshold and having to do something brittle like: > = > void *buffer; > if size > 16 kiB { > = > buffer =3D malloc(size); > = > = > } else { > buffer =3D alloca(size); > } > = > ... > = > if size > 16 kiB { > = > free(buffer); > = > = > } > = > Unfortunately, I haven't benchmarked this type of thing in the context > of AEAD so this is just drawing from my limited prior experience with > sizing these sorts of things. > = > :) Neal So, quoted from Daniel Huigens, who did the original benchmarking: "Re. Neal's request, I didn't have the numbers anymore, so I unscientifica= lly created some new ones It looks like either Chrome or we have actually fixed the performance issu= es there with c=3D8 since the last time I tested it, as for most message s= izes the performance is the same as c=3D12 or even a bit faster, except 12= 8KB-256KB, which fits in one chunk with c=3D12 and there c=3D8 is about 1.= 1x - 1.5x slower. In Firefox, for >=3D64KB messages, c=3D8 is still about 1.5x - 2.5x slower= than c=3D12, however, it looks like most of the overhead of smaller chunk= s comes from the streams polyfill, not the web crypto API. So that should = probably be possible for us to fix." I see your logic on 16 kiB but in particular for file encryption I think t= here's some value to being able to go bigger in the future (L2 cache sizes= have changed in the last 20 years as well and will probably change in the= next two decades), and to keep the size byte to be able to configure this= rather than have an entirely new packet. I think a SHOULD for 16 kiB thou= gh is totally appropriate now though for the reasons you mentioned. -----------------------0c7112be098168b8c2be0c5ed2163c3b-- -----------------------7f714e1f4702dbb3e94c8d439e90f45f 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 wl4EARYKAAYFAlx4MkYACgkQmQVEZe8zHkQKdQD/ZvWrOYx8vSC2PyBUdioq 66DbG+XH1GsUMMnynTWgQHoA/3bswGhJjNEyGZmw648sLlC4VXLcEyur3LsE taFy4kkO =uST8 -----END PGP SIGNATURE----- -----------------------7f714e1f4702dbb3e94c8d439e90f45f-- From nobody Thu Feb 28 11:28:48 2019 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 68BE6130EFE for ; Thu, 28 Feb 2019 11:28:46 -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=unavailable 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 eVwIKCWkM04H for ; Thu, 28 Feb 2019 11:28:44 -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 3C1FE130EE0 for ; Thu, 28 Feb 2019 11:28:44 -0800 (PST) Date: Thu, 28 Feb 2019 19:28:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1551382122; bh=rCrPo3OOoSwcIoE0PtuxwRmV8MZinhkNrLSQYw6lFi8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=NjsOSSBwb6p7XRQwxGyjujz0wA2GqSyIe7AtjWLidlyuC3myBWF0K87Psfup2/Woa vj0wZgoXr16QjMZP99qmkvorniyq28LbUK1tBVy8AO7i0MCAL6wetnxn9TgUXQuD/W shLhfMqCBgQX1jUJo0BsalkRnLUflOBsr6cl38jY= To: Jon Callas From: Bart Butler Cc: "Neal H. Walfield" , Jon Callas , "openpgp@ietf.org" , Vincent Breitmoser Reply-To: Bart Butler Message-ID: In-Reply-To: <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------20688ecde6120e430aaeee8dd61404a4"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 19:28:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------20688ecde6120e430aaeee8dd61404a4 Content-Type: multipart/mixed;boundary=---------------------d2068fb3025e5cee9fdba5f60f240b05 -----------------------d2068fb3025e5cee9fdba5f60f240b05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 On Thursday, February 28, 2019 10:39 AM, Jon Callas = wrote: > = > Implementations should pick a chunk size with care. Depending on the AEA= D algorithm, large chunk sizes may limit the ability to process chunks, pa= rticularly with an AEAD algorithm that is not single-pass, and thus the sy= stem decrypting it must hold the entire chunk as it decrypts it. In genera= l, the chunk size is irrelevant to any code outside of the chunk handling = code, so smaller is better. > = > An implementation SHOULD pick a chunk size of 256KiB or less. An impleme= ntation MAY use larger sizes, but this could limit interoperability with r= esource-limited systems and should be done with care. > = > I don=E2=80=99t think that=E2=80=99s perfect, but it=E2=80=99s okay as a= first draft. I would completely support something like the text above. I=E2= =80=99d support it if it said 16KiB too. I=E2=80=99ll also support hard = limits, but my intuition is that that decision will come with frustration = for someone else. > = > Does this make more sense? > = > Jon What do you think about this? I made the last sentence a bit scarier and i= ntroduces the lower recommendation as well: Implementations should pick a chunk size with care. Depending on the AEAD = algorithm, large chunk sizes may limit the ability to process chunks, part= icularly with an AEAD algorithm that is not single-pass, and thus the syst= em decrypting it must hold the entire chunk as it decrypts it. Small chunk= sizes may introduce unnecessary overhead in decryption. In general, the c= hunk size is irrelevant to any code outside of the chunk handling code. = An implementation SHOULD pick a chunk size between 16KiB and 256KiB (c bet= ween 8 and 12). An implementation SHOULD refuse to process chunks outside = this size range in federated or untrusted contexts. -----------------------d2068fb3025e5cee9fdba5f60f240b05-- -----------------------20688ecde6120e430aaeee8dd61404a4 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 wl4EARYKAAYFAlx4NmMACgkQmQVEZe8zHkScawEAhhovsySNjMluA9xokmEP Z5+mCmuXSNRYDFaAw2FSxFoBALJHRNb7CpaG8wfy64w49PTHSWa0aglFVX19 RNK/axkE =wUpi -----END PGP SIGNATURE----- -----------------------20688ecde6120e430aaeee8dd61404a4-- From nobody Thu Feb 28 11:44:56 2019 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 958B2130F7F for ; Thu, 28 Feb 2019 11:44:54 -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 wf4YgtriHWJ5 for ; Thu, 28 Feb 2019 11:44:51 -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 D135C130FBD for ; Thu, 28 Feb 2019 11:44:50 -0800 (PST) Date: Thu, 28 Feb 2019 19:44:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1551383088; bh=zu2t16oe/m++83HHMXPVE0Og89VdybNWtm8ck7jmasc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=nEHJChZ+ah5XTCaly3EYwkm1cu7i+H4bPA+fmKBRqxxBPmtEP5bdlIjQ9+K8Nm2HK RukVNyMD0gH10sLZJt/4m1oiEBu+puuv9tmhVm1SwJZzTLlJrQPg+n9N6eo9xSW2qT 8M3JqIZVypaE4Zu6aIX09k9L/6D2FZfJvkbSYkCM= To: "Neal H. Walfield" From: Bart Butler Cc: Vincent Breitmoser , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <87imx42tj9.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87imx42tj9.wl-neal@walfield.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------4f22db9c76945c90a1ad90e6ce332776"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size 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, 28 Feb 2019 19:44:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------4f22db9c76945c90a1ad90e6ce332776 Content-Type: multipart/mixed;boundary=---------------------7db0cc2274fcbc733d4ed40c38887e14 -----------------------7db0cc2274fcbc733d4ed40c38887e14 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, February 28, 2019 12:42 AM, Neal H. Walfield wrote: > On Wed, 27 Feb 2019 22:34:09 +0100, > Bart Butler wrote: > = > > So ideally we=E2=80=99d prefer to keep the size byte, but to shrink it= s > > range in both directions. For example, the RFC could state that the > > chunk SHOULD be 16 kiB (or 256 kiB, hint hint), but decryption MUST > > be available for `c` values between 8-12 inclusive. This would also > > allow us to be backwards-compatible with messages that have already > > been created following the current version of the draft, which do > > exist given the benefit that AEAD provides and that OpenPGP.js has > > supported the current draft in experimental mode for most of the > > last year. > = > Could you please comment on the approximate number of messages that > have been sent with AEAD? Is protonmail doing AEAD exclusively these > days? I can't because I do not know--it's an experimental feature in OpenPGP.js.= I do know that some users of the library are using it internally in close= d systems, and we'd prefer not to break decryption for their existing mess= ages but also prefer not to keep supporting an obsolete draft. You could a= rgue that they shouldn't have used an experimental feature for production = but given how overdue AEAD is for PGP I find it difficult to blame them my= self. ProtonMail doesn't use V5 keys yet at all, as we exist within the federate= d email ecosystem and it would break compatibility. So this is not coming = from us personally, just on behalf of the OpenPGP.js community in general. -----------------------7db0cc2274fcbc733d4ed40c38887e14-- -----------------------4f22db9c76945c90a1ad90e6ce332776 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 wl4EARYKAAYFAlx4OigACgkQmQVEZe8zHkTKbgEA7ZzS5hzNQzWVhLa1VjK8 tY3+5GnW1AENbKmabmWoGiwBANn0JQUNN0IenpyNO41puLYnYGfR9tMvaVlv axk1sKgM =Ky0Z -----END PGP SIGNATURE----- -----------------------4f22db9c76945c90a1ad90e6ce332776-- From nobody Thu Feb 28 16:27:01 2019 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 A9D3A12DDA3 for ; Thu, 28 Feb 2019 16:27:00 -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 6J9zVnHIxW80 for ; Thu, 28 Feb 2019 16:26:58 -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 B9FA412D4F3 for ; Thu, 28 Feb 2019 16:26:58 -0800 (PST) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:a4e9:9ba4:4fd2:4493]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 9F60C60429; Fri, 1 Mar 2019 00:26:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1551399987; bh=uzlc1zF8C6fsHBr3l/LyPk0fbEgrkg0m2szQNTiOqN4=; 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=DtNiWCLgEbItKAFkyD393o6H0Gn6WGUV24KFYvhhM50MGeKcKHlBCBIH5QySm9wIx ZFXLhAYaJ64FP9NqfBQoC1dVwlwHFdxQh2OQcZwbDFJnrpeqJ/pVAbCVKP8SnlgmQ4 Q/kJyontxi8W1qZUJRBsdCmmQvmsGTGLZrfFIqPv0CLx+xlpHo8QBtjOeV0PFP4huP rTpN3LwQHd1poNco2QXNKHBENR4thiL0EpejtVRSkxG/VkrEzLIAb75ueMGb83dDEx EvR+tMENFzaXzhwbtkx/PIo1c32T8m/UAUA6i7NEW+d51HNrvtmFAx8Tthsi8eSXOH 8A4eWbAfZM6I7cq01Sa7/QmC9A1QbjZT8dPmF2U9KaYvYUDnChMc3t5lz3vfL/hN0b peQuznbCAIQZHYluR7Rw/ir7GopfoNW2SHWSermU3aVrbX20Xzarylg+C3NAkm9e78 j1wfqVpVbGZKmeuQ1eHRqJhye0m4fWi7qTJ6PVIU7s/8t09zHvL Date: Fri, 1 Mar 2019 00:26:22 +0000 From: "brian m. carlson" To: Jon Callas Cc: "Neal H. Walfield" , Bart Butler , "openpgp@ietf.org" , Vincent Breitmoser , Jon Callas Message-ID: <20190301002621.GF601925@genre.crustytoothpaste.net> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+ts6NCQ4mrNQIV8p" Content-Disposition: inline In-Reply-To: <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.19.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] AEAD Chunk Size 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, 01 Mar 2019 00:27:01 -0000 --+ts6NCQ4mrNQIV8p Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 28, 2019 at 10:39:17AM -0800, Jon Callas wrote: > The best way to deal with it in a standard is to have non-normative guida= nce. It is non-normative guidance that I was suggesting. Let me write an ex= ample bit of non-normative guidance below: >=20 > - - - - - >=20 > Implementations should pick a chunk size with care. Depending on the AEAD= algorithm, large chunk sizes may limit the ability to process chunks, part= icularly with an AEAD algorithm that is not single-pass, and thus the syste= m decrypting it must hold the entire chunk as it decrypts it. In general, t= he chunk size is irrelevant to any code outside of the chunk handling code,= so smaller is better. >=20 > An implementation SHOULD pick a chunk size of 256KiB or less. An implemen= tation MAY use larger sizes, but this could limit interoperability with res= ource-limited systems and should be done with care. >=20 > - - - - - >=20 > I don=E2=80=99t think that=E2=80=99s perfect, but it=E2=80=99s okay as a = first draft. I would completely support something like the text above. I=E2= =80=99d support it if it said 16KiB too. I=E2=80=99ll also support hard lim= its, but my intuition is that that decision will come with frustration for = someone else. I think this is a good first start. However, I think we need to specify some guidelines about what sizes are required for interoperability. I'm happy to give people guidance, but if we state that chunk sizes up to 256 KiB (or whatever size we decide) are required to be supported, then we let people decide whether performance or interoperability is more important for their use case. So I'd specify a sentence at the beginning of the second paragraph that says, "An implementation MUST support chunk sizes up to 256 KiB." --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --+ts6NCQ4mrNQIV8p Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.12 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlx4fC0ACgkQv1NdgR9S 9osZqhAAxhFmMOg5Z2D0u7MOc7P+dPSJ7iZ5UnEmzU3DRtFQ4GZrMpjVed9mnuyw YqcX+JyaZcZaXrE6btAJMZ7ESxIgLu3GF83/kXouNfqDNFLebbWQWy6W2c9crUjJ IDH/s7DqITX/kFd+jf/G4drH43u0S7+3zHtmxNgubntFK8oQUghQ+tgvW93eI43Z 1fDjYWxTllCC8s2pDR1ihqpnwNTRSNCYQLk7bPSumumgI2kTtBNzI9gX7YrvmOnE JBIC5uyhXmvzkvbpVxzwfN2XXIPGQ9JzIbYpX/PlICc2kxF6JMaR+W3yZW8N8+oN LU2qkh98F7tRyPhxWkXj07l5yd5HZXYYM9uODYV7IUQd9LBIjybzW+x1hw9dFXhZ Ygp20r8JpOQeHw4YzMZKxcCCoZaH6uNTHNknnfczjIQWjMIK2BDbLlQyNzhkuC6k 4JHjLMneEpqSjlyGqxrWIceQNx+lt2ZKzSIZEK5jxnoedaXP+fA9qdkwtaUUG9Dj 0Vu2fPZniiV7NMCvYznZ3YcjgV2Y67RlBOhh5Ir+lqAsiA3TyBlnHhqFAWRkeGju PFb+8J9D99TDFwVlN2EJSM4iUps2HFLZ6XDuU+LYcqO5fqLlYRkSC8cvHqc8rDDa KNo6uSb2fAyFvLlJBooInJkjVuXN7n2QEuFdPgQ3f8xEteCSP2w= =+oy3 -----END PGP SIGNATURE----- --+ts6NCQ4mrNQIV8p--