Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0LAqwBe003685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 03:52:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0LAqw1x003684; Fri, 21 Jan 2011 03:52:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0LAqvIg003679 for ; Fri, 21 Jan 2011 03:52:58 -0700 (MST) (envelope-from iang@iang.org) Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id 8D2E0406C2; Fri, 21 Jan 2011 10:52:55 +0000 (UTC) Message-ID: <4D396586.5020700@iang.org> Date: Fri, 21 Jan 2011 21:52:54 +1100 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jon Callas CC: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org> In-Reply-To: <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 21/01/11 3:00 AM, Jon Callas wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A side-effect of this is something that's either an obvious extension or in the spec already. > > Section 3.3 says: "Implementations SHOULD NOT assume that Key IDs are unique." > > It's said that since 2440, for the following reason... > > In PGP1 days, Vinnie started working there and told me that he'd generated a key and gotten a certain error when putting it into the keyserver. I was thrilled, because that error was a duplicate keyid error. We'd been having debates over this ourselves. Being a software engineer, I tend to consider assuming that a database key is unique is bad form. I recognize that pseudo-random 64-bit numbers don't collide easily at all, but assuming uniqueness is something that is easily coded around. That key was my proof that engineering-wise, don't assume uniqueness. > > Sadly, he had deleted the key and just generated a new one, so that key is the Nessie of key ids. It's a crypto-cryptologist's dream, the true random collision. And we will never know if it was genuine. Sigh. > > Nonetheless, that led to that clause in 3.3, and I assert that if an implementation breaks because of a keyid collision, the implementation has a bug. Fascinating anecdote! Definately one to debate over beers: I'd not go so far as to agree that the implementation has a bug. I'd say this is the difference between "security culture" coding and an ordinary user-grade coding. Which is to say, as long as the error is rare enough, and as long as the knee-jerk reaction of the code at the top of the stack is approximately useful, and as long as this is a standard-grade application, it's reasonable to kick it way up there. In this case, the exception went all the way up the stack into the wetware, and Vinnie responded by re-generating the key! Problem solved. This "reboot" methodology made Bill Gates a lot of money... OTOH, if we were engaged in building a "security culture" product we would want to solve this in lower layers. iang Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0L4JM7c088182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 21:19:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0L4JMnH088181; Thu, 20 Jan 2011 21:19:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0L4JJoF088176 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Thu, 20 Jan 2011 21:19:21 -0700 (MST) (envelope-from avi.wiki@gmail.com) Received: by eyg5 with SMTP id 5so702091eyg.16 for ; Thu, 20 Jan 2011 20:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Zn9D0l/RRzrZ4hp/w6UZUu5A42p5Poj65pVvaZ7t7g4=; b=ZFQJJ8AsoDQoIvK0o9sN3omD1dBdJfy8FclkXlHmOo+FFme090akfGPbFPE1VA2PRc 07W+Zh/8M/LC2+CgmSfriEcLDDvAAD6b6yIJkxb9VyDmvhl2oD6a2MEJKJUJve8DpH+/ 0CE5wuunYpfS9LCTsUz0V1IjcLYaimGdMvda4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=fOwCrBd943teVesqh2RyBrrlb9lzl9FzL/M154gncjebWZo3ZAgNXqIxoV5Pv/Z31i 9WO18fgMvZl9FKOqf/qXbK9PW9CqXCsNZ5utI7HgVLLx8IlI1mT+Mi2DXDhVPqEG5In8 qk2gonuH/U5kEl7aQ2DF05rdJf+mdlgsA5IJ4= MIME-Version: 1.0 Received: by 10.213.112.131 with SMTP id w3mr184265ebp.42.1295583557628; Thu, 20 Jan 2011 20:19:17 -0800 (PST) Received: by 10.213.28.5 with HTTP; Thu, 20 Jan 2011 20:19:16 -0800 (PST) Reply-To: avi.wiki@gmail.com In-Reply-To: <20110120225114.GB4981@straylight.ringlet.net> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org> <20110120225114.GB4981@straylight.ringlet.net> Date: Thu, 20 Jan 2011 23:19:16 -0500 Message-ID: Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification From: Avi To: Peter Pentchev , Jon Callas , IETF OpenPGP Working Group Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I meant actually, as statistically speaking, the probability of picking any one point from any continuous interval on the real number line is exactly 0, which is why we deal with probability density functions over intervals instead of probability mass function at points. But I think I just got way off topic :) --Avi On 1/20/11, Peter Pentchev wrote: > On Thu, Jan 20, 2011 at 11:36:32AM -0500, Avi wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Even more strongly, there is the difference between "almost >> never" and "never". Even if there were an infinite number of key >> id's along the real number continuum, the possibility of a >> collision is mathematically 0%, > > ...I believe you mean "practically 0%", since mathematically, > it is definitely not 0% :) > >> but it is still possible. Heck, >> the possibility of ANY id would be mathematically 0, but each >> key would still have an ID. > > Same here, ITYM "practically" or "virtually" 0 :) > >> Here, we are dealing with a discrete distribution, so there >> /are/ mass points (be they VERY very small) at each ID, so yes, >> it is 100% certain that eventually, not only will there be a >> collision, but every key will have a collision. > > Theoretically, this is not necessarily true. It depends a lot on the > hashing algorithm used - it is completely possible to design a hashing > algorithm that would produce a certain digest for one input value and > one input value only - hell, it's trivial to design one based on another > hashing algorithm: "If the input is 'abcd', produce SHA1('abcd'); else, > if SHA1(input) == SHA1('abcd'), produce SHA1('abcde'); else, produce the > same result as SHA1(input)." > > I'm pretty much certain that for SHA1 your statement would be true, but > I'm not certain if it has been proved - greater minds here would > probably know: has anyone looked into that, and has it been proven that > there does not exist any sequence of bytes which would have an unique > SHA1 hash, that is, against which it is impossible to do a preimage > attack? > >> It may be >> though, that the waiting time may be longer than the heat death >> of the universe for the latter, so we don't have to worry about >> that too much :). > > G'luck, > Peter > > -- > Peter Pentchev roam@ringlet.net roam@FreeBSD.org peter@packetscale.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 > Hey, out there - is it *you* reading me, or is it someone else? > -- Sent from my mobile device ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KMpVI7077875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 15:51:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0KMpVsP077874; Thu, 20 Jan 2011 15:51:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from praag.hoster.bg (praag.hoster.bg [77.77.142.10]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KMpTW6077868 for ; Thu, 20 Jan 2011 15:51:30 -0700 (MST) (envelope-from roam@ringlet.net) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by praag.hoster.bg (Postfix) with ESMTP id D5B7C8CAE5 for ; Fri, 21 Jan 2011 00:51:27 +0200 (EET) Received: from straylight.ringlet.net (host86.office-vpn.int.hoster.bg [10.100.10.86]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id 5C2F95C455 for ; Fri, 21 Jan 2011 00:51:14 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 416024 by straylight.ringlet.net (DragonFly Mail Agent) Fri, 21 Jan 2011 00:51:14 +0200 Date: Fri, 21 Jan 2011 00:51:14 +0200 From: Peter Pentchev To: Avi Cc: Jon Callas , IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Message-ID: <20110120225114.GB4981@straylight.ringlet.net> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: 5C2F95C455.2AEF1 X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: ietf-openpgp@imc.org X-Spam-Status: No Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2011 at 11:36:32AM -0500, Avi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Even more strongly, there is the difference between "almost > never" and "never". Even if there were an infinite number of key > id's along the real number continuum, the possibility of a > collision is mathematically 0%, =09 =2E..I believe you mean "practically 0%", since mathematically, it is definitely not 0% :) > but it is still possible. Heck, > the possibility of ANY id would be mathematically 0, but each > key would still have an ID. Same here, ITYM "practically" or "virtually" 0 :) > Here, we are dealing with a discrete distribution, so there > /are/ mass points (be they VERY very small) at each ID, so yes, > it is 100% certain that eventually, not only will there be a > collision, but every key will have a collision. Theoretically, this is not necessarily true. It depends a lot on the hashing algorithm used - it is completely possible to design a hashing algorithm that would produce a certain digest for one input value and one input value only - hell, it's trivial to design one based on another hashing algorithm: "If the input is 'abcd', produce SHA1('abcd'); else, if SHA1(input) =3D=3D SHA1('abcd'), produce SHA1('abcde'); else, produce the same result as SHA1(input)." I'm pretty much certain that for SHA1 your statement would be true, but I'm not certain if it has been proved - greater minds here would probably know: has anyone looked into that, and has it been proven that there does not exist any sequence of bytes which would have an unique SHA1 hash, that is, against which it is impossible to do a preimage attack? > It may be > though, that the waiting time may be longer than the heat death > of the universe for the latter, so we don't have to worry about > that too much :). G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org peter@packetscale.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNOLxcAAoJEGUe77AlJ98TKeUP/iFf/lmyW9XOdsm9AyI5NHzd Ob+HRnGhbsAOFRfNMkRXWXq5LmkMedAD5RfQHimEJKx6h2W3lUa/jWbql37bIKXM FvYDaEnywo/AFWMs3mqoEBUXC7XQTZiIWwSPab252Wtv2t/sVmlCpBDbViaPlBks WMJgxf+9nlxPV7CsIcZZXNBf3jEvjC4OWPIieeEInj1/hZbJsF2AREcK7dUhmEDS 7ttcyHgDl136U5bH8kUh/zygiFaQ1KEDIUTA3D/DtYGohOi9P3iOfw0fUt03awLH qsVRTNMOgscBcG3n9iEQoRsiLB8Kx3S48P+yBJd5JEb1MOSwlEHprZo4KDVKyd+M xuNPjvLsJmMo7L4H5M0Ns2cmvumrgUkcrLfCNJYfK8aAEFzI4dL0ZR5B4aUM+yRK +AFcV0ZGi7J0Ov7lM3YEQ+mBcaaC7g5HoWt35gSbtisFMZy9FtKV6EILm0yH+GX1 +t0Z75O9CMuvCcO+ZG7lb9AJxLvewBV/b2zHrYoXXESvKdc6uen0MHAWRCGxT1KX 8dBY5aW33KcnrlzjQaRzZl2MYIqSCLnn8hGmhdsTeQZPsfDoSFzJKFzVfkDs60rG hHB5GhJebM3Ag+rnpTu5JdEDizF6ZJrEelwNfu2a7skeohhbt5IJorZLhZrQq7el 0J/ARwDn+hO4ZFxuq238 =yfj7 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KGb5no061176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 09:37:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0KGb5Yq061175; Thu, 20 Jan 2011 09:37:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KGb3MV061167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Thu, 20 Jan 2011 09:37:04 -0700 (MST) (envelope-from avi.wiki@gmail.com) Received: by ewy22 with SMTP id 22so358464ewy.16 for ; Thu, 20 Jan 2011 08:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=1F+riRajksYNoIicw1B3yWlsUYawIBXUlPi+rKbjV7Q=; b=fhhj9zVEoxWok1Nx9OVxbI/4hYWIt60V9aMplQO9hcBIldS3Vnk0J+sC84w0NBTxub bPDQZGg/Ug45td35QdLi251CnGlxdDwsBVyp10TXSGTVF4siJJ5cnlLGzvUFDFHf54Z3 R/SQhXK+yK8yW4ntBoNVEv1xhpzY7gdhAxuHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=rX5HUNR3xYmJ10da1sgOft0lucGJQWXUKWKeTPjkHk3v8eDg8td/Jt1d7DPQMeXHTz V4VGJMW6KmR2wQ5FJCJxDgLhBCYpa1ahZkJim8Azt+BQmRGxZ64u3pI8a57XnwTh3GMm OXOAEmViSO9vzcQiwLCux8BRN/JtS4Soz8jQk= Received: by 10.213.104.143 with SMTP id p15mr3180932ebo.68.1295541422209; Thu, 20 Jan 2011 08:37:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.21.129 with HTTP; Thu, 20 Jan 2011 08:36:32 -0800 (PST) Reply-To: avi.wiki@gmail.com In-Reply-To: <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org> From: Avi Date: Thu, 20 Jan 2011 11:36:32 -0500 Message-ID: Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification To: Jon Callas Cc: IETF OpenPGP Working Group Content-Type: multipart/alternative; boundary=0015174c3ffe433b5c049a49be94 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --0015174c3ffe433b5c049a49be94 Content-Type: text/plain; charset=ISO-8859-1 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Even more strongly, there is the difference between "almost never" and "never". Even if there were an infinite number of key id's along the real number continuum, the possibility of a collision is mathematically 0%, but it is still possible. Heck, the possibility of ANY id would be mathematically 0, but each key would still have an ID. Here, we are dealing with a discrete distribution, so there /are/ mass points (be they VERY very small) at each ID, so yes, it is 100% certain that eventually, not only will there be a collision, but every key will have a collision. It may be though, that the waiting time may be longer than the heat death of the universe for the latter, so we don't have to worry about that too much :). - --Avi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) - GPGshell v3.77 Comment: Most recent key: Click show in box @ http://is.gd/4xJrs iJgEAREKAEAFAk04ZIU5GGh0dHA6Ly9wZ3AubmljLmFkLmpwL3Brcy9sb29rdXA/ b3A9Z2V0JnNlYXJjaD0weEY4MEUyOUY5AAoJEA1isBn4Din525cA/R7idYB5pitE chXetB0o7Kvp1/DEmyv/sCG/dkt4dMlLAP9QtALK5BngB+pMWCt1bxA3wTcRH33J MO6qv7HAGBTNpQ== =hQBO -----END PGP SIGNATURE----- ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 On Thu, Jan 20, 2011 at 11:00 AM, Jon Callas wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A side-effect of this is something that's either an obvious extension or in > the spec already. > > Section 3.3 says: "Implementations SHOULD NOT assume that Key IDs are > unique." > > It's said that since 2440, for the following reason... > > In PGP1 days, Vinnie started working there and told me that he'd generated > a key and gotten a certain error when putting it into the keyserver. I was > thrilled, because that error was a duplicate keyid error. We'd been having > debates over this ourselves. Being a software engineer, I tend to consider > assuming that a database key is unique is bad form. I recognize that > pseudo-random 64-bit numbers don't collide easily at all, but assuming > uniqueness is something that is easily coded around. That key was my proof > that engineering-wise, don't assume uniqueness. > > Sadly, he had deleted the key and just generated a new one, so that key is > the Nessie of key ids. It's a crypto-cryptologist's dream, the true random > collision. And we will never know if it was genuine. Sigh. > > Nonetheless, that led to that clause in 3.3, and I assert that if an > implementation breaks because of a keyid collision, the implementation has a > bug. > > So you can consider a keyid to just be a database key. The way we do it now > (truncating a fingerprint) is a fine way to do it, but the underlying > principle is that an implementor really needs to code around the eventuality > that there will be a collision and do some right thing. > > Yeah, I know it's easier said than done, but that doesn't make it false. > > I forget what Terry Pratchett novel has it, but in one of them he has a > discussion that anything that is a million-to-one against is a certainty. > The million-to-one thing *will* happen. Cryptographers need to keep that > principle in the back of their head, too. > > Jon > -----BEGIN PGP SIGNATURE----- > Version: PGP Universal 2.10.0 (Build 554) > Charset: us-ascii > > wj8DBQFNOFwGsTedWZOD3gYRAtyVAJ40VCHrrUkG2Dc+Bi7fKQA5VZlCeQCfRQVc > Xs4TmguHftMh9uE/+b5Lqfw= > =B98X > -----END PGP SIGNATURE----- > > --0015174c3ffe433b5c049a49be94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Even more strongl= y, there is the difference between "almost
never" and "ne= ver". Even if there were an infinite number of key
id's along t= he real number continuum, the possibility of a
collision is mathematically 0%, but it is still possible. Heck,
the poss= ibility of ANY id would be mathematically 0, but each
key would still ha= ve an ID.

