Subject: Clarification needed on compressed messages

From: David Shaw <[email-masked]>
Date: Wed, 30 Jul 2003 13:34:58 -0400

I was sent an interesting interoperability problem today with a signed
message that wouldn't verify in GnuPG.  After some examination, and
once the encryption was stripped off, it seemed that it was a message
of the form:

   signature packet + compressed packet (literal packet)

That is, a signature packet, followed by a compressed packet which
contained a literal packet.

In the grammar, the latest draft (and 2440 also) say that a "Signed
Message" is:

Signed Message :- Signature Packet, OpenPGP Message |
               One-Pass Signed Message

GnuPG (and it seems the new PGP) generate the One-Pass method, but
still accept the common SIG+LITERAL construction.  No problems there.

However, since a valid "OpenPGP Message" may be a "Compressed
Message", that would also make the message I received a legal
construction.

Is this the intent?  And if so, in a SIG+COMPRESSED(LITERAL) message,
is the SIG issued over COMPRESSED(LITERAL) or LITERAL ?

David

---

From: Derek Atkins <[email-masked]>
Date: 30 Jul 2003 15:45:23 -0400

> contained a literal packet.

This should be legal.  Strange, but legal..

> Signed Message :- Signature Packet, OpenPGP Message |

That's sounds right...

> is the SIG issued over COMPRESSED(LITERAL) or LITERAL ?

I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the
SIG should be issued over the COMPRESSED(LITERAL).  The only special
case that I know of is SIG+LITERAL, where the SIG is over the data
inside the literal and doesn't include the literal packet itself.

However, all other constructions should build the SIG over the
underlying PGP message object.

Just my $0.02.

> David

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: David Shaw <[email-masked]>
Date: Thu, 31 Jul 2003 23:19:17 -0400

> inside the literal and doesn't include the literal packet itself.

ONEPASS+LITERAL+SIG is another case.

> underlying PGP message object.

This sounds very reasonable to me.  I think a word or two to make that
clear in the draft would be helpful: something that indicates that
"bare" literal packets should have their contents hashed, but anything
else should be hashed whole.

David

Date: Thu, 31 Jul 2003 23:19:17 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Clarification needed on compressed messages
Mail-Followup-To: [email-masked]
Sender: [email-masked]

> inside the literal and doesn't include the literal packet itself.

ONEPASS+LITERAL+SIG is another case.

> underlying PGP message object.

This sounds very reasonable to me.  I think a word or two to make that
clear in the draft would be helpful: something that indicates that
"bare" literal packets should have their contents hashed, but anything
else should be hashed whole.

David

Date: Thu, 31 Jul 2003 17:15:16 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: signature woes and reconciliation, examples appreciated
Sender: [email-masked]

> From: [email-masked]
> I recently ran into trouble trying to calculate the hash needed to
> verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python 
> hopeful-implementation-to-be.

I've had someone else run into the same problem interpreting this part of
the spec.  The language about "first you hash this, then you hash that,
then you hash this other thing" seems very natural to me (I wrote much of
it after all), working with a programming interface where you pass data
incrementally into a hash context object.  But other people interpret
it as you did, that you produce a hash of the first part, then a hash
of the second part, then a hash of the third part, and somehow combine
these hashes together to get the final signature.

Hal Finney

Subject: signature woes and reconciliation, examples appreciated
Date: Thu, 31 Jul 2003 23:55:28 +0000
From: [email-masked]
To: [email-masked]
Sender: [email-masked]

I recently ran into trouble trying to calculate the hash needed to
verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python 
hopeful-implementation-to-be.

>From bis-08:

    (V3 sigs)
    5.2.2 The data being signed is hashed, and then the signature type
          and creation time from the signature packet are hashed (5 
          additional octets).  The resulting hash value is used in the
          signature algorithm.
    (sigs in general)
    5.2.4 Once the data body is hashed, then a trailer is hashed.

This led me to assume (+: concatenate):

    h = HASH( data body ) + HASH( trailer ) # based on the above
    final = HASH( h ) # inferred from 160-bit DSA requirement 

..which didn't work, sending me back to Google and eventually to the
GnuPG source. Long source-searching story shortened, I ended up with:

    final = HASH( data body + trailer )

..which didn't feel right, even though it evidently worked for gpg and
definitely worked for me. Things were somewhat reconciled when I found
a file named 'pgpformat.txt' from a PGP 2.x archive:

    pgformat.txt "Signature packet" section:

        Offset Length Meaning

        4       1     Length of following material that is implicitly
                      included in MD calculation (=5).
        5       1     Signature classification field (see below).
                      Implicitly append this to message for MD 
                      calculation.
        6       4     32-bit timestamp of when signature was made.
                      Implicitly append this to message for MD
                      calculation.

    pgformat.txt "Literal data packet, with filename and mode":

        Whne calculating a signature on a literal packet, the signature
        calculation only includes the raw literal plaintext data that
        begins AFTER the header fields..

Probabilities being what they are, I'm going to assume I'm on the
right track and grant myself an attaboy.

Up until this point I had been working *exclusively* with bis-08 and 
had no trouble at all working out packet structure, MPIs, etc.. Code
and pseudo-code examples helped out enormously. Just thought that this
might be one area where something blatantly obvious to the gurus might
leave the wannabes a little perplexed (color me perplexed). 

I suggest adding pseudo code to more (if not all) operations in the 
spec (which I'd be happy to contribute as I continue along).

Aloha,
the poiboy

Date: Wed, 30 Jul 2003 15:10:45 -0700
To: [email-masked]
Cc: 
Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys
From: <[email-masked]>
Sender: [email-masked]

On Tue, 29 Jul 2003 21:53:47 -0700 Will Price <[email-masked]> wrote:
>
>This sounds to me very much like a private key format issue and not
>a 
>general public key issue. We made many changes in PGP 8 to adhere
>to 
>the OpenPGP RFC more closely and improve compatibility with other
>>
>OpenPGP implementations. As part of this, changing the passphrase
>of a 
>key or generating a new key in PGP 8.0.2+ will use the newer 0xFE
>>
>private key format from the Secret Key Packet Formats section of
>the 
>draft.

this is very interesting !

i just tried it out by exporting a key generated in gnupg 1.2.2 with
the new s2k hash protection, which does not work in pre-8 pgp (except
for ckt build 9), but does work without any problems in pgp 8.0.2

now here is where it becomes sort of surprising:

[1] if the imported gnupg key which works in pgp 8.0.2, is exported from

pgp 8.0.2, it will still not work in pre-8 pgp

[2] if the passphrase is changed in pgp 8.0.2, and then exported, it
still does not work in pre-8

[3] if the passphrase is removed in 8.0.2, and exported without a passphrase,
 then it 'does' work, in pre-8

[4] if the passphrase is removed in 8.0.2, and then then changed in 8.0.2,
 and then exported,
it still acts like the original gnupg and does 'not' work in pre-8
(even though the passphrase is changed in 8.0.2 after the passphrase
has been removed, the new pgp 8.0.2 one is still not a simple s2k hash)

*but*

[5] if the key is imported from 8.0.2 into pre-8 with the passphrase
removed in 8.0.2,
and the passphrase then changed in pre-8, 
then it does work

(probably since pre-8 does not have the capacity to produce the complex
s2k hash, so it does not, whereas pgp 8.0.2 does have this capacity,
so it produces it by default for this type of key, but not for other
keys generated de-novo in pgp 8.0.2)

these different key import/export variations can become very hard to
keep track of ;-)

would suggest/request:

(a) pgp 8.0.x have something in the key properties that identifies
the s2k hash type (simple or complex-gnupg-type)

(b) pgp 8.0.x allow the user to choose the s2k hash type when changing
the passphrase,
{and in the interests of maximum intercompatibility, have the default
be the simple s2k hash, which can be then be changed in gnupg to the
more complex one if desired, but will stillbe compatible in pre-8 pgp
by default}

with Respect,

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: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: Clarification needed on compressed messages
From: Derek Atkins <[email-masked]>
Date: 30 Jul 2003 15:45:23 -0400
Lines: 51
Sender: [email-masked]

That's sounds right...

Just my $0.02.

-derek

Date: Wed, 30 Jul 2003 13:34:58 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Clarification needed on compressed messages
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Date: Wed, 30 Jul 2003 10:06:24 -0700
To: [email-masked]
Cc: 
Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys
From: <[email-masked]>
Sender: [email-masked]

On Tue, 29 Jul 2003 11:00:59 -0700 Hal Finney <[email-masked]> wrote:
>
>Hi, at NAI we have a report that some PGP 8.0 keys can't be imported
>into the NAI "E-Business Server" command line version 7.1.1.  Can
>someone post an 8.0-generated key and I will see if there are any
>problems importing it?  We want to be sure and retain compatibility
>between the various OpenPGP implementations if possible.

i posted two keys generated in pgp 8.02, here:
http://www.angelfire.com/pr/pgpf/pgp802keypairs.html

the first key, 'rsav4pgp8' was generated with a passphrase the same as
the name:  rsav4pgp8
and by default, uses aes-256 as the protect cipher

the second key, 'dhpgp8', was generated without a passphrase

both are usable in pgp pre-8 versions

the incompatibility you referred to was present in pgp 8.0,
when it was made compatible with the newer gnupg secret key format,
and keys that were exported from that version of pgp 8,
could not be used in pre-8 versions,

hth,

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

Date: Tue, 29 Jul 2003 21:53:47 -0700
Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys
Cc: [email-masked]
To: "Hal Finney" <[email-masked]>
From: Will Price <[email-masked]>
Sender: [email-masked]

This sounds to me very much like a private key format issue and not a 
general public key issue. We made many changes in PGP 8 to adhere to 
the OpenPGP RFC more closely and improve compatibility with other 
OpenPGP implementations. As part of this, changing the passphrase of a 
key or generating a new key in PGP 8.0.2+ will use the newer 0xFE 
private key format from the Secret Key Packet Formats section of the 
draft.

As we have already published this source, these changes are on our 
website. The affected files are:

  libs2/pgpsdk/priv/crypto/hash/pgpHash.c
  libs2/pgpsdk/priv/crypto/hash/pgpHashPriv.h
  libs2/pgpsdk/priv/crypto/hash/pgpChecksum.c
  libs2/pgpsdk/priv/crypto/hash/pgpChecksum.h
  libs2/pgpsdk/priv/crypto/keys/pgpKeyMan.c
  libs2/pgpsdk/priv/crypto/pubkey/pgpDSAKey.c
  libs2/pgpsdk/priv/crypto/pubkey/pgpKeyMisc.c
  libs2/pgpsdk/priv/crypto/pubkey/pgpKeyMisc.h
  libs2/pgpsdk/priv/crypto/pubkey/pgpRSAKey.c

Thanks!
-- Will

Will Price, VP Engineering
PGP Corporation

On Tuesday, July 29, 2003, at 11:00 AM, Hal Finney wrote:
> Hi, at NAI we have a report that some PGP 8.0 keys can't be imported
> into the NAI "E-Business Server" command line version 7.1.1.  Can
> someone post an 8.0-generated key and I will see if there are any
> problems importing it?  We want to be sure and retain compatibility
> between the various OpenPGP implementations if possible.

Date: Tue, 29 Jul 2003 11:00:59 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Incompatibility between NAI command line and PGP 8.0 keys
Sender: [email-masked]

Hi, at NAI we have a report that some PGP 8.0 keys can't be imported
into the NAI "E-Business Server" command line version 7.1.1.  Can
someone post an 8.0-generated key and I will see if there are any
problems importing it?  We want to be sure and retain compatibility
between the various OpenPGP implementations if possible.

Hal Finney

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User IDsubpacket?)
Date: Fri, 25 Jul 2003 17:03:02 -0400
Sender: [email-masked]

"Jon Callas" <[email-masked]> writes:
> 2440 already says that a top-level key must be able to sign.

That was my interpretation, but David read it another way and his
reading was not unreasonable.  I'd ask that we clarify the language.
Someone suggested saying "V4" rather than "that has a main key
and subkeys"; that works for me.

> I would like to be able to add a user id to someone's key because I want to,
> and I sign it myself, and let it go at that.

Jon presents a very reasonable example.  If it's for his personal use,
then it can be encapsulated in user agents (not the protocol), much
the way trust is today.  (In fact, the value in signing such a local
alias is debatable.)  I sorely wish that user agents offered this
already.

If you feel that this is something that should be exportable, then
indeed, we need to allow non-selfsigned identities.  I considered this
use, and had decided that I could live without it (in the protocol) in
order to impose a strict self-signature rule.  But I'm willing to
relent.  As Jon points out, keyservers and user agents can (and
probably should) impose their own restrictions at storage/import time.

Date: Fri, 25 Jul 2003 08:22:34 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Text "attributes"
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 23, 2003 at 10:40:51AM -0700, [email-masked] wrote:

