Subject: Valid OpenPGP keys without self-signature?

From: [email-masked]
Date: Mon, 22 Dec 2003 11:38:30 +0100

During OpenPGP interoperability tests, I have recently come across an
unusual situation:

The German company "Robert Bosch GmbH" introduced a PKI on the basis
of a product called "Secure e-mail iT_SEC_outlook". This product uses
old-style V3 RSA keys that are created by the "trust center" of
the company for every user and are signed on creation by the trust
center key. The unusual aspect now is that only the "trust center key"
has a self-signature. All normal user keys have no self-signature but
only the trust center signature on them.

(I have added the trust center key and one user key at the end of
this message to show what I mean.)

My questions now are:

(1) Are such keys a security problem?

    (A key without any signature on it would be open to manipulation,
    of course, but the company claims that their trust center
    signature protects the exact same key contents that a
    self-signature would protect. And according to RFC 2440, this
    really seems to be the case.)

(2) Is such a key conforming to the OpenPGP spec (or at least
    interoperable with a conforming OpenPGP product)?

    (I re-read the spec yesterday and could not find any obvious
    violation although such a key loses lots of features because
    aspects like "Key expiration time", "Preferred symmectric
    algorithms", "Preferred hash algorithms", "Preferred compression
    algorithms", "Key server preferences" and the "Primary user id"
    flag all reside in the self-signature that is missing here.)

(3) Which OpenPGP products support such unusual public keys?

    (In my tests, PGP 5.x imported the user key without any error
    message, whereas GnuPG 1.2.x refused to import the key even in
    "--expert" mode. And a PGP 8.02 user reported to me that PGP 8.02
    also refuses to import any keys without self-signature.)

As I either have to find a solution to this interoperability problem
or have to prove to the company that their setup is insecure, I would
be very happy about any answers to the above questions.

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: [email-masked]
---------------------------------------------------------------------

The following is the trust center key of the company:
  [email-masked]
  [email-masked]
  [email-masked]

The following is a user key without self-signature, but with the
trust center signature on it:
   [email-masked]
   [email-masked]

---

From: Lutz Donnerhacke <[email-masked]>
Date: Mon, 22 Dec 2003 11:35:59 +0000 (UTC)

> (1) Are such keys a security problem?

In general: Yes. In this particular case: No.

>     interoperable with a conforming OpenPGP product)?

There are 2.6.x versions of PGP generating keys without a self signature.
So they are introduced and common, despite considered obsolet.

> (3) Which OpenPGP products support such unusual public keys?

There is a strong movement to require the self signature. This is currently
work in progress on the whole key space.

---

From: Ian Grigg <[email-masked]>
Date: Mon, 22 Dec 2003 11:59:36 -0500

> be very happy about any answers to the above questions.

Wolfgang,

I'm afraid you are on the pointy end of a sharp stick.

You are right that it is not strictly illegal, but as
Lutz says, it will become illegal at some hopefully near
stage. To all intents and purposes, it is already illegal
structure, de facto, and you can expect no current or
future OpenPGP product to accept it.

The reason for this is complexity:  OpenPGP's key structure
is a bit of a mess.  There is way too much freedom, in all
the options and subpackets and arrays of packets and what
have you.

At a data level, this is fine, wonderful, uplifting, even.

But at the level of security coding, this is a nightmare.
In practice, in a secure program, every little execption
adds to every other little exception to create the
potential for a security failure.  Either we have to as
a community deal with the interrelated exceptions - all
of them, in every body of code - or we have to remove
the exceptions.

The latter course is compelling, and in this particular
case, the group debated the self-signed issue a year or
so back, and came to the conclusion to deprecate un-self-
signed keys.

For your company - it is a matter of explaining that
they are technically secure, but they will not inter-
operate.  Their keys have been "declared unsafe".

That doesn't mean it is insecure.  Consider it like
taking the Mercedes in for the registration check and
being told the brake lines need to be replaced.  You
know the lines are good for another 5 years, but once
the standard is in place, that's it.  Out they go.

If they don't want to interoperate, then that's fine.
But, if they want to interoperate, they have to do it
on both the basis of security *and* the standard.

iang

PS: it would seem that a much bigger problem for them,
if they *do* want to interoperate, is that they want to
move over to V4 keys at some stage.  So maybe the way
to approach this is to leave the V3 keys in place, and
start issuing V4 keys in the future?

From: Jon Callas <[email-masked]>
Subject: Re: Valid OpenPGP keys without self-signature?
Date: Tue, 30 Dec 2003 14:08:27 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I want to add in a few comments.

I think that self-signatures are good. However, I think it is a bad 
thing to be draconian about them.

If a User ID (or attribute ID) is signed by me, then it should be 
valid, whether it's got a self-signature on it or not. I'd love to be 
able to add user names to other people's keys so that software I use 
can find them. Many people don't have every possible mail address on 
their keys, and it's damned annoying. Far too many people don't have 
the right user names on their keys.

A user id on a key that is signed by me can be thought of as a SDSI 
name. Using the web of trust, I could even trust other names. I might, 
for example, consider valid an unsigned name if it is signed by someone 
I trust.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: "Other" compression algorithms
Date: Tue, 30 Dec 2003 13:52:08 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

> Then section 9.3 says "Implementations MAY implement ZLIB."  That text
> was written before BZip2 was added to the draft, and should probably
> read "Implementations MAY implement any other algorithm." like the
> other two sections.
>

Done.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: From-plus-a-space
Date: Tue, 30 Dec 2003 13:51:11 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

On Dec 22, 2003, at 4:51 PM, David Shaw wrote:
> However, in the draft, the mention of "From " is broken over two
> lines as:
>
>    "From
>  "
>

I changed it to: "...SHOULD dash escape lines commencing "From" 
followed by a space..."

	Jon

content-class: urn:content-classes:message
Subject: RE: Compression and partial length chunks
Date: Mon, 29 Dec 2003 14:58:54 -0500
From: "Hasnain Mujtaba" <[email-masked]>
To: "Hal Finney" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hal,

I appreciate your clarification. 

I can see that the real challenge will be to deal with the 3 levels of
PBLs. When I detect that the EncryptedDataPacket is using PBLs, can I
safely assume that the enclosed compressed data and literal data packets
have been put into PBLs also? It is possible for a sender to prepare the
literal and compressed data packets as a whole without using PBLs and
then to send the encrypted data out in PBLs, even though it doesn't make
sense and defeats the purpose of employing PBLs. I'm not sure if the
specification prevents them from doing this sort of PBL encoding at the
outer layer only.

Regards
Hasnain 

-----Original Message-----
From: Hal Finney [mailto:[email-masked]] 
Sent: Monday, December 29, 2003 6:36 AM
To: [email-masked]; Hasnain Mujtaba; [email-masked]
Subject: RE: Compression and partial length chunks

Hasnain -

> If I must have hold the whole source data in memory before I can
> compress and then encrypt it, then I would always know before-hand the
> lengths of the resulting packets (literal, compressed, and encrypted).
> So when exactly does the need arise to use PBLs? Even when I am
> streaming data, I cannot avoid the basic constraint that the entire
> source data must be in memory before it can be processed. It is not
the
> case, as you pointed out, that I am feeding chunks of the source data
to
> the compression and encryption routines and then sending them out as
> PBLs.  

