Subject: Elgamal Signatures?

From: Ben Laurie <[email-masked]>
Date: Wed, 25 May 2005 12:26:53 +0100

I realise they're deprecated, but I still need to know the format. Where
can I find it? Should it be in the RFC?

The problem being, of course, that things exist out there that use them.

Cheers,

Ben.

---

From: David Shaw <[email-masked]>
Date: Fri, 27 May 2005 16:31:01 -0400

> The problem being, of course, that things exist out there that use them.

I don't think it should be in the RFC.  The new RFC does not permit
Elgamal signatures, so putting it in there serves little purpose.
2440 will continue to exist once the new RFC is out, so anyone looking
for 2440-specific formats can look there.

David

---

From: Ben Laurie <[email-masked]>
Date: Sat, 28 May 2005 21:48:35 +0100

> for 2440-specific formats can look there.

They aren't in 2440 either. Or I missed something.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: David Shaw <[email-masked]>
Date: Tue, 31 May 2005 14:22:02 -0400

> They aren't in 2440 either. Or I missed something.

Indeed, much to my surprise, they're not in 2440.  I thought I had
seen them in there.

To me this is another reason to not put them in the new RFC.  They
were underspecified in 2440, and they're verboten in 2440bis.
Specifying something that is not permitted now, and was not fully
specified in the past seems odd to me.

The format that GnuPG used (past tense) is similar to RSA in the PKCS
encoding.  If you look at the sign() function in
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/*checkout*/gnupg/cipher/elgamal.c?content-type=text%2Fplain&rev=1.35
you can see exactly what is done.  MPI a and b in that function are
the two MPIs that wind up in the Elgamal signature packet.

David

Date: Tue, 31 May 2005 14:22:02 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Elgamal Signatures?
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

> They aren't in 2440 either. Or I missed something.

Indeed, much to my surprise, they're not in 2440.  I thought I had
seen them in there.

To me this is another reason to not put them in the new RFC.  They
were underspecified in 2440, and they're verboten in 2440bis.
Specifying something that is not permitted now, and was not fully
specified in the past seems odd to me.

The format that GnuPG used (past tense) is similar to RSA in the PKCS
encoding.  If you look at the sign() function in
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/*checkout*/gnupg/cipher/elgamal.c?content-type=text%2Fplain&rev=1.35
you can see exactly what is done.  MPI a and b in that function are
the two MPIs that wind up in the Elgamal signature packet.

David

To: [email-masked]
Subject: Re: Stupid hash question?
Date: Tue, 31 May 2005 09:11:05 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Ben Laurie writes:
> This is true, as I said elsewhere - but the I-D does not refer to the
> place where you are told this.

Yes, perhaps section 8.1 of RFC 2437 would be a better place to link to.
Although that describes more than just padding...

> As an incidental cryptographic query - it seems to me that merely not
> having the top bit set should be sufficient to ensure that the MSB is
> not too large, so it isn't clear to me (given that the first byte is 1)
> why an extra byte of padding is deemed necessary. Did I miss something?

If the modulus started off 0x01 0x00... then padding as 0x01 0xFF...
would not be guaranteed to be smaller than the modulus.

Also, there are two padding versions, one with a type of 0x01 for
signatures, and one with a type of 0x02 for encryption, and the 0x02
version would be even more problematic if the 2 were put into the MSByte.
Making an MSB of zero solves both problems.

They could have done it bit-oriented and pushed the 1/2 type information
a few bits further to the left, but byte-oriented padding is generally
simpler to implement.

Hal

To: [email-masked], [email-masked], [email-masked]
Subject: Re: Problems with calculating signatures over keys
Date: Tue, 31 May 2005 08:51:13 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

I sent Kimmo private mail from on the road showing a problem:

> Thanks for the clarification, but I still can't get the right resuts. I 
> tried to calculate like this:
>
> SHA1(0x99 (public key tag)+ 0x01 + 0xA2 (key length) + Key packet (418 
> bytes) + 0xB4 (user id tag) + 0x00 + 0x00 + 0x00 + 0x28 (user id length) + 
> User Id packet (40 bytes) + 0x04 + 0x13 + 0x11 + 0x02 + 0x00 + 0x1E + 0x05 + 
> 0x02 + 0x42 + 0x95 + 0x6E + 0xD1 + 0x02 + 0x1B + 0x03 + 0x06 + 0x0B + 0x09 + 
> 0x08 + 0x07 + 0x03 + 0x02 + 0x03 + 0x15 + 0x02 + 0x03 + 0x03 + 0x16 + 0x02 + 
> 0x01 + 0x02 + 0x1E + 0x01 + 0x02 + 0x17 + 0x80 + Trailer: 0x04 + 0xFF + 0x24 
> (big endian length of hashed data from the sign. packet) + 0x00 + 0x00 + 
> 0x00)

The last four bytes should be 00 00 00 24 not 24 00 00 00.  It is supposed
to be the length of hashed data from the signature packet, which is hex
24, in four octet big-endian form.  He sent back that this fixed the
problem.

I do like the idea of an "implementation examples" document but I am not
sure I am the right person to do it, due to time demands.  I'll talk to
the management at work and see if this is something that I or someone
else could get some time to prepare in the next few weeks or months.

Hal Finney

To: "Konrad Rosenbaum" <[email-masked]>
Cc: "Ben Laurie" <[email-masked]>, [email-masked]
Subject: Re: Stupid hash question?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 31 May 2005 14:50:55 +0200
Sender: [email-masked]

On Tue, 31 May 2005 10:52:03 +0200 (CEST), Konrad Rosenbaum said:

> However, these signatures are not worth anything, since they leak the key
> and are easily forgable after the first signature. So bothering with

That is not correct.  They leak the key only when used with broken
software or when the key has been created with such software.  Certain
versions of GnuPG (1.0.2 - 1.3.3) were broken and thus one should
better assume that the key has been broken. See
http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000160.html for
details.

Salam-Shalom,

   Werner

From: Ian G <[email-masked]>
To: "Konrad Rosenbaum" <[email-masked]>
Subject: Re: Stupid hash question?
Date: Tue, 31 May 2005 13:24:50 +0100
Cc: "Ben Laurie" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tuesday 31 May 2005 09:52, Konrad Rosenbaum wrote:
> Ben Laurie said:
> > As I have previously stated, my keyring contains Elgamal signatures. I'm
> > sure I'm not alone in this. I want to be able to check them. I think its
> > fine to deprecate them, but refusing to describe them is just annoying.
>
> As far as I recall it is PKCS#1-v1.5 - just like RSA.
>
> However, these signatures are not worth anything, since they leak the key
> and are easily forgable after the first signature. So bothering with
> verifying them is nonsense in my opinion. Cryptographically an Elgamal
> signature on something tells you as much about that something as a coffee
> stain on a printout of it.

If they are as dangerous as you say - "leak the key" and "forgeable" -
then perhaps they should be more than deprecated, they should be
marked as "SHOULD NOT be verified and should be marked in some
negative fashion to indicate broken tech to the user" ?

Just because something exists is not a sufficient argument for including
it in the ID.  If we are of the opinion that something should not be
done and not be promulgated then leaving it out and marking the
allocated numbers as "reserved" should be sufficient.  A standard is
a document describing what we want people to do, not what we want
people not to do.

iang
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

