Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Ian G <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: IETF OpenPGP Working Group <[email-masked]>
Date: Fri, 21 Jan 2011 21:52:54 +1100
List-Id: <ietf-openpgp.imc.org>

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

Reply-To: [email-masked]
Date: Thu, 20 Jan 2011 23:19:16 -0500
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Avi <[email-masked]>
To: Peter Pentchev <[email-masked]>, Jon Callas <[email-masked]>, IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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 <[email-masked]> 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	[email-masked] [email-masked] [email-masked]
> 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) <[email-masked]>
   Primary key fingerprint: 167C 063F 7981 A1F6 71EC  ABAA 0D62 B019 F80E 29F9

Date: Fri, 21 Jan 2011 00:51:14 +0200
From: Peter Pentchev <[email-masked]>
To: Avi <[email-masked]>
Cc: Jon Callas <[email-masked]>, IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

--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	[email-masked] [email-masked] [email-masked]
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

--X1bOJ3K7DJ5YkBrT--

Reply-To: [email-masked]
From: Avi <[email-masked]>
Date: Thu, 20 Jan 2011 11:36:32 -0500
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
To: Jon Callas <[email-masked]>
Cc: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

--0015174c3ffe433b5c049a49be94
Content-Type: text/plain; charset=ISO-8859-1

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

----
User:Avraham

pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) <[email-masked]
>
   Primary key fingerprint: 167C 063F 7981 A1F6 71EC  ABAA 0D62 B019 F80E
29F9

On Thu, Jan 20, 2011 at 11:00 AM, Jon Callas <[email-masked]> 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-----<br>Hash: SHA512<br><br>Even more strongl=
y, there is the difference between &quot;almost<br>never&quot; and &quot;ne=
ver&quot;. Even if there were an infinite number of key<br>id&#39;s along t=
he real number continuum, the possibility of a<br>

collision is mathematically 0%, but it is still possible. Heck,<br>the poss=
ibility of ANY id would be mathematically 0, but each<br>key would still ha=
ve an ID.<br><br>Here, we are dealing with a discrete distribution, so ther=
e<br>

/are/ mass points (be they VERY very small) at each ID, so yes,<br>it is 10=
0% certain that eventually, not only will there be a<br>collision, but ever=
y key will have a collision. It may be<br>though, that the waiting time may=
 be longer than the heat death<br>

of the universe for the latter, so we don&#39;t have to worry about<br>that=
 too much :).<br><br>- --Avi<br>-----BEGIN PGP SIGNATURE-----<br>Version: G=
nuPG v1.4.11 (MingW32) - GPGshell v3.77<br>Comment: Most recent key: Click =
show in box @ <a href=3D"http://is.gd/4xJrs">http://is.gd/4xJrs</a><br>

<br>iJgEAREKAEAFAk04ZIU5GGh0dHA6Ly9wZ3AubmljLmFkLmpwL3Brcy9sb29rdXA/<br>b3A=
9Z2V0JnNlYXJjaD0weEY4MEUyOUY5AAoJEA1isBn4Din525cA/R7idYB5pitE<br>chXetB0o7K=
vp1/DEmyv/sCG/dkt4dMlLAP9QtALK5BngB+pMWCt1bxA3wTcRH33J<br>MO6qv7HAGBTNpQ=3D=
=3D<br>

=3DhQBO<br>-----END PGP SIGNATURE-----<br><br><br clear=3D"all">----<br>Use=
r:Avraham<br><br>pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) &=
lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>=A0=
=A0 Primary key fingerprint: 167C 063F 7981 A1F6 71EC=A0 ABAA 0D62 B019 F80=
E 29F9<br>

<br><br><div class=3D"gmail_quote">On Thu, Jan 20, 2011 at 11:00 AM, Jon Ca=
llas <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex;">

<div class=3D"im"><br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>A side-effect of this is something that&#39;s either an obvious exten=
sion or in the spec already.<br>
<br>
Section 3.3 says: &quot;Implementations SHOULD NOT assume that Key IDs are =
unique.&quot;<br>
<br>
It&#39;s said that since 2440, for the following reason...<br>
<br>
In PGP1 days, Vinnie started working there and told me that he&#39;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&#39;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&#39;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&#39;t assume uniqueness.<br>

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

<br>
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.=
<br>
<br>
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.<br>

<br>
Yeah, I know it&#39;s easier said than done, but that doesn&#39;t make it f=
alse.<br>
<br>
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.<br>

<div class=3D"im"><br>
 =A0 =A0 =A0 =A0Jon<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: PGP Universal 2.10.0 (Build 554)<br>
Charset: us-ascii<br>
<br>
</div>wj8DBQFNOFwGsTedWZOD3gYRAtyVAJ40VCHrrUkG2Dc+Bi7fKQA5VZlCeQCfRQVc<br>
Xs4TmguHftMh9uE/+b5Lqfw=3D<br>
=3DB98X<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br>