> On Wed, 23 Jul 2003 07:05:29 -0700 David Shaw <[email-masked]>
> wrote:
> 
> >An interesting problem came up on one of the GnuPG mailing lists a
> >little while ago, and I thought I'd mention it here.
> >
> >A vision-impaired user was using GnuPG via a text reader and
> >mentioned that photo IDs were obviously not going to be that useful
> >to him.  The idea came up of using an additional attribute
> >subpacket to include a textual user ID together with the photo
> >attribute subpacket (both inside a single attribute ID), rather
> >like the HTML "alt" tag is used to provide a text string for when
> >an image can not be displayed.
> >
> >It would be easy enough to do: just define attribute subpacket 2 as
> >a UTF8 string type.  Implementations could handle it however they
> >chose.
> >
> >Note that I'm not necessarily suggesting this for 2440bis.  Just
> >something to think about in the future.
> 
> along those lines, it might be helpful to such users to have an
> 'audio id' (the key signer's greeting in his/her own voice,
> [possibly together with a few other spoken sounds, enough to enable
> a text-to-speech synthesis in that voice, so that the receiver can
> hear each pgp message read in the voice of that sender]),

I don't think that including speech sounds to enable text-to-speech is
appropriate in a OpenPGP key, but I'm not against a generic sound
attribute.  I imagine it could be used (among other things) as a "Hi
there, this is David, and my fingerprint is ABCD..."

It is of course more complex than text since we'd need to pick at
least one sound format to use (WAV? AU? MP3? something else?)  It is
also large.

(Again, just speculating idly about the future - not talking about
2440bis here).

David

To: Jon Callas <[email-masked]>
Cc: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
From: Derek Atkins <[email-masked]>
Date: 24 Jul 2003 11:19:03 -0400
Lines: 29
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> On 6/17/03 8:02 AM, "Derek Atkins" <[email-masked]> wrote:
> 
> > 
> > Sure, this is fine... Theoretically the real key owner should have
> > access to both private keys at the same time, so this shouldn't be an
> > issue.  Using a subpacket is fine.  I still belive this is a MUST ;)
> 
> I'm happy with any suitable solution, but I have a grumbly thing to add in.
>
> The general case of this is something we've called "signature stealing" and
> is always possible in a system that involves administrative processes. All
> you have to do is take someone else's signing key and start shopping around
> for someone who is careless enough (or bribable enough) to certify it. You
> can then claim that you made any signature made by the victim of that
> attack.

How does this attack work if the signature subkey _REQUIRES_ cross
certification?  If I wanted to assume your signature key, how am I
supposed to get your signature subkey to sign my primary key in order
to perform the (to-be-required) cross-certification?

-derek

Date: Wed, 23 Jul 2003 23:25:00 -0700
Subject: Re: PoP & Signer's User ID subpacket?
From: Jon Callas <[email-masked]>
To: Derek Atkins <[email-masked]>, David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 6/17/03 8:02 AM, "Derek Atkins" <[email-masked]> wrote:

> 
> Sure, this is fine... Theoretically the real key owner should have
> access to both private keys at the same time, so this shouldn't be an
> issue.  Using a subpacket is fine.  I still belive this is a MUST ;)

I'm happy with any suitable solution, but I have a grumbly thing to add in.

The general case of this is something we've called "signature stealing" and
is always possible in a system that involves administrative processes. All
you have to do is take someone else's signing key and start shopping around
for someone who is careless enough (or bribable enough) to certify it. You
can then claim that you made any signature made by the victim of that
attack.

This is not a flaw in OpenPGP, it is a flaw in the very nature of digital
signatures. It is a flaw that can be narrowed, but not solved, period end of
sentence. Furthermore, there is a sense in which it's bad security practice
to worry about it too much. The reason is that it creates an opportunity for
attack escalation; it makes the system more brittle. In simple words, the
harder it is to steal a signature, then the more valuable a bogus cert is,
and the more devastating such an attack is to the victim.

Please note that I'm not suggesting we do nothing here. Anything we do to
improve the bindings is good. I'm merely pointing out that we shouldn't get
wrapped around the axle over an issue that is unsolvable.

A clever signature thief can claim possession of those signatures, and
refuse to make more on the grounds that they have retired that key and are
now using *this* one.

This is merely another place where sticky human issues can't be obviated by
mathematics.

    Jon

Date: Wed, 23 Jul 2003 14:01:56 -0700
Subject: Re: Adding in BZ2 compression?
From: Jon Callas <[email-masked]>
To: Derek Atkins <[email-masked]>
CC: David Shaw <[email-masked]>, Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 7/22/03 10:54 AM, "Derek Atkins" <[email-masked]> wrote:

> Ok.  I have no real objections to adding the algo -- I'm just worried
> about the interop issues.
> 

There are no interop issues because it's a MAY feature that presently no one
implements. :-) Implementations are already supposed to handle both ZIP and
zlib prefs, so it shouldn't be an issue.

(Incidentally, here at PGP, we presently implement only ZIP, but decided to
add in both zlib and bz2 for a future major relase.)

> Also, we still need to show multiple implementations to progress to
> DRAFT standard, so if we're adding new features it might take longer
> to do so.  Have we had any OpenPGP Bakeoffs?

I think so, but I wasn't on top of this for a while. I'm willing to help
push this now.

    Jon

Date: Wed, 23 Jul 2003 10:40:51 -0700
To: [email-masked]
Cc: 
Subject: Re: Text "attributes"
From: <[email-masked]>
Sender: [email-masked]

On Wed, 23 Jul 2003 07:05:29 -0700 David Shaw <[email-masked]>
wrote:

>An interesting problem came up on one of the GnuPG mailing lists
>a
>little while ago, and I thought I'd mention it here.
>
>A vision-impaired user was using GnuPG via a text reader and mentioned
>that photo IDs were obviously not going to be that useful to him.
> The
>idea came up of using an additional attribute subpacket to include
>a
>textual user ID together with the photo attribute subpacket (both
>inside a single attribute ID), rather like the HTML "alt" tag is
>used
>to provide a text string for when an image can not be displayed.
>
>It would be easy enough to do: just define attribute subpacket 2
>as a
>UTF8 string type.  Implementations could handle it however they
>chose.
>
>Note that I'm not necessarily suggesting this for 2440bis.  Just
>something to think about in the future.

along those lines,
it might be helpful to such users to have an 'audio id'
(the key signer's greeting in his/her own voice, [possibly together with
a few other spoken sounds, enough to enable a text-to-speech synthesis
in that voice, so that the receiver can hear each pgp message read in
the voice of that sender]),
 
the text reader can do the implementation from the saved audio id attribute
(which can display the 'text' only attribute for deaf users who have
no use for the audio component)

for anyone interested in implementation specifically with the needs of
the disabled in mind,
here is a good site of helpful links:

http://www.wata.org/resource/highlighted_links.htm

with Respect,

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

Date: Wed, 23 Jul 2003 10:05:29 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Text "attributes"
Mail-Followup-To: [email-masked]
Sender: [email-masked]

An interesting problem came up on one of the GnuPG mailing lists a
little while ago, and I thought I'd mention it here.

A vision-impaired user was using GnuPG via a text reader and mentioned
that photo IDs were obviously not going to be that useful to him.  The
idea came up of using an additional attribute subpacket to include a
textual user ID together with the photo attribute subpacket (both
inside a single attribute ID), rather like the HTML "alt" tag is used
to provide a text string for when an image can not be displayed.

It would be easy enough to do: just define attribute subpacket 2 as a
UTF8 string type.  Implementations could handle it however they chose.

Note that I'm not necessarily suggesting this for 2440bis.  Just
something to think about in the future.

David

To: Jon Callas <[email-masked]>
Cc: David Shaw <[email-masked]>, Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Adding in BZ2 compression?
Date: 22 Jul 2003 13:54:01 -0400
Lines: 26
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> On 7/20/03 8:48 AM, "David Shaw" <[email-masked]> wrote:
> 
> >> I was basically against it until it was explained to me why people
> >> wanted it, and I ended up thinking, "Hmmm, we don't have a
> >> compression system in there that's newer than 1977, and customers
> >> are often right."
> > 
> > I rather like the idea of OpenPGP as an archival primitive.
> > 
> 
> That's what sold me, too.

Ok.  I have no real objections to adding the algo -- I'm just worried
about the interop issues.

Also, we still need to show multiple implementations to progress to
DRAFT standard, so if we're adding new features it might take longer
to do so.  Have we had any OpenPGP Bakeoffs?

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

To: Werner Koch <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: key flag for authentication
From: Derek Atkins <[email-masked]>
Date: 22 Jul 2003 13:47:22 -0400
Lines: 18
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> On Thu, 17 Jul 2003 21:13:41 -0400, David Shaw said:
> 
> >> Is there a consensus for this? I'm happy with anything, myself.
> 
> > I support it.
> 
> Me too of course.

Ok, looks like we've got concensus on this...

-derek

Date: Mon, 21 Jul 2003 12:38:06 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Adding in BZ2 compression?
Mail-Followup-To: Jon Callas <[email-masked]>, Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Sun, Jul 20, 2003 at 02:35:14PM -0700, Jon Callas wrote:

> > How about adding:
> > 
> > Note that without the ability to rewrite a self-signature,
> > interoperability issues may occur when the same key is used in more
> > than one implementation.  Implementations may wish to check keys
> > upon import to ensure that the preferences on the key match the
> > reality of the implementation.
> > 
> > That doesn't mandate anything, but does call attention to the problem.
> > I guess the last line could be a SHOULD if there was a desire to make
> > it stronger.
> 
> I put in:
> 
> It is good practice to verify that a self-signature imported into an
> implementation doesn't advertise features that the implementation doesn't
> support, rewriting the signature as appropriate.

Excellent.  That works for me.

David

Date: Sun, 20 Jul 2003 14:35:14 -0700
Subject: Re: Adding in BZ2 compression?
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>
CC: Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 7/20/03 8:48 AM, "David Shaw" <[email-masked]> wrote:

>> I was basically against it until it was explained to me why people
>> wanted it, and I ended up thinking, "Hmmm, we don't have a
>> compression system in there that's newer than 1977, and customers
>> are often right."
> 
> I rather like the idea of OpenPGP as an archival primitive.
> 

That's what sold me, too.

> How about adding:
> 
> Note that without the ability to rewrite a self-signature,
> interoperability issues may occur when the same key is used in more
> than one implementation.  Implementations may wish to check keys
> upon import to ensure that the preferences on the key match the
> reality of the implementation.
> 
> That doesn't mandate anything, but does call attention to the problem.
> I guess the last line could be a SHOULD if there was a desire to make
> it stronger.

I put in:

It is good practice to verify that a self-signature imported into an
implementation doesn't advertise features that the implementation doesn't
support, rewriting the signature as appropriate.

    Jon

Date: Sun, 20 Jul 2003 14:22:42 -0700
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 7/20/03 5:34 AM, "David Shaw" <[email-masked]> wrote:

> I'm not sure 2440 says that.  The relevant bit is in section 11.1,
> which says "In a key that has a main key and subkeys, the primary key
> MUST be a key capable of signing."
> 
> I took this, perhaps wrongly, at face value - that is, if a key had
> subkeys, the primary had to be able to sign (for the binding
> signatures, presumably).  The flip side of this is that if a key does
> not have subkeys (and there is nothing wrong with a V4 key without
> subkeys), the primary did not have to be able to sign.
> 
> Did I misinterpret the intent in 2440 there?  If "a key that has a
> main key and subkeys" was intended to mean "V4 key", then I strongly
> suggest changing it to say "V4 key" explicitly to avoid the confusion
> that spawned a good bit of this thread.

Uh, I thought that meant that the top-level key can't be an encrypt-only
key. So yes, I was quite sure that 2440 said what you wanted.

    Jon

Date: Sun, 20 Jul 2003 11:48:07 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Adding in BZ2 compression?
Mail-Followup-To: Jon Callas <[email-masked]>, Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Sun, Jul 20, 2003 at 02:41:39AM -0700, Jon Callas wrote:

> I was basically against it until it was explained to me why people
> wanted it, and I ended up thinking, "Hmmm, we don't have a
> compression system in there that's newer than 1977, and customers
> are often right."

I rather like the idea of OpenPGP as an archival primitive.

> >> Yes, I know that there are potential interoperability issues when keys get
> >> migrated around, but I also of the opinion that when an implementation
> >> imports a key, it should make sure that the preferences reflect what it
> >> supports.
> > 
> > Amen. Can that be explicitly stated in the next draft?
> > 
> 
> I'm under the impression that it already says "SHOULD" in there. I
> don't think it should be any stronger. It's a feature of OpenPGP
> that it's small.  I don't want to force someone who wants to embed
> OpenPGP in something like a pager network (yeah, yeah, these days
> pagers play videos) to have to do everything in PGP or GPG.
> 
> OpenPGP is not supposed to mandate all the features a good desktop
> program should have.

The current draft says:

  Since a self-signature contains important information about the
  key's use, an implementation SHOULD allow the user to rewrite the
  self-signature, and important information in it, such as preferences
  and key expiration.