To: Jon Callas <[email-masked]>
Cc: Ben Laurie <[email-masked]>, Konrad Rosenbaum <[email-masked]>, [email-masked]
Subject: Re: Stupid hash question?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 31 May 2005 13:36:33 +0200
Sender: [email-masked]

On Tue, 31 May 2005 03:07:28 -0700, Jon Callas said:

> I believe Konrad Rosenbaum is correct, that it's a PKCS1/1.5
> content. The GnuPG guys would be best to comment, as they're the only
> ones who ever implemented them.

Frankly, I don't know this anymore because we have removed all Elgamal
signature code from GnuPG.  Old versions are still available and it
should be easy to figure out the format.

Shalom-Salam,

   Werner

Cc: Konrad Rosenbaum <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Stupid hash question?
Date: Tue, 31 May 2005 03:07:28 -0700
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 31 May 2005, at 2:16 AM, Ben Laurie wrote:

>
> This is a reason to deprecate them, not a reason not to describe them.
>
>

They're more than deprecated, they're disallowed. All of the keys have 
been declared invalid. The documents don't say you MUST or even SHOULD 
consider them all broken, but no one would bat an eyelash if you did.

Nonetheless, if you wanted to look inside one anyway, a lawyerly 
reading of the document doesn't disallow it.

I believe Konrad Rosenbaum is correct, that it's a PKCS1/1.5 content. 
The GnuPG guys would be best to comment, as they're the only ones who 
ever implemented them.

	Jon

Date: Tue, 31 May 2005 10:16:31 +0100
From: Ben Laurie <[email-masked]>
To: Konrad Rosenbaum <[email-masked]>
Cc: [email-masked]
Subject: Re: Stupid hash question?
Sender: [email-masked]

Konrad Rosenbaum wrote:
> Ben Laurie said:
> 
>>As I have previously stated, my keyring contains Elgamal signatures. I'm
>>sure I'm not alone in this. I want to be able to check them. I think its
>>fine to deprecate them, but refusing to describe them is just annoying.
> 
> 
> As far as I recall it is PKCS#1-v1.5 - just like RSA.
> 
> However, these signatures are not worth anything, since they leak the key
> and are easily forgable after the first signature. So bothering with
> verifying them is nonsense in my opinion. Cryptographically an Elgamal
> signature on something tells you as much about that something as a coffee
> stain on a printout of it.

This is a reason to deprecate them, not a reason not to describe them.

Date: Tue, 31 May 2005 10:52:03 +0200 (CEST)
Subject: Re: Stupid hash question?
From: "Konrad Rosenbaum" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: [email-masked]
Importance: Normal
Sender: [email-masked]

Ben Laurie said:
> As I have previously stated, my keyring contains Elgamal signatures. I'm
> sure I'm not alone in this. I want to be able to check them. I think its
> fine to deprecate them, but refusing to describe them is just annoying.

As far as I recall it is PKCS#1-v1.5 - just like RSA.

However, these signatures are not worth anything, since they leak the key
and are easily forgable after the first signature. So bothering with
verifying them is nonsense in my opinion. Cryptographically an Elgamal
signature on something tells you as much about that something as a coffee
stain on a printout of it.

    Konrad

Date: Tue, 31 May 2005 09:00:50 +0100
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Stupid hash question?
Sender: [email-masked]

Hal Finney wrote:
> Ben Laurie writes:
> 
>>I've been working on signatures recently, and I'm puzzled. As I
>>understand it, the form of a decrypted signature is:
>>
>>01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>>
>>However, every signature I look at decrypts to:
>>
>>00 01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>>
>>Before I hurt my head trying to figure out why, I wonder if there's
>>something obvious I missed?
> 
> 
> 
> Actually if you look at PKCS-1 v1.5 you will find that in fact the
> MSB is a 0 and the next byte is a 1 for signatures, a 2 for encryption.
> Generally the MSB may not be a whole octet, depending on the size of
> the modulus, so they put a zero there.

This is true, as I said elsewhere - but the I-D does not refer to the
place where you are told this.

As an incidental cryptographic query - it seems to me that merely not
having the top bit set should be sufficient to ensure that the MSB is
not too large, so it isn't clear to me (given that the first byte is 1)
why an extra byte of padding is deemed necessary. Did I miss something?

Cheers,

Ben.

Date: Tue, 31 May 2005 08:54:03 +0100
From: Ben Laurie <[email-masked]>
To: Konrad Rosenbaum <[email-masked]>
Cc: [email-masked]
Subject: Re: Stupid hash question?
Sender: [email-masked]

Konrad Rosenbaum wrote:
> On Monday 30 May 2005 16:36, Ben Laurie wrote:
> 
>>However, I'm still left with a question, since 2437 only specifies RSA
>>signatures. What lengths should be used with DSA and Elgamal?
> 
> 
> That's trivial: with DSA there is no such thing as an encoding length, since 
> the Hash is used directly and has to be of the correct length (with 1024 
> bit DSA you SHOULD use SHA-1, which is 160 bit wide, which (ohh wonder!) 
> matches the requirement of DSA).
> 
> Elgamal is also trivial: don't use it for signatures. It's insecure. (Or 
> rather: it is so hard to make it secure that it is not worth it.)

As I have previously stated, my keyring contains Elgamal signatures. I'm
sure I'm not alone in this. I want to be able to check them. I think its
fine to deprecate them, but refusing to describe them is just annoying.

Cheers,

Ben.

Date: Tue, 31 May 2005 08:48:47 +0100
From: Ben Laurie <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Stupid hash question?
Sender: [email-masked]

Peter Gutmann wrote:
> Ben Laurie <[email-masked]> writes:
> 
>>Peter Gutmann wrote:
>>
>>>You don't count the FF's, you just continue along them until you find a non-
>>>FF.
>>
>>This is incorrect.
> 
> 
> Since the data payload (i.e. the ASN.1 wrapper and hash) is variable-length
> and not known in advance, how are you expecting to know in advance how many
> FF's are present without walking along them until you find a non-FF?  ESP?
> Magic?

It is known in advance.

Cheers,

Ben.

From: Konrad Rosenbaum <[email-masked]>
To: Ben Laurie <[email-masked]>, [email-masked]
Subject: Re: Stupid hash question?
Date: Mon, 30 May 2005 20:25:55 +0200
Sender: [email-masked]

--nextPart1252236.2FXAaGreal
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 30 May 2005 16:36, Ben Laurie wrote:
> However, I'm still left with a question, since 2437 only specifies RSA
> signatures. What lengths should be used with DSA and Elgamal?

That's trivial: with DSA there is no such thing as an encoding length, sinc=
e=20
the Hash is used directly and has to be of the correct length (with 1024=20
bit DSA you SHOULD use SHA-1, which is 160 bit wide, which (ohh wonder!)=20
matches the requirement of DSA).

Elgamal is also trivial: don't use it for signatures. It's insecure. (Or=20
rather: it is so hard to make it secure that it is not worth it.)

	Konrad

--nextPart1252236.2FXAaGreal
Content-Type: application/pgp-signature

--nextPart1252236.2FXAaGreal--

To: [email-masked], [email-masked]
Subject: Re: Stupid hash question?
Date: Mon, 30 May 2005 09:25:51 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Ben Laurie writes:
> I've been working on signatures recently, and I'm puzzled. As I
> understand it, the form of a decrypted signature is:
>
> 01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>
> However, every signature I look at decrypts to:
>
> 00 01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>
> Before I hurt my head trying to figure out why, I wonder if there's
> something obvious I missed?