I'm afraid I misled you in my earlier comments.  Nothing in the OpenPGP
algorithms or formats requires you to hold the entire document in
memory.
The compression and encryption algorithms can operate on chunks at a
time,
as long as they are in order: first chunk, second chunk, third chunk,
etc.

You asked earlier whether you could process the chunk "independently of
the chunks already received" and my answer was no.  What I meant was
that you have to have processed those other chunks already, in order,
and retained state information from those chunks.  The widely used zlib
decompression library provides this functionality, for example, as do
most decryption libraries which provide the CFB chaining mode used by
PGP.

> I am new to the interesting world of PGP. I think it would be useful,
if
> at all possible, to be able to deal with the chunks independently so
as
> to avoid physical memory limitations. 

I hope my clarification above will show that it is possible to do this,
but that state must be retained from chunk to chunk in the decompression
and decryption modules.

Hal Finney

Date: Mon, 29 Dec 2003 03:35:44 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Compression and partial length chunks
Sender: [email-masked]

Hasnain -

> If I must have hold the whole source data in memory before I can
> compress and then encrypt it, then I would always know before-hand the
> lengths of the resulting packets (literal, compressed, and encrypted).
> So when exactly does the need arise to use PBLs? Even when I am
> streaming data, I cannot avoid the basic constraint that the entire
> source data must be in memory before it can be processed. It is not the
> case, as you pointed out, that I am feeding chunks of the source data to
> the compression and encryption routines and then sending them out as
> PBLs.  

I'm afraid I misled you in my earlier comments.  Nothing in the OpenPGP
algorithms or formats requires you to hold the entire document in memory.
The compression and encryption algorithms can operate on chunks at a time,
as long as they are in order: first chunk, second chunk, third chunk, etc.

You asked earlier whether you could process the chunk "independently of
the chunks already received" and my answer was no.  What I meant was
that you have to have processed those other chunks already, in order,
and retained state information from those chunks.  The widely used zlib
decompression library provides this functionality, for example, as do
most decryption libraries which provide the CFB chaining mode used by PGP.

> I am new to the interesting world of PGP. I think it would be useful, if
> at all possible, to be able to deal with the chunks independently so as
> to avoid physical memory limitations. 

I hope my clarification above will show that it is possible to do this,
but that state must be retained from chunk to chunk in the decompression
and decryption modules.

Hal Finney

content-class: urn:content-classes:message
Subject: RE: Compression and partial length chunks
Date: Mon, 29 Dec 2003 13:56:23 -0500
From: "Hasnain Mujtaba" <[email-masked]>
To: "Hal Finney" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hal,

Thank you for your feedback, it has clarified a lot of confusion. I have
a couple of follow up comments:

If I must have hold the whole source data in memory before I can
compress and then encrypt it, then I would always know before-hand the
lengths of the resulting packets (literal, compressed, and encrypted).
So when exactly does the need arise to use PBLs? Even when I am
streaming data, I cannot avoid the basic constraint that the entire
source data must be in memory before it can be processed. It is not the
case, as you pointed out, that I am feeding chunks of the source data to
the compression and encryption routines and then sending them out as
PBLs.  

My basic problem is that I cannot simultaneously hold both the encrypted
and decrypted data in memory because I will be dealing with large
documents up to 10GB. So, if an encrypted document comes in and it uses
PBLs, I still need to coallesce the chunks before I decrypt and
decompress them. In other words, I need to hold the entire
encrypted/compressed data in memory as well as the
decrypted/decompressed data. 

I am new to the interesting world of PGP. I think it would be useful, if
at all possible, to be able to deal with the chunks independently so as
to avoid physical memory limitations. 

If you can provide additional feedback, I would be most grateful.  

Regards
Hasnain. 

Date: Wed, 24 Dec 2003 01:07:41 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Partial length chunks and 5-byte lengths
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Section 4.2.2.4. ("Partial Body Lengths") of bis-09 specifies that
after the initial partial body length chunk:

  Another length header (of one of the three types -- one octet,
  two-octet, or partial) follows that portion.

It explicitly says "one of three types", and mentions only the one
octet, two octet, and partial length encodings.  Some bias against the
5-octet length encoding ? ;)

Unless that was intentional (was it?)  I suggest that the text be
changed to say one of the *four* types, etc, or just drop the
parenthetical comment altogether.

Also, it looks like part of the partial body length definition is in
section 4.2.3 ("Packet Length Examples"), but should be in section
4.2.2.4 along with the rest of the definition:

    An implementation MAY use Partial Body Lengths for data packets,
    be they literal, compressed, or encrypted. The first partial
    length MUST be at least 512 octets long. Partial Body Lengths MUST
    NOT be used for any other packet types.

David

Date: Tue, 23 Dec 2003 15:22:01 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Compression and partial length chunks
Sender: [email-masked]

Hasnain Mujtaba writes:
> I was wondering if someone could help clarify some issues for me.  It is
> not clear to me from the RFC2440 how compression works when using
> partial body length headers.  
> ...
> Are the chunks independent in that can they be decrypted and
> decompressed by the receiver without buffering them with other chunks?
> E.g, if a 8192 bytes chunk is received enclosed within a partial body
> length header, can the receiver take the chunk's payload and decrypt it
> and then decompress it independently of the chunks already received and
> those coming in?

No.  The partial body length headers have no implications for the data
stream into which they are inserted.  Their only purpose is to tell you
(eventually) when you get to the end of the data.  So your decompression
must be done on the data stream taken as a whole, without regard to the
presence of any partial body length headers.

Two other points.  First, within the encrypted packet is a compression
packet, as you said; but within the compression packet is typically a
literal data packet.  Three layers of packets typically exist for this
usage, not two.

Second, each packet (encryption, compression, literal) needs some kind
of length specification associated with it.  You can put the full packet
length in the header, if you know it in advance (which will not be the
case if you are streaming).  You can use partial body length.  Or You
can use the indefinite length type, which means that the packet goes
all the way to the end of the data.

The point is that this has to be done at each of the three layers.  If you
are using partial body lengths (PBLs), this must be done at each level.
The literal packet will use PBLs; then this data is compressed, and
the output of the compression gets PBLs inserted; and then the data is
encrypted, and the output of the encryption gets PBLs inserted.  There is
no logical connection between the packetizing at the different levels.
They could use different size partial body packets and insert their
PBLs at different points.  The PBLs are logically separate from the data
stream in which they are inserted.

Hal Finney

content-class: urn:content-classes:message
Subject: Compression and partial length chunks
Date: Tue, 23 Dec 2003 17:29:51 -0500
From: "Hasnain Mujtaba" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi all, 

I was wondering if someone could help clarify some issues for me.  It is
not clear to me from the RFC2440 how compression works when using
partial body length headers.  

I am working on an application that will support both inbound and
outbound streaming. Encrypted packets will be coming in over FTP and the
application will have to decrypt and decompress the chunks on the fly so
they can be written to a file or sent out over the network. Similary,
the application will encrypt an incoming plain text file using partial
length encoding. In both cases, the size of the incoming file (encrypted
one and the plain text is not known).