How about adding:

  Note that without the ability to rewrite a self-signature,
  interoperability issues may occur when the same key is used in more
  than one implementation.  Implementations may wish to check keys
  upon import to ensure that the preferences on the key match the
  reality of the implementation.

That doesn't mandate anything, but does call attention to the problem.
I guess the last line could be a SHOULD if there was a desire to make
it stronger.

David

Date: Sun, 20 Jul 2003 08:34:17 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Sun, Jul 20, 2003 at 03:05:14AM -0700, Jon Callas wrote:
> 
> >>> Can you explain what troubles you about encrypt-only primaries?
> >> 
> >> Aside from being an unclean exception to a simple model :-?
> > 
> > I don't see exceptions here.  The model is quite clearly and simply
> > stated in 2440.  Any key can be of any type.  There are no exceptions.
> > Does this mean that there are possible arrangements of packets that
> > make no sense?  Sure, so don't do that.
> > 
> > I see your suggestion as adding an exception: any key can be of any
> > type, except that the primary must be able to certify.
> 
> 2440 already says that a top-level key must be able to sign.

I'm not sure 2440 says that.  The relevant bit is in section 11.1,
which says "In a key that has a main key and subkeys, the primary key
MUST be a key capable of signing."

I took this, perhaps wrongly, at face value - that is, if a key had
subkeys, the primary had to be able to sign (for the binding
signatures, presumably).  The flip side of this is that if a key does
not have subkeys (and there is nothing wrong with a V4 key without
subkeys), the primary did not have to be able to sign.

Did I misinterpret the intent in 2440 there?  If "a key that has a
main key and subkeys" was intended to mean "V4 key", then I strongly
suggest changing it to say "V4 key" explicitly to avoid the confusion
that spawned a good bit of this thread.

David

Date: Sun, 20 Jul 2003 03:05:14 -0700
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

>>> Can you explain what troubles you about encrypt-only primaries?
>> 
>> Aside from being an unclean exception to a simple model :-?
> 
> I don't see exceptions here.  The model is quite clearly and simply
> stated in 2440.  Any key can be of any type.  There are no exceptions.
> Does this mean that there are possible arrangements of packets that
> make no sense?  Sure, so don't do that.
> 
> I see your suggestion as adding an exception: any key can be of any
> type, except that the primary must be able to certify.

2440 already says that a top-level key must be able to sign.

Getting, however to the issue in the subject line, I don't think 2440 should
require self-signed user ids.

Consider the following statements:

"Call me Ishmael."

"Call him Ishmael."

The first corresponds to a self-signed UID. The latter to an introducer
signature.

I think that PGP UIDs can be SDSI names. More than that, they should be.

I would like to be able to add a user id to someone's key because I want to,
and I sign it myself, and let it go at that.

Here's my real-world example. A person I work with, call this person "John
Doe," has a PGP key with the UID "[email-masked]" on it. However, this person
*always* sends mail from "[email-masked]" and I am constantly having to
cancel keyserver searches and then go manually select the right key. It
drive me up the blinking wall. I have asked said person to add in the proper
user name on a number of occasions, and am still waiting.

It would make me eternally happy if I can add the user name I want to that
key. It isn't self-signed, it's signed my *me*. Why should *my* software
accept UIDs as valid that are signed by me?

Now then, we get into a small bit of interesting protocol if I export that
key. But I don't see why that protocol has to be in 2440. Here are some
issues:

* What happens when I export that key? Should my software not export UIDs
that aren't self-signed? I don't care. Well, perhaps more to the point, I
consider that a bit of software design, not standards work.

* What happens if I import a key that has a UID that isn't self-signed?
Should it strip it? Should it strip it if it is signed by someone who is a
trusted introducer? Again, I consider that software design.

* What happens if a key is placed on a server? Should all non-self-signed
UIDs be stripped? I think that's a matter for the server owner, but "Yes" is
a fine answer.

If an implementation didn't export these "SDSI UIDs" I could live with it.
It might be nice to be able to import a SDSI UID that was signed by entities
I trust. But I could live without that.

But -- I consider all this to be software design issues, not standards
issues. The standard should allow gentlepersons to disagree on some facets
of design and use -- especially when the standard punts the whole issue of
trust.

    Jon

Date: Sun, 20 Jul 2003 02:41:39 -0700
Subject: Re: Adding in BZ2 compression?
From: Jon Callas <[email-masked]>
To: Len Sassaman <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 7/17/03 3:13 PM, "Len Sassaman" <[email-masked]> wrote:

> Putting multiple options for anything into a protocol does practical
> implications in the context of an anonymity system, however. (I'm not
> saying this should prevent adding a new compression algorithm if it serves
> a purpose -- it's just something to keep in mind.)
> 

I was basically against it until it was explained to me why people wanted
it, and I ended up thinking, "Hmmm, we don't have a compression system in
there that's newer than 1977, and customers are often right."

>> Yes, I know that there are potential interoperability issues when keys get
>> migrated around, but I also of the opinion that when an implementation
>> imports a key, it should make sure that the preferences reflect what it
>> supports.
> 
> Amen. Can that be explicitly stated in the next draft?
> 

I'm under the impression that it already says "SHOULD" in there. I don't
think it should be any stronger. It's a feature of OpenPGP that it's small.
I don't want to force someone who wants to embed OpenPGP in something like a
pager network (yeah, yeah, these days pagers play videos) to have to do
everything in PGP or GPG.

OpenPGP is not supposed to mandate all the features a good desktop program
should have. 

    Jon

Date: Fri, 18 Jul 2003 23:23:02 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Jul 19, 2003 at 12:06:01AM +0200, Imad R. Faiad wrote:

> I personally, will always prefer to
> encrypt to a signing key, if at all
> the public key algorithm supports
> encryption.  If there are any subkeys,
> I will chose the oldest, or a signing
> subkey, just to have some "PHUN", regardless
> of whether it is revoked or not.
> And there is nothing that you can do
> about it!  And I would recommend that
> every OpenPGP user does the same.

Not me.  I just pick a random person from the keyserver and encrypt to
them.  Now that's really phun.

David

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Date: Sat, 19 Jul 2003 00:06:01 +0200
Sender: [email-masked]

Hello David,

If it's an RSA key, then I guess that it is both,
unless the implementation honors the use flags,
and the OpenPGP's implied use of the public
key algorithm.

All of the public key algorithms support
signing, therefore, until a time when
there is a public key algorithm which
does not, one can say that all OpenPGP
keys can be signing keys.
One can generalize that and say, that
all OpenPGP key are encrypt enabled also,
with the exception of DSA keys.

While you control with what key/subkey
you sign with, you cannot control what
key will be used when encrypted messages
are sent to you.

I personally, will always prefer to
encrypt to a signing key, if at all
the public key algorithm supports
encryption.  If there are any subkeys,
I will chose the oldest, or a signing
subkey, just to have some "PHUN", regardless
of whether it is revoked or not.
And there is nothing that you can do
about it!  And I would recommend that
every OpenPGP user does the same.

Binding is not sufficient, all it implies is
that the one who had the secret part of the
primary key at the time chose to sign that
subkey.

A key or subkey should be self signed, this is
an indication that whoever purports to have
issued it had the secret part at the time.

A UID has to be signed by the primary key.

In short:-
1) A primary key with no self signature
   is meaningless.
2) A UID with no signature from the
   primary key is meaningless.
3) A subkey with no self signature and
   no binding signature from the primary
   key is meaningless also.

Hope the above helps,

Best regards

Imad R. Faiad

On Fri, 18 Jul 2003 13:10:37 -0400, you wrote:

>
>[F651E0D5]*** PGP SIGNATURE VERIFICATION ***
>[F651E0D5]*** Hash: SHA1
>[F651E0D5]*** Status: Good Signature from Invalid Key
>[F651E0D5]*** Alert: Please verify signer's key before trusting signature.
>[F651E0D5]*** Signer: David M. Shaw <[email-masked]>
>[F651E0D5]*** Note: Signing Key is a Sub-Key!
>[F651E0D5]*** Key ID: 0x49E1CBC9
>[F651E0D5]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923  2CE6 E266 5C87 49E1
>CBC9 [F651E0D5]*** Signed: 7/18/2003 7:10:37 PM
>[F651E0D5]*** Verified: 7/18/2003 9:53:22 PM
>[F651E0D5]*** BEGIN PGP VERIFIED MESSAGE ***
>
>On Fri, Jul 18, 2003 at 09:13:41AM -0700, Len Sassaman wrote:
>> On Thu, 17 Jul 2003, David Shaw wrote:
>> 
>> > > Simplicity is a good reason, as is the robustness of the OpenPGP
>> > > system. 
>> >
>> > I'm afraid I don't understand your response.  Simplicity is a good
>> > reason to add complexity? (??)
>> 
>> I think that saying "all v4 primary keys are signature keys" actually
>> simplifies things. You may disagree.
>
>Ah, ok.  I didn't parse your response properly.
>
>I'm of mixed feelings on the primary is a signing key issue.  There is
>definite appeal to having all non-signature items in a key be bound
>there by signatures.  As things stand now, subkeys are bound, but user
>IDs/attributes might not be.  There is a nice annoyance attack in the
>wait there.
>
>I do wonder what this case would mean in regards to the discussion
>though:
>
>1) Generate a RSA sign+encrypt key.  Naturally the user ID on that key
>   should have a self-signature.
>
>2) Now change the key flags so that the primary is encrypt-only.
>
>Is that an "encrypt-only" key?
>
>David
>
>[F651E0D5]*** END PGP VERIFIED MESSAGE ***

Date: Fri, 18 Jul 2003 11:22:05 -0700
To: [email-masked]
Cc: 
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
From: <[email-masked]>
Sender: [email-masked]

On Fri, 18 Jul 2003 10:10:37 -0700 David Shaw <[email-masked]>
wrote:

[...]

>I do wonder what this case would mean in regards to the discussion
>though:
>
>1) Generate a RSA sign+encrypt key.  Naturally the user ID on that
>key
>   should have a self-signature.
>
>2) Now change the key flags so that the primary is encrypt-only.
>
>Is that an "encrypt-only" key?

[...]

in the olden days of pgp 2.x, some people would make two keypairs, and
would use one only for signing and one only for encrypting,

so, if someone now were to generate a v4 rsa key and flag it as encrypt
only,

it might be (?mis)taken in exactly the v3 context,
that the user intended it as an encrypt-only key,
and, for whatever reason, might prefer to do it this way and not deal
with subkeys

the only problem would be if it could be flagged this way *un-intentionally*,
 
which doesn't seem to be the case

with Respect,

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

Date: Fri, 18 Jul 2003 13:10:37 -0400
From: David Shaw <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: [email-masked]
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Mail-Followup-To: Len Sassaman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Jul 18, 2003 at 09:13:41AM -0700, Len Sassaman wrote:
> On Thu, 17 Jul 2003, David Shaw wrote:
> 
> > > Simplicity is a good reason, as is the robustness of the OpenPGP system.
> >
> > I'm afraid I don't understand your response.  Simplicity is a good
> > reason to add complexity? (??)
> 
> I think that saying "all v4 primary keys are signature keys" actually
> simplifies things. You may disagree.

Ah, ok.  I didn't parse your response properly.

I'm of mixed feelings on the primary is a signing key issue.  There is
definite appeal to having all non-signature items in a key be bound
there by signatures.  As things stand now, subkeys are bound, but user
IDs/attributes might not be.  There is a nice annoyance attack in the
wait there.

I do wonder what this case would mean in regards to the discussion
though:

1) Generate a RSA sign+encrypt key.  Naturally the user ID on that key
   should have a self-signature.

2) Now change the key flags so that the primary is encrypt-only.

Is that an "encrypt-only" key?

David

Date: Fri, 18 Jul 2003 09:13:41 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: David Shaw <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Sender: [email-masked]

On Thu, 17 Jul 2003, David Shaw wrote:

> > Simplicity is a good reason, as is the robustness of the OpenPGP system.
>
> I'm afraid I don't understand your response.  Simplicity is a good
> reason to add complexity? (??)

I think that saying "all v4 primary keys are signature keys" actually
simplifies things. You may disagree.

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: key flag for authentication
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 18 Jul 2003 10:54:18 +0200
Sender: [email-masked]

On Thu, 17 Jul 2003 21:13:41 -0400, David Shaw said:

>> Is there a consensus for this? I'm happy with anything, myself.

> I support it.

Me too of course.

-- 
Werner Koch                                      <[email-masked]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org

Date: Thu, 17 Jul 2003 21:13:41 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: key flag for authentication
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Tue, Jul 01, 2003 at 12:57:29AM -0700, Jon Callas wrote:
> 
> Is there a consensus for this? I'm happy with anything, myself.

I support it.

David

Date: Thu, 17 Jul 2003 20:58:46 -0400
From: David Shaw <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Adding in BZ2 compression?
Mail-Followup-To: Len Sassaman <[email-masked]>, Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Thu, Jul 17, 2003 at 03:13:32PM -0700, Len Sassaman wrote:

> > Yes, I know that there are potential interoperability issues when keys get
> > migrated around, but I also of the opinion that when an implementation
> > imports a key, it should make sure that the preferences reflect what it
> > supports.
> 
> Amen. Can that be explicitly stated in the next draft?

Yes, please.

David

Date: Thu, 17 Jul 2003 20:57:24 -0400
From: David Shaw <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: [email-masked]
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Mail-Followup-To: Len Sassaman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Jul 17, 2003 at 03:20:26PM -0700, Len Sassaman wrote:
> 
> On Mon, 14 Jul 2003, David Shaw wrote:
> 
> > > I think there is value in requiring uids to be self-signed.  To allow
> > > encrypt-only top-level keys, one has to make a special case.  Given
> > > that they are only very limitedly useful, I'd rather not have the
> > > special case.
> >
> > Keep in mind that this renders valid 2440 keys invalid under 2440bis.
> > I can't imagine why we'd do such a thing just to gain the ability to
> > require self-signed user IDs.  To be honest, I've never seen an
> 
> I am surprised that there have not been widespread attacks on OpenPGP keys
> as a result of the permitted non-self-signed UIDs. I think this really
> must be fixed. (And for users to add self-signatures to their existing
> unsigned uids is trivial.)

No question.  I just object to tying the self-signature fix to
removing encrypt-only keys.  It's my own fault since I mentioned them
together, but I was wrong.  There is no need to tie the two together.

> > Note that GnuPG doesn't have any special support for encrypt-only
> > primary keys, but because of the nice general design of v4 keys, where
> > any key (primary or subkey) can be of any type, encrypt-only primaries
> > work just fine.  I don't have a copy of PGP handy (I'm traveling), but
> > I suspect that they'll "just plain work" in PGP as well.  My point
> > here is that it would take additional code and additional complexity
> > to *prevent* encrypt-only primaries from working... so why mess around
> > with this, especially since there is no security-related reason for
> > it?
> 
> Simplicity is a good reason, as is the robustness of the OpenPGP system.

I'm afraid I don't understand your response.  Simplicity is a good
reason to add complexity? (??)

David

Date: Thu, 17 Jul 2003 20:50:27 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: Michael Young <[email-masked]>
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Mail-Followup-To: [email-masked], Michael Young <[email-masked]>
Sender: [email-masked]

On Thu, Jul 17, 2003 at 05:50:49PM -0400, Michael Young wrote:
> 
> "David Shaw" <[email-masked]> writes:

> > So, as a solution, rather than ripping into the key construction
> > rules, why not just put in a line saying "user IDs and user attributes
> > SHOULD have a self-signature", and call it a day?
> 
> I think it's suitably "nice" to merit "ripping into" a key construction
> rule that I have always thought was wrong.  Despite your attempts to
> paint the current rule as cleaner, simpler, or more natural, I still
> disagree

"Despite your attempts to paint the current rule"?  Yikes.  We're all
working towards the same goal here.  Remember who suggested dealing
with this in 2440bis.  If I liked the no-required-self-sigs status
quo, I wouldn't have brought it up.

Although it might seem I'm arguing against required self-sigs, I'm
actually fairly torn.  One problem is that combining this change with
the encrypt-only key change implies a number of subtle and not so
subtle changes, and I'm not (yet) convinced that this is the right
thing to do.

I understand that you see the removal of encrypt-only keys as an
advantage (as you seem to be arguing against encrypt-only keys almost
more than you are arguing for a required self-signature), but I don't
see things that way.

Despite what I said earlier in this thread, requiring self-sigs does
not depend on removing encrypt-only keys.  Since there seems to be
widespread agreement for the former, and not for the latter, perhaps
it would be better to resolve the self-sigs question and then discuss
encrypt-only keys as a suppurate issue.  Discussing the two issues tied
together seems to be leading nowhere.

I propose "Self-signatures are REQUIRED for all user IDs and user
attribute IDs on any key that has a primary capable of certification".
This handles the self-sig issue without changing the key construction
rules at all.

If there is consensus on this, then a different discussion can be
opened on the matter of encrypt-only keys.

David

Date: Thu, 17 Jul 2003 15:20:26 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: David Shaw <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Sender: [email-masked]

On Mon, 14 Jul 2003, David Shaw wrote:

> > I think there is value in requiring uids to be self-signed.  To allow
> > encrypt-only top-level keys, one has to make a special case.  Given
> > that they are only very limitedly useful, I'd rather not have the
> > special case.
>
> Keep in mind that this renders valid 2440 keys invalid under 2440bis.
> I can't imagine why we'd do such a thing just to gain the ability to
> require self-signed user IDs.  To be honest, I've never seen an

I am surprised that there have not been widespread attacks on OpenPGP keys
as a result of the permitted non-self-signed UIDs. I think this really
must be fixed. (And for users to add self-signatures to their existing
unsigned uids is trivial.)

> encrypt-only primary in nature.  I know of no program that generates
> them.  I've never used one except to test.  But who am I to dictate -
> in the absence of an actual security-related reason - to someone else
> what type of key they may have?

That's what making an interoperable protocol is all about. (I'll also
argue that interoperability is a security-related reason in and of
itself.)

> Note that GnuPG doesn't have any special support for encrypt-only
> primary keys, but because of the nice general design of v4 keys, where
> any key (primary or subkey) can be of any type, encrypt-only primaries
> work just fine.  I don't have a copy of PGP handy (I'm traveling), but
> I suspect that they'll "just plain work" in PGP as well.  My point
> here is that it would take additional code and additional complexity
> to *prevent* encrypt-only primaries from working... so why mess around
> with this, especially since there is no security-related reason for
> it?

Simplicity is a good reason, as is the robustness of the OpenPGP system.

Date: Thu, 17 Jul 2003 15:14:41 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Michael Young <[email-masked]>
Cc: <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Sender: [email-masked]

On Sun, 13 Jul 2003, Michael Young wrote:

> "David Shaw" <[email-masked]> writes:
> > The only thing that really troubles me about the idea is that it
> > raises problems for the (legal, to my reading of 2440) encrypt-only v4
> > key.
>
> This doesn't trouble me... I strongly believe that we should
> remove the loophole that allows encrypt-only top-level v4 keys,
> for exactly this reason.  (I was astounded when David pointed out
> the seemingly permissive language in another forum.)

Agreed.

> Why is it important to be able to generate such a thing?  Is it such a
> burden to have to generate a signing key?
>
> [If you don't care about uid validity, which you mustn't if you're
> using an encrypt-only top-level key now, then you could even attach a
> bogus top-level key, which would take virtually no time to generate.]

Date: Thu, 17 Jul 2003 15:13:32 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Adding in BZ2 compression?
Sender: [email-masked]

On Mon, 7 Jul 2003, Jon Callas wrote:

> I'm not the person asking for them, so I may be inadequately explaining
> this. Nonetheless, here goes.
>
> The argument of "no new algorithms unless one is broken" makes more sense
> for things like ciphers than it does for compression. Compression in OpenPGP
> doesn't have the same sort of security implications that a cipher does, and
> so one doesn't need to be as conservative about it.

Putting multiple options for anything into a protocol does practical
implications in the context of an anonymity system, however. (I'm not
saying this should prevent adding a new compression algorithm if it serves
a purpose -- it's just something to keep in mind.)

> Yes, I know that there are potential interoperability issues when keys get
> migrated around, but I also of the opinion that when an implementation
> imports a key, it should make sure that the preferences reflect what it
> supports.

Amen. Can that be explicitly stated in the next draft?

(And does PGP do this yet?)

--Len.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Date: Thu, 17 Jul 2003 17:50:49 -0400
Sender: [email-masked]

"David Shaw" <[email-masked]> writes:
> Allow me to restate the original problem that spawned this thread: It
> would be nice to require self-signatures on user IDs.  We cannot do
> that since an encrypt-only primary is unable to issue such a
> self-signature.

It seems that we all agree that it would be "nice" to *require*
self-signatures.

> So, as a solution, rather than ripping into the key construction
> rules, why not just put in a line saying "user IDs and user attributes
> SHOULD have a self-signature", and call it a day?

I think it's suitably "nice" to merit "ripping into" a key construction
rule that I have always thought was wrong.  Despite your attempts to
paint the current rule as cleaner, simpler, or more natural, I still
disagree -- I think the current rule is more convoluted.  It *is*
the current rule, though, and I understand that we'd be invalidating
some currently valid keys "with the swipe of a pen".  As you've noted,
no known software generates encrypt-only top-level keys (except perhaps
for testing).  Anyone with a usable signing key can generate a self-signature
to make any intended uids valid.  With those facts in mind, I'm quite
willing to take a swipe to correct a mistake.

Perhaps one of the original authors can offer some insight here.
Why was it important to allow encrypt-only "primary" keys?

Date: Tue, 15 Jul 2003 13:37:34 -0400
From: Edwin Woudt <[email-masked]>
To: [email-masked]
Subject: Location of 'key expiration time' signature subpacket
Sender: [email-masked]

While implementing key expiration, I noticed that the 'key expiration time' 
signature subpacket (#9) is put in self certification signatures instead of 
in (self signed) direct key signature.

Why is that?

I find it more logical to put it in a direct key signature, as it says 
nothing about the user id that is self signed. In fact, given multiple user 
id's, putting it in self certification signatures could even result in 
conflicting information.

Edwin

Date: Mon, 14 Jul 2003 21:09:38 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Jul 14, 2003 at 01:39:04PM -0400, Michael Young wrote:

> I find it strange that you'd use the term "primary" for a top-level
> encrypt-only key.  It can't have subkeys; there is no "secondary".

I call it primary because 2440 calls it primary.  It doesn't matter if
there are no subkeys on it.  That's just wording.  I think we all know
what I am talking about when I say encrypt-only primary: a version 4
public key (tag 6) that is of an encrypt-only algorithm.

> > Can you explain what troubles you about encrypt-only primaries?
> 
> Aside from being an unclean exception to a simple model :-?

I don't see exceptions here.  The model is quite clearly and simply
stated in 2440.  Any key can be of any type.  There are no exceptions.
Does this mean that there are possible arrangements of packets that
make no sense?  Sure, so don't do that.

I see your suggestion as adding an exception: any key can be of any
type, except that the primary must be able to certify.

> I think there is value in requiring uids to be self-signed.  To allow
> encrypt-only top-level keys, one has to make a special case.  Given
> that they are only very limitedly useful, I'd rather not have the
> special case.

Keep in mind that this renders valid 2440 keys invalid under 2440bis.
I can't imagine why we'd do such a thing just to gain the ability to
require self-signed user IDs.  To be honest, I've never seen an
encrypt-only primary in nature.  I know of no program that generates
them.  I've never used one except to test.  But who am I to dictate -
in the absence of an actual security-related reason - to someone else
what type of key they may have?

Note that GnuPG doesn't have any special support for encrypt-only
primary keys, but because of the nice general design of v4 keys, where
any key (primary or subkey) can be of any type, encrypt-only primaries
work just fine.  I don't have a copy of PGP handy (I'm traveling), but
I suspect that they'll "just plain work" in PGP as well.  My point
here is that it would take additional code and additional complexity
to *prevent* encrypt-only primaries from working... so why mess around
with this, especially since there is no security-related reason for
it?

> I recognize that requiring self-signatures on uids restricts some
> otherwise valid uses, and that it doesn't provide any additional
> security given a strong trust model and a proper understanding of
> its limitations.  I still think it's worthwhile.

Allow me to restate the original problem that spawned this thread: It
would be nice to require self-signatures on user IDs.  We cannot do
that since an encrypt-only primary is unable to issue such a
self-signature.

So, as a solution, rather than ripping into the key construction
rules, why not just put in a line saying "user IDs and user attributes
SHOULD have a self-signature", and call it a day?

This has a few nice details:

* It doesn't render perfectly valid 2440 encrypt-only primary keys
  invalid with the swipe of a pen.

* It doesn't render perfectly valid 2440 non-self-signed keys invalid
  with the swipe of a pen.

* It accomplishes the intent of pointing out that implementations
  should really be self-signing user IDs (which they are already
  doing anyway).

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Date: Mon, 14 Jul 2003 13:39:04 -0400
Sender: [email-masked]

"David Shaw" <[email-masked]> writes:
> Do I strongly care about encrypt-only primaries in particular?  Not
> really.  I do care about clean design, though, and adding a special
> additional "no encrypt-only primaries" rule on top of the current
> clean primary/subkey design seems without clear benefit.

I think that the rules are cleaner without encrypt-only standalone
keys: "Every key has a primary that can sign and any number of subkeys
(of any type)."  Just one rule, no special cases, nothing "on top".

I find it strange that you'd use the term "primary" for a top-level
encrypt-only key.  It can't have subkeys; there is no "secondary".

> Can you explain what troubles you about encrypt-only primaries?

Aside from being an unclean exception to a simple model :-?

I think there is value in requiring uids to be self-signed.  To allow
encrypt-only top-level keys, one has to make a special case.  Given
that they are only very limitedly useful, I'd rather not have the
special case.

I recognize that requiring self-signatures on uids restricts some
otherwise valid uses, and that it doesn't provide any additional
security given a strong trust model and a proper understanding of its
limitations.  I still think it's worthwhile.  [Note that the same is
true of the signing-subkey problem.  I acknowledge that the problem
was more serious there, and the uses of non-owned subkeys are more
limited.  (By the way, I like David's signature-in-a-subpacket
solution.)  The same is also true of the requirement that a key have
at least one uid.]