Actually if you look at PKCS-1 v1.5 you will find that in fact the
MSB is a 0 and the next byte is a 1 for signatures, a 2 for encryption.
Generally the MSB may not be a whole octet, depending on the size of
the modulus, so they put a zero there.

Hal Finney

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Stupid hash question?
Cc: [email-masked], [email-masked]
Date: Tue, 31 May 2005 03:58:14 +1200
Sender: [email-masked]

Ben Laurie <[email-masked]> writes:
>Peter Gutmann wrote:
>>You don't count the FF's, you just continue along them until you find a non-
>>FF.
>
>This is incorrect.

Since the data payload (i.e. the ASN.1 wrapper and hash) is variable-length
and not known in advance, how are you expecting to know in advance how many
FF's are present without walking along them until you find a non-FF?  ESP?
Magic?

Peter.

Date: Mon, 30 May 2005 15:36:46 +0100
From: Ben Laurie <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Stupid hash question?
Sender: [email-masked]

Peter Gutmann wrote:
> Ben Laurie <[email-masked]> writes:
> 
> 
>>I have one less FF than I (think) I should have.
> 
> 
> You don't count the FF's, you just continue along them until you find a non-
> FF.

This is incorrect.

However, further research answers my own question and reveals a bug in
d-i-o-r-13. RFC 2437 specifies RSA signing in section 8.1.1 - and this
uses (for some reason, any idea why?) an EMSA-PKCS1-V1_5 encoding of
length k-1 (where k is the keylength in octets). I presume that OpenPGP
uses this algorithm. The I-D does not specify the length of the
encoding, which is a bug: it should either specify it is of length k-1
or refer to RFC 2437 8.1.1.

However, I'm still left with a question, since 2437 only specifies RSA
signatures. What lengths should be used with DSA and Elgamal?

Of course, since these will have to be specified, it would make more
sense to specify the length in the I-D than to refer to 2437 for it.

Cheers,

Ben.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Stupid hash question?
Cc: [email-masked]
Date: Tue, 31 May 2005 00:24:57 +1200
Sender: [email-masked]

Ben Laurie <[email-masked]> writes:

>I have one less FF than I (think) I should have.

You don't count the FF's, you just continue along them until you find a non-
FF.

Peter.

Date: Mon, 30 May 2005 13:14:43 +0100
From: Ben Laurie <[email-masked]>
To: Konrad Rosenbaum <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Stupid hash question?
Sender: [email-masked]

Konrad Rosenbaum wrote:
> Ben Laurie said:
> 
>>I've been working on signatures recently, and I'm puzzled. As I
>>understand it, the form of a decrypted signature is:
>>
>>01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>>
>>However, every signature I look at decrypts to:
>>
>>00 01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>>
>>Before I hurt my head trying to figure out why, I wonder if there's
>>something obvious I missed?
> 
> 
> Hi Ben,
> 
> leading zeros can be left out while it is still a large integer. Eg. for
> RSA signatures it is pretty normal that the signature is a) one byte
> smaller than the RSA-n or b) contains a leading zero. This pretty much
> depends on your implementation of large integers. Or to give you an
> example in C:
> 
> It does not matter whether you assign
> int a=0x01;
> or:
> int a=0x000001;
> or.... whatever, it is still a "1".

I realise that, but if I do that, then I have one less FF than I (think)
I should have.

Cheers,

Ben.

From: =?iso-8859-1?B?S2ltbW8gTeRrZWzkaW5lbg==?= <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Problems with calculating signatures over keys
Date: Mon, 30 May 2005 14:25:50 +0300
Sender: [email-masked]

Thanks for the clarification, but I still can't get the right resuts. I 
tried to calculate like this:

SHA1(0x99 (public key tag)+ 0x01 + 0xA2 (key length) + Key packet (418 
bytes) + 0xB4 (user id tag) + 0x00 + 0x00 + 0x00 + 0x28 (user id length) + 
User Id packet (40 bytes) + 0x04 + 0x13 + 0x11 + 0x02 + 0x00 + 0x1E + 0x05 + 
0x02 + 0x42 + 0x95 + 0x6E + 0xD1 + 0x02 + 0x1B + 0x03 + 0x06 + 0x0B + 0x09 + 
0x08 + 0x07 + 0x03 + 0x02 + 0x03 + 0x15 + 0x02 + 0x03 + 0x03 + 0x16 + 0x02 + 
0x01 + 0x02 + 0x1E + 0x01 + 0x02 + 0x17 + 0x80 + Trailer: 0x04 + 0xFF + 0x24 
(big endian length of hashed data from the sign. packet) + 0x00 + 0x00 + 
0x00)

The result I got was 0xfcfc4c8598c9349959eb5cb23321add6b92f2137, so the left 
bytes are 0xFC and 0xFC, but in the key the values are 0xE8 and 0xA4.

Kimmo