As I understand it, first the Sym. Encrypted & Integrity Protected
header is sent out by the sender, then only one CompressedDataPacket
header is encrypted and sent out in the first chunk, the subsequent
chunks are compressed and then encrypted and enclosed in the partial
body length header and then sent out. 

The receiving side (i.e my application) receives the Sym. Encrypted &
Integrity Protected header. It starts decryting the subsequent chunks.
In doing so, the receiver finds the CompressedDataPacket header.
Therefore, the receiver can start decompressing the subsequent chunks
after decrypting them.

Are the chunks independent in that can they be decrypted and
decompressed by the receiver without buffering them with other chunks?
E.g, if a 8192 bytes chunk is received enclosed within a partial body
length header, can the receiver take the chunk's payload and decrypt it
and then decompress it independently of the chunks already received and
those coming in?

I guess, if I understood the procedure for creating an
encrypted/compressed chunk, it would make it easier to understand the
decryption procedure. 

Any help would be greatly appreciated!

Regards 
Hasnain.

Subject: Re: Valid OpenPGP keys without self-signature?
To: [email-masked]
From: [email-masked]
Date: Tue, 23 Dec 2003 23:16:49 +0100
Sender: [email-masked]

You guys are great! Within 24 hours, I received complete answers
to all of my questions. So I now know that:

(1) the PKI setup of "Robert Bosch GmbH" uses obsolete key types,
    but does _not_ contain a (known) major security flaw. This
    means that they will have to change their product at some
    time in the future but are not going to do any emergency
    product switch within the next few weeks. (As a result of
    this, I will have to find a solution that interoperates with
    their current setup.)

(2) it should be possible to interoperate to their PKI with
    OpenPGP products (maybe after some fiddling);

(3) I can import their keys without self-signature not only into
    older PGP versions, but also into an up-to-date GnuPG
    version.

Thanks a lot to all who helped! (Lars, Lutz, Vedaal, Ian and
Konrad)

- Wolfgang Redtenbacher

Date: Mon, 22 Dec 2003 22:22:06 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: The signer's user ID subpacket and attribute IDs
Mail-Followup-To: [email-masked]
Sender: [email-masked]

The current draft specifies the "Signer's User ID" subpacket as the
user ID that is "responsible for the signing".  When I documented the
existing attribute ID design, I was concerned that someone might try
and make a Signer's User ID for an attribute packet which raises a
problem since there is no way for the verifier of the signature to
know if a given Signer's User ID should be parsed as a text or
attribute user ID.  Because of this (and a slight worry about massive
signatures that contain embedded JPEGs), I asked Jon Callas to put in
"This subpacket is not appropriate to use to refer to a User Attribute
packet."

This has always bothered me, since I feel that an attribute user ID
should be as useful as a regular text user ID.

Here are two different proposals to fix this.  I'm not strongly wedded
to either solution in particular.  I just want to address the
limitation.

1) Change the definition of the Signer's User ID to be the SHA-1 hash
   of the contents of the User ID (whether textual or attribute) in
   question.  The usual user ID hashing rules apply (0xd1/0xb4 + len +
   contents).  This eliminates the problem by making all Signer's User
   ID subpackets parsable in the same way.  Impact from this change
   should be minimal as nobody (so far as I know) has implemented
   Signer's User ID yet.

or

2) Add a new signature subpacket, which is an attribute user ID
   counterpart to the Signer's User ID subpacket, defined identically
   to the current Signer's User ID subpacket, but used for attribute
   user IDs.  This eliminates the problem by making it clear how the
   subpacket needs to be parsed (text or attribute).

Note that #1 has the detail that a signature containing a Signer's
User ID subpacket of a user ID that the verifier does not have on his
local copy of the key does not "give away" the contents of that user
ID.  I can see this as an advantage or a disadvantage, depending on
what the signer is trying to accomplish.

#2 has the detail that a signature could conceivably contain an
embedded attribute ID, and thus (for example) contain the photograph
of the signer.  Like #1, I can see this as an advantage or
disadvantage, depending on what the signer is trying to accomplish.
(It also can lead to really large signatures).

As I said before, I'm not wedded to either solution.  I would like to
address the limitation though.

David

Date: Mon, 22 Dec 2003 19:55:02 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: "Other" compression algorithms
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In bis-09:

Section 9.1 says "Implementations MAY implement any other algorithm."

Section 9.2 also says "Implementations MAY implement any other
algorithm."

Then section 9.3 says "Implementations MAY implement ZLIB."  That text
was written before BZip2 was added to the draft, and should probably
read "Implementations MAY implement any other algorithm." like the
other two sections.

David

Date: Mon, 22 Dec 2003 19:51:56 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: From-plus-a-space
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In bis-09, section 7.1 ("Dash-Escaped Text") says "An implementation
MAY dash escape any line, SHOULD dash escape lines commencing "From "
(note the space), and MUST dash escape any line commencing in a dash."

However, in the draft, the mention of "From " is broken over two
lines as:

   "From
 "

This makes the text a little unclear, despite the parenthetical "note
the space".  Also, once this draft becomes an RFC, people will be
HTMLizing it, and printing it with various non-monospaced fonts, and
so on.  I suggest changing the "(note the space)" to "(the string
'From' followed by a space)".

David

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: Valid OpenPGP keys without self-signature?
Date: Mon, 22 Dec 2003 19:03:21 +0100
Sender: [email-masked]

--Boundary-02=_sHz5/QbZMAzT63f
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

> only the trust center signature on them.
[...]
> (1) Are such keys a security problem?

The key material in itself should be pretty secure. The signature also shou=
ld=20
be ok, as long as it stays valid.

I personally would not use V3-keys for another reason: you can change the=20
creation date of the key without changing the keyID and fingerprint. This=20
means you can easily invalidate the signature without changing the main=20
identifiers of the key (key material, keyID, fingerprint). It can be very=20
annoying to try to verify a key that seemingly is the correct one, but has=
=20
been altered enough to make the signature invalid(*). V4 keys change their =
ID=20
and fingerprint whenever you change ANY bit in the public part of the key.

(*)Assuming that PGP2.x does verify the creation date of the key versus the=
=20
creation date of the signature. This is the only part that invalidates the=
=20
signature.

	Konrad

--Boundary-02=_sHz5/QbZMAzT63f
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_sHz5/QbZMAzT63f--

Date: Mon, 22 Dec 2003 11:59:36 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: Valid OpenPGP keys without self-signature?
Sender: [email-masked]

> be very happy about any answers to the above questions.

Wolfgang,

I'm afraid you are on the pointy end of a sharp stick.

You are right that it is not strictly illegal, but as
Lutz says, it will become illegal at some hopefully near
stage. To all intents and purposes, it is already illegal
structure, de facto, and you can expect no current or
future OpenPGP product to accept it.

The reason for this is complexity:  OpenPGP's key structure
is a bit of a mess.  There is way too much freedom, in all
the options and subpackets and arrays of packets and what
have you.

At a data level, this is fine, wonderful, uplifting, even.