Hal observed that all *existing* encrypt-only algorithms really can
support signing anyway.  Who knows whether that will hold up over time?
If we're convinced that it will, I'd rather remove the encrypt-only
notion from the algorithm entirely (putting it in the key preferences
instead).

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Date: Mon, 14 Jul 2003 12:46:11 -0400
Sender: [email-masked]

"David Shaw" <[email-masked]> writes:
> Do I strongly care about encrypt-only primaries in particular?  Not
> really.  I do care about clean design, though, and adding a special
> additional "no encrypt-only primaries" rule on top of the current
> clean primary/subkey design seems without clear benefit.

I think that the rules are cleaner without encrypt-only standalone
keys: "Every key has a primary that can sign and any number of subkeys
(of any type)."  Just one rule, no special cases, nothing "on top".

I find it strange that you'd use the term "primary" for a top-level
encrypt-only key.  It can't have subkeys; there is no "secondary".

> Can you explain what troubles you about encrypt-only primaries?

Aside from being an unclean exception to a simple model :-?

I think there is value in requiring uids to be self-signed.  To allow
encrypt-only top-level keys, one has to make a special case.  Given
that they are only very limitedly useful, I'd rather not have the
special case.

I recognize that requiring self-signatures on uids restricts some
otherwise valid uses, and that it doesn't provide any additional
security given a strong trust model and a proper understanding of its
limitations.  I still think it's worthwhile.  [Note that the same is
true of the signing-subkey problem.  I acknowledge that the problem
was more serious there, and the uses of non-owned subkeys are more
limited.  (By the way, I like David's signature-in-a-subpacket
solution.)  The same is also true of the requirement that a key have
at least one uid.]

Hal observed that all *existing* encrypt-only algorithms really can
support signing anyway.  Who knows whether that will hold up over time?
If we're convinced that it will, I'd rather remove the encrypt-only
notion from the algorithm entirely (putting it in the key preferences
instead).

Date: Mon, 14 Jul 2003 10:49:58 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Jul 14, 2003 at 02:07:27AM -0400, David Shaw wrote:
> On Sun, Jul 13, 2003 at 11:37:24PM -0400, Michael Young wrote:
> > 
> > "David Shaw" <[email-masked]> writes:
> > > The only thing that really troubles me about the idea is that it
> > > raises problems for the (legal, to my reading of 2440) encrypt-only v4
> > > key.
> > 
> > This doesn't trouble me... I strongly believe that we should
> > remove the loophole that allows encrypt-only top-level v4 keys,
> > for exactly this reason.  (I was astounded when David pointed out
> > the seemingly permissive language in another forum.)
> 
> Just so we're all clear, Michael and I had been discussing the
> legality of a v4 encrypt-only primary WITHOUT any subkeys.  An
> encrypt-only key WITH subkeys is clearly forbidden in 2440 both
> implicitly (an encrypt-only primary key could not issue the
> non-optional subkey binding signatures) and explicitly ("In a key that
> has a main key and subkeys, the primary key MUST be a key capable of
> certification.").
> 
> This is just a primary key that happens to be of an encrypt-only
> algorithm (presumably #16, since there is no way to express an
> encrypt-only primary key with algorithm #1 (you would need to use #2,
> which is deprecated)).

I should add, though, that I don't really understand the objection to
an encrypt-only primary.  OpenPGP is a collection of various tools
that can be combined in different ways for different uses.  Some
combinations are more useful than others, and some make no sense, but
I don't see why (in the absence of an actual problem) one particular
combination should be considered a "loophole" and removed.

Do I strongly care about encrypt-only primaries in particular?  Not
really.  I do care about clean design, though, and adding a special
additional "no encrypt-only primaries" rule on top of the current
clean primary/subkey design seems without clear benefit.

Can you explain what troubles you about encrypt-only primaries?

David

Date: Mon, 14 Jul 2003 02:07:27 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Jul 13, 2003 at 11:37:24PM -0400, Michael Young wrote:
> 
> "David Shaw" <[email-masked]> writes:
> > The only thing that really troubles me about the idea is that it
> > raises problems for the (legal, to my reading of 2440) encrypt-only v4
> > key.
> 
> This doesn't trouble me... I strongly believe that we should
> remove the loophole that allows encrypt-only top-level v4 keys,
> for exactly this reason.  (I was astounded when David pointed out
> the seemingly permissive language in another forum.)

Just so we're all clear, Michael and I had been discussing the
legality of a v4 encrypt-only primary WITHOUT any subkeys.  An
encrypt-only key WITH subkeys is clearly forbidden in 2440 both
implicitly (an encrypt-only primary key could not issue the
non-optional subkey binding signatures) and explicitly ("In a key that
has a main key and subkeys, the primary key MUST be a key capable of
certification.").

This is just a primary key that happens to be of an encrypt-only
algorithm (presumably #16, since there is no way to express an
encrypt-only primary key with algorithm #1 (you would need to use #2,
which is deprecated)).

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Date: Sun, 13 Jul 2003 23:37:24 -0400
Sender: [email-masked]

"David Shaw" <[email-masked]> writes:
> The only thing that really troubles me about the idea is that it
> raises problems for the (legal, to my reading of 2440) encrypt-only v4
> key.

This doesn't trouble me... I strongly believe that we should
remove the loophole that allows encrypt-only top-level v4 keys,
for exactly this reason.  (I was astounded when David pointed out
the seemingly permissive language in another forum.)

Why is it important to be able to generate such a thing?  Is it such a
burden to have to generate a signing key?

[If you don't care about uid validity, which you mustn't if you're
using an encrypt-only top-level key now, then you could even attach a
bogus top-level key, which would take virtually no time to generate.]

Date: Sun, 13 Jul 2003 09:18:42 -0400
From: David Shaw <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: [email-masked]
Subject: Re: PoP & Signer's User ID subpacket?
Mail-Followup-To: Len Sassaman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Jul 07, 2003 at 03:34:56PM -0700, Len Sassaman wrote:
> 
> On Mon, 16 Jun 2003, David Shaw wrote:
> 
> > This raises a 2440bis question: given all the recent deprecation of
> > PGP 2.x stuff, is it worth requiring self-signatures on user IDs now?
> > If I recall, the only reason that user ID self-signatures are not
> > currently required was for 2.x compatibility.  Certainly every modern
> > implementation (5.0+, any GnuPG) generates user ID self-signatures
> > automatically when a user ID is created.
> 
> I think this is a marvelous idea.

The only thing that really troubles me about the idea is that it
raises problems for the (legal, to my reading of 2440) encrypt-only v4
key.  A true encrypt-only key would have a problem issuing the
self-signature.  Of course, Hal's comments about encryption keys
issuing signatures apply here as well.

David

Date: Sun, 13 Jul 2003 09:31:09 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Two more items
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 09, 2003 at 10:24:26AM -0400, David Shaw wrote:
> My apologies.  I missed these two items when I last proofread:
> 
> ****************************
> 
> Sections 5.6 (Compressed Data Packet), 5.7 (Symmetrically Encrypted
> Data Packet), 5.13 (Sym. Encrypted Integrity Protected Data Packet)
> all indicate that they can contain more than one literal packet.  This
> makes sense for encrypting multiple files together, and both PGP and
> GnuPG correctly handle messages with multiple literal packets.
> 
> However, the grammar in section 10.2 defines a "Literal Message" as a
> single literal packet:

I should clarify exactly what I tested here.  Both PGP (8) and GnuPG
worked properly with an encrypted message that contained two literal
packets.  That is to say, a regular public key encrypted message
except that the encrypted data packet contained two literal packets
instead of one.

David

Date: Wed, 9 Jul 2003 10:24:26 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Two more items
Mail-Followup-To: [email-masked]
Sender: [email-masked]

My apologies.  I missed these two items when I last proofread:

****************************

Sections 5.6 (Compressed Data Packet), 5.7 (Symmetrically Encrypted
Data Packet), 5.13 (Sym. Encrypted Integrity Protected Data Packet)
all indicate that they can contain more than one literal packet.  This
makes sense for encrypting multiple files together, and both PGP and
GnuPG correctly handle messages with multiple literal packets.

However, the grammar in section 10.2 defines a "Literal Message" as a
single literal packet:

  Literal Message :- Literal Data Packet.

I suggest a small change to make the grammar match the rest of the
document (and reality):

  Literal Message :- Literal Data Packet |
                     Literal Message, Literal Data Packet.

****************************

Section 10.2 (OpenPGP Messages) has a blank line in the middle of the
paragraph beginning "In addition, decrypting a Symmetrically Encrypted
Data Packet".

****************************

David

Date: Mon, 7 Jul 2003 23:54:51 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Adding in BZ2 compression?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Jul 07, 2003 at 11:58:57AM -0700, Bill Frantz wrote:

> >I don't advocate making any severe changes in the preference system,
> >but perhaps the language here could be made a bit stronger?  Something
> >like "Note that without the ability to rewrite a self-signature,
> >interoperability issues may occur when the same key is used in more
> >than one implementation." would be great.
> 
> I realize this suggestion is getting into UI issues, but...
> 
> Perhaps implementations should also warn the user if the user's
> public key includes features that are not supported by the
> implementation, and offer to generate a new self-signature that does
> not include those features.

It's a good idea, and in fact has been on my todo list for GnuPG for a
little while now.  It's one of those things that sounds easy, but is
actually pretty fussy to do (What if there is more than one self-sig?
What if the user later removes a self-sig with safe permissions,
leaving a self-sig with unsafe permissions?  Etc).  Nothing
unsolvable, but there are a lot of corner cases.

That said, should such a thing be mentioned in 2440bis?  I'm not sure.
I certainly wouldn't be against something like "Implementations MAY
wish to warn the user when importing a key that has preferences that
contradict the capabilities of the implementation".

David

Date: Mon, 07 Jul 2003 18:03:58 -0700
Subject: Re: Adding in BZ2 compression?
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 7/3/03 6:56 PM, "Derek Atkins" <[email-masked]> wrote:

> Just to play devil's advocate, why do we need yet another compression
> algorithm?

I'm not the person asking for them, so I may be inadequately explaining
this. Nonetheless, here goes.

The argument of "no new algorithms unless one is broken" makes more sense
for things like ciphers than it does for compression. Compression in OpenPGP
doesn't have the same sort of security implications that a cipher does, and
so one doesn't need to be as conservative about it.

The practical technical reason for bz2 is that it compresses better. In a
test I saw, it compresses 12% better than Deflate, and 7% better than zlib.
That test was with a backup of a server. Here's the actual results:

Original tar file: 1,739,950,080 bytes (1.62 GB)    100%
.tar.pgp file    : 730,450,065 bytes   (696.6 MB)   43%
.tar.gz file     : 694,085,841 bytes   (661.9 MB)   40%
.tar.bz2 file    : 648,270,622 bytes   (618.2 MB)   38%

The practical product reason is that there are a number of storage archival
systems that are adding in crypto. Many are encrypting some compressed data
with PKCS7 or some home-brew thing. I've been getting questions about using
OpenPGP as an archival primitive, especially since it includes compression.

I would like to be responsive to this, and say that OpenPGP is a great
system to use for encryption and compression, and why sure, just code it up
this way. It would similarly pain me to have to say that OpenPGP isn't
suitable for encryption and compression of large amounts of data, please go
shop at Gimble's.

Yes, I know that there are potential interoperability issues when keys get
migrated around, but I also of the opinion that when an implementation
imports a key, it should make sure that the preferences reflect what it
supports.

    Jon

Date: Mon, 7 Jul 2003 15:34:56 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: David Shaw <[email-masked]>
Cc: <[email-masked]>
Subject: Re: PoP & Signer's User ID subpacket?
Sender: [email-masked]

On Mon, 16 Jun 2003, David Shaw wrote:

> This raises a 2440bis question: given all the recent deprecation of
> PGP 2.x stuff, is it worth requiring self-signatures on user IDs now?
> If I recall, the only reason that user ID self-signatures are not
> currently required was for 2.x compatibility.  Certainly every modern
> implementation (5.0+, any GnuPG) generates user ID self-signatures
> automatically when a user ID is created.

I think this is a marvelous idea.

Date: Mon, 7 Jul 2003 11:58:57 -0700
To: [email-masked]
From: Bill Frantz <[email-masked]>
Subject: Re: Adding in BZ2 compression?
Sender: [email-masked]