--0015174c3ffe433b5c049a49be94--

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Jon Callas <[email-masked]>
Date: Thu, 20 Jan 2011 08:00:04 -0800
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Jon Callas <[email-masked]>
Date: Thu, 20 Jan 2011 07:48:10 -0800
Cc: Jon Callas <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

> 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

Date: Thu, 20 Jan 2011 21:21:51 +1100
From: Ian G <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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.

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <[email-masked]>
Date: Wed, 19 Jan 2011 23:45:20 -0500
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 19 Jan 2011 12:37:11 +0100
From: "Daniel A. Nagy" <[email-masked]>
To: [email-masked]
CC: Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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" <[email-masked]> 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"

--------------enigC211D4E67E0F54FC72F02F16--

From: Werner Koch <[email-masked]>
To: David Shaw <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 19 Jan 2011 09:00:37 +0100
Sender: [email-masked]

On Tue, 18 Jan 2011 22:45, [email-masked] 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.

Date: Wed, 19 Jan 2011 01:14:02 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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"

--------------enigE97A4F6D31F833C305E17C3F--

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Cc: [email-masked], [email-masked]
Date: Wed, 19 Jan 2011 13:11:43 +1300
Sender: [email-masked]

"Daniel A. Nagy" <[email-masked]> 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.

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <[email-masked]>
Date: Tue, 18 Jan 2011 18:23:54 -0500
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <[email-masked]>
Date: Tue, 18 Jan 2011 17:43:01 -0500
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 18 Jan 2011 17:35:17 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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"

--------------enigD6BE80802367B5C059290AE7--

Date: Tue, 18 Jan 2011 17:18:41 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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 [email-masked] for the
current fingerprint and then name a new notation
[email-masked] 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"

--------------enig83637B46A964E7359DF2744A--

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <[email-masked]>
Date: Tue, 18 Jan 2011 17:05:55 -0500
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 18 Jan 2011 23:03:50 +0100
From: "Daniel A. Nagy" <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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"

--------------enig5089CC478F8BBF2264BA3852--

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <[email-masked]>
Date: Tue, 18 Jan 2011 16:45:14 -0500
Cc: Werner Koch <[email-masked]>, OpenPGP Working Group <[email-masked]>
To: Jon Callas <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 18 Jan 2011 16:07:22 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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"

--------------enigCF8B6F2528F40A55F30BC234--

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Jon Callas <[email-masked]>
Date: Tue, 18 Jan 2011 09:48:31 -0800
Cc: OpenPGP Working Group <[email-masked]>
To: Werner Koch <[email-masked]>
Sender: [email-masked]

> 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

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <[email-masked]>
Date: Tue, 18 Jan 2011 10:03:02 -0500
To: OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

On Jan 18, 2011, at 4:31 AM, Werner Koch wrote:

> 
> On Tue, 18 Jan 2011 09:06, [email-masked] 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

Date: Tue, 18 Jan 2011 11:01:08 +0100
From: "Daniel A. Nagy" <[email-masked]>
Organization: ePoint Systems Ltd.
To: IETF OpenPGP Working Group <[email-masked]>
CC: Daniel Kahn Gillmor <[email-masked]>, notmuch <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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"

--------------enig29B4C3D13C4C40618B3DA1EA--

From: Werner Koch <[email-masked]>
To: Ian G <[email-masked]>
Cc: OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 18 Jan 2011 10:31:11 +0100
Sender: [email-masked]

On Tue, 18 Jan 2011 09:06, [email-masked] 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.

Date: Tue, 18 Jan 2011 19:06:32 +1100
From: Ian G <[email-masked]>
To: OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Jon Callas <[email-masked]>
Date: Mon, 17 Jan 2011 22:40:05 -0800
Cc: OpenPGP Working Group <[email-masked]>
To: Peter Gutmann <[email-masked]>
Sender: [email-masked]

On Jan 17, 2011, at 6:42 PM, Peter Gutmann wrote:

> 
> Jon Callas <[email-masked]> 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

Date: Mon, 17 Jan 2011 23:47:53 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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 [email-masked]=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"

--------------enig3FFC5B717EBE1F287CBCC3A5--

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: David Shaw <[email-masked]>
Date: Mon, 17 Jan 2011 22:22:57 -0500
Cc: notmuch <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 17 Jan 2011 21:50:57 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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"

--------------enigF26F83C79B06F8C27FB9D0D0--

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
Cc: [email-masked]
Date: Tue, 18 Jan 2011 15:42:06 +1300
Sender: [email-masked]

Jon Callas <[email-masked]> 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.

Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
From: Jon Callas <[email-masked]>
Date: Mon, 17 Jan 2011 18:14:31 -0800
Cc: notmuch <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 17 Jan 2011 20:47:31 -0500
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
CC: notmuch <[email-masked]>
Subject: including the entire fingerprint of the issuer in an OpenPGP certification
Sender: [email-masked]

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"

--------------enigFBFACFA426B5BF54C7C24A9A--