But at the level of security coding, this is a nightmare.
In practice, in a secure program, every little execption
adds to every other little exception to create the
potential for a security failure.  Either we have to as
a community deal with the interrelated exceptions - all
of them, in every body of code - or we have to remove
the exceptions.

The latter course is compelling, and in this particular
case, the group debated the self-signed issue a year or
so back, and came to the conclusion to deprecate un-self-
signed keys.

For your company - it is a matter of explaining that
they are technically secure, but they will not inter-
operate.  Their keys have been "declared unsafe".

That doesn't mean it is insecure.  Consider it like
taking the Mercedes in for the registration check and
being told the brake lines need to be replaced.  You
know the lines are good for another 5 years, but once
the standard is in place, that's it.  Out they go.

If they don't want to interoperate, then that's fine.
But, if they want to interoperate, they have to do it
on both the basis of security *and* the standard.

iang

PS: it would seem that a much bigger problem for them,
if they *do* want to interoperate, is that they want to
move over to V4 keys at some stage.  So maybe the way
to approach this is to leave the V3 keys in place, and
start issuing V4 keys in the future?

Date: Mon, 22 Dec 2003 06:16:30 -0800
To: [email-masked]
Cc: 
Subject: Re: Valid OpenPGP keys without self-signature?
From: <[email-masked]>
Sender: [email-masked]

>During OpenPGP interoperability tests, I have recently come across

[...]

>As I either have to find a solution to this interoperability problem

[...]

can't each user simply just self-sign the key as soon as it is received,

and this should then allow it to be imported into gnupg 1.2.x / pgp 8.x
?

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Valid OpenPGP keys without self-signature?
Date: Mon, 22 Dec 2003 11:35:59 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 15
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Mon, 22 Dec 2003 11:35:59 +0000 (UTC)
Sender: [email-masked]

Subject: Valid OpenPGP keys without self-signature?
To: [email-masked]
From: [email-masked]
Date: Mon, 22 Dec 2003 11:38:30 +0100
Sender: [email-masked]

My questions now are:

- Wolfgang Redtenbacher

Date: Fri, 12 Dec 2003 15:38:53 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: Konrad Rosenbaum <[email-masked]>
Cc: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Sender: [email-masked]

Konrad Rosenbaum wrote:
> 
> On Thursday 11 December 2003 19:04, David Shaw wrote:
> > I disagree we need to change anything here.  There is already only one
> > separator permitted.  Using your example:
> >
> >   Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial
> >
> > The second instance of colon-space is NOT a separator.  It's just part
> > of the value.
> 
> As long as the line is not split, you are correct.

Knowing how coders make different assumptions, and have
different scanning tools available to them, even this could
cause some surprises.  For e.g., in list based languages,
popping is more natural than parsing left-to-right.

Here's some perl:

perl -e ' $x = "Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial"; @a = (split(": ", $x)); $_ = shift(@a); print "$_\n"; /Version/ && print pop(@a), "\n"; '

...
> I'm a newbie to implementing OpenPGP - so please forgive me, if my question is
> stupid: why consider the additional headers at all? They seem to me to only
> have any value to human readers and none at all to OpenPGP itself, since all
> important information is already encoded into the binary message blocks (once
> you got them out of their armor). Is there any technical reason for the RFC
> not saying "Implementations shall ignore header lines."?

This is meta-part of the issue.  Currently, the ID says:

   "OpenPGP should consider improperly
    formatted Armor Headers to be
    corruption of the ASCII Armor."

I wonder whether that is too strong.  It seems reasonable
to say that implementations may attempt to parse beyond and
ignore improperly formatted headers.  Perhaps with warnings.

As we have not gone to any great extent to define why the
optional ascii armour headers are important, it seems odd
to treat them as if they are important enough to be capable
of breaking the armoured message.

iang

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Date: Fri, 12 Dec 2003 18:44:26 +0100
Sender: [email-masked]

--Boundary-02=_95f2/hnr1WRFCZF
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Thursday 11 December 2003 19:04, David Shaw wrote:
> I disagree we need to change anything here.  There is already only one
> separator permitted.  Using your example:
>
>   Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial
>
> The second instance of colon-space is NOT a separator.  It's just part
> of the value.

As long as the line is not split, you are correct.

> This isn't very complicated.  I'd be quite surprised to hear of any
> parser that didn't do:
>
> a) Find the leftmost colon-space.
> b) The string to the left is the key.
> c) The string to the right is the value.
>
> That's how email works (note the subject line of this message has two
> colons!), how news works, and how OpenPGP works.

With one notable difference: in the case any MTA splits headerlines, it wil=
l=20
add space(s) in front of the next line, which is defined to continue the li=
ne=20
in RFC822. When a MUA or MTA splits body lines it will not add anything=20
(maybe except for some ">" characters). So the receiving system will not be=
=20
able to tell the difference between a new header line an a continuation.

I'm a newbie to implementing OpenPGP - so please forgive me, if my question=
 is=20
stupid: why consider the additional headers at all? They seem to me to only=
=20
have any value to human readers and none at all to OpenPGP itself, since al=
l=20
important information is already encoded into the binary message blocks (on=
ce=20
you got them out of their armor). Is there any technical reason for the RFC=
=20
not saying "Implementations shall ignore header lines."?

        Konrad

--Boundary-02=_95f2/hnr1WRFCZF
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_95f2/hnr1WRFCZF--

Date: Fri, 12 Dec 2003 10:43:46 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Sender: [email-masked]

[email-masked] wrote:
> 
> On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote:
> >
> > Such as:
> >
> > Version: 1.0.0 non-commercial, upgrade to
> > Version: 2.0.0-commercial
> >
> > When the line slicing behaviour is set to (about) column 42.
> 
> If I have to set my line width to 42, your mail system is so broken
> that I don't need to talk to it. 72 is reasonable, and and one should
> expect lines exceeding 80 characters to be wrapped. Anything under 68 is
> unreasonably small. I, for example, am using 72 character lines in my
> editor (vim).

It does appear to be the consensus that there
is no need or desire to change the ID on this
issue.  However, I'm not seeing a lot of real
consideration of the real points here.  So  I'm
unclear here whether to keep kicking this dying
horse, or perhaps Derik could rule on closing
it?

?  I disagree with the above logic on the
following grounds:

   OpenPGP is not only used for mail, and in
   fact takes great care to be more universally
   useful (scan the ID for the word "mail", I
   just did!).  We here should also strive to
   move from the particular to the general, when
   looking at examples, and back again.

   Security standards are not built on such
   considerations of "yours is broken because
   I don't like your numbers."  Bad software
   is certainly built with those sorts of
   criteria, but bad software is not what we
   are about here.  This is about security,
   so detail is important.

   The offending number chosen was related to
   the example;  the point remains with an
   example of a different number.  You pick.

   Notwithstanding many peoples' desires to
   impose their views of how mail works on
   the rest of the world, there are other
   mail considerations in the future:  PDAs
   and phones have smaller screens, for example.
   Web mailers and hush-style mailers can be
   very unkind to formatters.  Chat is replacing
   email....  the list goes on - if OpenPGP is
   to be based on the email view of the past,
   then, we should all stop work on it right
   now.