At 9:21 PM -0700 7/3/03, David Shaw wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Thu, Jul 03, 2003 at 07:05:16PM -0700, Hal Finney wrote:
>>
>> Jon Callas writes:
>> > I have a request for an algorithm number for bz2 compression. The
>> > implementer in question has promised on a stack of holy books only
>> > to use it along with compression prefs. Anyone object strongly?
>>
>> I don't see a need to add another compression algorithm unless there is
>> something wrong with the ones we already have.  Adding a new one can only
>> hurt interoperability in the long run.  What is the reason for adding it?
>
>I don't have strong feelings for or against adding bz2, but your
>comment about interoperability raises a related issue.  In theory, the
>preference system would prevent the use of bz2 except when it can be
>properly handled by the recipient so there should be no
>interoperability issues.
>
>...
>
>I have already seen a few examples of this problem (a PGP-generated
>key with an IDEA pref being used on GnuPG, and a GnuPG-generated key
>with a ZLIB pref being used on PGP).
>
>I don't think the answer here is to restrict the use of new
>algorithms.  2440 has this to say, which pretty much eliminates the
>problem in the design:
>
>   Since a self-signature contains important information about the
>   key's use, an implementation SHOULD allow the user to rewrite the
>   self-signature, and important information in it, such as
>   preferences and key expiration.
>
>I don't advocate making any severe changes in the preference system,
>but perhaps the language here could be made a bit stronger?  Something
>like "Note that without the ability to rewrite a self-signature,
>interoperability issues may occur when the same key is used in more
>than one implementation." would be great.

I realize this suggestion is getting into UI issues, but...

Perhaps implementations should also warn the user if the user's public key
includes features that are not supported by the implementation, and offer
to generate a new self-signature that does not include those features.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | "A Jobless Recovery is | Periwinkle -- Consulting
(408)356-8506         | like a Breadless Sand- | 16345 Englewood Ave.
[email-masked] | wich." -- Steve Schear | Los Gatos, CA 95032, USA

Date: Fri, 4 Jul 2003 15:02:14 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: bis-08 notes
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Here are the rest of my notes on bis-08.  There shouldn't be anything
terribly controversial here.  This is mostly just language and
phrasing stuff.

David

========================================

In the IESG Note at the head of the document, there is the phrase
"(say for new encryption algorithms for example)".  I suggest removing
the "for example", as using both "say..." and "...for example" is
redundant.

========================================

Section 1.1 (Terms) refers to GnuPG once as "GNUpg".

========================================

Section 3.7.1.3 (Iterated and Salted S2K) contains an extra space
before the sentence beginning "Then the salt, followed..."

========================================

Section 5.1 (Public-Key Encrypted Session Key Packet) contains the
sentence "An implementation should accept, but not generate a version
of 2, which is equivalent to V3 in all other respects.".  I suggest
rephrasing with RFC-2119 keywords as "An implementation SHOULD accept,
but MUST NOT generate a version of 2....".

Actually, this whole sentence may be better in the Implementation Nits
section where there already is an item for V2 public keys.

========================================

Section 5.2.3.2 (Signature Subpacket Type) contains the sentence
"Subpackets that are found on a self-signature are placed on a User ID
certification made by the key itself."  I suggest removing the words
"User ID" as there are other types of self-signatures than User ID
certifications (i.e. 1F signatures).

========================================

Section 5.2.3.3 (Notes on Self-Signatures) contains the sentence "If
the key is located by key id, then algorithm of the default User ID of
the key provides the default symmetric algorithm."

"then algorithm" should be "the algorithm".  Also, what is a "default
User ID"?  Is this intended to be an implementation defined default,
or was this supposed to say "primary User ID"?

========================================

Section 5.2.3.23 (Reason for Revocation) ends with "A revoked
certification no longer is a part of validity calculations."  That's a
little odd grammar-wise.  I suggest "A revoked certification is no
longer a part of validity calculations."

========================================

Section 5.2.4 (Computing Signatures) says "A V3 certification hashes
the contents of the name packet, without any header."  "name packet"
should probably be "User ID or attribute packet".

========================================

Section 5.10 (Trust Packet) should probably have some text noting that
the format of trust packets are implementation defined.

========================================

Section 6 (Radix-64 Conversions) discusses Radix-64 (and calls it
Radix-64) throughout, and then adds "An OpenPGP implementation MAY use
ASCII Armor to protect the raw binary data".  This statement comes
before the format of ASCII Armor is introduced in section 6.2, and
Radix-64 isn't equivalent to ASCII Armor anyway (it is a *part* of
ASCII Armor, but armor includes the headers and tail as well).  I
suggest moving that sentence to section 6.2.

========================================

Section 7 (Cleartext signature framework) implies that the only armor
header line that may be used in clear signatures is "Hash", which
isn't true in practice (Version and Comment are common).  Adding an
item for "zero or more lines of armor headers" would help.

========================================

Section 7 (Cleartext signature framework) says "If the "Hash" armor
header is given, the specified message digest algorithm is used for
the signature."  "algorithm is" should be "algorithm(s) are" as more
than one hash algorithm can be provided on a given Hash line, and more
than one Hash line can be given.

========================================

Section 9 (Constants) says "Note that these tables are not exhaustive
lists; an implementation MAY implement an algorithm not on these
lists."  I suggest adding "so long as the algorithm number is chosen
from the private or experimental algorithm range."

========================================

Section 10.1 (Transferable Public Keys) says "After the User ID
packets there may be one or more Subkey packets."  I suggest changing
"User ID packets" to "User ID or Attribute packets".

========================================

To: "Michael Young" <[email-masked]>
Cc: "OpenPGP" <[email-masked]>
Subject: Re: Adding in BZ2 compression?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 04 Jul 2003 19:07:54 +0200
Sender: [email-masked]

On Fri, 4 Jul 2003 12:30:26 -0400, Michael Young said:

> If it didn't have any obvious advantage, I'd agree with you; but, it does.
> It's certainly more useful than two stylistic variants of the same thing,
> which is what we have now.

Yep, I'd prefer to drop compression algo 1 because 2 is better defined
and provides a clean way to specify the used window size.  For
backward compatibility it can not be done though.

> essence of Werner's argument, although he makes it in terms of
> PGP/MIME, which I don't find compelling for the pure OpenPGP spec.)

OpenPGP is mostly used for email, so PGP/MIME makes a lot of sense.
The encapsulation provided by MIME is much more flexible than that of
OpenPGP.

-- 
Werner Koch                                      <[email-masked]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Re: Adding in BZ2 compression?
Date: Fri, 4 Jul 2003 12:30:26 -0400
Sender: [email-masked]

From: "Derek Atkins" <[email-masked]>
> Just to play devil's advocate, why do we need yet another compression
> algorithm?

OK... I'll argue the other side for you ;-).

Why did we need any more ciphers after adding 3DES?  Performance, for one.
BZ2 produces smaller output for many common forms of input.
If it didn't have any obvious advantage, I'd agree with you; but, it does.
It's certainly more useful than two stylistic variants of the same thing,
which is what we have now.

Turning the question around: what's the harm?

Adding another optional compression algorithm won't create any problems
we don't already have.  (ZLIB is supported by GnuPG but not PGP.)
The preference system is the architected solution to this problem.
As David notes, moving from one implementation to another requires
being able to rewrite preferences, but that's always been the case.

Now, given that compression can be done by the end-user, it's hard to
argue that *any* algorithm is a have-to-have.  (This seems to be the
essence of Werner's argument, although he makes it in terms of
PGP/MIME, which I don't find compelling for the pure OpenPGP spec.)
But since the architecture includes compression, I'd say that
including a popular and more powerful algorithm is worthwhile.

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Adding in BZ2 compression?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 04 Jul 2003 10:58:09 +0200
Sender: [email-masked]

On Thu, 03 Jul 2003 16:47:52 -0700, Jon Callas said:

> I have a request for an algorithm number for bz2 compression. The
> implementer in question has promised on a stack of holy books only to use it
> along with compression prefs. Anyone object strongly?

I don't see a real advantage.  bz2 does only make sense for large
files and thus it won't hurt to first but the bz2 compressed data into
an appropriate MIME container and then apply OpenPGP.

If it is a problem that the signature can only be applied on the
compressed data, one should use the PGP/MIME approach and don't
combine signature and encryption in one OpenPGP message.

Decompressing bz2 requires huge amounts of memory and thus it can't be
implemented for small devices.  If we assume that people are going to
use their keys also on PDAs, we will run into problems with the
preferences.

Shalom-Salam,

   Werner

-- 
Werner Koch                                      <[email-masked]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org

Date: Fri, 4 Jul 2003 00:47:33 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Two clarifications
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

I did a closer read of bis08, and have two minor questions for
clarification.  Nothing terribly controversial ;)

1) Is the ASCII armor checksum optional?  Sections 6 and 6.2 seem to
imply that is isn't (they never say "optional" or "if used" or
anything like that), but section 6 also says that it MAY be used.

2) Is the 1F direct key signature always a self-signature?  Nothing
else in the draft seems to say so, and a non-self-signature 1F seems
useful, but the grammar in section 11.1 (Key Structures) includes only
a "Direct Key Self Signature".  Perhaps dropping the word "Self" would
make this clearer.

David

Date: Fri, 4 Jul 2003 00:21:50 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Adding in BZ2 compression?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Jul 03, 2003 at 07:05:16PM -0700, Hal Finney wrote:
> 
> Jon Callas writes:
> > I have a request for an algorithm number for bz2 compression. The
> > implementer in question has promised on a stack of holy books only
> > to use it along with compression prefs. Anyone object strongly?
> 
> I don't see a need to add another compression algorithm unless there is
> something wrong with the ones we already have.  Adding a new one can only
> hurt interoperability in the long run.  What is the reason for adding it?

I don't have strong feelings for or against adding bz2, but your
comment about interoperability raises a related issue.  In theory, the
preference system would prevent the use of bz2 except when it can be
properly handled by the recipient so there should be no
interoperability issues.

Of course, that's theory.  The preference system works quite well on
paper, but unfortunately fails in the case where a key is generated in
an implementation that can use bz2 and the public key is distributed.
Later, the user changes their implementation to one that cannot use
bz2.  Anyone sending a message to that public key has the belief that
bz2 can be safely used, and may well use it, causing a problem since
the user's new implementation cannot handle bz2 (even though their key
claims they can).

I have already seen a few examples of this problem (a PGP-generated
key with an IDEA pref being used on GnuPG, and a GnuPG-generated key
with a ZLIB pref being used on PGP).

I don't think the answer here is to restrict the use of new
algorithms.  2440 has this to say, which pretty much eliminates the
problem in the design:

   Since a self-signature contains important information about the
   key's use, an implementation SHOULD allow the user to rewrite the
   self-signature, and important information in it, such as
   preferences and key expiration.

I don't advocate making any severe changes in the preference system,
but perhaps the language here could be made a bit stronger?  Something
like "Note that without the ability to rewrite a self-signature,
interoperability issues may occur when the same key is used in more
than one implementation." would be great.

David

Date: Thu, 3 Jul 2003 19:05:16 -0700
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Adding in BZ2 compression?
Sender: [email-masked]

Jon Callas writes:
> I have a request for an algorithm number for bz2 compression. The
> implementer in question has promised on a stack of holy books only to use it
> along with compression prefs. Anyone object strongly?

I don't see a need to add another compression algorithm unless there is
something wrong with the ones we already have.  Adding a new one can only
hurt interoperability in the long run.  What is the reason for adding it?

Hal Finney

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Adding in BZ2 compression?
From: Derek Atkins <[email-masked]>
Date: 03 Jul 2003 21:56:49 -0400
Lines: 19
Sender: [email-masked]

Just to play devil's advocate, why do we need yet another compression
algorithm?

-derek

Jon Callas <[email-masked]> writes:

> I have a request for an algorithm number for bz2 compression. The
> implementer in question has promised on a stack of holy books only to use it
> along with compression prefs. Anyone object strongly?
> 
>     Jon
> 

Date: Thu, 03 Jul 2003 16:47:52 -0700
Subject: Adding in BZ2 compression?
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I have a request for an algorithm number for bz2 compression. The
implementer in question has promised on a stack of holy books only to use it
along with compression prefs. Anyone object strongly?

    Jon

To: "Imad R. Faiad" <[email-masked]>
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Suggestion for the signing subkey problem
Date: 01 Jul 2003 14:57:41 -0400
Lines: 243
Sender: [email-masked]

Hi,

"Imad R. Faiad" <[email-masked]> writes:

> Greetings,
> 
> Except that the human psyche does not function in the
> manner in which your protocol thinks it should.
> And that may be it's shortcomings.

The human psyche also doesn't remember 1024-bit numbers
or perform RSA encryptions.  That's why we have computers,
to do a lot of work that the human brain cannot do itself.
The point is that the computer does the hard work and
presents the information in a form that the human psyche
can understand.

> Packets, protocols, and RFC's are meaningless, when
> the limitations of the human mind are not taken into
> consideration.  By UI, I do not mean an implementation,
> I mean, the UI of your RFC, yes, RFC's have a UI...
> UI does not only stand for "User Interface", it is
> also what I call "Human Element".

Uh, no.  Sorry.  RFCs certainly have "operational requirements"
but there is no UI to an RFC.  An RFC is a description of a
protocol.  Different implementations can present that protocol
to users in VERY different ways.  Except in very limited ways
the RFC does not say how information should be presented to
users, and this is a Good Thing.

