From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 83D5F138334 for ; Sun, 17 Feb 2019 08:56:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3CB6CE09CC; Sun, 17 Feb 2019 08:56:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E5268E09CB for ; Sun, 17 Feb 2019 08:56:00 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id BB523335CA6; Sun, 17 Feb 2019 08:55:58 +0000 (UTC) Message-ID: <1550393754.1257.5.camel@gentoo.org> Subject: Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Sun, 17 Feb 2019 09:55:54 +0100 In-Reply-To: References: <1550306421.831.16.camel@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Lui/B/OzcU0NE4O5r/gt" X-Mailer: Evolution 3.26.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 X-Archives-Salt: a0a1cc87-929a-4b80-ab14-630ef98a5374 X-Archives-Hash: 72511d41d7eceb9c6a2a81249450cf53 --=-Lui/B/OzcU0NE4O5r/gt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2019-02-17 at 06:56 +0000, Robin H. Johnson wrote: > On Sat, Feb 16, 2019 at 09:40:21AM +0100, Micha=C5=82 G=C3=B3rny wrote: > > Your comments? Anything I've missed? >=20 > Overall, strong +1 to the idea. >=20 > Some questions/remarks: > 0. I will oppose any intentions to tie this proposal to the GLEP76 or oth= er > requirements of disclosing "legal" names. I realize other developers may = object > to this, but I don't believe that "legal" names in this context actually = gain > us anything of value.=20 That's outside the scope. The key will be explicitly described as verifying the @gentoo.org account ownership only. > 1. Where are non-dev users trying to verify developer keys directly at th= e > moment? I thought all prior work discouraged that, in favour of verifying > service keys instead. I do see this proposal being of a LOT more use in t= he > infra-run systems that verify incoming commits/pushes. My main purpose is mail. > 2. The uid signatures should NOT be naively exported to keyservers. They > should use the CAFF method of generating a uid signature, writing it to a= file, > and sending it as an encrypted message to the uid address. The uid owner = is > responsible for decrypt + sending to servers. This ensures that the email > address and key are still tied together. That sounds like awful requirement of statefulness with requirement of manual manipulation to me, i.e. a can of worms. Do we really need to assume that Gentoo developers will be adding keys they can't use to LDAP? > 3. As raised elsewhere on the thread, what delays should be implicit on a= new > dev joining vs having their key auto-signed? I don't see any need for delay. As soon as the user can access LDAP and add his key, he's proven that he owns the @gentoo.org address at the moment. > 4. uid signatures cannot generally exceed the lifetime of a primary key; = the L2 > signing service will need to resign regularly. How will this interact wit= h the > CAFF design above? Adds to the 'can of worms'. > 5. You state that the users should trust the L1 key directly. Can you cla= rify > your intent here to cover the trust? >=20 > The most obvious interpretation to me is trust signature of of the L2 key= , with > depth=3D2 domain=3Dgentoo.org [1]. Yes, something along the lines of that. >=20 > [1] trust signatures domain restrictions are actually regular > expressions; but GnuPG limits the input thereof. Just answering the > query: > > Please enter a domain to restrict this signature, or enter for none. > > Your selection? gentoo.org >=20 > Actually generates: > > :signature packet: algo 22, keyid THROWAWAY > > version 4, created 1550385418, md5len 0, sigclass 0x10 > > digest algo 8, begin of digest f0 e4 > > hashed subpkt 33 len 21 (issuer fpr v4 THROWAWAY) > > hashed subpkt 2 len 4 (sig created 2019-02-17) > > hashed subpkt 5 len 2 (trust signature of depth 2, value 120) > > critical hashed subpkt 6 len 24 (regular expression: "<[^>]+[@.]gentoo= \x5c.org>$\0") > > subpkt 16 len 8 (issuer key ID THROWAWAY) > > data: [255 bits] > > data: [256 bits] >=20 >=20 --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-Lui/B/OzcU0NE4O5r/gt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlxpIZtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQolUhAAtyRB3VJqqWywDWGdqA6w3/avE4ynMOtPGGelW+V6srjhOo6JPM6qwaV+ Ra/cNa9KULOuW/BLdF+bZQTNMrGXCZ+q/X6380ueLocyf0Y3ViMy3kVDCmYNxu/K 9p+KUxqBRl6gKhHdqenh7UTa1+orru5E2kpkqHPO80nke8+F7B90AlDCqfXtIY3I nDLnTntKvzI485ZuTMqlIiFXun+qJft5YTN6Zm9ZmGW0Xi2c4uy+0JW6Em0vhykC jlTpHdgK19U5OOf8hs1dBQaViKC3ucWxD9+c0Z3basvZ0qfgMIe6MNap7Up6AA71 r5tSPjWwbeuBV/qQjgzDbEL1mAPHeqrTaivgIxiuepe9e0DQPxeQt53l4UNE9OfB nygEGoLi9ffFjZ0l4eDHdie9iLuCuoVfPcuX+DOVy8rW+HF0emUoCjc5TkIVy/IO qN1g9+2FLVfnw2lXQ8I+I2+wX/1I8J2CIz7dcuJy+ommv3GNCQKzanWL7x+b61C/ LzlgzDP1RdMfNm3eAIPYMya8JEl1YRRE9fxj8kJ3yCXJPn5+kDIwQgjkzEze5V0S ByQxP4JyMYihAFK0p42QrRC4lPd/E9M0BHz+ezVOhDwVOmJUPGhwsBNDwvuPzI19 nnn2Ik0o47uYZhmz/FHOgRRwDcleF4R6fY/miBs5reb4AzO6TR4= =O5G1 -----END PGP SIGNATURE----- --=-Lui/B/OzcU0NE4O5r/gt--