The greatest success comes when multiple
competing implementations communicate with
ease, and without games.  Here we have a case
where it is apparently easy to legally create
a correct message that gets turned into a
recipient message of indeterminate legality
by transport.

Fixing this costs nobody much at all [1].

> if (!(ptr=(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=' ')
>         exit(1);

Please make sure you read the entire example.

That doesn't decide which line of the two lines
in the previous text, post-slicing, goes on to
become the dominating one.

The game to play in security programming is to see
if a) we can confuse the other party, and b) we can
create a security breach out of a confusion.

We've shown a).  I grant b) is a little harder, as
optional headers aren't supposed to be "used" for
such things.  But, who knows what adventurous souls
have in their minds for the future... [2]

iang

[1] I just thought late last night how to breach
b)...  Imagine you are a company selling a device
that filters on the headers.  Imagine that you
make commercial decisions on the basis of those
headers.  (Because that's all you can read.)  Then,
an enterprising young chap realises that all he
has to do is to slice the headers, and they are
still human-readable, but they bypass the filtering
of the proxy that handles incoming messages.

marketing reference: NY AG v. WS == 1.3 bn.

[2]  the guys
over at PGP Inc might want to rewrite their
comment to be a bit shorter than the ASCII-
Armoured data lines - rule of thumb - and to
change the extra ": " to some other symbol.

If they haven't already done these steps,
I'd be very surprised!  Also, they should
reject sliced headers, or suggest we change
the ID on that point.  But, no real cost.

GPG might want to detect and warn that the
headers appear corrupted and can be fixed
easily with an editor, rather than silently
bailing on ID strictness.

Date: Fri, 12 Dec 2003 04:56:22 +0000
From: [email-masked]
To: Ian Grigg <[email-masked]>
Cc: David Shaw <[email-masked]>, [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Content-Conversion: prohibited
Sender: [email-masked]

--YG0IFkGWIt6MbjRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote:
>=20
> Such as:
>=20
> Version: 1.0.0 non-commercial, upgrade to
> Version: 2.0.0-commercial
>=20
> When the line slicing behaviour is set to (about) column 42.

If I have to set my line width to 42, your mail system is so broken
that I don't need to talk to it. 72 is reasonable, and and one should=20
expect lines exceeding 80 characters to be wrapped. Anything under 68 is
unreasonably small. I, for example, am using 72 character lines in my
editor (vim).

> > This isn't very complicated.  I'd be quite surprised to hear of any
> > parser that didn't do:
> >=20
> > a) Find the leftmost colon-space.
> > b) The string to the left is the key.
> > c) The string to the right is the value.
>=20
>=20
> How do parsers handle the above case?  Not that it's

Do a) with strchr(3) or memchr(3) by finding a colon and then check that
the next character is a space. If it's not, abort the message. The
code is:

if (!(ptr=3D(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=3D' ')
	exit(1);

> important.

--=20
Brian M. Carlson <[email-masked]> 0x560553e7

--YG0IFkGWIt6MbjRk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--YG0IFkGWIt6MbjRk--

Date: Thu, 11 Dec 2003 14:01:29 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Sender: [email-masked]

David Shaw wrote:
...

Sorry, I should have spelt this out:

> > On reflection, I think it should not be permitted.
> >
> > The reason for this is that when you combine
> > it with the line slicing behaviour, then some
> > games are possible:
> >
> > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial
> >
> >
> > Could result in an embarressing split.

Such as:

Version: 1.0.0 non-commercial, upgrade to
Version: 2.0.0-commercial

When the line slicing behaviour is set to (about) column 42.

> This isn't very complicated.  I'd be quite surprised to hear of any
> parser that didn't do:
> 
> a) Find the leftmost colon-space.
> b) The string to the left is the key.
> c) The string to the right is the value.

How do parsers handle the above case?  Not that it's
important.  The thing to realise here is that the
additional separator's presence, coupled with the
ability of line slicing by mailers, introduces an
exceptional case that's simply better off made
illegal.

The spirit of ascii armouring is to get the message
through in the face of aggressive and unpredictable
actions of many users' mailers.  In this case, I
think this spirit is preserved by making the optional
Armor Headings as simple as possible, and encouraging
strict legality.

iang

PS: actually, the above case is "legal".  If there
was no separator in the second split line, then
the armouring is broken ("OpenPGP should consider
improperly formatted Armor Headers to be corruption
of the ASCII Armor."), and the message should not be
accepted.  But that's hardly a reliable strategy.

Date: Thu, 11 Dec 2003 13:04:02 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Dec 11, 2003 at 12:17:20PM -0500, Ian Grigg wrote:
> 
> Ian Grigg wrote:
> > 
> > Peter Gutmann wrote:
> 
> > > Is it really a line-length issue, or something else like the
> > > presence of the second colon in the line for something that's
> > > scanning for <string>:<string>?
> 
> Peter brought up the issue of the additional
> ": " separators and I opined that the draft
> should be clearer on this issue.
> 
> On reflection, I think it should not be permitted.
> 
> The reason for this is that when you combine
> it with the line slicing behaviour, then some
> games are possible:
> 
> Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial
> 
> 
> Could result in an embarressing split.  Now, that's a superficial
> and ignorable result, and only presented for the sake of showing
> what might happen.
> 
> I can see no good reason to leave multiple separators as permitted
> in the ID, so I'd suggest adding a simple restriction such as "Only
> one separator is permitted."

I disagree we need to change anything here.  There is already only one
separator permitted.  Using your example:

  Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial

The second instance of colon-space is NOT a separator.  It's just part
of the value.

This isn't very complicated.  I'd be quite surprised to hear of any
parser that didn't do:

a) Find the leftmost colon-space.
b) The string to the left is the key.
c) The string to the right is the value.

That's how email works (note the subject line of this message has two
colons!), how news works, and how OpenPGP works.

David

Date: Thu, 11 Dec 2003 12:17:20 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Sender: [email-masked]

Ian Grigg wrote:
> Peter Gutmann wrote:

> > Is it really a line-length issue, or something else like the presence of the
> > second colon in the line for something that's scanning for <string>:<string>?

Peter brought up the issue of the additional
": " separators and I opined that the draft
should be clearer on this issue.

On reflection, I think it should not be permitted.

The reason for this is that when you combine
it with the line slicing behaviour, then some
games are possible:

Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial

Could result in an embarressing split.  Now, that's
a superficial and ignorable result, and only presented
for the sake of showing what might happen.

I can see no good reason to leave multiple separators
as permitted in the ID, so I'd suggest adding a simple
restriction such as "Only one separator is permitted."

As another observation, the use of the term "Armour
Headers" appears overloaded.  Could this be clarified
by changing the current usage into:

   Armour Headers:  -----.*PGP.*-----
   Optional Headers:  Version: ////

Or even Comment Headers, or Optional Armour Headers,
or Optional Comments?

iang

Date: Wed, 10 Dec 2003 12:06:37 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Sender: [email-masked]

Peter Gutmann wrote:
> 
> Ian Grigg <[email-masked]> writes:
> 
> >It appears that PGP 8 is breaking the spirit and intent of the ascii
> >armouring format, if not the "letter of the law."
> >
> >What it is doing is in essence putting in a Version that is too long for some
> >mailers' line slicing paramaters. The result is that people receive this:
> >
> >Version: PGP 8.0.2 - not licensed for commercial use:
> >www.pgp.com
> 
> Is it really a line-length issue, or something else like the presence of the
> second colon in the line for something that's scanning for <string>:<string>?