Yes, there is a "human element" in terms of usage constraints,
operational considerations, and even security implications,
and yes, the RFC can point implementors at a "best current practice"
to presenting information.  However that is all ancillary information;
the RFC is in general a protocol document.

> You talk about the WoT, but, isn't that broken
> with subkeys...

In general, no, it is not.  There is a particular problem with signing
subkeys not being able to securely refer to the master key (which is
what the current proposal is trying to fix), but no, in general there
is not a WoT problem with subkeys.

Walking through a normal WoT (in one direction -- the other is just a
mirror image).  Alice wants to send a message to Bob.  Alice gets
Bob's key and see's that Charlie has signed it.  Alice knows Charlie,
has verified Charlie's key, and trusts Charlie to properly verify
keys, so through the WoT Alice can now trust Bob's key.  Alice can now
encrypt a message to Bob's key and have some level of assurance that
it is correct.  An attacker could supply another key on a keyserver
with Bob's name, but it wouldn't have Charlie's signature

Now, let's look at encryption subkeys.  The beginning of the story
remains the same, except Charlie is signing Bob's master key.  Bob's
master key signs the encryption subkey, so Alice knows that Bob wants
to use that subkey.  An attacker couldn't add another encryption key
because it wouldn't be signed by Bob's master key.  An attacker could
claim an encryption key as their own, but to what end -- they couldn't
read the message anyways?  At best it provides plausible deniability
for the actual recipient of an encrypted message.

So we're perfectly safe so far.  Let's look at Bob signing messages
to Alice.

In a normal single-key (RSA or DSA) case we're in the same boat at the
first case.  Nothing new here.  The question is what happens when you
introduce signature subkeys?

Alice receives a message signed with 'key X'.  Bob's "keychain"
contains subkey X signed with his master key.  So, Alice knows that
Bob claims X is his key.  Alice knows the master key belongs to Bob
from Charlie's signature, so the master key is verified.  However,
there is a problem here (and in RFC2440).  Eve could strip out subkey
X from Bob's keychain, put it onto her own and self-sign the subkey
with Eve's master key.  Now (following 2440) Alice does not know
whether key X belongs to Bob or Eve.

HOWEVER, if we take a step forward in time and look at the current
proposal, where the master key and sub-key co-sign the binding.  With
the co-signature, key X signs "I belong to Bob's master key B" and
Bob's master key signs "key X belongs to me".  Now, just having key X
you can back-track to Bob's master key and the existing WoT for
verification.  Even if Eve extracts subkey X and puts it on her
keychain a 2440bis-compliant implementation wont accept it, because
the subkey wont be co-signed.

So signing subkeys are safe (with the change to cosign).

> That is all I have to say, and only time
> will prove me right.

Perhaps, but you have not provided the math to back yourself up.
Please, if you see a problem with this proposal please explain
it... Please provide the math showing how it doesn't work, or
the use cases where the key-bindings are insufficient.

We want to make 2440bis complete, and all input is welcome.
But please keep the topic to "fixing the subkey problem" instead
of "subkeys are bad -- get rid of them".  The latter is both
unhelpful and derailing, neither of which helps make forward progress.

> If you do find me obnoxious, then, by all means
> do let me know, I will then refrain for posting
> anything to this forum.

I have not asked you to refrain from posting.  I have
asked that posts remain on topic and in-scope.  I do not
feel that is an unreasonable request.

> Best Regards
> Imad R. Faiad

-derek

> On 01 Jul 2003 11:57:13 -0400, you wrote:
> 
> >Ok, putting my chair hat on.
> >
> >Removing subkeys from 2440bis is OUT OF SCOPE.  Fixing security
> >problems with subkeys is IN SCOPE.  The goal of 2440bis is to fix
> >security and interop issues, not remove functionality just because
> >some people have minimalist views.
> >
> >While minimalism is a virtue, it (like all things) should be applied
> >in moderation.
> >
> >Having said that, and taking my chair hat off....
> >
> >"Imad R. Faiad" <[email-masked]> writes:
> >
> >> 9)  She sends a message to Bob, which
> >>     is at least signed with the signing
> >>     subkey of Alice's fake key.  Does
> >>     the same with Alice using the signing
> >>     subkey in Bob's fake key.
> >
> >Except there is no subkey-signature from the signing subkey on the
> >fake-Alice master key, so Bob wont accept it as a valid subkey.
> >
> >> 10) Alice and Bob thinking that the other
> >>     party must have generated yet another
> >>     subkey update their copy from the servers.
> >
> >Except they wont think this, because the subkey wont validate on
> >Eve's replacement keys.
> >
> >> 11) In both cases the message authenticates,
> >>     giving credence to the respective fake keys.
> >> 12) In the worst case scenario, Alice
> >>     and Bob, will start using the other's
> >>     fake key, while each is ignorant
> >>     that the other party is using his fake
> >>     key.  Since, Eve is in the middle,
> >>     decrypting the messages, then
> >>     re-encrypting and forwarding them to
> >>     the other party.
> >
> >Well, first, if Alice and Bob have signed each other's master key,
> >then they wont use the fake keys.  
> >
> >> The above sounds implausible to you?
> >
> >It sounds implausible in the face of a real WoT between
> >Alice and Bob.  It also sounds implausible once Alice and
> >Bob have keys in the local keyright.  It is certainly plausible
> >on a first-contact basis without a real WoT.
> >
> >I will note that UI issues are out of scope here.  The UI issue
> >is an implementation issue and has nothing to do with interop.
> >The purpose of 2440bis is to fix security and interop problems;
> >how that is translated to a UI is implementation dependent and has
> >little to do with the protocol.
> >
> >> There are a spectrum of solutions.
> >> On the one extreme there is the scalpel school of
> >> thought which believes that if something
> >> is questionable, you get rid of it altogether,
> >> to put my suggestion on the Master key/ one
> >> subkey restriction, into perspective.  It does
> >> not mean that I belong to the "scalpel school of
> >> thought".  Nor do I profess such a proposed solution
> >> as a religion...  I could care less what the adopted
> >> solution is, as long as it addresses the root of
> >> the problem to my satisfaction.
> >
> >As I have already stated, removing subkeys is out of scope.
> >
> >> David Shaw's patch, does not solve the problem.
> >
> >Can you please show an example where David's patch does not work?
> >In particular, the approach where the master key and subkey cross-sign
> >each other seems to protect against all the attacks you've proposed so
> >far...  The case where Alice does not know Bob's master key is a WoT
> >issue and has nothing to do with subkeys -- the subkey issue is knowing
> >what master key a subkey belongs to.
> >
> >> Why shouldn't subkeys be regarded like any other
> >> keys.  What applies to key, should apply to them
> >> too.
> >
> >In what way are subkeys not regarded like master keys?
> >
> >> my 2c
> >> 
> >> Best Regards
> >> 
> >> Imad R. Faiad
> >
> >-derek
> >
> >> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote:
> >> 
> >> >
> >> >> >I am amazed that this thread is still running several weeks 
> >> >> after you 
> >> >> >started it, with virtually every response refuting your arguments...
> >> >> >
> >> >> And what amazes me, is that you have yet to grasp what we are 
> >> >> talking about!  Please re-read the thread, some issues have 
> >> >> been addressed.  I sincerely hope that you re-read each and 
> >> >> every message in that thread, because, you are taylor made 
> >> >> for the kind of attacks which can be inflicted to your OpenPGP keys.
> >> >
> >> >I've read all the messages. Your request that subkey capability be
> >> >essentially removed has been rejected by all of them.
> >> >
> >> >> >RFC 2440 was published five years ago. I look forward to your draft 
> >> >> >removing multiple subkey capability from it.
> >> >> I am no paper pusher, and do not have the funding or 
> >> >> time/ability to publish RFC's
> >> >
> >> >So I guess this thread is at an end then, with the capability
> >> >remaining.
> 
> 

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

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Cc: Derek Atkins <[email-masked]>
Subject: Re: Suggestion for the signing subkey problem
Date: Tue, 01 Jul 2003 20:19:21 +0200
Sender: [email-masked]

Greetings,

Except that the human psyche does not function in the
manner in which your protocol thinks it should.
And that may be it's shortcomings.

Packets, protocols, and RFC's are meaningless, when
the limitations of the human mind are not taken into
consideration.  By UI, I do not mean an implementation,
I mean, the UI of your RFC, yes, RFC's have a UI...
UI does not only stand for "User Interface", it is
also what I call "Human Element".

You talk about the WoT, but, isn't that broken
with subkeys...

That is all I have to say, and only time
will prove me right.

If you do find me obnoxious, then, by all means
do let me know, I will then refrain for posting
anything to this forum.

Best Regards

Imad R. Faiad

On 01 Jul 2003 11:57:13 -0400, you wrote:

>Ok, putting my chair hat on.
>
>Removing subkeys from 2440bis is OUT OF SCOPE.  Fixing security
>problems with subkeys is IN SCOPE.  The goal of 2440bis is to fix
>security and interop issues, not remove functionality just because
>some people have minimalist views.
>
>While minimalism is a virtue, it (like all things) should be applied
>in moderation.
>
>Having said that, and taking my chair hat off....
>
>"Imad R. Faiad" <[email-masked]> writes:
>
>> 9)  She sends a message to Bob, which
>>     is at least signed with the signing
>>     subkey of Alice's fake key.  Does
>>     the same with Alice using the signing
>>     subkey in Bob's fake key.
>
>Except there is no subkey-signature from the signing subkey on the
>fake-Alice master key, so Bob wont accept it as a valid subkey.
>
>> 10) Alice and Bob thinking that the other
>>     party must have generated yet another
>>     subkey update their copy from the servers.
>
>Except they wont think this, because the subkey wont validate on
>Eve's replacement keys.
>
>> 11) In both cases the message authenticates,
>>     giving credence to the respective fake keys.
>> 12) In the worst case scenario, Alice
>>     and Bob, will start using the other's
>>     fake key, while each is ignorant
>>     that the other party is using his fake
>>     key.  Since, Eve is in the middle,
>>     decrypting the messages, then
>>     re-encrypting and forwarding them to
>>     the other party.
>
>Well, first, if Alice and Bob have signed each other's master key,
>then they wont use the fake keys.  
>
>> The above sounds implausible to you?
>
>It sounds implausible in the face of a real WoT between
>Alice and Bob.  It also sounds implausible once Alice and
>Bob have keys in the local keyright.  It is certainly plausible
>on a first-contact basis without a real WoT.
>
>I will note that UI issues are out of scope here.  The UI issue
>is an implementation issue and has nothing to do with interop.
>The purpose of 2440bis is to fix security and interop problems;
>how that is translated to a UI is implementation dependent and has
>little to do with the protocol.
>
>> There are a spectrum of solutions.
>> On the one extreme there is the scalpel school of
>> thought which believes that if something
>> is questionable, you get rid of it altogether,
>> to put my suggestion on the Master key/ one
>> subkey restriction, into perspective.  It does
>> not mean that I belong to the "scalpel school of
>> thought".  Nor do I profess such a proposed solution
>> as a religion...  I could care less what the adopted
>> solution is, as long as it addresses the root of
>> the problem to my satisfaction.
>
>As I have already stated, removing subkeys is out of scope.
>
>> David Shaw's patch, does not solve the problem.
>
>Can you please show an example where David's patch does not work?
>In particular, the approach where the master key and subkey cross-sign
>each other seems to protect against all the attacks you've proposed so
>far...  The case where Alice does not know Bob's master key is a WoT
>issue and has nothing to do with subkeys -- the subkey issue is knowing
>what master key a subkey belongs to.
>
>> Why shouldn't subkeys be regarded like any other
>> keys.  What applies to key, should apply to them
>> too.
>
>In what way are subkeys not regarded like master keys?
>
>> my 2c
>> 
>> Best Regards
>> 
>> Imad R. Faiad
>
>-derek
>
>> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote:
>> 
>> >
>> >> >I am amazed that this thread is still running several weeks 
>> >> after you 
>> >> >started it, with virtually every response refuting your arguments...
>> >> >
>> >> And what amazes me, is that you have yet to grasp what we are 
>> >> talking about!  Please re-read the thread, some issues have 
>> >> been addressed.  I sincerely hope that you re-read each and 
>> >> every message in that thread, because, you are taylor made 
>> >> for the kind of attacks which can be inflicted to your OpenPGP keys.
>> >
>> >I've read all the messages. Your request that subkey capability be
>> >essentially removed has been rejected by all of them.
>> >
>> >> >RFC 2440 was published five years ago. I look forward to your draft 
>> >> >removing multiple subkey capability from it.
>> >> I am no paper pusher, and do not have the funding or 
>> >> time/ability to publish RFC's
>> >
>> >So I guess this thread is at an end then, with the capability
>> >remaining.

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Cc: Derek Atkins <[email-masked]>
Subject: Re: Suggestion for the signing subkey problem
Date: Tue, 01 Jul 2003 20:18:55 +0200
Sender: [email-masked]