Here, we are dealing with a discrete distribution, so ther= e
/are/ mass points (be they VERY very small) at each ID, so yes,
it is 10= 0% certain that eventually, not only will there be a
collision, but ever= y key will have a collision. It may be
though, that the waiting time may= be longer than the heat death
of the universe for the latter, so we don't have to worry about
that= too much :).

- --Avi
-----BEGIN PGP SIGNATURE-----
Version: G= nuPG v1.4.11 (MingW32) - GPGshell v3.77
Comment: Most recent key: Click = show in box @ http://is.gd/4xJrs

iJgEAREKAEAFAk04ZIU5GGh0dHA6Ly9wZ3AubmljLmFkLmpwL3Brcy9sb29rdXA/
b3A= 9Z2V0JnNlYXJjaD0weEY4MEUyOUY5AAoJEA1isBn4Din525cA/R7idYB5pitE
chXetB0o7K= vp1/DEmyv/sCG/dkt4dMlLAP9QtALK5BngB+pMWCt1bxA3wTcRH33J
MO6qv7HAGBTNpQ=3D= =3D
=3DhQBO
-----END PGP SIGNATURE-----


----
Use= r:Avraham

pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) &= lt;avi.wiki@gmail.com>
=A0= =A0 Primary key fingerprint: 167C 063F 7981 A1F6 71EC=A0 ABAA 0D62 B019 F80= E 29F9


On Thu, Jan 20, 2011 at 11:00 AM, Jon Ca= llas <jon@callas.org= > wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A side-effect of this is something that's either an obvious exten= sion or in the spec already.

Section 3.3 says: "Implementations SHOULD NOT assume that Key IDs are = unique."

It's said that since 2440, for the following reason...

In PGP1 days, Vinnie started working there and told me that he'd genera= ted a key and gotten a certain error when putting it into the keyserver. I = was thrilled, because that error was a duplicate keyid error. We'd been= having debates over this ourselves. Being a software engineer, I tend to c= onsider assuming that a database key is unique is bad form. I recognize tha= t pseudo-random 64-bit numbers don't collide easily at all, but assumin= g uniqueness is something that is easily coded around. That key was my proo= f that engineering-wise, don't assume uniqueness.

Sadly, he had deleted the key and just generated a new one, so that key is = the Nessie of key ids. It's a crypto-cryptologist's dream, the true= random collision. And we will never know if it was genuine. Sigh.

Nonetheless, that led to that clause in 3.3, and I assert that if an implem= entation breaks because of a keyid collision, the implementation has a bug.=

So you can consider a keyid to just be a database key. The way we do it now= (truncating a fingerprint) is a fine way to do it, but the underlying prin= ciple is that an implementor really needs to code around the eventuality th= at there will be a collision and do some right thing.

Yeah, I know it's easier said than done, but that doesn't make it f= alse.

I forget what Terry Pratchett novel has it, but in one of them he has a dis= cussion that anything that is a million-to-one against is a certainty. The = million-to-one thing *will* happen. Cryptographers need to keep that princi= ple in the back of their head, too.

=A0 =A0 =A0 =A0Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFNOFwGsTedWZOD3gYRAtyVAJ40VCHrrUkG2Dc+Bi7fKQA5VZlCeQCfRQVc
Xs4TmguHftMh9uE/+b5Lqfw=3D
=3DB98X
-----END PGP SIGNATURE-----