Well, the slicing that is occuring is in the
transmission process, in this case, so I am
theorising that this is a line length issue.
(I haven't been able to check this, because
the person sending the dodgy email doesn't
understand what I am asking...  That's the
way it is in userland.)

But you raise a point I hadn't seen, the line
above is badly formatted in a second way, in that
it includes two ": " separators.

Examination of the para in section 6.2, page 50:

    The format of an Armor Header is that of a key-value pair.  A colon
    (':' 0x38) and a single space (0x20) separate the key and value.
    OpenPGP should consider improperly formatted Armor Headers to be
    corruption of the ASCII Armor.  Unknown keys should be reported to
    the user, but OpenPGP should continue to process the message.

indicates that this is not explicitly ruled
against, but I'd say it is implicit stated
that only one separator is permitted.

Or, in the alternate, if two separators are
permitted, then the text should be clarified,
as different parsing strategies will result
in confusion.

Should there be only one ": " or are additionals
permitted in the value and thereafter ignored?

As the ID says "OpenPGP should consider improperly
formatted Armor Headers to be corruption of the
ASCII Armor," I suggest this be explicitly
clarified to improve interworkability.

> For a mailer to be unable to handle a 66-char line sounds pretty... broken.

My view is that when it comes to lines, all
mailers seem broken.  But what do I know?

Mostly, this seems to occur when going from
one distinct community to another.  Within
a particular flavour of mailers, they all
understand each other, but across distinct
communities, the mailers have different
ways of dealing with things.

I did a quick straw poll today, and found

   76,72,76,58,72,56,72,72

A few points:

* In communities where they always reply
with full interpolation, and full (audit)
chains of replies, sometimes people set
the width to be very narrow, because they
end up with scores (i.e., 20) series of
replies, which scan across to the right
hand columns.

* from the *same* email, 50-72!  Which
makes me think that this guy had his mailer
set up for proportional text.  Another couple
of emails I wasn't able to work out what was
going on, but inserted lines seemed to be
part of the bug set.

* I've just noticed another thing about
the community stuff - Macs tend to interpret
a trailing space as a continuation character,
and that sometimes works and sometimes doesn't
(I suppose it always works on Macs).

* If you look at my original mail, you will see
that the sliced line I presented was broken,
but in Will Price's reply, it had been repaired,
presumably by his mailer, so in his view, there
was apparently nothing wrong!

iang

Date: Wed, 10 Dec 2003 19:47:10 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Cc: [email-masked]
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:

>It appears that PGP 8 is breaking the spirit and intent of the ascii
>armouring format, if not the "letter of the law."
>
>What it is doing is in essence putting in a Version that is too long for some
>mailers' line slicing paramaters. The result is that people receive this:
>
>Version: PGP 8.0.2 - not licensed for commercial use:
>www.pgp.com

Is it really a line-length issue, or something else like the presence of the
second colon in the line for something that's scanning for <string>:<string>?
For a mailer to be unable to handle a 66-char line sounds pretty... broken.

Peter.

Date: Tue, 09 Dec 2003 21:45:06 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: Will Price <[email-masked]>
Cc: [email-masked]
Subject: Re: armour pierced with PGP 8 arrow
Sender: [email-masked]

Will Price wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I see no problem here and no need for any change to the draft or a
> product. 66 columns is at least 10 columns shorter than any
> conventional recommended line length. If your mailer wrapped that line,
> it would be almost equally likely to wrap the ASCII armor itself (65
> columns -- 11 less than the OpenPGP limit).

I've observed this problem many times, myself, but
it didn't occur in this recent case.

> In addition, your claims are patently contrary to the exact words and
> spirit of the draft. Please see section 6.3 where it says: "The encoded
> output stream must be represented in lines of no more than 76
> characters each."

You are correct, I did not see that part, so it
would appear that PGP 8 is within the letter of
the draft.

> Thus, whatever the problem you are seeing is, and based on observing
> the line length used in your own message on this topic, it appears to
> be related specifically to a low limit somewhere in your configuration,
> it is not a fault of PGP nor the OpenPGP draft.

This behaviour was observed with ordinary people
out there with ordinary mailers, not my own (which
is set to not slice lines at all).  That is, users
failed to communicate because their mailers sliced
the lines.

I make no comment on whether any particular product
should change, rather, I was suggesting that there
be attention brought to the line length issue within
the draft.  As line length in mailers is a moving
target, one can only be general and flexible.

As an aside, in the ascii armoured messages that
my company produces, we used to use the same or a
similar number as various other products (I guess
that would be about 65), but dropped it down to 48
about 2 years back because of continual problem
with mailers.

That's just an old observation, to match the new
one I've just seen in users' setups - if nobody
else has seen those problems then there isn't an
issue.  I don't imagine that two data points are
representative.

iang

From: Will Price <[email-masked]>
Subject: Re: armour pierced with PGP 8 arrow
Date: Tue, 9 Dec 2003 17:04:48 -0800
To: [email-masked]
Sender: [email-masked]

I see no problem here and no need for any change to the draft or a 
product. 66 columns is at least 10 columns shorter than any 
conventional recommended line length. If your mailer wrapped that line, 
it would be almost equally likely to wrap the ASCII armor itself (65 
columns -- 11 less than the OpenPGP limit).

In addition, your claims are patently contrary to the exact words and 
spirit of the draft. Please see section 6.3 where it says: "The encoded 
output stream must be represented in lines of no more than 76 
characters each."

Thus, whatever the problem you are seeing is, and based on observing 
the line length used in your own message on this topic, it appears to 
be related specifically to a low limit somewhere in your configuration, 
it is not a fault of PGP nor the OpenPGP draft.

- - Will

On Dec 9, 2003, at 10:37 AM, Ian Grigg wrote:
> It appears that PGP 8 is breaking the spirit and intent
> of the ascii armouring format, if not the "letter of the
> law."
>
> What it is doing is in essence putting in a Version that
> is too long for some mailers' line slicing paramaters.
> The result is that people receive this:
>
>
>
>
> -----BEGIN PGP MESSAGE-----
> Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com
>
> qANQR1DBw04Dxrpn2akpjMkQD/457fxRygbnZG7jAssMb4JuMeXqZdXmMhcGetrm
> ...
> -----END PGP MESSAGE-----
>
>
>
> Now, reading from the 28th October 2003 draft, it appears
> that there is no comment on line length - but there are
> comments on the line sanctity and on UTF-8 in the Comment
> field that are apropos.
>
> To cut the gordian knot, I propose:
>
>
> 1. changing the comment at the end of p49 to
> include a warning on line length:
>
>     ... The
>     header lines, therefore, MUST start at the beginning of a line, and
>     MUST NOT have text following them on the same line (BEWARE OF
>     USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS).
>
> (addition in caps...) (as a suggestion only).
>
>
> 2. moving the "Comment" comment out of that
> section and/or expanding it to include a
> comment about long lines.  Something like:
>
>
>    Armor Header contents are not strictly defined, so may
>    include UTF-8 strings and long lines.
>
>    However, the point of Armoring is to provide a clean
>    textual representation that survives transport over
>    pernickety systems such as email.  Consequently, if an
>    Armor Header includes such things as characters outside
>    the range of US-ASCII or too many characters, the Armored
>    message may not survive transport.
>
>
> (At the bottom of page 50.) (because it seems
> to apply equally to all armoured headers).
>
>
> 3.  It also seemed plausible to put in
> "rule of thumb" that the line length
> of headers should be no longer than
> the ascii armoured body line length.
>
>
> I'm not wedded to any of those, just
> thinking out aloud some thoughts on
> improving the ID so it best serves.
>
> iang
>
>
> PS: To compound this, it appears that GPG
> (1.2.2) is also rejecting these messages
> out of hand.  It would appear that GPG is
> in the right here, as there is this strict
> rule:
>
>    "OpenPGP should consider improperly formatted Armor Headers to be
>     corruption of the ASCII Armor. ..."
>
> (top of page 50).
>