Greetings,

Except that the human psyche does not function in the
manner in which your protocol thinks it should.
And that may be it's shortcomings.

Packets, protocols, and RFC's are meaningless, when
the limitations of the human mind are not taken into
consideration.  By UI, I do not mean an implementation,
I mean, the UI of your RFC, yes, RFC's have a UI...
UI does not only stand for "User Interface", it is
also what I call "Human Element".

You talk about the WoT, but, isn't that broken
with subkeys...

That is all I have to say, and only time
will prove me right.

If you do find me obnoxious, then, by all means
do let me know, I will then refrain for posting
anything to this forum.

Best Regards

Imad R. Faiad

On 01 Jul 2003 11:57:13 -0400, you wrote:

>Ok, putting my chair hat on.
>
>Removing subkeys from 2440bis is OUT OF SCOPE.  Fixing security
>problems with subkeys is IN SCOPE.  The goal of 2440bis is to fix
>security and interop issues, not remove functionality just because
>some people have minimalist views.
>
>While minimalism is a virtue, it (like all things) should be applied
>in moderation.
>
>Having said that, and taking my chair hat off....
>
>"Imad R. Faiad" <[email-masked]> writes:
>
>> 9)  She sends a message to Bob, which
>>     is at least signed with the signing
>>     subkey of Alice's fake key.  Does
>>     the same with Alice using the signing
>>     subkey in Bob's fake key.
>
>Except there is no subkey-signature from the signing subkey on the
>fake-Alice master key, so Bob wont accept it as a valid subkey.
>
>> 10) Alice and Bob thinking that the other
>>     party must have generated yet another
>>     subkey update their copy from the servers.
>
>Except they wont think this, because the subkey wont validate on
>Eve's replacement keys.
>
>> 11) In both cases the message authenticates,
>>     giving credence to the respective fake keys.
>> 12) In the worst case scenario, Alice
>>     and Bob, will start using the other's
>>     fake key, while each is ignorant
>>     that the other party is using his fake
>>     key.  Since, Eve is in the middle,
>>     decrypting the messages, then
>>     re-encrypting and forwarding them to
>>     the other party.
>
>Well, first, if Alice and Bob have signed each other's master key,
>then they wont use the fake keys.  
>
>> The above sounds implausible to you?
>
>It sounds implausible in the face of a real WoT between
>Alice and Bob.  It also sounds implausible once Alice and
>Bob have keys in the local keyright.  It is certainly plausible
>on a first-contact basis without a real WoT.
>
>I will note that UI issues are out of scope here.  The UI issue
>is an implementation issue and has nothing to do with interop.
>The purpose of 2440bis is to fix security and interop problems;
>how that is translated to a UI is implementation dependent and has
>little to do with the protocol.
>
>> There are a spectrum of solutions.
>> On the one extreme there is the scalpel school of
>> thought which believes that if something
>> is questionable, you get rid of it altogether,
>> to put my suggestion on the Master key/ one
>> subkey restriction, into perspective.  It does
>> not mean that I belong to the "scalpel school of
>> thought".  Nor do I profess such a proposed solution
>> as a religion...  I could care less what the adopted
>> solution is, as long as it addresses the root of
>> the problem to my satisfaction.
>
>As I have already stated, removing subkeys is out of scope.
>
>> David Shaw's patch, does not solve the problem.
>
>Can you please show an example where David's patch does not work?
>In particular, the approach where the master key and subkey cross-sign
>each other seems to protect against all the attacks you've proposed so
>far...  The case where Alice does not know Bob's master key is a WoT
>issue and has nothing to do with subkeys -- the subkey issue is knowing
>what master key a subkey belongs to.
>
>> Why shouldn't subkeys be regarded like any other
>> keys.  What applies to key, should apply to them
>> too.
>
>In what way are subkeys not regarded like master keys?
>
>> my 2c
>> 
>> Best Regards
>> 
>> Imad R. Faiad
>
>-derek
>
>> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote:
>> 
>> >
>> >> >I am amazed that this thread is still running several weeks 
>> >> after you 
>> >> >started it, with virtually every response refuting your arguments...
>> >> >
>> >> And what amazes me, is that you have yet to grasp what we are 
>> >> talking about!  Please re-read the thread, some issues have 
>> >> been addressed.  I sincerely hope that you re-read each and 
>> >> every message in that thread, because, you are taylor made 
>> >> for the kind of attacks which can be inflicted to your OpenPGP keys.
>> >
>> >I've read all the messages. Your request that subkey capability be
>> >essentially removed has been rejected by all of them.
>> >
>> >> >RFC 2440 was published five years ago. I look forward to your draft 
>> >> >removing multiple subkey capability from it.
>> >> I am no paper pusher, and do not have the funding or 
>> >> time/ability to publish RFC's
>> >
>> >So I guess this thread is at an end then, with the capability
>> >remaining.

To: "Imad R. Faiad" <[email-masked]>
Cc: [email-masked], Ian Brown <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Suggestion for the signing subkey problem
Date: 01 Jul 2003 11:57:13 -0400
Lines: 126
Sender: [email-masked]

Ok, putting my chair hat on.

Removing subkeys from 2440bis is OUT OF SCOPE.  Fixing security
problems with subkeys is IN SCOPE.  The goal of 2440bis is to fix
security and interop issues, not remove functionality just because
some people have minimalist views.

While minimalism is a virtue, it (like all things) should be applied
in moderation.

Having said that, and taking my chair hat off....

"Imad R. Faiad" <[email-masked]> writes:

> 9)  She sends a message to Bob, which
>     is at least signed with the signing
>     subkey of Alice's fake key.  Does
>     the same with Alice using the signing
>     subkey in Bob's fake key.

Except there is no subkey-signature from the signing subkey on the
fake-Alice master key, so Bob wont accept it as a valid subkey.

> 10) Alice and Bob thinking that the other
>     party must have generated yet another
>     subkey update their copy from the servers.

Except they wont think this, because the subkey wont validate on
Eve's replacement keys.

> 11) In both cases the message authenticates,
>     giving credence to the respective fake keys.
> 12) In the worst case scenario, Alice
>     and Bob, will start using the other's
>     fake key, while each is ignorant
>     that the other party is using his fake
>     key.  Since, Eve is in the middle,
>     decrypting the messages, then
>     re-encrypting and forwarding them to
>     the other party.

Well, first, if Alice and Bob have signed each other's master key,
then they wont use the fake keys.  

> The above sounds implausible to you?

It sounds implausible in the face of a real WoT between
Alice and Bob.  It also sounds implausible once Alice and
Bob have keys in the local keyright.  It is certainly plausible
on a first-contact basis without a real WoT.

I will note that UI issues are out of scope here.  The UI issue
is an implementation issue and has nothing to do with interop.
The purpose of 2440bis is to fix security and interop problems;
how that is translated to a UI is implementation dependent and has
little to do with the protocol.

> There are a spectrum of solutions.
> On the one extreme there is the scalpel school of
> thought which believes that if something
> is questionable, you get rid of it altogether,
> to put my suggestion on the Master key/ one
> subkey restriction, into perspective.  It does
> not mean that I belong to the "scalpel school of
> thought".  Nor do I profess such a proposed solution
> as a religion...  I could care less what the adopted
> solution is, as long as it addresses the root of
> the problem to my satisfaction.

As I have already stated, removing subkeys is out of scope.

> David Shaw's patch, does not solve the problem.

Can you please show an example where David's patch does not work?
In particular, the approach where the master key and subkey cross-sign
each other seems to protect against all the attacks you've proposed so
far...  The case where Alice does not know Bob's master key is a WoT
issue and has nothing to do with subkeys -- the subkey issue is knowing
what master key a subkey belongs to.

> Why shouldn't subkeys be regarded like any other
> keys.  What applies to key, should apply to them
> too.

In what way are subkeys not regarded like master keys?

> my 2c
> Best Regards
> Imad R. Faiad

-derek

> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote:
> 
> >
> >> >I am amazed that this thread is still running several weeks 
> >> after you 
> >> >started it, with virtually every response refuting your arguments...
> >> >
> >> And what amazes me, is that you have yet to grasp what we are 
> >> talking about!  Please re-read the thread, some issues have 
> >> been addressed.  I sincerely hope that you re-read each and 
> >> every message in that thread, because, you are taylor made 
> >> for the kind of attacks which can be inflicted to your OpenPGP keys.
> >
> >I've read all the messages. Your request that subkey capability be
> >essentially removed has been rejected by all of them.
> >
> >> >RFC 2440 was published five years ago. I look forward to your draft 
> >> >removing multiple subkey capability from it.
> >> I am no paper pusher, and do not have the funding or 
> >> time/ability to publish RFC's
> >
> >So I guess this thread is at an end then, with the capability remaining.
> >
> >
> 
> 
> 

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

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Cc: Ian Brown <[email-masked]>
Subject: Re: Suggestion for the signing subkey problem
Date: Tue, 01 Jul 2003 16:45:51 +0200
Sender: [email-masked]

Hello Ian,

Alice and Bob use OpenPGP to securely communicate
with each other.  They both are prolific with
their use of subkeys for signing and encryption.

1)  Eve obtains Alice's public key.
2)  Generates a Master Key with as many of
    the attributes as Alice's master key.
3)  She then extracts all the public subkey
    which are Alice's key and binds them
    to the Master Key generated in 1).
4)  She generates a signing subkey.
5)  She then generates an encryption
    subkey, in such a way so that it will
    be the most likely one to be used
    by an OpenPGP implementation.
6)  She performs steps 1) through 5),
    with Bob's key in mind.
7)  Both fake keys are then submitted to
    the keyserver.
8)  She sit in the middle intercepting
    and forwarding Alice's messages
    to Bob and vise versa.
9)  She sends a message to Bob, which
    is at least signed with the signing
    subkey of Alice's fake key.  Does
    the same with Alice using the signing
    subkey in Bob's fake key.
10) Alice and Bob thinking that the other
    party must have generated yet another
    subkey update their copy from the servers.
11) In both cases the message authenticates,
    giving credence to the respective fake keys.
12) In the worst case scenario, Alice
    and Bob, will start using the other's
    fake key, while each is ignorant
    that the other party is using his fake
    key.  Since, Eve is in the middle,
    decrypting the messages, then
    re-encrypting and forwarding them to
    the other party.

I know that the above may not be the
best.  But, I am sure, that someone,
with better skills than mine, can refine,
or come up with one which is a lot more
effective than the above.

The above sounds implausible to you?
Think again, while you think that you know
what you are doing, most OpenPGP users
don't, so don't trust that they do.
No fool is going to attack the cryptographic
aspect of OpenPGP.  Subkeys, used incorrectly,
gives yet another avenue for a would be attacker,
to exploit the vulnerabilities of the user.
Please read this:-
http://home.earthlink.net/~cortana/johnny.pdf
The users are finding hard to understand
the simple aspects of OpenPGP.
The user interface has yet to evolve
to present such simple aspects to the
user in an easily understood manner.
I wish that someone from say the PGP team,
can comment on the impact of the prolific
use of subkeys on the user interface of their
software.  OpenPGP is not a Diffie-Hellman
key exchange protocol, people are in the
middle of it, and they do err...
Now, which you do you prefer, more bells
and whistles, which will be mis-understood,
and mis-used, or less which is better
understood, and more likely to be used
in a more idiot proof manner.

There are a spectrum of solutions.
On the one extreme there is the scalpel school of
thought which believes that if something
is questionable, you get rid of it altogether,
to put my suggestion on the Master key/ one
subkey restriction, into perspective.  It does
not mean that I belong to the "scalpel school of
thought".  Nor do I profess such a proposed solution
as a religion...  I could care less what the adopted
solution is, as long as it addresses the root of
the problem to my satisfaction.

David Shaw's patch, does not solve the problem.

Why shouldn't subkeys be regarded like any other
keys.  What applies to key, should apply to them
too.

my 2c

Best Regards

Imad R. Faiad

On Sun, 29 Jun 2003 23:01:26 +0100, you wrote:

>
>> >I am amazed that this thread is still running several weeks 
>> after you 
>> >started it, with virtually every response refuting your arguments...
>> >
>> And what amazes me, is that you have yet to grasp what we are 
>> talking about!  Please re-read the thread, some issues have 
>> been addressed.  I sincerely hope that you re-read each and 
>> every message in that thread, because, you are taylor made 
>> for the kind of attacks which can be inflicted to your OpenPGP keys.
>
>I've read all the messages. Your request that subkey capability be
>essentially removed has been rejected by all of them.
>
>> >RFC 2440 was published five years ago. I look forward to your draft 
>> >removing multiple subkey capability from it.
>> I am no paper pusher, and do not have the funding or 
>> time/ability to publish RFC's
>
>So I guess this thread is at an end then, with the capability remaining.
>
>

Date: Tue, 01 Jul 2003 00:57:29 -0700
Subject: Re: key flag for authentication
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

Is there a consensus for this? I'm happy with anything, myself.

    Jon