>From: [email-masked] ("Hal Finney")
>To: [email-masked], [email-masked]
>Subject: Re: Problems with calculating signatures over keys
>Date: Thu, 26 May 2005 08:34:29 -0700 (PDT)
>
>Kimmo M?kel?inen writes:
> > First, how many octets there should be in the user id packet to define 
>the
> > length of the username?
> >
> > It is said in the 5.2.4 that
> > "A V4 certification hashes the constant 0xb4 (which is an
> >    old-style packet header with the length-of-length set to zero), a
> >    four-octet number giving the length of the username, and then the
> >    username data."
> >
> > However, in the key generated by GnuPG the length is given with only one
> > octet. I have used the PGPdump interface (http://www.pgpdump.net) to
> > visualize the key data, and the interface shows the data correctly,
> > including the user id packet.
>
>The number of octets that is hashed is different from the number that
>is used in the packet.  For a V4 signature, always 4 octets of length
>are hashed.  The number used in the packet may be 1, 2 or 4 octets.
>You need to pad the octets from the packet with leading 0's to get 4
>octets for hash purposes, if fewer are used there.
>
> > In 5.2.4 is also said that
> >
> > "V4 signatures also hash in a final trailer of six octets: the version
> >    of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian
> >    number that is the length of the hashed data from the signature
> >    packet (note that this number does not include these final six
> >    octets."
> >
> > I haven't found an unambiguous explanation for the length bytes. Is it 
>the
> > length of the whole data being hashed (from the public key packet 
>through
> > the end of the hashed subpacket data of signature packet) or just from 
>the
> > version number of the signature packet through the end of hashed 
>subpacket
> > data?
>
>It is the latter, it is the number of bytes hashed from the signature
>packet starting from the version number and going through the end of
>the hashed subpacket data.
>
>You are not the first person to have trouble getting it to work.
>Unfortunately it is the nature of cryptographic hashes that making even
>the slightest error produces a completely wrong result, with no hint
>about how close you are.
>
>We might want to consider some "test vectors" in the RFC which work
>through the process of verifying a signature.  We'd show the key and
>associated packets, and then show the exact sequence of bytes which
>gets hashed.  I think that would be a big help to implementors.
>
>Unfortunately once we open the door to including such an example,
>there are a lot of other things we might need to show.  The public key
>signature operations themselves, signatures on text and binary messages,
>encryption and decryption, encrypt+sign, etc.  We could almost use a
>separate RFC just with examples as an aid to implementors.
>
>Hal Finney
>

_________________________________________________________________
Lataa ilmainen MSN Messenger http://messenger.msn.fi

From: =?iso-8859-1?B?S2ltbW8gTeRrZWzkaW5lbg==?= <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Problems with calculating signatures over keys
Date: Mon, 30 May 2005 14:25:21 +0300
Sender: [email-masked]

Thanks for the clarification, but I still can't get the right resuts. I 
tried to calculate like this:

SHA1(0x99 (public key tag)+ 0x01 + 0xA2 (key length) + Key packet (418 
bytes) + 0xB4 (user id tag) + 0x00 + 0x00 + 0x00 + 0x28 (user id length) + 
User Id packet (40 bytes) + 0x04 + 0x13 + 0x11 + 0x02 + 0x00 + 0x1E + 0x05 + 
0x02 + 0x42 + 0x95 + 0x6E + 0xD1 + 0x02 + 0x1B + 0x03 + 0x06 + 0x0B + 0x09 + 
0x08 + 0x07 + 0x03 + 0x02 + 0x03 + 0x15 + 0x02 + 0x03 + 0x03 + 0x16 + 0x02 + 
0x01 + 0x02 + 0x1E + 0x01 + 0x02 + 0x17 + 0x80 + Trailer: 0x04 + 0xFF + 0x24 
(big endian length of hashed data from the sign. packet) + 0x00 + 0x00 + 
0x00)

The result I got was 0xfcfc4c8598c9349959eb5cb23321add6b92f2137, so the left 
bytes are 0xFC and 0xFC, but in the key the values are 0xE8 and 0xA4.

Kimmo

>From: [email-masked] ("Hal Finney")
>To: [email-masked], [email-masked]
>Subject: Re: Problems with calculating signatures over keys
>Date: Thu, 26 May 2005 08:34:29 -0700 (PDT)
>
>Kimmo M?kel?inen writes:
> > First, how many octets there should be in the user id packet to define 
>the
> > length of the username?
> >
> > It is said in the 5.2.4 that
> > "A V4 certification hashes the constant 0xb4 (which is an
> >    old-style packet header with the length-of-length set to zero), a
> >    four-octet number giving the length of the username, and then the
> >    username data."
> >
> > However, in the key generated by GnuPG the length is given with only one
> > octet. I have used the PGPdump interface (http://www.pgpdump.net) to
> > visualize the key data, and the interface shows the data correctly,
> > including the user id packet.
>
>The number of octets that is hashed is different from the number that
>is used in the packet.  For a V4 signature, always 4 octets of length
>are hashed.  The number used in the packet may be 1, 2 or 4 octets.
>You need to pad the octets from the packet with leading 0's to get 4
>octets for hash purposes, if fewer are used there.
>
> > In 5.2.4 is also said that
> >
> > "V4 signatures also hash in a final trailer of six octets: the version
> >    of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian
> >    number that is the length of the hashed data from the signature
> >    packet (note that this number does not include these final six
> >    octets."
> >
> > I haven't found an unambiguous explanation for the length bytes. Is it 
>the
> > length of the whole data being hashed (from the public key packet 
>through
> > the end of the hashed subpacket data of signature packet) or just from 
>the
> > version number of the signature packet through the end of hashed 
>subpacket
> > data?
>
>It is the latter, it is the number of bytes hashed from the signature
>packet starting from the version number and going through the end of
>the hashed subpacket data.
>
>You are not the first person to have trouble getting it to work.
>Unfortunately it is the nature of cryptographic hashes that making even
>the slightest error produces a completely wrong result, with no hint
>about how close you are.
>
>We might want to consider some "test vectors" in the RFC which work
>through the process of verifying a signature.  We'd show the key and
>associated packets, and then show the exact sequence of bytes which
>gets hashed.  I think that would be a big help to implementors.
>
>Unfortunately once we open the door to including such an example,
>there are a lot of other things we might need to show.  The public key
>signature operations themselves, signatures on text and binary messages,
>encryption and decryption, encrypt+sign, etc.  We could almost use a
>separate RFC just with examples as an aid to implementors.
>
>Hal Finney
>

_________________________________________________________________
Hotmail vai Hotmail Plus? Tutustu palveluihin. 
http://www.imagine-msn.com/hotmail/fi-fi/

Date: Mon, 30 May 2005 12:10:28 +0200 (CEST)
Subject: Re: Stupid hash question?
From: "Konrad Rosenbaum" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "OpenPGP" <[email-masked]>
Importance: Normal
Sender: [email-masked]

Ben Laurie said:
>
> I've been working on signatures recently, and I'm puzzled. As I
> understand it, the form of a decrypted signature is:
>
> 01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>
> However, every signature I look at decrypts to:
>
> 00 01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>
>
> Before I hurt my head trying to figure out why, I wonder if there's
> something obvious I missed?

Hi Ben,

leading zeros can be left out while it is still a large integer. Eg. for
RSA signatures it is pretty normal that the signature is a) one byte
smaller than the RSA-n or b) contains a leading zero. This pretty much
depends on your implementation of large integers. Or to give you an
example in C:

It does not matter whether you assign
int a=0x01;
or:
int a=0x000001;
or.... whatever, it is still a "1".

Really, leave the leading zero out. Even the former east-block states got
rid of their leading zeros - it works pretty well... ;-)

    Konrad

Date: Mon, 30 May 2005 10:19:32 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Stupid hash question?
Sender: [email-masked]

I've been working on signatures recently, and I'm puzzled. As I
understand it, the form of a decrypted signature is:

01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>

However, every signature I look at decrypts to:

00 01 FF FF ... FF FF 00 <ASN.1 nonsense> <hash>

Before I hurt my head trying to figure out why, I wonder if there's
something obvious I missed?

Cheers,

Ben.

Date: Sat, 28 May 2005 21:48:35 +0100
From: Ben Laurie <[email-masked]>
To: David Shaw <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Elgamal Signatures?
Sender: [email-masked]

Cc: [email-masked], [email-masked] ("Hal Finney"), [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Problems with calculating signatures over keys
Date: Sat, 28 May 2005 07:51:02 -0700
To: Derek Atkins <[email-masked]>
Sender: [email-masked]

> I also agree that a separate "Test Vectors" draft would be the right
> place to put it.  It could even be an informational draft instead of a
> standards-track draft, but it could still be called something like:
>    draft-ietf-openpgp-test-vectors
>
>> Hal Finney
>
> Are there any objections from the WG to doing this?  As chair I think
> it's a good idea and would welcome a test vectors draft.
>

I'd go so far as to say it should be an implementation hints draft. It 
could include things like Elgamal signatures, as well, and other things 
that doing belong in the standards RFCs.

	Jon

Date: Fri, 27 May 2005 16:31:01 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Elgamal Signatures?
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

From: Derek Atkins <[email-masked]>
To: [email-masked] ("Hal Finney")
Cc: [email-masked], [email-masked]
Subject: Re: Problems with calculating signatures over keys
Date: Thu, 26 May 2005 12:52:46 -0400
Sender: [email-masked]

Hal,

<chair hat>

[email-masked] ("Hal Finney") writes:

> We might want to consider some "test vectors" in the RFC which work
> through the process of verifying a signature.  We'd show the key and
> associated packets, and then show the exact sequence of bytes which
> gets hashed.  I think that would be a big help to implementors.

I agree that this would be a boon to implementors.  Do you want to
volunteer to do this?  :)