--0015174c3ffe433b5c049a49be94-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KG09Bk059526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 09:00:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0KG09bR059525; Thu, 20 Jan 2011 09:00:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KG08YK059520 for ; Thu, 20 Jan 2011 09:00:08 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 265952E0E6 for ; Thu, 20 Jan 2011 08:00:11 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 13368-05 for ; Thu, 20 Jan 2011 08:00:08 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id DC8D02E0D0 for ; Thu, 20 Jan 2011 08:00:08 -0800 (PST) Received: from [10.58.48.195] ([12.180.86.130]) by keys.merrymeet.com (PGP Universal service); Thu, 20 Jan 2011 08:00:06 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 20 Jan 2011 08:00:06 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification From: Jon Callas In-Reply-To: <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> Date: Thu, 20 Jan 2011 08:00:04 -0800 Message-Id: <4764FF65-D26A-40A2-98F9-53A9857BD41E@callas.org> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1082) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: Maia Mailguard Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p0KG09YK059521 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A side-effect of this is something that's either an obvious extension or in the spec already. Section 3.3 says: "Implementations SHOULD NOT assume that Key IDs are unique." It's said that since 2440, for the following reason... In PGP1 days, Vinnie started working there and told me that he'd generated a key and gotten a certain error when putting it into the keyserver. I was thrilled, because that error was a duplicate keyid error. We'd been having debates over this ourselves. Being a software engineer, I tend to consider assuming that a database key is unique is bad form. I recognize that pseudo-random 64-bit numbers don't collide easily at all, but assuming uniqueness is something that is easily coded around. That key was my proof that engineering-wise, don't assume uniqueness. Sadly, he had deleted the key and just generated a new one, so that key is the Nessie of key ids. It's a crypto-cryptologist's dream, the true random collision. And we will never know if it was genuine. Sigh. Nonetheless, that led to that clause in 3.3, and I assert that if an implementation breaks because of a keyid collision, the implementation has a bug. So you can consider a keyid to just be a database key. The way we do it now (truncating a fingerprint) is a fine way to do it, but the underlying principle is that an implementor really needs to code around the eventuality that there will be a collision and do some right thing. Yeah, I know it's easier said than done, but that doesn't make it false. I forget what Terry Pratchett novel has it, but in one of them he has a discussion that anything that is a million-to-one against is a certainty. The million-to-one thing *will* happen. Cryptographers need to keep that principle in the back of their head, too. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFNOFwGsTedWZOD3gYRAtyVAJ40VCHrrUkG2Dc+Bi7fKQA5VZlCeQCfRQVc Xs4TmguHftMh9uE/+b5Lqfw= =B98X -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KFmG6g058918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 08:48:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0KFmGnm058917; Thu, 20 Jan 2011 08:48:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KFmFot058912 for ; Thu, 20 Jan 2011 08:48:16 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id B2B512E0F4 for ; Thu, 20 Jan 2011 07:48:17 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 13193-10 for ; Thu, 20 Jan 2011 07:48:15 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 7599C2E0E6 for ; Thu, 20 Jan 2011 07:48:15 -0800 (PST) Received: from [10.58.48.195] ([12.180.86.130]) by keys.merrymeet.com (PGP Universal service); Thu, 20 Jan 2011 07:48:12 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 20 Jan 2011 07:48:12 -0800 Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Mime-Version: 1.0 (Apple Message framework v1082) From: Jon Callas In-Reply-To: <4D3615A5.1050700@fifthhorseman.net> Date: Thu, 20 Jan 2011 07:48:10 -0800 Cc: Jon Callas Message-Id: <3B73CC58-35BE-460D-8378-4869DB00BA30@callas.org> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1082) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: Maia Mailguard Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p0KFmGot058913 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > i'm pretty sure that's not what he suggested, actually. But clearly it > wasn't successfully communicated to everyone, since we appear to have > different interpretations. Jon, can you clarify what you meant? I meant nothing more than a one-byte algorithm number (section 9.4) and then the hash. So for example all the current fingerprints could be recoded with an 0x02 (SHA1) and then the existing fingerprint. If you want to version it, too, sure, why not. I think it's superfluous, but it wouldn't hurt and what's a byte among friends? Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFNOFk8sTedWZOD3gYRAl/kAKCq81J9mFBXQaTSrpgI6K38EHSwjQCgwwqh ygCLYLfs+YV1pxn++5SvAcM= =fPxq -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KALrpf043769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 03:21:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0KALrdu043768; Thu, 20 Jan 2011 03:21:53 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0KALrCN043763 for ; Thu, 20 Jan 2011 03:21:53 -0700 (MST) (envelope-from iang@iang.org) Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id AEC82406C2; Thu, 20 Jan 2011 10:21:51 +0000 (UTC) Message-ID: <4D380CBF.7080905@iang.org> Date: Thu, 20 Jan 2011 21:21:51 +1100 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> In-Reply-To: <4D36010A.30205@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 19/01/11 8:07 AM, Daniel Kahn Gillmor wrote: > On 01/18/2011 12:48 PM, Jon Callas wrote: >> If we combine it with a hash-independent fingerprint -- e.g., first byte is an algorithm ID, others are the actual hash -- then we can put it in now and then run with it. > > Daniel Nagy suggests that we also change the material being hashed in > the fingerprint (he wants to leave out the creation date). If that > proposal ends up achieving consensus then your proposal here will need > further modification. > > Does anyone feel strongly about Nagy's proposal, by the way? i'm not > sure what the tradeoffs are. > > Even without that concern, if we encourage super-flexible use like this, > user agents who wanted to use it to test for the presence of a given key > in an indexed keystore would need to index their keys with every > possible digest that might be used -- that seems excessive somehow. > (and unlikely that keyserver implementations would want a half-dozen > indexes, for that matter) Wouldn't it be better to just implement it > for today's fingerprint, and then when a new fingerprint is agreed upon, > determine (by subpacket length maybe?) whether it's the new fingerprint > or the old one. Compliant user agents would keep the two indexes around > until the v4 fingerprint goes away, and then drop the old one. > > Alternately, we could embed the algorithm ID as you suggest, and SHOULD > people into generating them using only the consensus fingerprint > algorithms so that reasonable user agents only need to create indexes > over SHA1 (now) and SHA3 (whenever that happens). The style of OpenPGP v5++ has been algorithm agility, and getting away from that is likely to take time, and/or bravery. Which leads me to agree that the fingerprint should include the leading algorithm Id, because that's how we do message digests. And in text, we browbeat the developers to stick to the "the one." (In which, the one will be two, SHA1 then SHA3, until we can ditch the other "one".) On the other hand, there is that hanging question: do we want algorithm agility in the future? What did we ever win by it? Did it ever meet its promise? If the answer is in the negative, I'd be inclined to ignore the whole packet question and start thinking instead about a completely new layout generation that simplified the coding requirements back to something ... PGP 2.3 like. iang PS: at least, that's my question & hobby horse. Others have other questions and hobby horses. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0K4jNCb030502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 21:45:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0K4jNJM030501; Wed, 19 Jan 2011 21:45:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0K4jLhB030496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Jan 2011 21:45:23 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p0K4jKcV030261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Jan 2011 23:45:21 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification From: David Shaw In-Reply-To: <4D36812A.9050601@fifthhorseman.net> Date: Wed, 19 Jan 2011 23:45:20 -0500 Message-Id: <4CCBCFF0-211C-4405-99D1-B626E14C252B@jabberwocky.com> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D3611C1.5050706@fifthhorseman.net> <05AB0704-53F0-4969-B0CA-DAC501D8CC40@jabberwocky.com> <4D36812A.9050601@fifthhorseman.net> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p0K4jNhA030497 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 19, 2011, at 1:14 AM, Daniel Kahn Gillmor wrote: > On 01/18/2011 05:43 PM, David Shaw wrote: >> No, this would be another use of the existing public/secret key version registry. We already have a registry that covers key versions. > [...] >> Sorry - I wasn't clear enough. Rather than using a notation, I was saying that if that we should define a "true" subpacket (not a notation) >> for this, but define the subpacket in a flexible enough way that we > won't be throwing the subpacket away (or having to maintain it just for > V4) when V5 comes. > > ok, i understand what you're saying. I'm game for either approach. > > Here's a proposal: i'll start with an issuer-fpr@... notation that will > use the exact value (version byte, fpr) that we expect to be the content > of the new subpacket type, demonstrate it, and then use that experience > to draft an update to RFC 4880 and apply for a new subpacket allocation > if it seems to make sense. > > Is it kosher to use a notation this way instead of using an explicitly > experimental subpacket type? Sure, you can do either one. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0JBbJmM090291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 04:37:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0JBbJEe090290; Wed, 19 Jan 2011 04:37:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0JBbG6o090283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Wed, 19 Jan 2011 04:37:18 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by fxm18 with SMTP id 18so728546fxm.16 for ; Wed, 19 Jan 2011 03:37:16 -0800 (PST) Received: by 10.223.74.5 with SMTP id s5mr593868faj.72.1295437035887; Wed, 19 Jan 2011 03:37:15 -0800 (PST) Received: from [192.168.3.151] (catv-89-132-111-180.catv.broadband.hu [89.132.111.180]) by mx.google.com with ESMTPS id c11sm2527374fav.2.2011.01.19.03.37.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Jan 2011 03:37:14 -0800 (PST) Message-ID: <4D36CCE7.4050505@epointsystem.org> Date: Wed, 19 Jan 2011 12:37:11 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Peter Gutmann , dkg@fifthhorseman.net Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC211D4E67E0F54FC72F02F16" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC211D4E67E0F54FC72F02F16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter Gutmann wrote: > "Daniel A. Nagy" writes: >=20 >> generating a new key with the same 64-bit key ID as an existing key is= on the >> very far end of the realm of feasibility. >=20 > That should be: >=20 > generating a *secure* new key with the same 64-bit key ID as an exist= ing key > is on the very far end of the realm of feasibility. >=20 > If you don't mind that your key's weak then it's not that much more wor= k than > just finding a 64-bit collision. I disagree. It's not a collision that you are after, but a 64 bit pre-ima= ge. Basically, you need to enumerate, on average, 2^63 possibilities, which i= s very expensive. Regards, --=20 Daniel --------------enigC211D4E67E0F54FC72F02F16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAk02zOcACgkQ28D1wCI06YXKvwCcDKUPs0+Qo4+NhsmiHY66at/E DjAAn21xk+B23K1a3vFKiYUx6761vlZd =b1RI -----END PGP SIGNATURE----- --------------enigC211D4E67E0F54FC72F02F16-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0J85B47080950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 01:05:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0J85B3P080949; Wed, 19 Jan 2011 01:05:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0J85AMg080941 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 19 Jan 2011 01:05:11 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.69 #1 (Debian)) id 1PfT2T-0000TH-DQ for ; Wed, 19 Jan 2011 09:05:09 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.72 #1 (Debian)) id 1PfSy5-00067n-Fa; Wed, 19 Jan 2011 09:00:37 +0100 From: Werner Koch To: David Shaw Cc: Jon Callas , OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <6C85BB3E-90BC-4FDC-967C-0867F5B1F57F@jabberwocky.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 19 Jan 2011 09:00:37 +0100 In-Reply-To: <6C85BB3E-90BC-4FDC-967C-0867F5B1F57F@jabberwocky.com> (David Shaw's message of "Tue, 18 Jan 2011 16:45:14 -0500") Message-ID: <877he1s4pm.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 18 Jan 2011 22:45, dshaw@jabberwocky.com said: > Rather than first byte being an algorithm ID, how about first byte > being the version of the fingerprint? So, it would be "4" for the > current fingerprint, "5" I think this is better than just the algorithm id. It can be used to account for different ways of computing the fingerprint as it matches the version number of the key packets. We don't specify the the fingerprint algorithm at any other place directly; thus why do it here. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0J6E9Q6077245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 23:14:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0J6E9Yr077244; Tue, 18 Jan 2011 23:14:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0J6E854077237 for ; Tue, 18 Jan 2011 23:14:09 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 999E2F987 for ; Wed, 19 Jan 2011 01:14:07 -0500 (EST) Message-ID: <4D36812A.9050601@fifthhorseman.net> Date: Wed, 19 Jan 2011 01:14:02 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D3611C1.5050706@fifthhorseman.net> <05AB0704-53F0-4969-B0CA-DAC501D8CC40@jabberwocky.com> In-Reply-To: <05AB0704-53F0-4969-B0CA-DAC501D8CC40@jabberwocky.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE97A4F6D31F833C305E17C3F" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE97A4F6D31F833C305E17C3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/18/2011 05:43 PM, David Shaw wrote: > No, this would be another use of the existing public/secret key version= registry. We already have a registry that covers key versions. [...] > Sorry - I wasn't clear enough. Rather than using a notation, I was say= ing that if that we should define a "true" subpacket (not a notation) > for this, but define the subpacket in a flexible enough way that we won't be throwing the subpacket away (or having to maintain it just for V4) when V5 comes. ok, i understand what you're saying. I'm game for either approach. Here's a proposal: i'll start with an issuer-fpr@... notation that will use the exact value (version byte, fpr) that we expect to be the content of the new subpacket type, demonstrate it, and then use that experience to draft an update to RFC 4880 and apply for a new subpacket allocation if it seems to make sense. Is it kosher to use a notation this way instead of using an explicitly experimental subpacket type? --dkg --------------enigE97A4F6D31F833C305E17C3F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNNoErXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpAv8P/i3svlo8X2cJDYm0bdrRTgsP nEESC5tOK3Fxofi08Kx1U+eblGgxkyhBohew8IbJqNnuuyV5zY4qbVO/T5f3xiBF GH+JsckngxUFZMWNy7z0CDcavAnruHha2Uflr7kcdkgV/KVn6sK9QKSr+3sde3pz kVtPcZDsQp6IijqBSj2rslCXLR2iCrk9OUwr3bLuDmrxCBjmLp5l84+jmKcevYYq /0eZMQD7+8MamfG+IUOZeK0TkECEgvYOOpBUvWX2XgwlmCazOR6KYVyeZpm9Ufr0 Uj/Tb43Po1PQKoZiFY+Xa0NF4rjeqHO1k2tUVHzTEWcxXP769N/2g8HkFWFNwRqS 4X2W/S+gVY0VokHng8lkYBmde9cQKuQHClADGFRkeF59nWOE8DLRPbw2ZroTBie1 zAaZegiNaM1VQZQzoqgO5Z3w5hJP/HkmnhuM+8YtvwiV97Tk0/hPqFzzSG2IHOF/ 6Desf5HX2JtsmXbKnnQqZbW4aTQagqF0668LT0lcONQJdiWKhekfP6rDtXKHtjms Q0kMnO4mA/ZkC9dENtXULj8GqN3xdr7SiosbfrbjnilwqgWeaib2gfDu4NHqv8XR NsRH5kW3K4fCB6iXUGTxH/L5Dg0ei8vo2pmtawjJmHITaCp90GxBxGvqhMXvIcqw 1VCbE+e+i8zNTauNGbJB =OpKc -----END PGP SIGNATURE----- --------------enigE97A4F6D31F833C305E17C3F-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0J0BoPM065312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 17:11:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0J0Bo9O065311; Tue, 18 Jan 2011 17:11:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0J0BiwY065305 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 18 Jan 2011 17:11:47 -0700 (MST) (envelope-from pgut001@login01.fos.auckland.ac.nz) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1295395908; x=1326931908; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ietf-openpgp@imc.org,=20nagydani@epointsystem.org |Subject:=20Re:=20including=20the=20entire=20fingerprint =20of=20the=20issuer=20in=20an=20OpenPGP=20certification |Cc:=20dkg@fifthhorseman.net,=20notmuch@notmuchmail.org |In-Reply-To:=20<4D3564E4.1010203@epointsystem.org> |Message-Id:=20|Date:=20Wed,=2019=20Jan=202011=2013:11:43=20+1300; bh=ntqTGfQQ7qJId6UnhG6SWZGCvU1kjRdQOe3fJLjkxm4=; b=YFZDlTz8RJdEACn4nwBkb0a0DxmgM+aNmCe8wSohORkmMCb8VFlh3k30 dd4gc841HFNozW0BApDhH96DfrosWFzpibBbs41K4QhTfbqe2uCX+nPWf fOUFlqqbm+6sRrrONXPfM2uc9y6AgRxZ2zNL0MnvKa5dfy0b27P0w49p1 s=; X-IronPort-AV: E=Sophos;i="4.60,341,1291546800"; d="scan'208";a="42824993" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Jan 2011 13:11:43 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PfLeJ-0005es-Gh; Wed, 19 Jan 2011 13:11:43 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PfLeJ-0002cY-4A; Wed, 19 Jan 2011 13:11:43 +1300 From: Peter Gutmann To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Cc: dkg@fifthhorseman.net, notmuch@notmuchmail.org In-Reply-To: <4D3564E4.1010203@epointsystem.org> Message-Id: Date: Wed, 19 Jan 2011 13:11:43 +1300 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Daniel A. Nagy" writes: >generating a new key with the same 64-bit key ID as an existing key is on the >very far end of the realm of feasibility. That should be: generating a *secure* new key with the same 64-bit key ID as an existing key is on the very far end of the realm of feasibility. If you don't mind that your key's weak then it's not that much more work than just finding a 64-bit collision. Peter. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0INNwjU064070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 16:23:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0INNwqx064069; Tue, 18 Jan 2011 16:23:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0INNuVG064063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 16:23:57 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (gw-comcast1.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p0INNtY5019504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jan 2011 18:23:55 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification From: David Shaw In-Reply-To: <4D3615A5.1050700@fifthhorseman.net> Date: Tue, 18 Jan 2011 18:23:54 -0500 Message-Id: References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> <4D3615A5.1050700@fifthhorseman.net> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1081) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p0INNvVF064065 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 18, 2011, at 5:35 PM, Daniel Kahn Gillmor wrote: >> I think that there must be only ONE string called THE fingerprint of a certain >> public key. > > why? we currently have three strings that are frequently used to > identify keys with varying levels of assurance of "uniqueness" -- the > 32-bit keyID (no guarantee at all, trivially spoofable), the 64-bit > keyID (more difficult to spoof), and the 160-bit SHA1-based fingerprint > (believed to be invulnerable to preimage attacks given the state of > knowledge of math and available computer hardware). I'm aware that > these are derivable from each other, but it doesn't seem to change the > fact that we're using them in a comparable way right now. > > What significant problems will we encounter by adding a 4th identifying > shorthand variant (hopefully with stronger guarantees of "uniqueness" > than the existing three) that people can use if they want the stronger > guarantees? I think we're overloading the term "fingerprint" and it's causing confusion. The original mail was a desire to help disambiguate the signer of a particular signature to resist a particular attack. Of course, we have a thing-that-disambiguates already - the key fingerprint, which is already well defined in the spec and very widely implemented. I don't want to invent a brand new thing-that-disambiguates that a) only applies to making signatures, and b) is not compatible with the existing method. Like Werner, I don't want to have to support it more-or-less forever after V5 obsoletes it, and it also feels rather like an end-run around the "let's wait for SHA-3" consensus here on fingerprint changes. My proposal is to make a subpacket that is defined as the fingerprint of the signing key plus a version byte. This is an excellent disambiguator. As you point out, it is believed to be invulnerable to preimage attacks given the state of knowledge of math and available computer hardware. If and when we do V5, the same subpacket can be used for the V5 fingerprint (whatever that turns out to be), so we're not being forced to support an obsolete subpacket. Think of it as an improved Issuer (#16) subpacket. Shorter version of all that from your original email: > Alternately, what about a new subpacket type that simply includes the > entire 160 bits of the issuer's fingerprint? (the "full fingerprint" > proposal) Add a version byte to the front of that, and we're talking about the same thing. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IMh5Pl062816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:43:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IMh5Jw062815; Tue, 18 Jan 2011 15:43:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IMh38R062807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 15:43:04 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (gw-comcast1.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p0IMh2vK019330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jan 2011 17:43:02 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification From: David Shaw In-Reply-To: <4D3611C1.5050706@fifthhorseman.net> Date: Tue, 18 Jan 2011 17:43:01 -0500 Message-Id: <05AB0704-53F0-4969-B0CA-DAC501D8CC40@jabberwocky.com> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D3611C1.5050706@fifthhorseman.net> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1081) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p0IMh48Q062811 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 18, 2011, at 5:18 PM, Daniel Kahn Gillmor wrote: > On 01/18/2011 05:05 PM, David Shaw wrote: >> I don't think we want people using other than the consensus fingerprint algorithms and methods. I suggest we make the first byte a version field, which can be >> set to '4' today for the current fingerprint, '5' for v5 keys, etc. > > Are we talking about versioning the fingerprint scheme, or versioning > the key? It sounds like a versioned fingerprint scheme, not a versioned > key scheme to me. > > If we say '4' means the fingerprinting standard in RFC 4880 (OpenPGPv4) > and '5' means some other fingerprint scheme then we're effectively > creating a new registry to be managed by IANA, right? No, this would be another use of the existing public/secret key version registry. We already have a registry that covers key versions. >> I suppose we could skip that field and detect version based on size, >> but why use heuristics when we can know for sure with a version byte? > > We could also be sure if the name of the notation is precise enough. Sorry - I wasn't clear enough. Rather than using a notation, I was saying that if that we should define a "true" subpacket (not a notation) for this, but define the subpacket in a flexible enough way that we won't be throwing the subpacket away (or having to maintain it just for V4) when V5 comes. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IMZPMI062592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:35:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IMZPA8062591; Tue, 18 Jan 2011 15:35:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IMZOhl062586 for ; Tue, 18 Jan 2011 15:35:24 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 428C2F987 for ; Tue, 18 Jan 2011 17:35:23 -0500 (EST) Message-ID: <4D3615A5.1050700@fifthhorseman.net> Date: Tue, 18 Jan 2011 17:35:17 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> <4D360E46.1080208@epointsystem.org> In-Reply-To: <4D360E46.1080208@epointsystem.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD6BE80802367B5C059290AE7" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD6BE80802367B5C059290AE7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/18/2011 05:03 PM, Daniel A. Nagy wrote: > There are specific use cases that I am interested in, where including t= he > creation date in the fingerprint hash causes problems. If anyone is int= erested, > I can describe them in necessary detail. I'd like to read about (or be pointed to) the necessary detail. > I believe you mis-interpreted Jon's suggestion. He was suggesting to tr= eat the > fingerprint field as a free-form string within the signature subpacket.= Nothing > more and nothing less. i'm pretty sure that's not what he suggested, actually. But clearly it wasn't successfully communicated to everyone, since we appear to have different interpretations. Jon, can you clarify what you meant? > Key servers must also eventually treat > fingerprints as (possibly limited-length, but by no means fixed-length)= strings. Why? Shouldn't keyservers be responsible for calculating the fingerprints themselves? treating fingerprinting as a total black box seems like it loses several of the really useful properties of fingerprin= ts. > I think that there must be only ONE string called THE fingerprint of a = certain > public key. why? we currently have three strings that are frequently used to identify keys with varying levels of assurance of "uniqueness" -- the 32-bit keyID (no guarantee at all, trivially spoofable), the 64-bit keyID (more difficult to spoof), and the 160-bit SHA1-based fingerprint (believed to be invulnerable to preimage attacks given the state of knowledge of math and available computer hardware). I'm aware that these are derivable from each other, but it doesn't seem to change the fact that we're using them in a comparable way right now. What significant problems will we encounter by adding a 4th identifying shorthand variant (hopefully with stronger guarantees of "uniqueness" than the existing three) that people can use if they want the stronger guarantees? --dkg --------------enigD6BE80802367B5C059290AE7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNNhWlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznptaAP/R53N6lgYnDt7fPqDk3SDeWS 0sTWoljU7WToF15mz5HsH5f4z5SKtuT8SjNUcTd7Wq1VIEYUqPh2B4dzxIxbONwW ghILAANX9hr6j00I1JlxG4ky+gp3aYjyaC/XSgtQ/bAmSdgqVI0+pwodLmXM+yD/ 0oHii3xhbRaJp4x0qwVBQd1lHgjGhZ5LClaqHdTHveFWzFAUePrzURmfoSeVdyuW M3WpCx5OT8m6kLfj82IEgcMhX/usr/qFOxKbclHqYMPIuRFO3pssSf41SmGYtI1g Zg0k/1wkvZjO4pYiFrVjn4yQ3uleIXIsWFW9qgbhfBSUnaWp1hWPkifIoV8qdngn csA3/4xO3GOturyIcRkB+nIFcrmH/3ya3QHysEQMfTMxNDTg+K5YV8+ksKZ0BTPs o5OBd9IxYKWW3q41JxCu2MogM+XV3dLtNnDqvqMWn95hkwbn7m32Qef+DCngRpAn i6UTkN7TwygHf5I5gPnq3blQNprduUqO0BUgTb/E2vydM/4GFTGMctQEyJhC0rZT 52tpD2OWnTrVG/OgB9jLzbxIJWfDG1YJoniac3AehIdGxUUcdhsB+wioZXyuEqoo 1Uy1LZP7uvqrR/Q5kG03s6gdxQd74GUEUoNCl3lLb6NX98LJm6NfL30UJspvHSH8 ZB2Fx/xmOookvRWupOfY =W3dz -----END PGP SIGNATURE----- --------------enigD6BE80802367B5C059290AE7-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IMImxV061992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:18:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IMImq0061990; Tue, 18 Jan 2011 15:18:48 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IMIlLx061979 for ; Tue, 18 Jan 2011 15:18:48 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id D85C6F987 for ; Tue, 18 Jan 2011 17:18:46 -0500 (EST) Message-ID: <4D3611C1.5050706@fifthhorseman.net> Date: Tue, 18 Jan 2011 17:18:41 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig83637B46A964E7359DF2744A" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83637B46A964E7359DF2744A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/18/2011 05:05 PM, David Shaw wrote: > I don't think we want people using other than the consensus fingerprint= algorithms and methods. I suggest we make the first byte a version fiel= d, which can be=20 > set to '4' today for the current fingerprint, '5' for v5 keys, etc. Are we talking about versioning the fingerprint scheme, or versioning the key? It sounds like a versioned fingerprint scheme, not a versioned key scheme to me. If we say '4' means the fingerprinting standard in RFC 4880 (OpenPGPv4) and '5' means some other fingerprint scheme then we're effectively creating a new registry to be managed by IANA, right? I have no objection to that (and presumably it would be an exceptionally slow-growing registry) but it'd be good to be clear about what we're doin= g. I'd just as soon name the notation issuer-fpr4@whatever.example for the current fingerprint and then name a new notation issuer-fpr5@whatever.example when that happens, reusing the existing notation registry. (or, if this works and we want iana to allocate a "global" notation title, just ask for "issuer-fpr4" now, an "issuer-fpr5" later) This is all fiddly syntax choices, of course, without much importance, other than avoiding (current and future) bureaucratic overhead. > I suppose we could skip that field and detect version based on size, > but why use heuristics when we can know for sure with a version byte? We could also be sure if the name of the notation is precise enough. --dkg --------------enig83637B46A964E7359DF2744A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNNhHBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpZ4oP/0TdCfXu1VgQTDxuE2v9TuCG 6BQ26gaylw3uEb4reAMkQzdMnnigGr7oGk0ceBwQhNLX/sRt8gF2w1bNSJEfGLho xb3s5TTeZdj0htE0F7XuZ5yJg+W6FqlE1z61LldFDXGv5Y8wCOrVTXth2/4gkJ+2 C05rpnd0MrpctN1WZnmBHVfpicjJYbaog8xPa8bITsjwdON9v6cvlotXJ+F8jSld or5G1bmznohPm8jVgXBUDMoDmoez+AMj/Y3Zu/b7Iw4JBFObBJKHSVvcFMMhy8WB yBjsc5Bi0RYo61oNQVhJYAFQUK7wT2TCQcLFhUo7IKZvkTCDwD9GA5AabKvO1TFj q+ee4XCTI4waao008ea8yS0HYmcCCeFesAXFRYfMdlXEaxfDEFDELClVVDERDapv 8ONVDX0IRTbt6kvdrsZVxr0VbWileE7MhUdNcb2yLc2QmoRIEYgTdNUS9T8op8Pf KWWRE8hQxmFjWyvBZcusPUZDK0Jxu9pFlJrVDub9xGrPOoCj4vG5X5tWF/babPah SOaUPbXEEXkQR+JTTXQMMskerUMlzZ6DqLI/tRLycbrqExm95v+oy4JrG9ICupH6 zi5NgrNMT+hrNxtiLf/fKN1GoFXe2DTieuL/g7b2I1ZjD53XxXi/zH6t8F5fF8PB RtYqJB/JK59Uo7Xsx88D =ASea -----END PGP SIGNATURE----- --------------enig83637B46A964E7359DF2744A-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IM5w69061553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:05:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IM5w40061552; Tue, 18 Jan 2011 15:05:58 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IM5ukI061547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 15:05:57 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (gw-comcast1.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p0IM5tSI019147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jan 2011 17:05:55 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification From: David Shaw In-Reply-To: <4D36010A.30205@fifthhorseman.net> Date: Tue, 18 Jan 2011 17:05:55 -0500 Message-Id: References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1081) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p0IM5vkH061548 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 18, 2011, at 4:07 PM, Daniel Kahn Gillmor wrote: > On 01/18/2011 12:48 PM, Jon Callas wrote: >> If we combine it with a hash-independent fingerprint -- e.g., first byte is an algorithm ID, others are the actual hash -- then we can put it in now and then run with it. > > Daniel Nagy suggests that we also change the material being hashed in > the fingerprint (he wants to leave out the creation date). If that > proposal ends up achieving consensus then your proposal here will need > further modification. > > Does anyone feel strongly about Nagy's proposal, by the way? i'm not > sure what the tradeoffs are. > > Even without that concern, if we encourage super-flexible use like this, > user agents who wanted to use it to test for the presence of a given key > in an indexed keystore would need to index their keys with every > possible digest that might be used -- that seems excessive somehow. > (and unlikely that keyserver implementations would want a half-dozen > indexes, for that matter) Wouldn't it be better to just implement it > for today's fingerprint, and then when a new fingerprint is agreed upon, > determine (by subpacket length maybe?) whether it's the new fingerprint > or the old one. Compliant user agents would keep the two indexes around > until the v4 fingerprint goes away, and then drop the old one. > > Alternately, we could embed the algorithm ID as you suggest, and SHOULD > people into generating them using only the consensus fingerprint > algorithms so that reasonable user agents only need to create indexes > over SHA1 (now) and SHA3 (whenever that happens). I don't think we want people using other than the consensus fingerprint algorithms and methods. I suggest we make the first byte a version field, which can be set to '4' today for the current fingerprint, '5' for v5 keys, etc. I suppose we could skip that field and detect version based on size, but why use heuristics when we can know for sure with a version byte? David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IM3u1t061466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 15:03:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IM3uD1061465; Tue, 18 Jan 2011 15:03:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IM3tui061458 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Tue, 18 Jan 2011 15:03:56 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by fxm18 with SMTP id 18so143251fxm.16 for ; Tue, 18 Jan 2011 14:03:54 -0800 (PST) Received: by 10.223.98.204 with SMTP id r12mr6777013fan.102.1295388234210; Tue, 18 Jan 2011 14:03:54 -0800 (PST) Received: from [192.168.3.151] (catv-89-132-111-180.catv.broadband.hu [89.132.111.180]) by mx.google.com with ESMTPS id a25sm2335885fak.44.2011.01.18.14.03.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 14:03:53 -0800 (PST) Message-ID: <4D360E46.1080208@epointsystem.org> Date: Tue, 18 Jan 2011 23:03:50 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> <4D36010A.30205@fifthhorseman.net> In-Reply-To: <4D36010A.30205@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig5089CC478F8BBF2264BA3852" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5089CC478F8BBF2264BA3852 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Daniel Kahn Gillmor wrote: > On 01/18/2011 12:48 PM, Jon Callas wrote: >> If we combine it with a hash-independent fingerprint -- e.g., first by= te is an algorithm ID, others are the actual hash -- then we can put it i= n now and then run with it. >=20 > Daniel Nagy suggests that we also change the material being hashed in > the fingerprint (he wants to leave out the creation date). If that > proposal ends up achieving consensus then your proposal here will need > further modification. >=20 > Does anyone feel strongly about Nagy's proposal, by the way? i'm not > sure what the tradeoffs are. There are specific use cases that I am interested in, where including the= creation date in the fingerprint hash causes problems. If anyone is inter= ested, I can describe them in necessary detail. > Even without that concern, if we encourage super-flexible use like this= , > user agents who wanted to use it to test for the presence of a given ke= y > in an indexed keystore would need to index their keys with every > possible digest that might be used -- that seems excessive somehow. > (and unlikely that keyserver implementations would want a half-dozen > indexes, for that matter) Wouldn't it be better to just implement it > for today's fingerprint, and then when a new fingerprint is agreed upon= , > determine (by subpacket length maybe?) whether it's the new fingerprint= > or the old one. Compliant user agents would keep the two indexes aroun= d > until the v4 fingerprint goes away, and then drop the old one. I believe you mis-interpreted Jon's suggestion. He was suggesting to trea= t the fingerprint field as a free-form string within the signature subpacket. N= othing more and nothing less. This makes the change future-proof without any of = the problems that you mention above. Key servers must also eventually treat fingerprints as (possibly limited-length, but by no means fixed-length) s= trings. On the other hand, one can argue that there is no reason to move from 160= -bit fingerprints, even if we change the algorithm of their calculation for v5= keys. Even if a different hash function is used. This would make transition a b= it less painful, without any real compromises on security. > Alternately, we could embed the algorithm ID as you suggest, and SHOULD= > people into generating them using only the consensus fingerprint > algorithms so that reasonable user agents only need to create indexes > over SHA1 (now) and SHA3 (whenever that happens). I think that there must be only ONE string called THE fingerprint of a ce= rtain public key. Even if the algorithm is included, it should be either includ= ed in the key itself indicating that for that particular key this particular al= gorithm must be used or even mandated by the standard for all keys until further revisions. I see no benefit in explicitly including any details of the al= gorithm used to obtain it into the fingerprint itself, though. Cheers, --=20 Daniel --------------enig5089CC478F8BBF2264BA3852 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAk02DkYACgkQ28D1wCI06YXQQgCeIbBFtspAJqjluzKvBeylY89Q 3LkAn0VSen942Wn/G4kNcfWFaKuG0I97 =k/pt -----END PGP SIGNATURE----- --------------enig5089CC478F8BBF2264BA3852-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0ILjRiP060842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 14:45:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0ILjRQ2060841; Tue, 18 Jan 2011 14:45:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0ILjPWH060836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 14:45:26 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (gw-comcast1.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p0ILjEJF018984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jan 2011 16:45:15 -0500 Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Shaw In-Reply-To: <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> Date: Tue, 18 Jan 2011 16:45:14 -0500 Cc: Werner Koch , OpenPGP Working Group Message-Id: <6C85BB3E-90BC-4FDC-967C-0867F5B1F57F@jabberwocky.com> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> To: Jon Callas X-Mailer: Apple Mail (2.1081) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p0ILjQWG060837 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 18, 2011, at 12:48 PM, Jon Callas wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> I agree. Further I am not sure whether we should do this full >> fingerprint proposal right now or better wait for SHA-3. If we would >> settle now for a new fingerprint signature subpacket we will for sure >> need to revise that for SHA-3. We would need to maintain code for the >> current fingerprint as well as for a SHA-3 for a little eternity. > > If we combine it with a hash-independent fingerprint -- e.g., first byte is an algorithm ID, others are the actual hash -- then we can put it in now and then run with it. Rather than first byte being an algorithm ID, how about first byte being the version of the fingerprint? So, it would be "4" for the current fingerprint, "5" for whatever we come up with later, etc. If it is an algorithm ID, then we could end up with two different people encoding their fingerprints in two different ways, and have to support reading that in the clients. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IL7Ua4059515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 14:07:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IL7UWo059514; Tue, 18 Jan 2011 14:07:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IL7T4P059509 for ; Tue, 18 Jan 2011 14:07:30 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 7ABE7F987 for ; Tue, 18 Jan 2011 16:07:28 -0500 (EST) Message-ID: <4D36010A.30205@fifthhorseman.net> Date: Tue, 18 Jan 2011 16:07:22 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> In-Reply-To: <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCF8B6F2528F40A55F30BC234" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCF8B6F2528F40A55F30BC234 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/18/2011 12:48 PM, Jon Callas wrote: > If we combine it with a hash-independent fingerprint -- e.g., first byt= e is an algorithm ID, others are the actual hash -- then we can put it in= now and then run with it. Daniel Nagy suggests that we also change the material being hashed in the fingerprint (he wants to leave out the creation date). If that proposal ends up achieving consensus then your proposal here will need further modification. Does anyone feel strongly about Nagy's proposal, by the way? i'm not sure what the tradeoffs are. Even without that concern, if we encourage super-flexible use like this, user agents who wanted to use it to test for the presence of a given key in an indexed keystore would need to index their keys with every possible digest that might be used -- that seems excessive somehow. (and unlikely that keyserver implementations would want a half-dozen indexes, for that matter) Wouldn't it be better to just implement it for today's fingerprint, and then when a new fingerprint is agreed upon, determine (by subpacket length maybe?) whether it's the new fingerprint or the old one. Compliant user agents would keep the two indexes around until the v4 fingerprint goes away, and then drop the old one. Alternately, we could embed the algorithm ID as you suggest, and SHOULD people into generating them using only the consensus fingerprint algorithms so that reasonable user agents only need to create indexes over SHA1 (now) and SHA3 (whenever that happens). --dkg --------------enigCF8B6F2528F40A55F30BC234 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNNgEKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpAegP/RV5rVYaNGC7NBpHKXwUfJvG Jsrn7t8GP93gWLC9/15MKUI4eLPDr+j/eSr3zXSj/4u32O2DqgHyB3qCMhu8WQsJ 2TElUfEaAy2vZPcFZ/QGNanlHPnC6QM70LE+Vs3a/Xylkpooppee8uzS7nCWaV+u hWaqLhVxR93J5yRro2yBcY1VCZ4uZauJ7U9cBPR6FI0NaROKp9PBIvuG7x1/yiRm +buQ1EBLPMIK8VDVVtLzcEIpn9saxxrrgFJowsZ8rRwO+AOoQQ4zsmzFwblTuuKD jrZRQ2nMW7MV/punxEImHbGAd5prdVzqs6kl6i248fR4QgKeTRmFfREv7aQ4AK/P HgFYqQZt8nrqxMyPmzyCsH4t+hxo4sPafQ9B4Mjk8C9XiXE+fB0qKBnNU1vWHiF4 MMuj2cIteUN0fY2scMGA1msg/Wb5rNHqHb0C3/RuOGoMcuXZuBoaWuWWKel5/y7T lc3hhlNNW820nvvcPgTyjyZuhqtxnDMp98S5iXmIAipHbe1Fv23ym847lSMjAhkj CJwDmXBbTHcsOrduUi60sC2OAYDjpTZmCov+YMbq8kleQCvg5Qr0CBBJ8IJnqNGq Jupoql0HT2Te2g8YxwY6PTqbN73WkybFPuaCZTEWlyENwvi52wILHobTmioPc8dR QwhfvtHzjrfHkqyfG8aZ =n8nf -----END PGP SIGNATURE----- --------------enigCF8B6F2528F40A55F30BC234-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IHmbXT049974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 10:48:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IHmbjX049973; Tue, 18 Jan 2011 10:48:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IHmarF049968 for ; Tue, 18 Jan 2011 10:48:37 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 570212E11D for ; Tue, 18 Jan 2011 09:48:52 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24732-10 for ; Tue, 18 Jan 2011 09:48:49 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id D34C02E0B4 for ; Tue, 18 Jan 2011 09:48:47 -0800 (PST) Received: from [10.0.23.19] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Tue, 18 Jan 2011 09:48:31 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 18 Jan 2011 09:48:31 -0800 Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Mime-Version: 1.0 (Apple Message framework v1082) From: Jon Callas In-Reply-To: <87lj2isgm8.fsf@vigenere.g10code.de> Date: Tue, 18 Jan 2011 09:48:31 -0800 Cc: OpenPGP Working Group Message-Id: <58216C60-3DFD-4312-B514-19243ED4220A@callas.org> References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.1082) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: Maia Mailguard Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p0IHmbrF049969 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I agree. Further I am not sure whether we should do this full > fingerprint proposal right now or better wait for SHA-3. If we would > settle now for a new fingerprint signature subpacket we will for sure > need to revise that for SHA-3. We would need to maintain code for the > current fingerprint as well as for a SHA-3 for a little eternity. If we combine it with a hash-independent fingerprint -- e.g., first byte is an algorithm ID, others are the actual hash -- then we can put it in now and then run with it. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFNNdJvsTedWZOD3gYRAuSFAJ4/4MtnU/FgAJrEmvfHJdF94Lut+gCgirkD GcLhz9vEEss8t4o1uLM5qSg= =i+IA -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IF36KK042788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 08:03:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IF36jt042787; Tue, 18 Jan 2011 08:03:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IF34jb042782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 08:03:06 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (gw-comcast1.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p0IF33k1016143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Jan 2011 10:03:03 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification From: David Shaw In-Reply-To: <87lj2isgm8.fsf@vigenere.g10code.de> Date: Tue, 18 Jan 2011 10:03:02 -0500 Message-Id: References: <4D354A08.1010206@iang.org> <87lj2isgm8.fsf@vigenere.g10code.de> To: OpenPGP Working Group X-Mailer: Apple Mail (2.1081) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p0IF36ja042783 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 18, 2011, at 4:31 AM, Werner Koch wrote: > > On Tue, 18 Jan 2011 09:06, iang@iang.org said: > >> And, head towards the fingerprint, the whole fingerprint and nothing >> but the fingerprint! Dispense with all these weird and wonderful > > I agree. Further I am not sure whether we should do this full > fingerprint proposal right now or better wait for SHA-3. If we would > settle now for a new fingerprint signature subpacket we will for sure > need to revise that for SHA-3. We would need to maintain code for the > current fingerprint as well as for a SHA-3 for a little eternity. What if we made up a new subpacket that was defined as simply "the fingerprint" (that is, without specifying special encoding, or version, or what-have-you). For today, that is the full SHA-1 fingerprint we know and love. In the future, the same subpacket could be used in the V5 world as well (we'd have to have a way of telling a V4 from a future V5 fingerprint, but we need to do that anyway). This is similar to how the current "signer ID" subpacket works - it can take V3 or V4 key IDs. One of the things I wanted to push for in V5 was to use full fingerprints instead of key IDs internally. This new subpacket could be the new "signer ID" subpacket. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IA18r7028576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 03:01:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0IA183l028575; Tue, 18 Jan 2011 03:01:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IA15OW028568 for ; Tue, 18 Jan 2011 03:01:06 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by bwz14 with SMTP id 14so3163955bwz.16 for ; Tue, 18 Jan 2011 02:01:04 -0800 (PST) Received: by 10.204.45.150 with SMTP id e22mr3019021bkf.125.1295344864413; Tue, 18 Jan 2011 02:01:04 -0800 (PST) Received: from [192.168.55.151] ([213.163.35.18]) by mx.google.com with ESMTPS id b6sm2522506bkb.22.2011.01.18.02.01.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 02:01:03 -0800 (PST) Message-ID: <4D3564E4.1010203@epointsystem.org> Date: Tue, 18 Jan 2011 11:01:08 +0100 From: "Daniel A. Nagy" Organization: ePoint Systems Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Daniel Kahn Gillmor , notmuch Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D34F133.3000807@fifthhorseman.net> In-Reply-To: <4D34F133.3000807@fifthhorseman.net> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29B4C3D13C4C40618B3DA1EA" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29B4C3D13C4C40618B3DA1EA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/18/2011 02:47 AM, Daniel Kahn Gillmor wrote: > i believe collisions of the low 64 bits of SHA1 are within reach today,= > i'd love to be corrected if this is not the case I'd suggest using the entire fingerprint as a reference and leaving the creation date out of the fingerprint calculation for v5 for the following reasons: Yes, generating two keys with identical long key ID's is feasible (and not even particularly expensive on 64-bit machines with dozens of gigabytes of RAM), but generating a new key with the same 64-bit key ID as an existing key is on the very far end of the realm of feasibility. Given the dubious gains from success, I would rule out this attack as impractical. Another problem with fingerprints and key IDs is that they are generated over the key and the creation date, meaning that the same key can have different key ID's. Since the signature subpacket with the reference is not part of the hashed data, one can change both the key ID and the reference and keep the signature valid. Again, I don't know what the practical value of such an attack might be, but just like in the first case, it creates an odd situation potentially undermining the trust in the security of the system. When arguing in front of a non-expert judge, such quirks erode the claims of rock-solid evidence very badly. The key ID itself (especially the long one) is not a bad idea, however. It is a nice compromise in the middle of Zooko's triangle (almost memorable, almost globally unique and almost secure). In order to make it more useful, I'd suggest using 20-digit decimal identifiers (like credit card numbers) instead of 16-digit hexadecimal ones. Regards, --=20 Daniel --------------enig29B4C3D13C4C40618B3DA1EA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk01ZOgACgkQ28D1wCI06YWaKACffiStcNXJhiUxxNBCwpXK9Pg2 3LYAnjEnlPZ4Nxb6HrEFihVD72//UIWh =7Gg2 -----END PGP SIGNATURE----- --------------enig29B4C3D13C4C40618B3DA1EA-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I9ZCCq027045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 02:35:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I9ZC0D027044; Tue, 18 Jan 2011 02:35:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I9ZATl027039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 02:35:11 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.69 #1 (Debian)) id 1Pf7y1-0003Au-R0 for ; Tue, 18 Jan 2011 10:35:09 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.72 #1 (Debian)) id 1Pf7uB-000371-4A; Tue, 18 Jan 2011 10:31:11 +0100 From: Werner Koch To: Ian G Cc: OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D354A08.1010206@iang.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 18 Jan 2011 10:31:11 +0100 In-Reply-To: <4D354A08.1010206@iang.org> (Ian G.'s message of "Tue, 18 Jan 2011 19:06:32 +1100") Message-ID: <87lj2isgm8.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 18 Jan 2011 09:06, iang@iang.org said: > And, head towards the fingerprint, the whole fingerprint and nothing > but the fingerprint! Dispense with all these weird and wonderful I agree. Further I am not sure whether we should do this full fingerprint proposal right now or better wait for SHA-3. If we would settle now for a new fingerprint signature subpacket we will for sure need to revise that for SHA-3. We would need to maintain code for the current fingerprint as well as for a SHA-3 for a little eternity. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I86apU022786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 01:06:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I86aP9022784; Tue, 18 Jan 2011 01:06:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I86ZvC022778 for ; Tue, 18 Jan 2011 01:06:35 -0700 (MST) (envelope-from iang@iang.org) Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id 1DCB4406C2; Tue, 18 Jan 2011 08:06:32 +0000 (UTC) Message-ID: <4D354A08.1010206@iang.org> Date: Tue, 18 Jan 2011 19:06:32 +1100 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 18/01/11 5:40 PM, Jon Callas (and others) wrote (words to effect): > Still, making things better with a full fingerprint is a great idea. Nod. And, head towards the fingerprint, the whole fingerprint and nothing but the fingerprint! Dispense with all these weird and wonderful variations that just generate code, bugs, posts, arguments, wacky philosophy and silly songs like "every bit is sacred." Not that I'm dogmatic or anything :) iang Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I6eIvg019210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 23:40:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I6eIYX019209; Mon, 17 Jan 2011 23:40:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I6eHiq019202 for ; Mon, 17 Jan 2011 23:40:18 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 9206C2E0B4 for ; Mon, 17 Jan 2011 22:40:26 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16218-04 for ; Mon, 17 Jan 2011 22:40:21 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id CDE672E02C for ; Mon, 17 Jan 2011 22:40:21 -0800 (PST) Received: from [10.0.23.19] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 17 Jan 2011 22:40:07 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 17 Jan 2011 22:40:07 -0800 Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Mime-Version: 1.0 (Apple Message framework v1082) From: Jon Callas In-Reply-To: Date: Mon, 17 Jan 2011 22:40:05 -0800 Cc: OpenPGP Working Group Message-Id: References: To: Peter Gutmann X-Mailer: Apple Mail (2.1082) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: Maia Mailguard Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p0I6eIiq019204 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 17, 2011, at 6:42 PM, Peter Gutmann wrote: > > Jon Callas writes: > >> On the other hand, this has never been a problem. It's harder than you think, >> because you have to generate a new key each time, which takes a while on RSA. > > Only if you want a secure key. For SSH fuzzy fingerprinting the limiting > factor is the hashing, not the rate at which you can crank out keys, as long > as you don't mind that the keys aren't very secure. OK, they're not secure at > all, but that doesn't matter since you're going for spoofing, not a secure > signature forgery. Good point, you could generate a crap key. Nonetheless, for DSA it's just a number, and those are cheap. Still, making things better with a full fingerprint is a great idea. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFNNTXHsTedWZOD3gYRAheeAKCL1wAwD0FKBAR5JsZJQJff1x7LZQCg9MpM gfLvp5yE3cfNqbdGyZvtIgc= =Q7tP -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I4m003014930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 21:48:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I4m052014929; Mon, 17 Jan 2011 21:48:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I4lxVQ014924 for ; Mon, 17 Jan 2011 21:47:59 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 4C5F1F987 for ; Mon, 17 Jan 2011 23:47:58 -0500 (EST) Message-ID: <4D351B79.6090600@fifthhorseman.net> Date: Mon, 17 Jan 2011 23:47:53 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D34F133.3000807@fifthhorseman.net> <2885367E-D215-4BE7-983D-C82C55C64B0F@jabberwocky.com> In-Reply-To: <2885367E-D215-4BE7-983D-C82C55C64B0F@jabberwocky.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3FFC5B717EBE1F287CBCC3A5" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3FFC5B717EBE1F287CBCC3A5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/17/2011 10:22 PM, David Shaw wrote: > I like this idea. I would do it as "full fingerprint" myself. > The difference in storage between 160 bits and 96 bits is all > of 8 bytes. I think the simplicity of being able to say the > whole fingerprint is in there is worth a measly 8 bytes. That seems like a reasonable cost/benefit analysis to me. > Do we necessarily need a new subpacket type for this? It > could pretty easily be a notation. Thereby making it even longer -- how many bytes are you prepared to throw at the problem? ;) So with gpg, this is doable already with something like this in gpg.conf:= sig-notation signer-fpr@notations.openpgp.fifthhorseman.net=3D%g I dislike this aesthetically for 3 reasons: 0) the subpacket is hashed into the signature created, which doesn't seem necessary. 1) the notation value is in plain text (twice as long as it needs to be)= 2) i don't like the notation name being as long as the one i just chose = :P but maybe i'm just being a bit-miser with 1 and 2. And maybe 0 isn't all that important, either. (is there a way to tell GnuPG to make the notation subpacket in the unhashed part of the signature?) i (think i) have signed this message using the above notation name. i'd be happy to drop that notation name in favor of anything more concise from a domain with a reasonably stable track record related to this stuff= =2E If anyone on the list has difficulty verifying my signature as a result of this notation, please let me know. David, do you think a patch to interpret a notation like this would be of interest to GnuPG? Are any other OpenPGP implementations willing or interested in coming to consensus on a notation name and working on this?= And what should an implementation do if the issuer subpacket and the "full fingerprint" packet disagree on the last 64 bits? --dkg --------------enig3FFC5B717EBE1F287CBCC3A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNNRt5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp1Y8P/0zzU1PYBB+v350XFe6ZZcKM SOblUgNHCTCGIXuSwRrOEay4eZNypKzzhPRNdgK/Osw1P290VKwWlHVbrqltXBA/ wnah4mmZ/q4WLYtB8HxaC0G/n9HpxOP9ZdhlTt20kPpcxKGNmwaVwpUfFDpeWTT/ BcoQQSWWLVGFZIBaBJuJhjUPFWrN4HkJPfrSW0268srejsGu5Vox4kOUXCH0Qc8v UFj/FGkYcsoB/BAOaJGgS7DYby4hzxz0pdmZnwyceQblw3aFy4HjJuXf6NFYn9V/ +iggbZ2KHYHnVCZ+nP7FypfCmdipVZsaQoG0j896VfmLa69TQShlc3yM3gTbPeTA K4OxXTF8VFNKDaq7Hj3XSV80LEL48CqnZwTpFMPuCtWLNQIH2jmA+YlqqetU3dsq teJPFID7kOaEOxd5At35bLxRjGsNVcypz2apjeqbJ+b//+v3u/AiiQrqjTYiOdQc kqxG7UIW0NNLs4hGfKrnJKPS9nBJKu6FDaQ9+ylWOa1ngcFP76W0MEfHCIqCEphb ZoKiQz7TneZlOC2sYFBVzDl0F0A7LK55v2fjeE809L7cUAABMG7C4vyMgVB6Oggs RA2hqPGv6qzOt4eDlSSruc1x50rLBU3nVW+4s+rKHDu/c80rJwD1EwwWbX2j2N94 TBFpPiLYSiXV0ejI4kq1 =vFRY -----END PGP SIGNATURE----- --------------enig3FFC5B717EBE1F287CBCC3A5-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I3N1Al012325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 20:23:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I3N16D012324; Mon, 17 Jan 2011 20:23:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I3N00N012319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 20:23:01 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p0I3MvV1011930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jan 2011 22:22:58 -0500 Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David Shaw In-Reply-To: <4D34F133.3000807@fifthhorseman.net> Date: Mon, 17 Jan 2011 22:22:57 -0500 Cc: notmuch Message-Id: <2885367E-D215-4BE7-983D-C82C55C64B0F@jabberwocky.com> References: <4D34F133.3000807@fifthhorseman.net> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p0I3N10M012320 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 17, 2011, at 8:47 PM, Daniel Kahn Gillmor wrote: > Would there be any objection to a new subpacket type for OpenPGPv4 that > would include the remaining 96 bits of the issuer's fingerprint? (the > "high 96" proposal) > > Alternately, what about a new subpacket type that simply includes the > entire 160 bits of the issuer's fingerprint? (the "full fingerprint" > proposal) I like this idea. I would do it as "full fingerprint" myself. The difference in storage between 160 bits and 96 bits is all of 8 bytes. I think the simplicity of being able to say the whole fingerprint is in there is worth a measly 8 bytes. Do we necessarily need a new subpacket type for this? It could pretty easily be a notation. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I2p4iZ011232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 19:51:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I2p4bG011231; Mon, 17 Jan 2011 19:51:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I2p3ka011226 for ; Mon, 17 Jan 2011 19:51:04 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 947A7F987 for ; Mon, 17 Jan 2011 21:51:02 -0500 (EST) Message-ID: <4D350011.6030209@fifthhorseman.net> Date: Mon, 17 Jan 2011 21:50:57 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification References: <4D34F133.3000807@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF26F83C79B06F8C27FB9D0D0" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF26F83C79B06F8C27FB9D0D0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/17/2011 09:14 PM, Jon Callas wrote: > On the one hand, my only disagreement with you is to suggest that > your proposal be tied into using SHA256 for a fingerprint. > If you're going to expand the keyid to a fingerprint, why not > get a better fingerprint? hrm, interesting. > On the other hand, this has never been a problem. It's harder than > you think, because you have to generate a new key each > time, which takes a while on RSA. It's not as hard as all that, though, because an attacker trying to force a collision of the low 64 bits doesn't need to care about two thing= s: (a) the key creation time doesn't need to correct. This gives them 32 bits to play with (or ~30 if they want to avoid timestamps in the future) for brute force against a single generated RSA key. (b) for a non-cross-signed subkey, the RSA modulus itself doesn't need to correspond to an actual secret key, since it doesn't need to make any signatures. So an attacker could flip arbitrary bits within the modulus during a search for 64-bit collisions. > Nonetheless, I think it's a good idea. I'd just go all the way to a bet= ter fingerprint. That would sound reasonable if a consensus already existed on an improved fingerprint, and if existing tools already used an internal index with that fingerprint. But the closest thing to consensus about a new fingerprint that i've heard from this list is "wait for the outcome of the SHA-3 NIST process", and i'd like to get something real-world tools can produce before then. (there seemed to be some disagreement on this list about whether the material being digested for the fingerprint would itself change, too). So maybe: go with the "high 96" proposal for now, and when a consensus forms for an alternate fingerprint format, introduce a new subpacket type that uses that fingerprint. Other thoughts? --dkg --------------enigF26F83C79B06F8C27FB9D0D0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJNNQARAAoJEMzS7ZTSFznpwH4P/1JnhLVIspjx0rmb1vhlyz2y fMvNGl1CRpI3+WhMQIq6waNRZhucTWMofxoAMFcMhm7QAQXmIM+FiZYVf2nTUic+ kwxfl5Ddfln+b1D535vzb4FG0scqxbXrPJMn8wWdLKmjHB2btjIUD9NVC6ISDEa9 gY9xKwZWjDNi4qyc2UX6ZrgGFd40wRpsxI+hd2u/xRlDeJWdmlVxolMDeb/tgmhp 4ljIMEBhQxmL1V0P39zVy4TZKZl4Kt+Cqsd7yJWL8qbe/4kIoG7+PfudOltxaTXS efO4nWD0qLihIawjJVziNI6exorRNWW5msMkklmc5ORNCrJw1sQHAjaRr1VAFbrT D2Rx3vZhoK4VgrSqHdff0xWh+KuuNBudcYO1D0k5E9H0Ks8dqqyTEKCIlBMVaqEy lH/+as4lCL/BsnTbZVDDXaL5BPk2A31CgjCDD7Ie0pTGlWwgjfuNb4cusLPYD+lb frtpA6iqPq2oGP6ra1bSUYysJGIiEokHQfIkRk3HZkFbmkZQkStXW7BveLFpc3/d Ekn/XnANGO9CoVYa5oGmUyToNgC0b2NZaNHdv7pxbEYL1BRSFWeU0tPJs1daRXga 6DBFIILxNzFkM0jr+ZVDyCYC9uEzr6vYiwJj9q9ajX5H3fnGarCdGo484KeHSpXd bLU5/DiViDdBf49llGZ8 =mz9A -----END PGP SIGNATURE----- --------------enigF26F83C79B06F8C27FB9D0D0-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I2gCIF010991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 19:42:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I2gBvS010990; Mon, 17 Jan 2011 19:42:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I2g7mN010985 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 17 Jan 2011 19:42:11 -0700 (MST) (envelope-from pgut001@login01.fos.auckland.ac.nz) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1295318531; x=1326854531; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ietf-openpgp@imc.org,=20jon@callas.org|Subject:=20 Re:=20including=20the=20entire=20fingerprint=20of=20the =20issuer=20in=20an=20OpenPGP=20certification|Cc:=20notmu ch@notmuchmail.org|In-Reply-To:=20|Message-Id:=20|Date:=20Tue,=2018=20Jan=20 2011=2015:42:06=20+1300; bh=3DMPLArlr7HcMTiIHRGvceJOoZFivevah/uYaAEDYOA=; b=A/nK60EhT3z+k+VWFUpTShN+zieWm8EqIvb5e/+6aHwYK+WO63W+PihW GzFRCKuHc234cXJfHImVqlynzZkRHM8RwPMOjv4mRwRCf958PglyZCvNr vEeVzcKk/8UA5OOCnsX7rC8tE+Wv49+Vf4FyfHZMTNG5yWRAR17hOBNzW 8=; X-IronPort-AV: E=Sophos;i="4.60,336,1291546800"; d="scan'208";a="42689730" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Jan 2011 15:42:06 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Pf1WI-000611-Hh; Tue, 18 Jan 2011 15:42:06 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Pf1WI-0007aL-EN; Tue, 18 Jan 2011 15:42:06 +1300 From: Peter Gutmann To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Cc: notmuch@notmuchmail.org In-Reply-To: Message-Id: Date: Tue, 18 Jan 2011 15:42:06 +1300 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: >On the other hand, this has never been a problem. It's harder than you think, >because you have to generate a new key each time, which takes a while on RSA. Only if you want a secure key. For SSH fuzzy fingerprinting the limiting factor is the hashing, not the rate at which you can crank out keys, as long as you don't mind that the keys aren't very secure. OK, they're not secure at all, but that doesn't matter since you're going for spoofing, not a secure signature forgery. Peter. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I2EeQn009869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 19:14:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I2EejN009868; Mon, 17 Jan 2011 19:14:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I2EdUQ009863 for ; Mon, 17 Jan 2011 19:14:39 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 081EF2E0B4 for ; Mon, 17 Jan 2011 18:14:53 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12947-09 for ; Mon, 17 Jan 2011 18:14:48 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 30FA82E02C for ; Mon, 17 Jan 2011 18:14:48 -0800 (PST) Received: from [10.0.23.19] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Mon, 17 Jan 2011 18:14:34 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 17 Jan 2011 18:14:34 -0800 Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification Mime-Version: 1.0 (Apple Message framework v1082) From: Jon Callas In-Reply-To: <4D34F133.3000807@fifthhorseman.net> Date: Mon, 17 Jan 2011 18:14:31 -0800 Cc: notmuch Message-Id: References: <4D34F133.3000807@fifthhorseman.net> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1082) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: Maia Mailguard Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p0I2EdUQ009864 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the one hand, my only disagreement with you is to suggest that your proposal be tied into using SHA256 for a fingerprint. If you're going to expand the keyid to a fingerprint, why not get a better fingerprint? On the other hand, this has never been a problem. It's harder than you think, because you have to generate a new key each time, which takes a while on RSA. Nonetheless, I think it's a good idea. I'd just go all the way to a better fingerprint. Jon On Jan 17, 2011, at 5:47 PM, Daniel Kahn Gillmor wrote: > * PGP Signed by an unknown key > > Hi OpenPGP folks (and Cc'ed notmuch developers/users)-- > > Some recent discussion about verifying OpenPGP signatures for the > notmuch mail user agent got me thinking about different ways one might > interpret a negative result from a signature made over a message. > > Most OpenPGP signatures i've seen use the (unhashed) issuer subpacket to > refer to the low 64 bits of the fingerprint of the issuer's key (the > issuer's "key ID"): > > https://tools.ietf.org/html/rfc4880#section-5.2.3.5 > > Given that we can't assume that key IDs are unique with any high degree > of confidence, this creates some ambiguity between these states: > > A) "you don't have the key that made this signature" > > B) "this signature is bad" > > a user-friendly MUA that thinks it is in state A might do something > sensible like offer to do a keyserver lookup (if it is online), while > simply reporting "signature error" if it thinks it is in state B. > > But a devious attacker could potentially create a colliding Key ID (i > believe collisions of the low 64 bits of SHA1 are within reach today, > i'd love to be corrected if this is not the case) and cause the > user-friendly MUA to assume it is in state B when it is actually in > state A. The attacker doesn't even need access to the message or > signature in question to do this. They'd only need to have been able to > supply a key to the user at some time in the past. (e.g. push a new > subkey to the keyservers which a user pulls during a keyring refresh) > > One way around this ambiguity would be to include the issuer's entire > fingerprint instead of just the low 64 bits, which would make the > certainty of state A vs. state B much clearer. > > Would there be any objection to a new subpacket type for OpenPGPv4 that > would include the remaining 96 bits of the issuer's fingerprint? (the > "high 96" proposal) > > Alternately, what about a new subpacket type that simply includes the > entire 160 bits of the issuer's fingerprint? (the "full fingerprint" > proposal) > > A third proposal would be a new subpacket type that simply includes the > entire public key of the issuer (the "full pubkey" proposal). > > I lean toward "high 96", since using it in conjunction with the issuer > subpacket retains backward compatibility with existing tools (which know > how to interpret the issuer subpacket) while introducing the smallest > amount of additional data per signature. > > Given that the size of a signature from a 2048-bit RSA key is 256 bytes > already, adding an additional 12 bytes (plus a few bytes of subpacket > overhead) per signature doesn't seem particularly excessive. > > I'm also assuming that the typical use of this subpacket would be in the > unhashed section of a signature packet, since it is an advisory field > and not intended to address attacks against an adversary capable of > tampering directly with the data in the signature itself. > > I will write code to implement this using an experimental subpacket ID, > but i'd like to know if anyone has any caveats, concerns, or preferences > between the proposals i've outlined above (or entirely different > proposals that would address the underlying concern). > > Any thoughts? > > Regards, > > --dkg > > > * Unknown Key > * 0xD21739E9 -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFNNPeJsTedWZOD3gYRAm4YAJ4nuTf1aPoh4xoUGsH9c7PgDqSiyACguVMs Ht6Zmyj72mx7JzoKHFrX6PY= =XIxu -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I1lilB008784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 18:47:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p0I1liLW008783; Mon, 17 Jan 2011 18:47:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0I1lf0R008756 for ; Mon, 17 Jan 2011 18:47:42 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id CBC87F987; Mon, 17 Jan 2011 20:47:39 -0500 (EST) Message-ID: <4D34F133.3000807@fifthhorseman.net> Date: Mon, 17 Jan 2011 20:47:31 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: notmuch Subject: including the entire fingerprint of the issuer in an OpenPGP certification X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFBFACFA426B5BF54C7C24A9A" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFBFACFA426B5BF54C7C24A9A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi OpenPGP folks (and Cc'ed notmuch developers/users)-- Some recent discussion about verifying OpenPGP signatures for the notmuch mail user agent got me thinking about different ways one might interpret a negative result from a signature made over a message. Most OpenPGP signatures i've seen use the (unhashed) issuer subpacket to refer to the low 64 bits of the fingerprint of the issuer's key (the issuer's "key ID"): https://tools.ietf.org/html/rfc4880#section-5.2.3.5 Given that we can't assume that key IDs are unique with any high degree of confidence, this creates some ambiguity between these states: A) "you don't have the key that made this signature" B) "this signature is bad" a user-friendly MUA that thinks it is in state A might do something sensible like offer to do a keyserver lookup (if it is online), while simply reporting "signature error" if it thinks it is in state B. But a devious attacker could potentially create a colliding Key ID (i believe collisions of the low 64 bits of SHA1 are within reach today, i'd love to be corrected if this is not the case) and cause the user-friendly MUA to assume it is in state B when it is actually in state A. The attacker doesn't even need access to the message or signature in question to do this. They'd only need to have been able to supply a key to the user at some time in the past. (e.g. push a new subkey to the keyservers which a user pulls during a keyring refresh) One way around this ambiguity would be to include the issuer's entire fingerprint instead of just the low 64 bits, which would make the certainty of state A vs. state B much clearer. Would there be any objection to a new subpacket type for OpenPGPv4 that would include the remaining 96 bits of the issuer's fingerprint? (the "high 96" proposal) Alternately, what about a new subpacket type that simply includes the entire 160 bits of the issuer's fingerprint? (the "full fingerprint" proposal) A third proposal would be a new subpacket type that simply includes the entire public key of the issuer (the "full pubkey" proposal). I lean toward "high 96", since using it in conjunction with the issuer subpacket retains backward compatibility with existing tools (which know how to interpret the issuer subpacket) while introducing the smallest amount of additional data per signature. Given that the size of a signature from a 2048-bit RSA key is 256 bytes already, adding an additional 12 bytes (plus a few bytes of subpacket overhead) per signature doesn't seem particularly excessive. I'm also assuming that the typical use of this subpacket would be in the unhashed section of a signature packet, since it is an advisory field and not intended to address attacks against an adversary capable of tampering directly with the data in the signature itself. I will write code to implement this using an experimental subpacket ID, but i'd like to know if anyone has any caveats, concerns, or preferences between the proposals i've outlined above (or entirely different proposals that would address the underlying concern). Any thoughts? Regards, --dkg --------------enigFBFACFA426B5BF54C7C24A9A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJNNPEzAAoJEMzS7ZTSFznpto0P/2cuF3qAuFZQru7IABrZiYvx r7W45B1wY+wlniVtgPqlviDuxY6AOIaubIMU+Tkp+805C8XfvZVLNRExlOAxF/K9 paoNHkX18dys2HVK9EHosS71c866iK+cK736U9XUIKvI9w5pTFXPevFLnCDTbuge ZWVG6LCJ22UqIDsRpMSlO6NmR7w0+0DBwfNS56K6FwXZxWUc9VgPq7O7H3B0/S1K qFUktRg4W6Rs0jZbiIVVNa9n6YJFfQnjZC0Nl1suJmJECm0zx3KJGu0CUeegqnmj 15G7TytUv1EELxlHMjMXRjBs3MLuSytL1aPu8v+Fbg1NyRuNdZWDqCoxCedXzJJ+ 7x9Ztbk/XcQllXGQTnrJcicmVjDapp2wGge2YYwdzVLzxcNdEaO+vBYDewx2/QCN 4xIWtghVACDaImFgvX5KnbFkYlyHIudlLSEdFqmXS70U1R50JS6MtePTQEFxohAB j3MaDUSrMcp7oKRBg/0HPHw4n0iKnTpG40XeKodSM52KU+RPvjtJQPb/gP/alBmb nwp1bqpBzIaboXYnmA1AhFZg9sILj930OJN97A1Ipu5ucSvvLjeSn/ndZgLDFXcm 64Xq+Bdxvyfv7B+rveqQCiaZgYKBvDGM/p4MlRyCUAx7VZHbbvOY3PL0L3ikbK1F 77U94cUaFjqGgW0N9k8p =zeOX -----END PGP SIGNATURE----- --------------enigFBFACFA426B5BF54C7C24A9A--