- --
Will Price, VP Engineering
PGP Corporation

Date: Tue, 09 Dec 2003 13:37:00 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: armour pierced with PGP 8 arrow
Sender: [email-masked]

It appears that PGP 8 is breaking the spirit and intent
of the ascii armouring format, if not the "letter of the
law."

What it is doing is in essence putting in a Version that
is too long for some mailers' line slicing paramaters.
The result is that people receive this:

Now, reading from the 28th October 2003 draft, it appears
that there is no comment on line length - but there are
comments on the line sanctity and on UTF-8 in the Comment
field that are apropos.

To cut the gordian knot, I propose:

1. changing the comment at the end of p49 to
include a warning on line length:

    ... The
    header lines, therefore, MUST start at the beginning of a line, and
    MUST NOT have text following them on the same line (BEWARE OF
    USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS).

(addition in caps...) (as a suggestion only).

2. moving the "Comment" comment out of that
section and/or expanding it to include a
comment about long lines.  Something like:

   Armor Header contents are not strictly defined, so may
   include UTF-8 strings and long lines.

   However, the point of Armoring is to provide a clean
   textual representation that survives transport over
   pernickety systems such as email.  Consequently, if an
   Armor Header includes such things as characters outside
   the range of US-ASCII or too many characters, the Armored
   message may not survive transport.

(At the bottom of page 50.) (because it seems
to apply equally to all armoured headers).

3.  It also seemed plausible to put in 
"rule of thumb" that the line length
of headers should be no longer than
the ascii armoured body line length.

I'm not wedded to any of those, just
thinking out aloud some thoughts on
improving the ID so it best serves.

iang

PS: To compound this, it appears that GPG
(1.2.2) is also rejecting these messages
out of hand.  It would appear that GPG is
in the right here, as there is this strict
rule:

   "OpenPGP should consider improperly formatted Armor Headers to be
    corruption of the ASCII Armor. ..."

(top of page 50).

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Removing Elgamal signatures
Date: Fri, 5 Dec 2003 11:49:34 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 21
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Fri, 5 Dec 2003 11:49:34 +0000 (UTC)
Sender: [email-masked]

* Florian Weimer wrote:
> Lutz Donnerhacke wrote:
>> I'd like to oppose. ElGamal signatures are still useful,
>
> Useful for what?

I prefer more than one algorithm for a given task. That's all.
My personal opinion is not relevant to the removal of this packet type.

> objections to its design process), but this is no longer a convincing
> justification since we now have RSA at our disposal.

Do we use RSA right? Requiring SSP?

> Are you confident that no additional implementation traps will
> discovered?  With RSA, I have some confidence that the most important
> things are properly documented, but ElGamal signatures appear to be much
> more problematic.  Please keep in mind that this is the second case of
> such an implementation trap for the ElGamal signature scheme.

There are a lot of listed RSA attacks, too.

Date: Thu, 4 Dec 2003 23:51:35 +0100
To: Lutz Donnerhacke <[email-masked]>
Cc: [email-masked]
Subject: Re: Removing Elgamal signatures
From: Florian Weimer <[email-masked]>
Sender: [email-masked]

Lutz Donnerhacke wrote:

> I'd like to oppose. ElGamal signatures are still useful,

Useful for what?

In the past, your primary argument seems to have been the avoidance of
DSA (not because of patent problems, but because of rather theoretical
objections to its design process), but this is no longer a convincing
justification since we now have RSA at our disposal.

> despite there is a charge of signatures with some algorithmic errors.
> I'd prefer a paragraph describing the problem and advicing to not use
> keys of this charge.

Are you confident that no additional implementation traps will
discovered?  With RSA, I have some confidence that the most important
things are properly documented, but ElGamal signatures appear to be much
more problematic.  Please keep in mind that this is the second case of
such an implementation trap for the ElGamal signature scheme.

Date: Mon, 1 Dec 2003 21:05:28 -0800
Subject: Re: Removing Elgamal signatures
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I'm happy to remove it, if there's rough consensus that it be removed, 
myself. I just want to make sure that there is that consensus.

Elgamal sigs have been controversial from the start.

The main reason for them is to have a discrete-log public key system 
that parallels RSA in being able to both encrypt and sign. We've always 
known that Elgamal signatures were tetchy, and 2440 has finger-wagging 
in that direction, anyway.

In 1998, there was more reason to have a discrete-log encrypt+sign key 
than there is in 2004. There's very little reason to have them today.

Lutz has stated a preference for them remaining, but with exactly zero 
implementers of it, that sounds like something resembling rough 
consensus to remove them.

If we *don't* remove them, then they are part of the standard, but an 
interesting part of the folklore. If a brand new implemented came to me 
and asked about them, I'd reply something like the following:

"I don't see why you should implement them. They're a MAY, which means 
you don't have do. All signature algorithms are tetchy in that if you 
don't do them right, bad things can happen, but Elgamal sigs are even 
tetchier. The only people who did implement them removed them after 
some exasperating bugs showed up. If you implement them, then you have 
to make sure you don't put in some weird bug. If you do, people will 
say, 'I told you so.' If you do, anyone with a different implementation 
can't verify a signature -- you're the only one who does. I see a lot 
of bother for you and not much benefit. There are much better things 
for you to spend your time on."

I then hear in my head, "So why didn't you remove them from 2440+ when 
you had the chance? If they're such a pain that no one does them, why 
are they there at all?"

I don't have a good answer to that question. I say remove them, myself.

	Jon

Date: Mon, 01 Dec 2003 16:54:04 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Removing Elgamal signatures
Sender: [email-masked]

Ian Grigg wrote:
> >   c. Some change has to be made, because there is a bug.

Correction supplied by Micheal Young:
> The bug is in the GnuPG implementation, not the specification.

Thanks!  Delete c. then.