> Unfortunately once we open the door to including such an example,
> there are a lot of other things we might need to show.  The public key
> signature operations themselves, signatures on text and binary messages,
> encryption and decryption, encrypt+sign, etc.  We could almost use a
> separate RFC just with examples as an aid to implementors.

I also agree that a separate "Test Vectors" draft would be the right
place to put it.  It could even be an informational draft instead of a
standards-track draft, but it could still be called something like:
   draft-ietf-openpgp-test-vectors

> Hal Finney

Are there any objections from the WG to doing this?  As chair I think
it's a good idea and would welcome a test vectors draft.

</chair hat>

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

To: [email-masked], [email-masked]
Subject: Re: Problems with calculating signatures over keys
Date: Thu, 26 May 2005 08:34:29 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Kimmo M?kel?inen writes:
> First, how many octets there should be in the user id packet to define the 
> length of the username?
>
> It is said in the 5.2.4 that
> "A V4 certification hashes the constant 0xb4 (which is an
>    old-style packet header with the length-of-length set to zero), a
>    four-octet number giving the length of the username, and then the
>    username data."
>
> However, in the key generated by GnuPG the length is given with only one 
> octet. I have used the PGPdump interface (http://www.pgpdump.net) to 
> visualize the key data, and the interface shows the data correctly, 
> including the user id packet.

The number of octets that is hashed is different from the number that
is used in the packet.  For a V4 signature, always 4 octets of length
are hashed.  The number used in the packet may be 1, 2 or 4 octets.
You need to pad the octets from the packet with leading 0's to get 4
octets for hash purposes, if fewer are used there.

> In 5.2.4 is also said that
>
> "V4 signatures also hash in a final trailer of six octets: the version
>    of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian
>    number that is the length of the hashed data from the signature
>    packet (note that this number does not include these final six
>    octets."
>
> I haven't found an unambiguous explanation for the length bytes. Is it the 
> length of the whole data being hashed (from the public key packet through 
> the end of the hashed subpacket data of signature packet) or just from the 
> version number of the signature packet through the end of hashed subpacket 
> data?

It is the latter, it is the number of bytes hashed from the signature
packet starting from the version number and going through the end of
the hashed subpacket data.

You are not the first person to have trouble getting it to work.
Unfortunately it is the nature of cryptographic hashes that making even
the slightest error produces a completely wrong result, with no hint
about how close you are.

We might want to consider some "test vectors" in the RFC which work
through the process of verifying a signature.  We'd show the key and
associated packets, and then show the exact sequence of bytes which
gets hashed.  I think that would be a big help to implementors.

Unfortunately once we open the door to including such an example,
there are a lot of other things we might need to show.  The public key
signature operations themselves, signatures on text and binary messages,
encryption and decryption, encrypt+sign, etc.  We could almost use a
separate RFC just with examples as an aid to implementors.

Hal Finney

From: =?iso-8859-1?B?S2ltbW8gTeRrZWzkaW5lbg==?= <[email-masked]>
To: [email-masked]
Subject: Problems with calculating signatures over keys
Date: Thu, 26 May 2005 10:20:43 +0300
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_194f_56dd_6dda
Content-Type: text/plain; charset=iso-8859-1; format=flowed

I'm trying to compute the signature over the DSA key and I'm rather 
confused.

I have generated DSA and El Gamal keys with Gnu Privacy Guard software.

First, how many octets there should be in the user id packet to define the 
length of the username?

It is said in the 5.2.4 that
"A V4 certification hashes the constant 0xb4 (which is an
   old-style packet header with the length-of-length set to zero), a
   four-octet number giving the length of the username, and then the
   username data."

However, in the key generated by GnuPG the length is given with only one 
octet. I have used the PGPdump interface (http://www.pgpdump.net) to 
visualize the key data, and the interface shows the data correctly, 
including the user id packet.

Here is the key packet:

The "raw" data of the key is attached to this message.

My main problem is that I can't calculate the correct hash value. PGPdump 
shows that the two left bytes of the calculated hash value over the 
keypacket + user id packet + signature packet are 0xE8 and 0xA4.

In 5.2.4 is also said that

"V4 signatures also hash in a final trailer of six octets: the version
   of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian
   number that is the length of the hashed data from the signature
   packet (note that this number does not include these final six
   octets."

I haven't found an unambiguous explanation for the length bytes. Is it the 
length of the whole data being hashed (from the public key packet through 
the end of the hashed subpacket data of signature packet) or just from the 
version number of the signature packet through the end of hashed subpacket 
data?

I have studied old messages from the mailing list. For example in 
http://www.imc.org/ietf-openpgp/mail-archive/msg02966.html the structure of 
the explained like this:

(header data)
0x99
2 octet length
key packet body data

(user id data)
0xb4
4 octet length
username data

(signature trailer)

version field to end of hashable data

V4 signature trailer
0x04
0xFF
4 octet length

I think the structure is otherwise clear, but what should be done with the 
length of the user name? If I add three bytes to the key generated with the 
GnuPG, I still can't get the hash value to match with the two bytes GnuPG 
has calculated.

Best regards,
Kimmo Mäkeläinen

_________________________________________________________________
3 vrk:n sääennuste http://www.msn.fi/uutiset/saa

------=_NextPart_000_194f_56dd_6dda
Content-Type: application/octet-stream; name="pubring.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pubring.gpg"

------=_NextPart_000_194f_56dd_6dda--

Date: Wed, 25 May 2005 12:26:53 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Elgamal Signatures?
Sender: [email-masked]

Cheers,

Ben.

Date: Fri, 20 May 2005 20:18:00 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Critical bits and notations
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Fri, May 20, 2005 at 09:45:17AM +0100, Ben Laurie wrote:
> 
> Werner Koch wrote:
> >On Thu, 19 May 2005 21:43:34 +0100, Ben Laurie said:
> >
> >
> >>This whole discussion scares me. You have an extension mechanism with
> >>no registry for extensions.
> >
> >
> >We do have a way to register extensions ([5.2.3.16. Notation Data]):
> >
> >   The IETF name space is registered with IANA. These names MUST NOT
> >   contain the "@" character (0x40) is this is a tag for the user name
> >   space.
> >
> >   Names in the user name space consist of a UTF-8 string tag followed
> >   by "@" followed by a DNS domain name. Note that the tag MUST NOT
> >   contain an "@" character. For example, the "sample" tag used by
> >   Example Corporation could be "[email-masked]".
> >
> >   Names in a user space are owned and controlled by the owners of that
> >   domain. Obviously, it's of bad form to create a new name in a DNS
> >   space that you don't own.
> >
> >Where do you see the problem?
> 
> Doh! The problem lies between my chair and keyboard. Sorry.
> 
> A passing comment, though - if you want domain names to be a safe 
> extension mechanism, you should include a date, since they can change 
> hands (without consent of the current owner, even).

It's also worth noting that the naming rules are often ignored in
practice.  A year or two ago, I pulled a keyring from one of the
keyservers and enumerated the notation names.  I'd have to dig up my
notes from then, but I seem to recall that around 85-90% of them were
the string "COMMENT".

(Since then, GnuPG has refused to create notation names without a '@'
in them).

David

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Key Algorithms?
Date: Fri, 20 May 2005 15:32:33 -0700
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 19 May 2005, at 1:37 PM, Ben Laurie wrote:

>
> Key algorithms ... these are used in various contexts, and there's a
> list in 9.1 - some of these are clearly unsuitable in some contexts -
> for example, one would not expect to see RSA Encrypt-Only (3) in a
> signature. But I can't find any language saying anything about
> this. Are there any rules?
>

All of these are deprecated or disallowed.

12.4. RSA

    There are algorithm types for RSA-signature-only, and
    RSA-encrypt-only keys. These types are deprecated. The "key flags"
    subpacket in a signature is a much better way to express the same
    idea, and generalizes it to all algorithms. An implementation SHOULD
    NOT create such a key, but MAY interpret it.

[...]

12.7. Reserved Algorithm Numbers

    A number of algorithm IDs have been reserved for algorithms that
    would be useful to use in an OpenPGP implementation, yet there are
    issues that prevent an implementer from actually implementing the
    algorithm. These are marked in the Public Algorithms section as
    "(reserved for)".

[...]

    Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
    with a public key identifier of 20. These are no longer permitted.
    An implementation MUST NOT generate such keys. An implementation
    MUST NOT generate Elgamal signatures.

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Minor nit: Issuer vs. Issuer key ID
Date: Fri, 20 May 2005 15:28:40 -0700
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 19 May 2005, at 1:35 PM, Ben Laurie wrote:

>
> 5.2.3.5 Issuer
>
> should be:
>
> 5.2.3.5 Issuer key ID
>
> A tiny point, I know, but it made it hard to find.
>

Fixed in bis-14.

	Jon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-13.txt
Date: Fri, 20 May 2005 15:35:07 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-13.txt
	Pages		: 72
	Date		: 2005-5-20
	
This document is maintained in order to publish all necessary
    information needed to develop interoperable applications based on
    the OpenPGP format. It is not a step-by-step cookbook for writing an
    application. It describes only the format and methods needed to
    read, check, generate, and write conforming packets crossing any
    network. It does not deal with storage and implementation questions.
    It does, however, discuss implementation issues necessary to avoid
    security flaws.

    OpenPGP software uses a combination of strong public-key and
    symmetric cryptography to provide security services for electronic
    communications and data storage.  These services include
    confidentiality, key management, authentication, and digital
    signatures. This document specifies the message formats used in
    OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-13.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-13.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-13.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 20 May 2005 09:45:17 +0100
From: Ben Laurie <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: Jon Callas <[email-masked]>, David Shaw <[email-masked]>, [email-masked]
Subject: Re: Critical bits and notations
Sender: [email-masked]

Werner Koch wrote:
> On Thu, 19 May 2005 21:43:34 +0100, Ben Laurie said:
> 
> 
>>This whole discussion scares me. You have an extension mechanism with
>>no registry for extensions.
> 
> 
> We do have a way to register extensions ([5.2.3.16. Notation Data]):
> 
>    The IETF name space is registered with IANA. These names MUST NOT
>    contain the "@" character (0x40) is this is a tag for the user name
>    space.
> 
>    Names in the user name space consist of a UTF-8 string tag followed
>    by "@" followed by a DNS domain name. Note that the tag MUST NOT
>    contain an "@" character. For example, the "sample" tag used by
>    Example Corporation could be "[email-masked]".
> 
>    Names in a user space are owned and controlled by the owners of that
>    domain. Obviously, it's of bad form to create a new name in a DNS
>    space that you don't own.
> 
> Where do you see the problem?

Doh! The problem lies between my chair and keyboard. Sorry.

A passing comment, though - if you want domain names to be a safe 
extension mechanism, you should include a date, since they can change 
hands (without consent of the current owner, even).

Cheers,

Ben.

To: Ben Laurie <[email-masked]>
Cc: Jon Callas <[email-masked]>, David Shaw <[email-masked]>, [email-masked]
Subject: Re: Critical bits and notations
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 20 May 2005 09:24:31 +0200
Sender: [email-masked]

On Thu, 19 May 2005 21:43:34 +0100, Ben Laurie said:

> This whole discussion scares me. You have an extension mechanism with
> no registry for extensions.

We do have a way to register extensions ([5.2.3.16. Notation Data]):

   The IETF name space is registered with IANA. These names MUST NOT
   contain the "@" character (0x40) is this is a tag for the user name
   space.

   Names in the user name space consist of a UTF-8 string tag followed
   by "@" followed by a DNS domain name. Note that the tag MUST NOT
   contain an "@" character. For example, the "sample" tag used by
   Example Corporation could be "[email-masked]".

   Names in a user space are owned and controlled by the owners of that
   domain. Obviously, it's of bad form to create a new name in a DNS
   space that you don't own.

Where do you see the problem?

Salam-Shalom,

   Werner

Date: Thu, 19 May 2005 21:43:34 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: David Shaw <[email-masked]>, [email-masked]
Subject: Re: Critical bits and notations
Sender: [email-masked]

Jon Callas wrote:
> 
> 
> On 11 May 2005, at 7:35 AM, David Shaw wrote:
> 
>>
>> On Tue, May 10, 2005 at 09:28:36PM -0700, "Hal Finney" wrote:
>>
>>>
>>> In my opinion, the critical bit on a notation packet should mean
>>> that the implementation needs to recognize that particular notation,
>>> not just notation packets in general.  Otherwise we would have no way
>>> of expressing the requirement that the particular notation packet be
>>> understood.
>>
>>
>> That makes good sense, and I agree.  However, the text in the draft
>> doesn't exactly say this (and rather implies the opposite).
>>
> 
> I agree with Hal. I don't think that the text in the draft implies the 
> opposite, however. Here's a quote:
> 
>    ... The
>    purpose of the critical bit is to allow the signer to tell an
>    evaluator that it would prefer a new, unknown feature to generate an
>    error than be ignored.
> 
> This says to me that if you see a notation you don't understand, you 
> should error out.
> 
> Notations are our extension mechanism. It strikes me as perverse to 
> think that you only have to know the general concept of extensions and 
> not the specific extension.
> 
>> I suggest adding this sentence (or similar) to the end of section
>> 5.2.3.16. Notation Data:
>>
>>   When used on a notation subpacket, the critical bit refers to that
>>   particular notation, and not to notation subpackets in general.
> 
> 
> I put in:
> 
>    If there is a critical notation, the criticality applies to that 
> specific
>    notation and not to notations in general.
> 
> but I'll bet you a beer someone finds a creative way to misinterpret this.

This whole discussion scares me. You have an extension mechanism with no 
registry for extensions.

When these things get popular, it turns out everyone hates them. cf. DNS 
TXT records.

Date: Thu, 19 May 2005 21:37:20 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Key Algorithms?
Sender: [email-masked]

Key algorithms ... these are used in various contexts, and there's a
list in 9.1 - some of these are clearly unsuitable in some contexts -
for example, one would not expect to see RSA Encrypt-Only (3) in a
signature. But I can't find any language saying anything about
this. Are there any rules?

Date: Thu, 19 May 2005 21:35:30 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Minor nit: Issuer vs. Issuer key ID
Sender: [email-masked]

5.2.3.5 Issuer

should be:

5.2.3.5 Issuer key ID

A tiny point, I know, but it made it hard to find.

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Tag 11 unclear
Date: Thu, 12 May 2005 15:16:15 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 12 May 2005, at 8:49 AM, David Shaw wrote:

> Isn't _CONSOLE what is used when something shouldn't be saved as a
> file?  I'd say zero length just means that the sender didn't give a
> file name, whether because the data doesn't have one, or because the
> filename is private, or even because it just didn't want to.
>

No, _CONSOLE means "eyes only." Then you do whatever it is you do for 
eyes only.

> I think the 0 option for the literal timestamp is similar - it just
> means the sender didn't give a time.  The recipient can interpret that
> however it likes.
>

Again, I think there are three options: data mod date (typically 
meaning its source is a file), encrypt time, and decrypt time. The 
encryptor picks. The decryptor has no way of knowing which of the first 
two was picked.

	Jon

Date: Thu, 12 May 2005 11:49:24 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Tag 11 unclear
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Wed, May 11, 2005 at 05:19:01PM -0700, Jon Callas wrote:
> 
> >   " - File name as a string (one-octet length, followed by file name),
> >       if the encrypted data should be saved as a file."
> >
> >but no mention of what if it shouldn't be saved as a file. 0 length,
> >perhaps?
> >
> 
> That's what I'd do.

Isn't _CONSOLE what is used when something shouldn't be saved as a
file?  I'd say zero length just means that the sender didn't give a
file name, whether because the data doesn't have one, or because the
filename is private, or even because it just didn't want to.

I think the 0 option for the literal timestamp is similar - it just
means the sender didn't give a time.  The recipient can interpret that
however it likes.

David

Date: Thu, 12 May 2005 15:29:21 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Tag 11 unclear
Sender: [email-masked]

Jon Callas wrote:
>>    " - File name as a string (one-octet length, followed by file name),
>>        if the encrypted data should be saved as a file."
>>
>> but no mention of what if it shouldn't be saved as a file. 0 length,
>> perhaps?
>>
> 
> That's what I'd do.
> 
>> Then:
>>
>>    " - A four-octet number that indicates the modification date of the
>>        file, or the creation time of the packet, or a zero that
>>        indicates the present time."
>>
>> I would _guess_ that it means modification date of the file if there's
>> a filename, the creation time if there isn't. I have no idea what zero
>> is supposed to mean. Nothing, would be the obvious interpretation -
>> "the present time" is nonsensical.
>>
> 
> I think that the major problem is that OpenPGP gets used for a lot of 
> things, and this is giving latitude, which always means lack of clarity. 
> This dates back at least as far as RFC 1991, which says:
> 
>    ... Field (d) [labeled previously as "a time field"]
>    should be the time at which
>    the file was last modified, or the time at which the data packet was
>    created, or 0.
> 
> Which is even less helpful, as it doesn't tell us about the zero option. 
> Unfortunately, this is not only ambiguous, but insufficient.
> 
> Let's presume that I've decrypted a packet. If I'm storing that in a 
> file, it seems to me that I should take that time field and make it be 
> the creation and modification date of the file, or now if it's zero. If 
> I'm putting it in a text widget (for example), then obviously I don't do 
> anything as the time doesn't really apply.
> 
> If I am creating a literal packet, I have several options. One is that I 
> take the modification time of the file, assuming it's available. 
> Personally, I think if you're transferring files around, you should 
> preserve the creation time and the modification time, but I'm fussy that 
> way.
> 
> The next option that I have is to put the current time in there. The 
> reason I might do that is if I think I'm leaking data by doing it, or -- 
> whatever. If I don't want to put the modification time of the data in 
> the packet, I can put "now" in there.

The obvious "whatever" is when the source is not otherwise dated, such 
as the user typing at a keyboard, or the output of a pipe.

> The last option is that if I don't want to use *my* now, but the 
> *recipient's* now, I can put a zero in there.
> 
> It's completely up to me to decide for whatever arcane reasons I have 
> which of those is the right thing to do.
> 
> I added to the end of the paragraph there: "It is up to the creator of 
> the packet which of these they use." Does that help?

Not really. My objection to the wording is that it makes no sense. That 
is, the time field has three alleged possible meanings:

a) last modification time of file

b) creation time of packet

c) now

we have no way to tell whether a) or b) is meant, unless we link that to 
the presence of a filename, and having a time field mean "now" without 
saying what "now" is supposed to apply to makes no sense whatsoever.

I can't even see how to fix that and retain the "now"ness - if we say it 
applies to the file or the packet, that's clearly untrue. So what does 
it apply to? The only thing that makes sense to me is to define 0 as 
"the sender has declined to provide a time".

As before, if we can agree on this, I'll produce proposed words.

Cheers,

Ben.

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Tag 11 unclear
Date: Wed, 11 May 2005 17:19:01 -0700
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

>    " - File name as a string (one-octet length, followed by file name),
>        if the encrypted data should be saved as a file."
>
> but no mention of what if it shouldn't be saved as a file. 0 length,
> perhaps?
>

That's what I'd do.

> Then:
>
>    " - A four-octet number that indicates the modification date of the
>        file, or the creation time of the packet, or a zero that
>        indicates the present time."
>
> I would _guess_ that it means modification date of the file if there's
> a filename, the creation time if there isn't. I have no idea what zero
> is supposed to mean. Nothing, would be the obvious interpretation -
> "the present time" is nonsensical.
>

I think that the major problem is that OpenPGP gets used for a lot of 
things, and this is giving latitude, which always means lack of 
clarity. This dates back at least as far as RFC 1991, which says:

    ... Field (d) [labeled previously as "a time field"]
    should be the time at which
    the file was last modified, or the time at which the data packet was
    created, or 0.