> [I'm neutral on whether to keep ElGamal signatures in the
> specification, but I wouldn't consider this a compelling factor.]

iang

Date: Mon, 1 Dec 2003 16:38:48 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Removing Elgamal signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Dec 01, 2003 at 02:48:17PM -0500, Ian Grigg wrote:

>   If there are O(1000) users of the ElGamal signature
>   algorithm, I'd say at first glance this does not qualify
>   as a major usage.
> 
>   Also, if GnuPG is the *only* implementation of this,
>   then that would seem to go against the spirit of the
>   "two implementations" rule.  (Although, not breached
>   in practice, as it is only a small part, I would guess.)

With regards to this point - very shortly, GnuPG will not be an
implementation of this.  The upcoming GnuPG (1.2.4) does not allow
users to do anything with Elgamal sign+encrypt keys except revoke
them.  It will not encrypt to them, it will not sign with them.  The
next large release (1.4) will not implement Elgamal sign+encrypt at
all.

> One thing I am not sure of - what is it useful for?  In the
> sense, does it do something that is highly prized and wanted?

In the past it was a patent-free signing algorithm that wasn't limited
to a 1024 bit key and a 160 bit hash.  Given that the RSA patent has
expired, I see little benefit to Elgamal signatures that RSA
signatures do not provide, and at the same time there are some
significant advantages to RSA (like speed.)

David

Date: Mon, 01 Dec 2003 15:22:32 -0500
From: Michael Young <[email-masked]>
To: [email-masked]
Subject: Re: Removing Elgamal signatures
Sender: [email-masked]

Hal Finney wrote:
 > It would be good to see these results made available because
 > they might turn out to be applicable to other types of keys
 > that we might consider in the future.

While we're at it, I'd like the specification to include references to
the research that was the rationalization for using a small "k" for
encryption.  Given that a full-width "k" is impractical (for cost
reasons) and every implementation will be inclined to use a small "k",
it's important that we make note of the security limitations.
This is particularly true when they're based on the *relative*
performance of known methods, which can change over time.

[As I recall, the published PGP6 source code contained a comment with
a reference.  I don't have that handy, but perhaps someone here does.]

Date: Mon, 01 Dec 2003 14:48:17 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Removing Elgamal signatures
Sender: [email-masked]

Lutz Donnerhacke wrote:
> 
> * Werner Koch wrote:
> > In the light of the recent GnuPG bug, where I accidently used the same
> > small sized k for signature creation as it is used for encrypting, I'd
> > very much like to drop the ElGamal signing ability all together from
> > OpenPGP.  AFAIK, GnuPG is the only implementation with support for
> > these keys and by now the about 1100 known primary and subkeys should
> > have been revoked.  Thus there won't be any interoperability problem
> > anymore.
> 
> I'd like to oppose. ElGamal signatures are still useful, despite there is a
> charge of signatures with some algorithmic errors. I'd prefer a paragraph
> describing the problem and advicing to not use keys of this charge.

Thinking about the case for removing ElGamal from the
standard, here are the pluses that I see:

  a. The purpose of the standard is to document the greater
  good set of common and useful algorithms to which most
  implementation should try and implement.

  If there are O(1000) users of the ElGamal signature
  algorithm, I'd say at first glance this does not qualify
  as a major usage.

  Also, if GnuPG is the *only* implementation of this,
  then that would seem to go against the spirit of the
  "two implementations" rule.  (Although, not breached
  in practice, as it is only a small part, I would guess.)

  b. Removing it from the standard would only mean that other
  implementations could then totally ignore it, instead of
  choosing to ignore it.  Also, removing it from the standard
  does not mean it can't be used - it just means that it is
  then a private algorithm.  If it later on proves to be
  of great use and other implementations adopt it, it can
  always be added back into a future version, or written
  into a informational draft.

  c. Some change has to be made, because there is a bug.  So
  it might simply be a balance between removing it - easy? -
  and writing in the bug-fixed-text - not so easy?

  d. Less is much better.  OpenPGP is already way too big and
  complex, which slows its implementation and thus slows
  its use, and its long term success.

Against the removal:

  A. This is supposed to be very late in the game for the
  production of the standard.  There should be very minor
  changes, if any.

On balance, there seems to be a good case for removing it
entirely!

( I speak here without any knowledge of the technical aspects
of the algorithm, of course!  Standard Dilbert comments
apply... )

One thing I am not sure of - what is it useful for?  In the
sense, does it do something that is highly prized and wanted?

That would perhaps be key in determining if removal is to
be warranted at this late stage...

iang

Date: Mon, 1 Dec 2003 12:31:11 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Removing Elgamal signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Dec 01, 2003 at 08:46:25AM -0800, Hal Finney wrote:
> It would be good to see these results made available because they might
> turn out to be applicable to other types of keys that we might consider
> in the future.

The paper is as yet unpublished, but the author's web page with
contact info is http://www.di.ens.fr/~pnguyen/

David

Date: Mon, 1 Dec 2003 11:58:12 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Removing Elgamal signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Nov 29, 2003 at 02:14:08PM +0100, Werner Koch wrote:

> In the light of the recent GnuPG bug, where I accidently used the same
> small sized k for signature creation as it is used for encrypting, I'd
> very much like to drop the ElGamal signing ability all together from
> OpenPGP.  AFAIK, GnuPG is the only implementation with support for
> these keys and by now the about 1100 known primary and subkeys should
> have been revoked.  Thus there won't be any interoperability problem
> anymore.

I agree with this.  Not too long ago, we removed a handful of unused
hash algorithms from the standard using the "less is more" rationale.
I see this as a similar case.

David

Date: Mon, 1 Dec 2003 08:46:25 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Re: Removing Elgamal signatures
Sender: [email-masked]

I'd like to see some technical details about the attack, if they can be
made available.  The ElGamal signature formulas are:

   r = g^k mod p
   s = (H-rx)/k mod q

The latter comes from rx+sk=H mod q.

I gather from what Werner has said that choosing small x and k in this
formula is unsafe.  This looks similar to a lattice problem where there
are relatively efficient articles for finding "small" vectors.  But I
am not that familiar with the mathematics.

Incidentally, in trying to research this I found that the attack by
Bleichenberger on poorly-chosen random numbers in DSA signatures had never
been published.  I'm not sure if that was a lattice based attack or not.

It would be good to see these results made available because they might
turn out to be applicable to other types of keys that we might consider
in the future.

Hal Finney

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Removing Elgamal signatures
Date: Mon, 1 Dec 2003 14:45:08 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 19
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Mon, 1 Dec 2003 14:45:08 +0000 (UTC)
Sender: [email-masked]

* Werner Koch wrote:
> In the light of the recent GnuPG bug, where I accidently used the same
> small sized k for signature creation as it is used for encrypting, I'd
> very much like to drop the ElGamal signing ability all together from
> OpenPGP.  AFAIK, GnuPG is the only implementation with support for
> these keys and by now the about 1100 known primary and subkeys should
> have been revoked.  Thus there won't be any interoperability problem
> anymore.

I'd like to oppose. ElGamal signatures are still useful, despite there is a
charge of signatures with some algorithmic errors. I'd prefer a paragraph
describing the problem and advicing to not use keys of this charge.

> If we can't agree on that, I'd suggest to declare type 20 keys to be
> Elgamal sign only - this way a new problem with this algorithm will
> at least not affect the encryption use.

It's only the parameter k, right? Type 20 keys are not limited to the small
parameter.