Which is even less helpful, as it doesn't tell us about the zero 
option. Unfortunately, this is not only ambiguous, but insufficient.

Let's presume that I've decrypted a packet. If I'm storing that in a 
file, it seems to me that I should take that time field and make it be 
the creation and modification date of the file, or now if it's zero. If 
I'm putting it in a text widget (for example), then obviously I don't 
do anything as the time doesn't really apply.

If I am creating a literal packet, I have several options. One is that 
I take the modification time of the file, assuming it's available. 
Personally, I think if you're transferring files around, you should 
preserve the creation time and the modification time, but I'm fussy 
that way.

The next option that I have is to put the current time in there. The 
reason I might do that is if I think I'm leaking data by doing it, or 
-- whatever. If I don't want to put the modification time of the data 
in the packet, I can put "now" in there.

The last option is that if I don't want to use *my* now, but the 
*recipient's* now, I can put a zero in there.

It's completely up to me to decide for whatever arcane reasons I have 
which of those is the right thing to do.

I added to the end of the paragraph there: "It is up to the creator of 
the packet which of these they use." Does that help?

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Editorial Nit
Date: Wed, 11 May 2005 16:56:13 -0700
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

On 26 Apr 2005, at 5:39 AM, Ben Laurie wrote:

>
> 5.2.3.7. Preferred symmetric algorithms
>
>    (sequence of one-octet values)
>
> 5.2.3.8. Preferred hash algorithms
>
>    (array of one-octet values)
>
> It seems these (and others) should all either say "sequence" or 
> "array".
>

I changed them all to "array" for no particular reason other than I 
think I like it better today.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Critical bits and notations
Date: Wed, 11 May 2005 16:54:01 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 11 May 2005, at 7:35 AM, David Shaw wrote:

>
> On Tue, May 10, 2005 at 09:28:36PM -0700, "Hal Finney" wrote:
>>
>> In my opinion, the critical bit on a notation packet should mean
>> that the implementation needs to recognize that particular notation,
>> not just notation packets in general.  Otherwise we would have no way
>> of expressing the requirement that the particular notation packet be
>> understood.
>
> That makes good sense, and I agree.  However, the text in the draft
> doesn't exactly say this (and rather implies the opposite).
>

I agree with Hal. I don't think that the text in the draft implies the 
opposite, however. Here's a quote:

    ... The
    purpose of the critical bit is to allow the signer to tell an
    evaluator that it would prefer a new, unknown feature to generate an
    error than be ignored.

This says to me that if you see a notation you don't understand, you 
should error out.

Notations are our extension mechanism. It strikes me as perverse to 
think that you only have to know the general concept of extensions and 
not the specific extension.

> I suggest adding this sentence (or similar) to the end of section
> 5.2.3.16. Notation Data:
>
>   When used on a notation subpacket, the critical bit refers to that
>   particular notation, and not to notation subpackets in general.

I put in:

    If there is a critical notation, the criticality applies to that 
specific
    notation and not to notations in general.

but I'll bet you a beer someone finds a creative way to misinterpret 
this.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: minor comments on draft-ietf-openpgp-rfc2440bis-12.txt
Date: Wed, 11 May 2005 16:42:45 -0700
To: Rachel Willmer <[email-masked]>
Sender: [email-masked]

On 11 May 2005, at 7:22 AM, Rachel Willmer wrote:

>
> Minor nitpicks:
>
> 1/ 5.2.3.23 "Reason for revocation"
>
> "superceded" should be "superseded"

Done. Both occurrences.

>
> 2/ Sections 5.2.3.8 and 5.2.3.9 both reference algorithm lists in
> section 6, which is currently the section entitled "Radix-64
> conversions". I suspect the reference should be to Section 9.
>

Done.

	Jon

Date: Wed, 11 May 2005 18:09:01 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Tag 11 unclear
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Wed, May 11, 2005 at 02:51:33PM -0700, "Hal Finney" wrote:
> 
> David Shaw writes:
> > What about (onepass, literal, literal, literal, sig) ?  Treat as the
> > multiple literal bodies concatenated together?
> 
> I don't think we should allow this.  There are too many potentials
> for mischief due to the absence of boundary information feeding into
> the signature.

Note that this is currently legal syntax in the grammar.

(I actually suggested the run-of-literal-packets grammar change to
resolve a problem elsewhere in the document, but that doesn't mean I
was right).

David

To: [email-masked]
Subject: Re: Tag 11 unclear
Date: Wed, 11 May 2005 14:51:33 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

David Shaw writes:
> What about (onepass, literal, literal, literal, sig) ?  Treat as the
> multiple literal bodies concatenated together?

I don't think we should allow this.  There are too many potentials
for mischief due to the absence of boundary information feeding into
the signature.

Hal

Date: Wed, 11 May 2005 17:25:28 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Tag 11 unclear
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Apr 26, 2005 at 12:02:23PM -0700, "Hal Finney" wrote:
> We might also want to note here that literal packet headers are not
> signed, unless the literal packet is first wrapped in another packet
> such as a compressed packet.  Only the body of a literal packet is
> signed in a message which consists of sig-packet, literal-packet.
> (Or sig1-packet, literal-packet, sig-packet)

What about (onepass, literal, literal, literal, sig) ?  Treat as the
multiple literal bodies concatenated together?

David

Date: Wed, 11 May 2005 10:35:36 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Critical bits and notations
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, May 10, 2005 at 09:28:36PM -0700, "Hal Finney" wrote:
> 
> In my opinion, the critical bit on a notation packet should mean
> that the implementation needs to recognize that particular notation,
> not just notation packets in general.  Otherwise we would have no way
> of expressing the requirement that the particular notation packet be
> understood.

That makes good sense, and I agree.  However, the text in the draft
doesn't exactly say this (and rather implies the opposite).

I suggest adding this sentence (or similar) to the end of section
5.2.3.16. Notation Data:

  When used on a notation subpacket, the critical bit refers to that
  particular notation, and not to notation subpackets in general.

David

Date: Wed, 11 May 2005 15:22:17 +0100
From: Rachel Willmer <[email-masked]>
To: [email-masked]
Subject: minor comments on draft-ietf-openpgp-rfc2440bis-12.txt
Sender: [email-masked]

Minor nitpicks:

1/ 5.2.3.23 "Reason for revocation"

"superceded" should be "superseded"

2/ Sections 5.2.3.8 and 5.2.3.9 both reference algorithm lists in
section 6, which is currently the section entitled "Radix-64
conversions". I suspect the reference should be to Section 9.

Rachel

To: [email-masked] ("Hal Finney")
Cc: [email-masked], [email-masked]
Subject: Re: Critical bits and notations
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 11 May 2005 09:17:26 +0200
Sender: [email-masked]

On Tue, 10 May 2005 21:28:36 -0700 (PDT), "Hal Finney" said:

> In my opinion, the critical bit on a notation packet should mean
> that the implementation needs to recognize that particular notation,
> not just notation packets in general.  Otherwise we would have no way

I agree.  This matches the way the critical flag of CMS' extended
attributes is used.

Shalom-Salam,

   Werner

To: [email-masked], [email-masked]
Subject: Re: Critical bits and notations
Date: Tue, 10 May 2005 21:28:36 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

In my opinion, the critical bit on a notation packet should mean
that the implementation needs to recognize that particular notation,
not just notation packets in general.  Otherwise we would have no way
of expressing the requirement that the particular notation packet be
understood.

I also wouldn't say that human-readable means that it is enough to display
it.  My interpretation of human-readable is that it is OK to display it
to a person, i.e. that the data is in UTF-8, but not that displaying it
to a person is sufficient to claim full support of the packet.

Hal Finney

Date: Tue, 10 May 2005 23:43:19 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Critical bits and notations
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

Here's an odd corner case, one that I'd be grateful for some thoughts
on: what does the critical bit mean in the context of a signature
notation?  Does the critical bit refer to support of the notation
subpacket in general, or to the specific notation given in the
critical notation subpacket?

For example, take an implementation that can read notations, and
specifically understands and acts on the "foo" notation.  Given that,
it's very clear that this implementation should accept a critical
notation "foo=1".  Now try a critical notation of "bar=2".  Should the
implementation accept it because it knows what a notation is, and
implements notations, or should it reject it because it doesn't know
what the specific "bar" notation is?

The draft has this to say on the subject of critical bits for
signature subpackets:

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the
   evaluator of the signature to recognize.  If a subpacket is
   encountered that is marked critical but is unknown to the
   evaluating software, the evaluator SHOULD consider the signature to
   be in error.

   An evaluator may "recognize" a subpacket, but not implement it. The
   purpose of the critical bit is to allow the signer to tell an
   evaluator that it would prefer a new, unknown feature to generate
   an error than be ignored.

According to this, it would seem that a critical bit on a notation
would seem to refer to support for the notation subpacket
(i.e. notations in general).  However, this seems a bit less useful
than it could be, since the main idea of notations is to be able to
add interesting things to the standard later.  A critical bit that
applied to the specific notation seems more useful.

How does human-readable fit into this - if a notation is human
readable, is it sufficient to display the notation to a human to say
that it is "recognized"?

David