Subject: Re: From Lorraine,as promised,I can lower your bill

From: <[email-masked]>
Date: Sat, 29 Jul 2000 14:59:12

Today, everyone knows the impact of the Internet.

But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31
Saudi Arabia $.59     Denmark $.04
Sweden $.05

Click Here Now.

If you do not have flash please go to

www.macromedia.com

to download it.

Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24947 for ietf-openpgp-bks; Sat, 29 Jul 2000 10:59:30 -0700 (PDT)
Received: from altavistausa.com (max1-3.newyork.corecomm.net [209.81.238.131]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24929; Sat, 29 Jul 2000 10:59:26 -0700 (PDT)
From:
Subject: Re: From Lorraine,as promised,I can lower your bill
Date: Sat, 29 Jul 2000 14:59:12
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Untitled Document

Today, everyone knows the impact of the Internet.

But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31
Saudi Arabia $.59     Denmark $.04
Sweden $.05

Click Here Now.

If you do not have flash please go to

www.macromedia.com

to download it.

Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12163 for ietf-openpgp-bks; Sat, 29 Jul 2000 06:50:22 -0700 (PDT)
Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12143 for ; Sat, 29 Jul 2000 06:50:10 -0700 (PDT)
Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 8B01949; Sat, 29 Jul 2000 09:53:01 -0400 (AST)
Message-ID: <[email-masked]>
Date: Sat, 29 Jul 2000 09:53:01 -0400
From: "Jeroen C. van Gelderen"
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Erron Criddle
Cc: [email-masked], Edwin Woudt
Subject: Re: CFB padding q
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Erron Criddle wrote:
[...]
> From section 12.8, item 12, it says; "FRE is xored with the next BS octets."
>
> From this, I read that the CFB requires the plaintext to be a multiple of
> the blocksize of the symmetrical algorithm.

I guess that strictly speaking the RFC is not correct. It
should read:

if( BS < remainder ):
FRE is xored with the next 'BS' octets.
go to step 12
else:
FRE is xored with the next 'remainder' octets.
exit

Have a look at Bruce Schneier's description of standard CFB
mode on page 200 of Applied Cryptography, 2nd Edition. The
only difference between openpgpCFB and CFB mode is that the
openpgpCFB sometimes does an encryption before the shift
register is full.

> For example, if we are using twofish that has a blocksize of 128 bits and
> we only have 96 bits of plaintext, what/how do I pad the plaintext up to
> 128 bits?

You prefix 18 bytes as per RFC 2440, giving you 30 bytes to
encrypt. Initialize the shift register with an IV of all
zeros.

Encrypt the shift register, which gives you 16 bytes of key
stream. Encrypt the first 16 bytes by xor-ing 'em with the
16 bytes of key stream and shift the encrypted bytes into the
shift register as you go. (The shift register holds 16 bytes
so all the old bytes fall off the left end.)

Now encrypt the shift register again, which gives you the
next 16 bytes of key stream. Encrypt the next *two* bytes by
xor-ing with the first two key stream bytes and shift the
encrypted two bytes into the shift register. (Only two bytes
fall off the left end.)

Encrypt the shift register again (yes, you just threw away
14 of your key stream bytes unused) giving you the next 16
bytes of key stream. Encrypt next 12 bytes by xor-ing and
throw away the unused 4 bytes of your keystream.

No padding needed. A working implementation can be found at:

http://anoncvs.cryptix.org/cgi-bin/cvsweb.cgi/projects/ \
jce/src/cryptix.jce.provider.cipher/ \
ModeCFB.java?rev=1.2&content-type=text/x-cvsweb-markup

HTH,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
[email-masked] _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA07830 for ietf-openpgp-bks; Fri, 28 Jul 2000 20:59:35 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA07824 for ; Fri, 28 Jul 2000 20:59:33 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA6F7E110220; Sat, 29 Jul 2000 12:03:11 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 29 Jul 2000 11:51:37 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: CFB padding q
Cc: Edwin Woudt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Edwin,

At 09:40 AM 28/07/2000 -0400, Edwin Woudt wrote:

>Erron Criddle wrote:
> >
> > To all,
> >
> > I have noticed that in the RFC, it says to use PKCS-1 padding for "Public
> > Key Encrypted Session key Packets", however, I was wondering what padding
> > to use for symmetrical encryption using OpenPGP's version of CFB?
> >
> > I can't seem to find any references anywhere.
>
>
>You do not need padding with CFB and OpenPGP CFB.
>CFB turns a block cipher into a stream cipher.

I'm not sure what you're saying Edwin.

From section 12.8, item 12, it says; "FRE is xored with the next BS octets."

From this, I read that the CFB requires the plaintext to be a multiple of
the blocksize of the symmetrical algorithm. My question is, then, how do
you pad the plaintext to make it equal to the blocksize of the symmetrical
algorithm?

For example, if we are using twofish that has a blocksize of 128 bits and
we only have 96 bits of plaintext, what/how do I pad the plaintext up to
128 bits?

Cheers.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id GAA20463 for ietf-openpgp-bks; Fri, 28 Jul 2000 06:37:37 -0700 (PDT)
Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20457 for ; Fri, 28 Jul 2000 06:37:35 -0700 (PDT)
Received: from woudt.nl (diziliks.ai [209.88.68.211]) by cypherpunks.ai (Postfix) with ESMTP id B4BD44C; Fri, 28 Jul 2000 09:40:21 -0400 (AST)
Message-ID: <[email-masked]>
Date: Fri, 28 Jul 2000 09:40:21 -0400
From: Edwin Woudt
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386)
X-Accept-Language: nl, en
MIME-Version: 1.0
To: Erron Criddle
Cc: [email-masked]
Subject: Re: CFB padding q
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Erron Criddle wrote:
>
> To all,
>
> I have noticed that in the RFC, it says to use PKCS-1 padding for "Public
> Key Encrypted Session key Packets", however, I was wondering what padding
> to use for symmetrical encryption using OpenPGP's version of CFB?
>
> I can't seem to find any references anywhere.

You do not need padding with CFB and OpenPGP CFB.
CFB turns a block cipher into a stream cipher.

Edwin

Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29069 for ietf-openpgp-bks; Fri, 28 Jul 2000 02:15:15 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA29061 for ; Fri, 28 Jul 2000 02:15:10 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A2E399101CA; Fri, 28 Jul 2000 17:18:43 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Jul 2000 17:07:10 +0800
To: [email-masked]
From: Erron Criddle
Subject: CFB padding q
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

I have noticed that in the RFC, it says to use PKCS-1 padding for "Public
Key Encrypted Session key Packets", however, I was wondering what padding
to use for symmetrical encryption using OpenPGP's version of CFB?

I can't seem to find any references anywhere.

Cheers.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09067 for ietf-openpgp-bks; Tue, 25 Jul 2000 09:41:40 -0700 (PDT)
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09062 for ; Tue, 25 Jul 2000 09:41:38 -0700 (PDT)
Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA26349; Tue, 25 Jul 2000 12:44:33 -0400 (EDT)
Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id MAA16198; Tue, 25 Jul 2000 12:44:09 -0400
Date: Tue, 25 Jul 2000 12:44:09 -0400
From: Tom Zerucha
To: Erron Criddle
Cc: [email-masked]
Subject: Re: dash escaped text and cleartext sig. q
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Jul 25, 2000 at 03:45:52PM +0800
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Tue, Jul 25, 2000 at 03:45:52PM +0800, Erron Criddle wrote:
> Tom,
>
> At 11:27 AM 20/07/2000 -0400, Tom Zerucha wrote:
>
> >My opgp will insert the extra dashes on any line beginning with a dash
> >(and hash the thus escaped text).

OOPS! I was wrong...

> I have just read 7.1, paragraph 2 and it states "...The message digest is
> computed using the cleartext itself, not the dash escaped form."

I should have looked at my code more carefully. I insert a
dash/space, but I call my text line canonicalizer which strips it.

> You say "(and hash the thus escaped text)", however they say different...
>
> What way is the right way - to hash the dash escaped text or not?

> Also, does the receiver of a dash-escaped email receive text as "-
> ---------" or "---------"?

Good question..

I think they are supposed to receive:

- ------------

But my implementation doesn't do this, though it probably should

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA23741 for ietf-openpgp-bks; Tue, 25 Jul 2000 00:54:19 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA23737 for ; Tue, 25 Jul 2000 00:54:16 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB4A34610140; Tue, 25 Jul 2000 15:57:14 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 25 Jul 2000 15:45:52 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: dash escaped text and cleartext sig. q
Cc: Tom Zerucha
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Tom,

At 11:27 AM 20/07/2000 -0400, Tom Zerucha wrote:

>On Thu, Jul 20, 2000 at 03:10:14PM +0800, Erron Criddle wrote:
> > To all,
> >
> > Just to clarify:
> >
> > If a cleartext signed message is sent to a recipient and the message body
> > originally contained a "-" at the start of a line, would the recipient
> > receive that same line prepended with a "- "?
> >
> > I am asking this because I have just received a message that has been
> > cleartext signed using GnuPG 1.0.1, however there are whole lines of
> "-" in
> > them and they are not received as "- -------------------..."???
> >
> > Does anyone know what is going on here or, once again, have I missed
> something?
>
>My opgp will insert the extra dashes on any line beginning with a dash
>(and hash the thus escaped text).

I have just read 7.1, paragraph 2 and it states "...The message digest is
computed using the cleartext itself, not the dash escaped form."

You say "(and hash the thus escaped text)", however they say different...

What way is the right way - to hash the dash escaped text or not?

Also, does the receiver of a dash-escaped email receive text as "-
---------" or "---------"?

TIA.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22427 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:58:41 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22423 for ; Sun, 23 Jul 2000 22:58:39 -0700 (PDT)
From: [email-masked]
Received: (qmail 23268 invoked from network); 24 Jul 2000 06:00:26 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jul 2000 06:00:26 -0000
To: [email-masked]
Subject: Re: Recommended 5.3 wording change
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Mon, 24 Jul 2000 15:01:49 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 20
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: [email-masked]
Subject: Re: Recommended 5.3 wording change
Date: Thu, 20 Jul 2000 22:23:16 -0700
Message-ID: <[email-masked]>

...

> Furthermore the corresponding language in 5.2.3, which describes what is
> hashed for V4 signature packets, is missing the description of the five
> byte postscript, which is wrong.
>
> I think it would be best in each case simply to refer to section 5.2.4,
> Computing Signatures, which gives a more complete description of exactly
> what is hashed. You might want to look there and see if the language
> is unclear.

i think these are good points. section 5.2.4 reads much more clearly
to me than the earlier sections. i think adding appropriate
references to section 5.2.4 in relevant locations would be a good
improvement.

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22384 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:57:11 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22379 for ; Sun, 23 Jul 2000 22:57:09 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AE5E31801E8; Mon, 24 Jul 2000 14:00:14 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 13:48:57 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: final q re sigs.
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hal,

At 10:50 PM 23/07/2000 -0700, [email-masked] wrote:

> > My question is, for a version 4 sig using DSA and SHA1, do we:
> >
> > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg.
>
>It is this one, where the "+" means concatenation. Most implementations
>of hash functions do not require you to literally concatenate the data,
>but rather you can pass the data in pieces, so you first pass in a, then
>b, then c. In the spec we write this as "first hash a, then hash b, then
>hash c," and so on.

Aahhh...this is where I was getting confused (re the *then* words)

Thanks :)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22215 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:49:27 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22210 for ; Sun, 23 Jul 2000 22:49:25 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA09707; Sun, 23 Jul 2000 22:50:44 -0700
Date: Sun, 23 Jul 2000 22:50:44 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: final q re sigs.
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> My question is, for a version 4 sig using DSA and SHA1, do we:
>
> 2) H(a + b + c) = 160 bit value to be fed into the sig. alg.

It is this one, where the "+" means concatenation. Most implementations
of hash functions do not require you to literally concatenate the data,
but rather you can pass the data in pieces, so you first pass in a, then
b, then c. In the spec we write this as "first hash a, then hash b, then
hash c," and so on.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21991 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:39:43 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21986 for ; Sun, 23 Jul 2000 22:39:40 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA3E1B701E8; Mon, 24 Jul 2000 13:42:38 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 13:31:21 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: final q re sigs.
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 02:07 PM 24/07/2000 +0900, [email-masked] wrote:

> > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg.
>
>i think it's closest to this.

I also thought this, however I needed confirmation...can anyone else confirm?

> my interpretation is:
>
>H(actual data +
> version + signature type + pubkey algo + hash algo +
> hashed subpacket length + hashed subpackets +
> 0x04 + 0xff + length of hashed data from sig packet)
>
>or
>
>H(actual data +
> fields of sig packet from version through hashed subpackets +
> trailer of six octets a la section 5.2.4)
>
>perhaps someone else can confirm ;-)
>
>note that your definition of (b) says "incl. subpackets", but
>actually, you don't include unhashed subpackets...but you probably
>meant that anyway, right?

Yes :)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21225 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:04:07 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21218 for ; Sun, 23 Jul 2000 22:04:02 -0700 (PDT)
From: [email-masked]
Received: (qmail 22056 invoked from network); 24 Jul 2000 05:05:46 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jul 2000 05:05:46 -0000
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Subject: Re: final q re sigs.
To: [email-masked]
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Mon, 24 Jul 2000 14:07:08 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 42
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: final q re sigs.
Date: Mon, 24 Jul 2000 11:05:50 +0800
Message-ID: <[email-masked]>

...

> Let's assume: (a) = actual data, (b) = signature data to be hashed (incl.
> subpackets), (c) = last six octets
>
> My question is, for a version 4 sig using DSA and SHA1, do we:
>
> 1) H(a) + H(b) + H(c) = 480 bit value, then hash this to produce the final
> hash value (before sig. alg.)

i don't think it is this.

as Hal mentioned in an earlier post, a "more complete description of
exactly what is hashed" is given in section 5.2.4. you'll note that
in his post, he suggested that other sections might refer to section
5.2.4. that seems like a good idea to me.

> 2) H(a + b + c) = 160 bit value to be fed into the sig. alg.

i think it's closest to this. my interpretation is:

H(actual data +
version + signature type + pubkey algo + hash algo +
hashed subpacket length + hashed subpackets +
0x04 + 0xff + length of hashed data from sig packet)

or

H(actual data +
fields of sig packet from version through hashed subpackets +
trailer of six octets a la section 5.2.4)

perhaps someone else can confirm ;-)

note that your definition of (b) says "incl. subpackets", but
actually, you don't include unhashed subpackets...but you probably
meant that anyway, right?

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19195 for ietf-openpgp-bks; Sun, 23 Jul 2000 20:14:01 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19163 for ; Sun, 23 Jul 2000 20:13:57 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A8144050070; Mon, 24 Jul 2000 11:16:52 PDT
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 24 Jul 2000 11:05:50 +0800
To: [email-masked]
From: Erron Criddle
Subject: final q re sigs.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

One final clarifying question re 2440:

After looking at 5.2.3 and 5.2.4 regarding "what" is hashed and "how" it is
hashed before being fed into the DSA, I'm still slightly confused.

-----BEGIN QUOTES-----

5.2.3 states: "The data being signed is hashed, and then the signature data
from the version number through the hashed subpacket data (inclusive) is
hashed."

5.2.4 states: "Once the data body is hashed, then a trailer is hashed.
. A version 4 signature hashes the packet body starting from its
first field, the version number, through the end of the hashed subpacket data."

"V4 signatures also hash in a final trailer of six octets:..."

"After all this has been hashed , the resulting hash field is used in the
signature algorithm,..."

-----END QUOTES-----

Let's assume: (a) = actual data, (b) = signature data to be hashed (incl.
subpackets), (c) = last six octets

My question is, for a version 4 sig using DSA and SHA1, do we:

1) H(a) + H(b) + H(c) = 480 bit value, then hash this to produce the final
hash value (before sig. alg.)

2) H(a + b + c) = 160 bit value to be fed into the sig. alg.

3)
i) Initialise the SHA1 hashing alg. with the values A=0x67452301,
B=0xEFCDAB89, C=0x98BADCFE, D=0x10325476, E=0xC3D2E1F0

ii) Hash (a) then split the 160 bit result into 5x 32 bit values,
representing the next five 32 bit initialization numbers (A,B, C, D, E)
for the hashing algorithm.

iii) Hash (b) then split the 160 bit result into 5x 32 bit values,
representing the next five 32 bit initialization numbers (A,B, C, D, E)
for the hashing algorithm.

iv) Hash (c) then use the 160 bit result in the signature algorithm (DSA).

Thanks for any replies as I am reading these three possibilities from the
doc and I'm not sure which one to use.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id FAA20267 for ietf-openpgp-bks; Sun, 23 Jul 2000 05:30:19 -0700 (PDT)
Received: from mailserver1.hrz.tu-darmstadt.de ([email-masked] [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20263 for ; Sun, 23 Jul 2000 05:30:17 -0700 (PDT)
Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id OAA21608; Sun, 23 Jul 2000 14:30:45 +0200 (MET DST)
Received: from ppp310.stud.tu-darmstadt.de (ppp310.stud.tu-darmstadt.de [130.83.176.61]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id OAA12538; Sun, 23 Jul 2000 14:32:35 +0200 (MET DST)
Received: id ; Sun, 23 Jul 2000 14:44:17 +0200 (CEST)
Message-Id:
Date: Sun, 23 Jul 2000 14:44:17 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked], Jon Callas , [email-masked], [email-masked]
Subject: Re: Y2K is over
In-Reply-To:
References: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Jon Callas :
> [email-masked]:

>> Benefits from saving a few bytes in PGP sigs:
>>
>> PGP users 4 M
>> (original business plan claim)
>> bytes saved per sig 3
>> sigs per user 100
>> ---
>> total bytes saved 1.2 G

> The byte savings you put assumes that you have a disk with a 1 byte block
> size. Typically, block sizes on disks are larger. Suppose you have a disk
> with an 8K block size. Changing a file from 3000 bytes to 2999 bytes saves
> nothing. You only really save space if the file that contains a structure
> changes the block count of the file.

But in this case you save 8K bytes at once. If the file size modulo
the block size is roughly uniformly distributed, then you have expected
savings of one actual byte of disk space for each byte of file size.

(Actually it's the fragment size, not the block size, that counts.
Since 4.3 BSD, file sytems don't waste a complete block for the final
bytes of a file. Instead a block can be shared for the final
fragments of multiple files. This is more likely to be 1K than 8K,
so even if you usually have rather short messages you will often
use more than one fragment.)

Also there can be multiple signatures in the same file (mbox for example).

And some folks even back up their disks (often using compression so
that block sizes are not an issue). Tapes are cheaper per GB than
hard disks, but there'll usually be multiple copies of the same files.

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA04743 for ietf-openpgp-bks; Fri, 21 Jul 2000 08:29:55 -0700 (PDT)
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04733 for ; Fri, 21 Jul 2000 08:29:53 -0700 (PDT)
Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA24797; Fri, 21 Jul 2000 11:32:33 -0400 (EDT)
Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id LAA10943; Fri, 21 Jul 2000 11:32:28 -0400
Date: Fri, 21 Jul 2000 11:32:28 -0400
From: Tom Zerucha
To: Paul Koning
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: The price of the one v.s. the price of the many
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[email-masked]>; from [email-masked] on Fri, Jul 21, 2000 at 10:14:32AM -0400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is getting a little off topic, but I think OpenPGP has a
programming philosophy of elegance and simplicity, so it isn't too far
off. So I apologize in advance but will still respond ;).

On Fri, Jul 21, 2000 at 10:14:32AM -0400, Paul Koning wrote:
> >>>>> "Tom" == Tom Zerucha writes:
>
> Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, [email-masked] wrote:
> >> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive,
> >> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k)
> >> $5000 > > net gain (loss) to society > from the Zimm Buddism >
> >> ("every byte is sacred"): ($4988) > > The 2nd millenium is over.
> >> Save programmers, not bytes.
> >>
> >> This is a misleading comparsion. There are circumstances where
> >> bytes can be extremely costly, such as in the new wave of wireless
> >> devices, smart
>
> Tom> You miss the biggest point.
>
> Tom> Value of 50 hours programming - $5000.
>
> Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE.
>
> Um, no.
>
> Right now drives are about $10 per GB. So 0.6 MB cost less than a
> penny. It takes nearly a million drives to break even.

And it drops each year. Just wait and we will all have 10GHz
processors with a terabyte drive connected by high speed optical...

The cost of Palm RAM is around $4000/GB. And it doesn't have a hard
drive port. The cost of extra kilopackets on the VII if you don't
have unlimited is quite high.

If you want to embed something in 1M devices, the difference between a
$15 and a $20 chip will pay for a lot of engineering time.

In one sense your argument says that the US cars of the late '60s and
early '70s were optimal because steel and fuel were cheap and getting
cheaper, so 4-5K pounds wasn't a problem and maybe an asset in an
accident.

> Not only that, but the cost of extra programming is not just time
> spent, but also quality reduced, which can be a lot more expensive.

This assumes it reduces quality. Normally collapsing a complex (and
big) interface into something which is both smaller and simpler
increases quality.

In my experience, the number of bugs is inversely proportional to the
complexity of the system, and simple systems don't produce a lot of
extra bytes.

In the original context, I think the argument was "We could add this
feature although it will take extra memory". Arguing your point, we
shouldn't add such extra features because the cost won't simply be the
extra memory, but the programmer, tester, and fixup time due to bugs
or other incompatibilities said feature would introduce.

Also, such things tax other programmers who want to interface with the
software. That extra byte might cause hundreds of other programmers
hours of grief.

> In fact, if it introduces just one more bug that causes 1% of the
> users $1 worth of extra hassle, you've already paid for the extra
> bits.

There is a point of diminishing returns, but I know of very little
software that isn't 60% extra junk and gratuitous changes when new
versions come out with all the problems you note - and I am not even
talking about actual bugs. Bloat is something that is anti-quality -
more interfaces, more code, more structures, more bytes that can be
misinterpreted.

Most of this applies to W32, less so for Mac, far less for Unicies
where you get complaints about being too simplistic to be usable.

The desire to reduce memory requirements is an indirect way to prevent
bloat, and as such is probably inefficient or even wrong in some cases.

Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29841 for ietf-openpgp-bks; Fri, 21 Jul 2000 07:11:56 -0700 (PDT)
Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29837 for ; Fri, 21 Jul 2000 07:11:54 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyuq15570; Fri, 21 Jul 2000 14:14:34 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26321; Fri, 21 Jul 00 10:10:39 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA09110; Fri, 21 Jul 2000 10:14:33 -0400
From: Paul Koning
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Fri, 21 Jul 2000 10:14:32 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: The price of the one v.s. the price of the many
References: <[email-masked]> <[email-masked]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

>>>>> "Tom" == Tom Zerucha writes:

Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, [email-masked] wrote:
>> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive,
>> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k)
>> $5000 > > net gain (loss) to society > from the Zimm Buddism >
>> ("every byte is sacred"): ($4988) > > The 2nd millenium is over.
>> Save programmers, not bytes.
>>
>> This is a misleading comparsion. There are circumstances where
>> bytes can be extremely costly, such as in the new wave of wireless
>> devices, smart

Tom> You miss the biggest point.

Tom> Value of 50 hours programming - $5000.

Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE.

Um, no.

Right now drives are about $10 per GB. So 0.6 MB cost less than a
penny. It takes nearly a million drives to break even.

Not only that, but the cost of extra programming is not just time
spent, but also quality reduced, which can be a lot more expensive.
In fact, if it introduces just one more bug that causes 1% of the
users $1 worth of extra hassle, you've already paid for the extra
bits.

paul

Received: by ns.secondary.com (8.9.3/8.9.3) id BAA13867 for ietf-openpgp-bks; Fri, 21 Jul 2000 01:53:27 -0700 (PDT)
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13856 for ; Fri, 21 Jul 2000 01:53:21 -0700 (PDT)
From: [email-masked]
Received: from [195.20.224.208] (helo=mrvdom01.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 13FYbA-0003Bn-00 for [email-masked]; Fri, 21 Jul 2000 10:56:00 +0200
Received: from fra-pci-lai-vty57.as.wcom.net ([212.211.70.57]) by mrvdom01.kundenserver.de with smtp (Exim 2.12 #2) id 13FYav-0008LD-00 for [email-masked]; Fri, 21 Jul 2000 10:55:46 +0200
Subject: Re: Y2K is over
Message-Id:
Bcc:
Date: Fri, 21 Jul 2000 10:55:46 +0200
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> balance sheet
>
> value of 1.6 G bytes
> ($200 IBM 20Gb drive, y2k) $12
>
> value of 50 hours programming
> ($100 per hour, y2k) $5000
>
> net gain (loss) to society
> from the Zimm Buddism
> ("every byte is sacred"): ($4988)
>
> The 2nd millenium is over. Save programmers, not bytes.

I would rather say: "Save user ressources, and then save hardware
and program maintainance ressources".

The attitude "Size is no longer important as RAM and disks are so
cheap!" is the reason behind Reiser's "law": "The speed increase
of hardware is slower than the speed loss of software." ("Die
Hardware wird langsamer schneller als die Software langsamer.")

Experience shows that programmers who stop to worry about the
ressources their programs eat up, have a tendency to more bugs
and poorer code design than the "good old byte savers". So don't
throw out the ideals of good programming just because in certain
areas the hardware prices have gone down.

Let us face it: First time creation of new programs is _not_ any
real bottleneck. Evolution of programs to improve their quality
and usability, however, _is_ a bottleneck. And outside the
wonderful world of universities and research labs, hardware
ressources _always_ show up as bottlenecks earlier or later, too.

Therefore, don't overdo "byte saving" at the cost of poor
program maintainability. But if byte saving can be achieved by a
simple sub-routine that is coded once and can be ignored
throughout the remainder of a program's life time (as in the case
of PGP packet lengths), then, for God's sake, save those bytes!

- Wolfgang Redtenbacher
Chairman DIN NI-22.13 "Programming languages, M2"
D/Chairman DIN NI-Erg/UA5 "Software ergonomics"
(DIN = German Standards Institute)

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA10893 for ietf-openpgp-bks; Fri, 21 Jul 2000 00:32:42 -0700 (PDT)
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10889 for ; Fri, 21 Jul 2000 00:32:39 -0700 (PDT)
Received: from [199.174.205.25] (user-33qtj8p.dialup.mindspring.com [199.174.205.25]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id DAA31968; Fri, 21 Jul 2000 03:35:07 -0400 (EDT)
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 21 Jul 2000 00:33:04 -0700
To: Jon Callas , Erron Criddle , [email-masked]
From: Bill Frantz
Subject: Re: Correction reqd. in 5.2
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 9:52 PM -0700 7/20/00, Jon Callas wrote:
>In our last episode ("Correction reqd. in 5.2", shown on 7/21/00), Erron
>Criddle said:
>
>>To all,
>>
>>Another one (trivial but may confuse newcomers):
>>
>>section 5.2 starts off with:
>>
>>"A signature packet describes a binding between some public key and some
>>data."
>>
>>should read:
>>
>>"A signature packet describes a binding between a private key and some data."
>>
>
>I disagree. A signature binds the public key and the data. Signature
>verification is done with the public key only, and that is the whole point
>of the exercise.
>
> Jon

Well, really there are two bindings. The signature binds the public key
and the data. The public key and the private key are bound by their
mathematical relationship.

However, the real binding people are usually interested in is the binding
between the holder of the private key and the data. The two bindings let
us get between the private key and the data, but the next step is still
only conjecture.

-------------------------------------------------------------------------
Bill Frantz | Microsoft Outlook, the | Periwinkle -- Consulting
(408)356-8506 | hacker's path to your | 16345 Englewood Ave.
[email-masked] | hard disk. | Los Gatos, CA 95032, USA

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05755 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:58 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05751 for ; Thu, 20 Jul 2000 22:22:56 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A1B146E0182; Fri, 21 Jul 2000 13:25:21 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jul 2000 13:14:29 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: Correction reqd. in 5.2
Cc: [email-masked]
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 09:52 PM 20/07/2000 -0700, Jon Callas wrote:

>I disagree. A signature binds the public key and the data.

Isn't the private key used as well to create the sig?

> Signature verification is done with the public key only, and that is the
> whole point
>of the exercise.
>
> Jon

Agreed.

It should read key pair as the signature is bound to both the private and
public keys.

Anyhow, you decide - I understood it, however someone else *may* get confused.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05722 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:10 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05717 for ; Thu, 20 Jul 2000 22:22:08 -0700 (PDT)
From: [email-masked]
Received: (qmail 10756 invoked from network); 21 Jul 2000 05:23:45 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 21 Jul 2000 05:23:45 -0000
To: [email-masked]
Subject: Re: Recommended 5.3 wording change
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Fri, 21 Jul 2000 14:25:00 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 26
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: Recommended 5.3 wording change
Date: Fri, 21 Jul 2000 12:23:13 +0800
Message-ID: <[email-masked]>

> The paragraph in section 5.3 (the one following the definition of the
> packet body) reads as follows:
>
> "The data being signed is hashed, and then the signature data from the
> version number through the hashed sub-packet data (inclusive) is hashed.
> The..."
>
> From my previous e-mails regarding signatures, it seems it should read
> something like:
>
> "To produce a signature, the data to be signed has the signature data from
> the version number through to the hashed sub-packet data (inclusive)
> appended to it. This data is then hashed and the resulting hash value is
> signed. The..."

i think this phrasing is easier to understand. [ the original
phrasing sounds to me like describing a particular implementation. ]

> Is that right?

it agrees w/ my understanding.

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05715 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:07 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05709 for ; Thu, 20 Jul 2000 22:22:06 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA02739; Thu, 20 Jul 2000 22:23:16 -0700
Date: Thu, 20 Jul 2000 22:23:16 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Recommended 5.3 wording change
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> The paragraph in section 5.3 (the one following the definition of the
> packet body) reads as follows:
>
> "The data being signed is hashed, and then the signature data from the
> version number through the hashed sub-packet data (inclusive) is hashed.
> The..."
>
> From my previous e-mails regarding signatures, it seems it should read
> something like:
>
> "To produce a signature, the data to be signed has the signature data from
> the version number through to the hashed sub-packet data (inclusive)
> appended to it. This data is then hashed and the resulting hash value is
> signed. The..."
>
> Is that right?

This is from 5.2.2 in the RFC.

Neither description is all that great, IMO. "First this data is hashed,
then that data is hashed" may not make it clear that all the data is
feeding into one hash context. And the language about appending to the
data may be taken literally by a naive implementer who thinks he has to
construct a buffer holding this data all appended together nicely before
feeding it to the hash function.

Furthermore the corresponding language in 5.2.3, which describes what is
hashed for V4 signature packets, is missing the description of the five
byte postscript, which is wrong.

I think it would be best in each case simply to refer to section 5.2.4,
Computing Signatures, which gives a more complete description of exactly
what is hashed. You might want to look there and see if the language
is unclear.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05484 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:13:44 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05480 for ; Thu, 20 Jul 2000 22:13:43 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA02718; Thu, 20 Jul 2000 22:14:51 -0700
Date: Thu, 20 Jul 2000 22:14:51 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Correction reqd. in 5.2
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Erron writes:
> section 5.2 starts off with:
>
> "A signature packet describes a binding between some public key and some data."
>
> should read:
>
> "A signature packet describes a binding between a private key and some data."

I don't agree. It is equally as valid to consider a signature as being
bound to the verification public key as to the signing private key.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05205 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:06:06 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05199 for ; Thu, 20 Jul 2000 22:06:04 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ADBE7D00216; Fri, 21 Jul 2000 13:08:30 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jul 2000 12:57:38 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: Correction reqd. in 5.2
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 01:51 PM 21/07/2000 +0900, [email-masked] wrote:

>hi-
>
>From: Erron Criddle
>Subject: Correction reqd. in 5.2
>Date: Fri, 21 Jul 2000 12:02:10 +0800
>Message-ID: <[email-masked]>
>
> > Another one (trivial but may confuse newcomers):
> >
> > section 5.2 starts off with:
> >
> > "A signature packet describes a binding between some public key and
> some data."
> >
> > should read:
> >
> > "A signature packet describes a binding between a private key and some
> data."
>
>isn't the binding really between "the keypair" and "some data"?

I believe that would be a better description. It could read:

"A signature packet describes a binding between a public key pair and some
data."

or thereabouts :)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05177 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:05:43 -0700 (PDT)
Received: from merrymeet.com ([email-masked] [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05173 for ; Thu, 20 Jul 2000 22:05:40 -0700 (PDT)
Received: from [63.73.97.181] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1d11); Thu, 20 Jul 2000 22:08:13 -0700
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 20 Jul 2000 21:52:45 -0700
To: Erron Criddle , [email-masked]
From: Jon Callas
Subject: Re: Correction reqd. in 5.2
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In our last episode ("Correction reqd. in 5.2", shown on 7/21/00), Erron
Criddle said:

>To all,
>
>Another one (trivial but may confuse newcomers):
>
>section 5.2 starts off with:
>
>"A signature packet describes a binding between some public key and some
>data."
>
>should read:
>
>"A signature packet describes a binding between a private key and some data."
>

I disagree. A signature binds the public key and the data. Signature
verification is done with the public key only, and that is the whole point
of the exercise.

Jon

Received: by ns.secondary.com (8.9.3/8.9.3) id VAA03290 for ietf-openpgp-bks; Thu, 20 Jul 2000 21:31:29 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA03283 for ; Thu, 20 Jul 2000 21:31:26 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5AD4520182; Fri, 21 Jul 2000 12:34:05 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jul 2000 12:23:13 +0800
To: [email-masked]
From: Erron Criddle
Subject: Recommended 5.3 wording change
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

The paragraph in section 5.3 (the one following the definition of the
packet body) reads as follows:

"The data being signed is hashed, and then the signature data from the
version number through the hashed sub-packet data (inclusive) is hashed.
The..."

From my previous e-mails regarding signatures, it seems it should read
something like:

"To produce a signature, the data to be signed has the signature data from
the version number through to the hashed sub-packet data (inclusive)
appended to it. This data is then hashed and the resulting hash value is
signed. The..."

Is that right?

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02916 for ietf-openpgp-bks; Thu, 20 Jul 2000 21:10:26 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA02912 for ; Thu, 20 Jul 2000 21:10:24 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0BE909022C; Fri, 21 Jul 2000 12:13:02 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jul 2000 12:02:10 +0800
To: [email-masked]
From: Erron Criddle
Subject: Correction reqd. in 5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

Another one (trivial but may confuse newcomers):

section 5.2 starts off with:

"A signature packet describes a binding between some public key and some data."

should read:

"A signature packet describes a binding between a private key and some data."

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA01524 for ietf-openpgp-bks; Thu, 20 Jul 2000 20:46:00 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA01520 for ; Thu, 20 Jul 2000 20:45:57 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AAF88ED018E; Fri, 21 Jul 2000 11:48:24 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jul 2000 11:37:32 +0800
To: [email-masked]
From: Erron Criddle
Subject: Correction reqd. in 5.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

You may have already noticed, but in 5.5.2 the MPI values for y (for DSA
and ElGamal) have been stated as:

MPI of ... public key value y (=g**x where x is secret)

This should read:

MPI of ... public key value y (=g**x mod p where x is secret)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id RAA14325 for ietf-openpgp-bks; Thu, 20 Jul 2000 17:22:33 -0700 (PDT)
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14321 for ; Thu, 20 Jul 2000 17:22:31 -0700 (PDT)
Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id UAA24121; Thu, 20 Jul 2000 20:25:08 -0400 (EDT)
Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id UAA07758; Thu, 20 Jul 2000 20:25:11 -0400
Date: Thu, 20 Jul 2000 20:25:10 -0400
From: Tom Zerucha
To: [email-masked]
Cc: [email-masked]
Subject: The price of the one v.s. the price of the many
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[email-masked]>; from [email-masked] on Thu, Jul 20, 2000 at 11:22:37AM -0700
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Thu, Jul 20, 2000 at 11:22:37AM -0700, [email-masked] wrote:
> > balance sheet
> >
> > value of 1.6 G bytes
> > ($200 IBM 20Gb drive, y2k) $12
> >
> > value of 50 hours programming
> > ($100 per hour, y2k) $5000
> >
> > net gain (loss) to society
> > from the Zimm Buddism
> > ("every byte is sacred"): ($4988)
> >
> > The 2nd millenium is over. Save programmers, not bytes.
>
> This is a misleading comparsion. There are circumstances where bytes can
> be extremely costly, such as in the new wave of wireless devices, smart

You miss the biggest point.

Value of 50 hours programming - $5000.

value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE.

Assuming it will be installed on more than 416 drives it is cheaper to
pay a programmer to shrink the application.

You may have noticed this if you had to upgrade CPU, Memory, or Disk
when going from Windows 3.1 to Windows 2000.

(and if you use a Palm Pilot's ram as an example the cost goes way up)

Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05950 for ietf-openpgp-bks; Thu, 20 Jul 2000 11:38:47 -0700 (PDT)
Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05946 for ; Thu, 20 Jul 2000 11:38:46 -0700 (PDT)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id LAA04600; Thu, 20 Jul 2000 11:41:23 -0700 (PDT)
Received: from [63.73.97.181] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id LAA04596; Thu, 20 Jul 2000 11:41:14 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 20 Jul 2000 11:38:05 -0700
To: [email-masked], [email-masked]
From: Jon Callas
Subject: Re: Y2K is over
Cc: [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

The byte savings you put assumes that you have a disk with a 1 byte block
size. Typically, block sizes on disks are larger. Suppose you have a disk
with an 8K block size. Changing a file from 3000 bytes to 2999 bytes saves
nothing. You only really save space if the file that contains a structure
changes the block count of the file.

There's another effect, too. And that is the code size. Saving 1 byte of
data at the cost of 200 bytes of code is probably not cost effective
because memory is more expensive than disk, and a large code size may
preclude using small devices, like pagers, iButtons, etc. Data is
transient, code is resident.

So yeah, what you said. Saving a byte isn't worth it. If it were up to me,
I would deprecate anything but the 5-byte lengths. Small devices are better
served by only using 5-byte lengths.

Jon

Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05330 for ietf-openpgp-bks; Thu, 20 Jul 2000 11:21:27 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05326 for ; Thu, 20 Jul 2000 11:21:26 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA01530; Thu, 20 Jul 2000 11:22:37 -0700
Date: Thu, 20 Jul 2000 11:22:37 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Y2K is over
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> balance sheet
>
> value of 1.6 G bytes
> ($200 IBM 20Gb drive, y2k) $12
>
> value of 50 hours programming
> ($100 per hour, y2k) $5000
>
> net gain (loss) to society
> from the Zimm Buddism
> ("every byte is sacred"): ($4988)
>
> The 2nd millenium is over. Save programmers, not bytes.

This is a misleading comparsion. There are circumstances where bytes can
be extremely costly, such as in the new wave of wireless devices, smart
cards, and other forms of portable electronics where every byte counts,
both for storage and for transmission. Not all uses of signatures will
have access to a 20 GB hard drive and megabit data transmission rates.

Furthermore, although any given optimization may save only a few bytes,
the net result of multiple such choices based on a philosophy of space
savings can add up to a substantial percentage reduction.

This is especially true when contrasted with the philosophy that space
doesn't matter any more. The end result of that philosophical approach
would be something like XML, with ascii rendering of data and verbose
tags to identify each field. PGP's signatures are probably 1/3 the size
you'd get if you used straightforward XML to represent the data.

So, yes, the second millennium is over, but no, there are still situations
where saving bytes makes sense.

Having said that, you can still look at the various optimizations
in the OpenPGP spec to see which give you the most space-saving bang
for the programmer-effort buck. Obviously using untagged binary data
is the biggest win. Beyond that, some of the optimizations, like the
string-to-key iteration count, are probably a lot more effort than they
are worth, since they're not used much.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03459 for ietf-openpgp-bks; Thu, 20 Jul 2000 10:03:39 -0700 (PDT)
Received: from fs3.freedom.net (fs3.freedom.net [209.5.124.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03455 for ; Thu, 20 Jul 2000 10:03:38 -0700 (PDT)
From: [email-masked]
Received: (from freedom@localhost) by fs3.freedom.net (8.9.2/8.9.2) id NAA14948 for [email-masked]; Thu, 20 Jul 2000 13:06:15 -0400 (EDT)
Message-Id: <[email-masked]>
Comments: This message was processed by the Freedom Mail Gateway
X-ZKS-Freedom-Hdr-Sig: AQGDdthjQcbiLoVCBULujs57t30dEPeKR0acWZw0jSRx9+y7P8KosB0E
X-ZKS-Freedom-Auth-Date: Thu, 20 Jul 2000 13:05:33 -0400
X-ZKS-Freedom-Auth-Cc: [email-masked]
X-ZKS-Freedom-Auth-To: [email-masked]
X-ZKS-Freedom-Auth-From: [email-masked]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset = "us-ascii"
Subject: Y2K is over
CC: [email-masked]
To: [email-masked]
MIME-Version: 1.0
Date: Thu, 20 Jul 2000 13:05:33 -0400
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> Hal wrote on the [email-masked] list:
>
> ... We have had many complaints that the current variable-length
> packet-length mechanism is somewhat over-engineered for the purpose.
> Still, almost all subpackets are short enough that one byte is enough
> for the length, so you do save a few bytes by using the compressed
> length encoding.

Benefits from saving a few bytes in PGP sigs:

PGP users 4 M
(original business plan claim)

bytes saved per sig 3

sigs per user 100
---
total bytes saved 1.2 G

Costs of saving a few bytes in PGP sigs:

Cost of coding weird length field 1
Maintenance factor of complex code 5
Independant implementations 10
--
total hours spent 50

balance sheet

value of 1.6 G bytes
($200 IBM 20Gb drive, y2k) $12

value of 50 hours programming
($100 per hour, y2k) $5000

net gain (loss) to society
from the Zimm Buddism
("every byte is sacred"): ($4988)

The 2nd millenium is over. Save programmers, not bytes.

kryptoBunny

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA02070 for ietf-openpgp-bks; Thu, 20 Jul 2000 00:18:34 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA02059 for ; Thu, 20 Jul 2000 00:18:31 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB512D801B8; Thu, 20 Jul 2000 15:21:05 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 20 Jul 2000 15:10:14 +0800
To: [email-masked]
From: Erron Criddle
Subject: dash escaped text and cleartext sig. q
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

Just to clarify:

If a cleartext signed message is sent to a recipient and the message body
originally contained a "-" at the start of a line, would the recipient
receive that same line prepended with a "- "?

I am asking this because I have just received a message that has been
cleartext signed using GnuPG 1.0.1, however there are whole lines of "-" in
them and they are not received as "- -------------------..."???

Does anyone know what is going on here or, once again, have I missed something?

TIA.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24181 for ietf-openpgp-bks; Wed, 19 Jul 2000 21:18:07 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24174 for ; Wed, 19 Jul 2000 21:18:05 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id VAA04221; Wed, 19 Jul 2000 21:19:04 -0700
Date: Wed, 19 Jul 2000 21:19:04 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: sig. subpacket & length conflicts?
Cc: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Erron writes:
> Maybe in a version 5 sig., simply make the signature subpacket length
> definition packet equal to a two octet scalar - this would then marry with
> the total length of all un/hashed subpackets and would also reduce the
> amount of processing required to determine the length of a signature subpacket.

Maybe so. We have had many complaints that the current variable-length
packet-length mechanism is somewhat over-engineered for the purpose.
Still, almost all subpackets are short enough that one byte is enough
for the length, so you do save a few bytes by using the compressed
length encoding.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17215 for ietf-openpgp-bks; Wed, 19 Jul 2000 19:29:56 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA17211 for ; Wed, 19 Jul 2000 19:29:54 -0700 (PDT)
From: [email-masked]
Received: (qmail 22248 invoked from network); 20 Jul 2000 02:31:33 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jul 2000 02:31:33 -0000
To: [email-masked]
Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs.
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Thu, 20 Jul 2000 11:32:45 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 22
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: [email-masked]
Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs.
Date: Wed, 19 Jul 2000 09:35:18 -0700
Message-ID: <[email-masked]>

> > that is, should the specification say:
> >
> > Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message
> >
> > or
> >
> > Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message
>
> The spec is correct; it is the latter. Signature packets have *always*
> come at the front, since back in PGP 1.0. If you have seen messages
> that were different (and not one-pass signed messages), you have seen
> invalid messages.

i think i must have been looking at a one-pass signed message.

yes, it looks like that's what i did. sorry for that, and thanks for
the clarification.

Received: by ns.secondary.com (8.9.3/8.9.3) id TAA16750 for ietf-openpgp-bks; Wed, 19 Jul 2000 19:23:49 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA16746 for ; Wed, 19 Jul 2000 19:23:47 -0700 (PDT)
From: [email-masked]
Received: (qmail 22221 invoked from network); 20 Jul 2000 02:25:25 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jul 2000 02:25:25 -0000
To: [email-masked]
Subject: Re: sig. subpacket & length conflicts?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Thu, 20 Jul 2000 11:26:37 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 42
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

thanks for the response.

From: [email-masked]
Subject: Re: sig. subpacket & length conflicts?
Date: Wed, 19 Jul 2000 09:10:09 -0700
Message-ID: <[email-masked]>

> > to all: what's the verdict?
>
> The "verdict" is that there is a limit of 65535 on the length of each
> of the hashed and unhashed segments. That's what the spec says, that's
> what you do. Obviously this implies that each individual subpacket has
> to be no larger than this. You can express the subpacket length using any
> of the permitted encoding methods. There is no ambiguity that I can see.

from a clarity perspective, i think it would be helpful to make a note
in section 5.2.3.1 saying something like: "but note the length
restriction imposed by the two octet scalar length specified in
section 5.2.3". something like this text could appear directly after
the following text:

Each subpacket consists of a subpacket header and a body. The
header consists of:

- the subpacket length (1, 2, or 5 octets)

- the subpacket type (1 octet)

and is followed by the subpacket specific data.

[ since Erron has asked about it, it seems to me that it isn't
necessarily obvious in the absolute (if there is such a thing). i
agree that it is obvious if you know which details to focus on when
you are thinking about the matter. ]

> The only "issue" was whether we might want to make a new signature version
> in the future to hold larger subpackets, but the consensus seemed to be
> that this would be a misuse of signature subpackets; such large amounts
> of data should not be hidden within sigs, but should be expressed on
> their own somewhere.

thanks for the clarification.

Received: by ns.secondary.com (8.9.3/8.9.3) id SAA14272 for ietf-openpgp-bks; Wed, 19 Jul 2000 18:55:06 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA14258 for ; Wed, 19 Jul 2000 18:55:05 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AF7C5B801E4; Thu, 20 Jul 2000 09:57:32 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 20 Jul 2000 09:46:45 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: sig. subpacket & length conflicts?
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hal,

At 09:10 AM 19/07/2000 -0700, [email-masked] wrote:

> > to all: what's the verdict?
>
>The "verdict" is that there is a limit of 65535 on the length of each
>of the hashed and unhashed segments. That's what the spec says, that's
>what you do. Obviously this implies that each individual subpacket has
>to be no larger than this. You can express the subpacket length using any
>of the permitted encoding methods. There is no ambiguity that I can see.
>
>The only "issue" was whether we might want to make a new signature version
>in the future to hold larger subpackets, but the consensus seemed to be
>that this would be a misuse of signature subpackets; such large amounts
>of data should not be hidden within sigs, but should be expressed on
>their own somewhere.

Maybe in a version 5 sig., simply make the signature subpacket length
definition packet equal to a two octet scalar - this would then marry with
the total length of all un/hashed subpackets and would also reduce the
amount of processing required to determine the length of a signature subpacket.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id SAA13760 for ietf-openpgp-bks; Wed, 19 Jul 2000 18:52:49 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA13751 for ; Wed, 19 Jul 2000 18:52:47 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AEEA5B201E4; Thu, 20 Jul 2000 09:55:06 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 20 Jul 2000 09:44:19 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs.
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 09:35 AM 19/07/2000 -0700, [email-masked] wrote:

> > 2) Why would you need a One-Pass Signature Packet if we conform to 10.2
> and simply prepend a normal signature packet to the literal data with a
> > subpacket of type 16 (key id), thus removing the need for a One-Pass
> packet
> > in the first place?
>
>This is so that the signer can process the message in one pass.
>He doesn't know the hash until he comes to the end of the message,
>so he can't compute the signature until that time. With the old-style
>signature packets he would then have to go back to the beginning of the
>message and put the sig there, preventing one-pass processing.

Thanks Hal.

Also looked at 2.1 and saw I assumed that "attached" meant "appended" -
sorry for the wasted bandwidth.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA04499 for ietf-openpgp-bks; Wed, 19 Jul 2000 17:55:39 -0700 (PDT)
Received: from yahoo.com (216-164-132-57.s311.tnt2.lnhva.md.dialup.rcn.com [216.164.132.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04429; Wed, 19 Jul 2000 17:55:29 -0700 (PDT)
From:
Subject: Tuition-Free Computer and IT Training for Non-Profit Employees
Date: Wed, 19 Jul 2000 21:01:39
Message-Id: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Tuition-Free Computer and IT Training for Non-Profit Employees

Dear Non-Profit Employee,

Most non-profit employees want to improve their computer skills.
However, high cost of training and a busy schedule have held them back.

Now, the National Education Foundation (NEF) CyberLearning, a non-profit
organization, dedicated to bridging the "Digital Divide," offers the Nation's
non-profit employees a unique opportunity. With the support of
Microsoft and others, NEF CyberLearning is now able to offer full tuition
scholarships of $2,000 to the first 10,000 applicants, thus enabling them
to take any or all of the 400+ Internet-based online personal computing and
computer professional courses from anywhere at any time.

The high-quality, user-friendly courses are either self-study or instructor-led.
They cover all levels and almost all topics, including Computer Basics,
Internet Basics, Web Design Basics, Networking Basics, Programming Basics,
A+, Network+, MCSE, CNE, Microsoft Office, MOUS, WordPerfect, Lotus,
Operating Systems, Windows, Windows 2000, Linux, Unix, Networking, WAN,
LAN, Programming, Java, C++, Visual Basics, Internet, Web Design,
Web Applications, Web Master, E-commerce, Databases, Oracle and Cisco.

To sign up, just visit www.cyberlearning.org, click on "Free IT Training,"
complete the application and pay a nominal registration fee of $75 with
an organization/personal credit card. This $75 is your only cost, since the
tuition is free for you. Many non-profit organizations reimburse the $75.

You can receive immediate access to all 400+ online courses, an online
library of the latest 1,000+ computer/information technology books,
instructor assistance, course-specific chat areas and round the clock
technical support.

Please feel free to forward this information to interested colleagues
and others in non-profit organizations. If your department or division wants
to sign up a group of employees, please indicate so in your reply and provide
contact information. If you received this e-mail, it is because you are listed
as a contact person or employee of a non-profit organization.
If you do not wish to receive any further scholarship information from us,
please reply with the message, "remove" in the Subject line. Thank you.

The non-profit National Education Foundation (NEF) CyberLearning has
provided tuition-free IT training to thousands of students, teachers,
government and non-profit employees and disadvantaged individuals.
It has earned many distinctions including "The Ivy League of IT Training,"
"1995 Fairfax Human Rights Award Winner," and " A Leader in Bridging the
Digital Divide."

"You are helping to empower America. I salute you for your ongoing
commitment to creating a better America," --- President Clinton

"This is an awesome opportunity." --- Washingtonjobs.com

"Microsoft is pleased to play a part ... NEF can make a positive
difference in the lives of a great number of individuals." --- Microsoft

"I have found the CyberLearning online courses to be extremely easy and useful.
I liked pre-course self-assessment and IT books online and available 24/7. The
course screens were interactive and made me feel as if I was in the application
itself. The site looks and feels very professional. The list of courses is huge.
It includes something for almost everyone. I find this to be a very worthy cause."
--- Ken Horowitz, IT Training Coordinator.

Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23467 for ietf-openpgp-bks; Wed, 19 Jul 2000 14:59:37 -0700 (PDT)
Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23463 for ; Wed, 19 Jul 2000 14:59:36 -0700 (PDT)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA23391; Wed, 19 Jul 2000 15:02:09 -0700 (PDT)
Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA23387; Wed, 19 Jul 2000 15:02:08 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Wed, 19 Jul 2000 14:38:42 -0700
To: [email-masked], [email-masked]
From: Jon Callas
Subject: Re: Signature Subpacket format questions
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 4:28 PM +0900 7/19/00, [email-masked] wrote:

>since there does not appear to be any mention of null-termination in
>the section on text (3.4), i interpreted "String" to mean that there
>is no null-termination. [ also because many of the field boundaries
>can be determined by various lengths that are explicitly spelled out
>as well as length definitions. ]
>

You're correct -- there's no null termination on any of the strings.

Jon

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA15340 for ietf-openpgp-bks; Wed, 19 Jul 2000 09:34:10 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15336 for ; Wed, 19 Jul 2000 09:34:09 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA02429; Wed, 19 Jul 2000 09:35:18 -0700
Date: Wed, 19 Jul 2000 09:35:18 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs.
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> that is, should the specification say:
>
> Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message
>
> or
>
> Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message

The spec is correct; it is the latter. Signature packets have *always*
come at the front, since back in PGP 1.0. If you have seen messages
that were different (and not one-pass signed messages), you have seen
invalid messages.

With regard to Erron Criddle's earlier question:

> To me, "attached" (as in 2.1 and 2.2) means you add it to the end of
> something and this contradicts 10.2 explanation of a Signed Message (a
> signed message implies that it is prepended, not attached).

Not to me. That word would be "appended". "Attached" is not meant to
imply any ordering. 2.1 and 2.2 are meant to give a very rough overview
of the steps involved in creating an OpenPGP message, not to be a detailed
specification of the process. That is for the rest of the document.

> By reading section 10.2, it seems that there are two possibilities for
> signing a literal message:
>
> 1) You create a signature packet then prepend it to the literal packet
>
> 2) You create a signature packet and a One-Pass Signature Packet then
> prepend the One-Pass packet to the literal packet and append the signature
> packet to the literal packet.
>
> Therefore, my final questions are:
>
> 1) Can you create a simple signature packet and attach it to the end of a
> literal packet as stated in 2.1 and 2.2 and subsequently contradict 10.2
> regarding the definition of a signed message and:

2.1 and 2.2 don't say that, and you can't do this.

> 2) Why would you need a One-Pass Signature Packet if we conform to 10.2 and
> simply prepend a normal signature packet to the literal data with a
> subpacket of type 16 (key id), thus removing the need for a One-Pass packet
> in the first place?

This is so that the signer can process the message in one pass.
He doesn't know the hash until he comes to the end of the message,
so he can't compute the signature until that time. With the old-style
signature packets he would then have to go back to the beginning of the
message and put the sig there, preventing one-pass processing.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14566 for ietf-openpgp-bks; Wed, 19 Jul 2000 09:08:59 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14562 for ; Wed, 19 Jul 2000 09:08:58 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA02285; Wed, 19 Jul 2000 09:10:09 -0700
Date: Wed, 19 Jul 2000 09:10:09 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: sig. subpacket & length conflicts?
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> to all: what's the verdict?

The "verdict" is that there is a limit of 65535 on the length of each
of the hashed and unhashed segments. That's what the spec says, that's
what you do. Obviously this implies that each individual subpacket has
to be no larger than this. You can express the subpacket length using any
of the permitted encoding methods. There is no ambiguity that I can see.

The only "issue" was whether we might want to make a new signature version
in the future to hold larger subpackets, but the consensus seemed to be
that this would be a misuse of signature subpackets; such large amounts
of data should not be hidden within sigs, but should be expressed on
their own somewhere.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17875 for ietf-openpgp-bks; Wed, 19 Jul 2000 02:50:53 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17871 for ; Wed, 19 Jul 2000 02:50:50 -0700 (PDT)
From: [email-masked]
Received: (qmail 11579 invoked from network); 19 Jul 2000 09:52:28 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 09:52:28 -0000
To: [email-masked]
Subject: Re: sig. subpacket & length conflicts?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Wed, 19 Jul 2000 18:53:37 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 43
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: Re: sig. subpacket & length conflicts?
Date: Wed, 19 Jul 2000 17:33:22 +0800
Message-ID: <[email-masked]>

> > also, in section 5.2.3.1, it is explicitly pointed
> >out that the subpacket length is:
> >
> > similar to the "new" format packet header lengths
> >
> >and since 5.2.3 itself didn't mention anything, i didn't think to
> >interpret "two-octet scalar" as similar to the "new" format packet
> >header length.
> >
> >to all: is this interpretation (0 - 255) correct?
>
> Actually, a two octet scalar is equal to a maximum length of 65535 bytes.

ack, duh! silly me. i must have been asleep when writing ;-) thanks
for pointing that out.

> > > So, do we limit the subpacket length to two bytes or redefine that
> > > maximum allowed total length for all subpackets (of type hashable or
> > > unhashable) as 0xFFFFFFFF ( up to 5 bytes)?
> >
> >my guess would be that although you can express length of over 255 (or
> >8383, whichever is correct) using 2 or 5 octets, that you don't do so
> >in practice in this context. if that interpretation is correct,
> >perhaps a note pointing this out in the text would be helpful for
> >future readers.
>
> From reading the archive, it looks like this is known - that the total of
> the un/hashed subpackets is a maximum of 65535 bytes and that each
> subpacket can have a max length of 0xFFFFFFFF.
>
> I didn't find a final decision on this issue though, however I think I did
> see mention of a version 5.0 signature solving this "minor" problem. I
> suppose the practical thing to do is NOT use extremely large subpackets (of
> which I don't think we will anyway :)

hmmm, so no resolution yet.

to all: what's the verdict?

Received: by ns.secondary.com (8.9.3/8.9.3) id CAA16656 for ietf-openpgp-bks; Wed, 19 Jul 2000 02:41:59 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA16639 for ; Wed, 19 Jul 2000 02:41:56 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB597080256; Wed, 19 Jul 2000 17:44:09 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 19 Jul 2000 17:33:22 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: sig. subpacket & length conflicts?
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 05:29 PM 19/07/2000 +0900, [email-masked] wrote:

>i took "Two-octet scalar octet count" in section 5.2.3 to mean 0 to 255,
>as the text says:
>
> - Two-octet scalar octet count for following hashed subpacket
> data. Note that this is the length in octets of all of the
> hashed subpackets; a pointer incremented by this number will
> skip over the hashed subpackets.
>
>i took the word "scalar" to mean that i should think about section 3.1
>(Scalar numbers).

Duh...yes, you are right regarding scalars - I must have been asleep when
reading the doc once again.

> also, in section 5.2.3.1, it is explicitly pointed
>out that the subpacket length is:
>
> similar to the "new" format packet header lengths
>
>and since 5.2.3 itself didn't mention anything, i didn't think to
>interpret "two-octet scalar" as similar to the "new" format packet
>header length.
>
>to all: is this interpretation (0 - 255) correct?

Actually, a two octet scalar is equal to a maximum length of 65535 bytes.

> > So, do we limit the subpacket length to two bytes or redefine that
> > maximum allowed total length for all subpackets (of type hashable or
> > unhashable) as 0xFFFFFFFF ( up to 5 bytes)?
>
>my guess would be that although you can express length of over 255 (or
>8383, whichever is correct) using 2 or 5 octets, that you don't do so
>in practice in this context. if that interpretation is correct,
>perhaps a note pointing this out in the text would be helpful for
>future readers.

From reading the archive, it looks like this is known - that the total of
the un/hashed subpackets is a maximum of 65535 bytes and that each
subpacket can have a max length of 0xFFFFFFFF.

I didn't find a final decision on this issue though, however I think I did
see mention of a version 5.0 signature solving this "minor" problem. I
suppose the practical thing to do is NOT use extremely large subpackets (of
which I don't think we will anyway :)

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id BAA11469 for ietf-openpgp-bks; Wed, 19 Jul 2000 01:26:53 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA11463 for ; Wed, 19 Jul 2000 01:26:50 -0700 (PDT)
From: [email-masked]
Received: (qmail 10152 invoked from network); 19 Jul 2000 08:28:27 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 08:28:27 -0000
To: [email-masked]
Subject: Re: sig. subpacket & length conflicts?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Wed, 19 Jul 2000 17:29:36 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 39
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: sig. subpacket & length conflicts?
Date: Wed, 19 Jul 2000 15:38:46 +0800
Message-ID: <[email-masked]>

> As stated in 5.2.3.1, signature subpackets can contain lengths up to
> 0xFFFFFFFF, however the maximum length as defined for ALL hashable (or
> unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two
> octet scalar).

i took "Two-octet scalar octet count" in section 5.2.3 to mean 0 to 255,
as the text says:

- Two-octet scalar octet count for following hashed subpacket
data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will
skip over the hashed subpackets.

i took the word "scalar" to mean that i should think about section 3.1
(Scalar numbers). also, in section 5.2.3.1, it is explicitly pointed
out that the subpacket length is:

similar to the "new" format packet header lengths

and since 5.2.3 itself didn't mention anything, i didn't think to
interpret "two-octet scalar" as similar to the "new" format packet
header length.

to all: is this interpretation (0 - 255) correct?

> So, do we limit the subpacket length to two bytes or redefine that
> maximum allowed total length for all subpackets (of type hashable or
> unhashable) as 0xFFFFFFFF ( up to 5 bytes)?

my guess would be that although you can express length of over 255 (or
8383, whichever is correct) using 2 or 5 octets, that you don't do so
in practice in this context. if that interpretation is correct,
perhaps a note pointing this out in the text would be helpful for
future readers.

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA10184 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:47:17 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA10176 for ; Wed, 19 Jul 2000 00:47:12 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A07D2AF0182; Wed, 19 Jul 2000 15:49:33 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 19 Jul 2000 15:38:46 +0800
To: [email-masked]
From: Erron Criddle
Subject: sig. subpacket & length conflicts?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

I think I have found another area that *may* be contradictory.

Regarding V4 sigs the two octet scalar octet count for hashable and
unhashable packets conflicts with the signature subpacket lengths.

As stated in 5.2.3.1, signature subpackets can contain lengths up to
0xFFFFFFFF, however the maximum length as defined for ALL hashable (or
unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two
octet scalar).

So, do we limit the subpacket length to two bytes or redefine that maximum
allowed total length for all subpackets (of type hashable or unhashable) as
0xFFFFFFFF ( up to 5 bytes)?

TIA.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09913 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:38:47 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09909 for ; Wed, 19 Jul 2000 00:38:45 -0700 (PDT)
From: [email-masked]
Received: (qmail 9318 invoked from network); 19 Jul 2000 07:40:22 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:40:22 -0000
To: [email-masked]
Subject: Re: Question regarding 2440:5.2.3.16
In-Reply-To:
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Wed, 19 Jul 2000 16:41:34 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: "L. Sassaman"
Subject: Re: Question regarding 2440:5.2.3.16
Date: Mon, 10 Jul 2000 11:29:05 -0700 (PDT)
Message-ID:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 10 Jul 2000 [email-masked] wrote:
>
> > That seems OK, or perhaps you could use an SSL (TLS) session using the
> > PGP key to authenticate the client. In any case I don't think this
> > mechanism should be documented in 2440.
>
> That's fine, but I do think that this definately needs to be
> documented. If 2440 isn't the place, then we need to start work on a
> keyserver draft.

have you started a draft?

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA09884 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:38:16 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09879 for ; Wed, 19 Jul 2000 00:38:13 -0700 (PDT)
From: [email-masked]
Received: (qmail 9310 invoked from network); 19 Jul 2000 07:39:50 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:39:50 -0000
To: [email-masked]
Subject: Re: Question regarding 2440:5.2.3.16
In-Reply-To:
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Wed, 19 Jul 2000 16:41:01 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 80
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

sorry for the horribly slow response.

From: "L. Sassaman"
Subject: Re: Question regarding 2440:5.2.3.16
Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT)
Message-ID:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 10 Jul 2000 [email-masked] wrote:
>
> > so you are suggesting that proof of ownership of the corresponding
> > secret key (via an appropriate signature) should server this purpose,
> > right?
>
> Yes, because the owner needs to prove he has the secret key, and the
> public key block that is to be added must be signed to prevent
> unauthorized signatures being added during this process.

sure, i was just making sure i followed your statements.

> > > Werner Koch and I have been discussing this, and he suggests that we put
> > > it into a clear-text signature packet. Would that be suitable?
> >
> > would you mind briefly describing the steps involved for the mechanism
> > you are considering (in terms like "first, the client connects to the
> > server. then the server responds w/..." etc.)?
> >
> > [ i understand what you are saying about the form a signature would
> > take, but i don't see the overall flow of the process of
> > authentication. ]
>
> The client takes the public key block, signs it, and submits this signed
> blob to the server. The server then verifies the signature, trims away
> that signature, and adds the key.

thanks for the explanation.

> Keys that are added unsigned should always be checked for the existance of
> the "no-modify" flag, and rejected if it exists.
>
> Furthermore, I suggest that we have a "modify" flag added to the spec, so
> that, if a signature is made at a later date containing this flag, it
> would superceed a preveous no-modify. But that digresses from this
> discussion.

that makes sense.

> > also, is it necessary to consider replay attacks for this kind of
> > scenario? alternatively, would the following scenario be of any concern:
> >
> > an attacker captures a session between a user and a keyserver at some
> > point in time. later, after the user has made several updates to the
> > keyserver, the attacker replays the captured session to set the
> > state of the user's key to an earlier state.
>
> This scenerio is only partially valid. A signed key that is added to a
> server does not remove the previous key and replace it with the new
> one. It is treated like and other add, and is merged with the existing
> key. So, an attacker could not truly set the key to a previous state.

is there a reason why it is not replacement? from the standpoint of a
user, i think i prefer replacement as that goes along w/ being able to
delete.

> What an attacker *could* do, via a replay attack, is re-add signatures or
> user-ids to a key on the server that the owner had later deleted. I see
> this as a minor annoyance, rather than an attack, so I don't think that we
> need to address it. (Though we could, through the use of server tokens or
> timestamps, etc. I just think it is more work than is necessary.)

i guess i'd prefer to have the ability to delete things and then not
have other people be able to add things back later. whether the
annoyance is minor or major is in the eye of the beholder, imo. i
don't consider it minor.

i would prefer to have a timestamp / server token kind of a set-up.
if some people don't care about this and others do, i suppose it could
also be expressed as policy as part of a user's key.

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09384 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:29:42 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09375 for ; Wed, 19 Jul 2000 00:29:37 -0700 (PDT)
From: [email-masked]
Received: (qmail 9189 invoked from network); 19 Jul 2000 07:31:14 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:31:14 -0000
To: [email-masked]
Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs.
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Wed, 19 Jul 2000 16:32:26 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 12
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

i didn't see any other responses to this thread. was there a verdict
on this issue?

that is, should the specification say:

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

or

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

?

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09109 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:26:05 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09097 for ; Wed, 19 Jul 2000 00:25:57 -0700 (PDT)
From: [email-masked]
Received: (qmail 9097 invoked from network); 19 Jul 2000 07:27:25 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:27:25 -0000
To: [email-masked]
Subject: Re: Signature Subpacket format questions
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Wed, 19 Jul 2000 16:28:30 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 31
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Edwin Woudt
Subject: Signature Subpacket format questions
Date: Sat, 15 Jul 2000 14:12:07 -0400
Message-ID: <[email-masked]>

> While implementing V4 signature support for a Java OpenPGP library, I
> encountered a few things with some Signature Subpackets that were not
> immediately clear to me. I would be very grateful if someone could
> answer these questions:

i wouldn't take the following as definitive answers, but here's some
feedback anyway.

> * The format specified for both 5.2.3.18. 'Preferred key server' and
> 5.2.3.20. 'Policy URL' is 'String'. Is this string terminated by a
> null value, like 5.2.3.14. 'Regular expression', or not?

since there does not appear to be any mention of null-termination in
the section on text (3.4), i interpreted "String" to mean that there
is no null-termination. [ also because many of the field boundaries
can be determined by various lengths that are explicitly spelled out
as well as length definitions. ]

> * What is the format for 5.2.3.22. 'Signer's User ID'? A String like in
> the previous question?

i interpreted this to refer to what is stored in the body of a user id
packet (5.11) -- so, if the contents of the body are text, it's
encoded in utf-8. since 5.11 doesn't really say much about non-text, i
don't know about that case ;-)

Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19994 for ietf-openpgp-bks; Tue, 18 Jul 2000 18:59:35 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA19983 for ; Tue, 18 Jul 2000 18:59:31 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AEFF5F00216; Wed, 19 Jul 2000 10:01:51 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 19 Jul 2000 09:51:06 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: CFB Mode correction in 12.8?
Cc: Jon Callas
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 01:22 PM 18/07/2000 -0700, Jon Callas wrote:

>At 1:40 PM +0800 7/18/00, Erron Criddle wrote:
>
> >FROM:
> >
> >10) FR is loaded with C11 to C18
> >
> >TO:
> >
> >10) FR is loaded with C[BS+3] to C[BS + (BS+2)]
> >
>
>I changed it to:
>
>FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an
>8-octet block).
>
>I think this addresses all the concerns?

Yes - the more well defined the RFC is, the easier it will be for others to
understand in the future.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id NAA08055 for ietf-openpgp-bks; Tue, 18 Jul 2000 13:48:19 -0700 (PDT)
Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08051 for ; Tue, 18 Jul 2000 13:48:18 -0700 (PDT)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id NAA07706; Tue, 18 Jul 2000 13:50:16 -0700 (PDT)
Received: from [63.73.97.186] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id NAA07702; Tue, 18 Jul 2000 13:50:14 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 18 Jul 2000 13:22:48 -0700
To: Erron Criddle , [email-masked]
From: Jon Callas
Subject: Re: CFB Mode correction in 12.8?
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 1:40 PM +0800 7/18/00, Erron Criddle wrote:

>FROM:
>
>10) FR is loaded with C11 to C18
>
>TO:
>
>10) FR is loaded with C[BS+3] to C[BS + (BS+2)]
>

I changed it to:

FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an
8-octet block).

I think this addresses all the concerns?

Thanks.

Jon

Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23398 for ietf-openpgp-bks; Tue, 18 Jul 2000 08:01:25 -0700 (PDT)
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23385 for ; Tue, 18 Jul 2000 08:01:23 -0700 (PDT)
Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA08281; Tue, 18 Jul 2000 11:03:44 -0400 (EDT)
Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id LAA15925; Tue, 18 Jul 2000 11:03:02 -0400
Date: Tue, 18 Jul 2000 11:03:02 -0400
From: Tom Zerucha
To: Erron Criddle
Cc: [email-masked]
Subject: Re: CFB Mode correction in 12.8?
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Jul 18, 2000 at 01:40:26PM +0800
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Tue, Jul 18, 2000 at 01:40:26PM +0800, Erron Criddle wrote:
> To all,
>
> Regarding previous posts and block sizes etc etc, should 12.8 (part 10) read:
>
> FROM:
>
> 10) FR is loaded with C11 to C18
>
> TO:
>
> 10) FR is loaded with C[BS+3] to C[BS + (BS+2)]

Yes and no. The earlier paragraph (the third one in the section)
explains about block sizes <> 8 bytes.

It should say that the procedure/example is using an 8 byte cipher,
and perhaps note your modification to 10 above.

If you describe everything (in this case examples) with mathematical
equations that are correct in all situations, the spec becomes even
harder to understand. The exact details are described precisely
elsewhere, but because of that complexity this section attempts to
explain it more like pseudocode.

I am not adverse to any adjustment, but I would prefer it in the form
of footnotes or parenthesis just to keep the instructions simpler.

Received: by ns.secondary.com (8.9.3/8.9.3) id CAA04499 for ietf-openpgp-bks; Tue, 18 Jul 2000 02:36:55 -0700 (PDT)
Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA04495 for ; Tue, 18 Jul 2000 02:36:53 -0700 (PDT)
Received: from sobolev.does-not-exist.org (dialup20.ip.lu [208.161.253.20]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id LAA05257 for ; Tue, 18 Jul 2000 11:39:16 +0200 (CEST)
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id CD3642F032; Tue, 18 Jul 2000 11:39:14 +0200 (CEST)
Date: Tue, 18 Jul 2000 11:39:14 +0200
From: Thomas Roessler
To: [email-masked]
Subject: Re: PGP/MIME: encoding restrictions.
Message-ID: <[email-masked]>
Mail-Followup-To: [email-masked]
References: <[email-masked]> <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.5i
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Jul 18, 2000 at 09:42:58AM +0100
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On 2000-07-18 09:42:58 +0100, Ian Bell wrote:

> For example, in draft-ietf-usefor-article-02 (USEFOR)
> it says "Posting agents SHOULD NOT use the encoding
> method quoted-printable". Since USEFOR articles will
> usually contain trailing whitespace (personal
> signatures MUST be delimited by "-- "), clients will be
> unable to post RFC2015bis articles to UseNet without
> breaking one RFC or another.

If you happen to be on the USEFOR list, it would be nice
if you could ask them to add an exception for
cryptographically signed messages just like the one in the
"text/plain; format=flowed" RFC. After all, a restriction
like the one you quote only makes sense in a context where
MIME is avoided. People using multipart/signed bother
recipients with MIME anyway, so the
content-transfer-encoding of the text transmitted isn't
really an issue any more.

--
Thomas Roessler

Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02089 for ietf-openpgp-bks; Tue, 18 Jul 2000 01:42:51 -0700 (PDT)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02083 for ; Tue, 18 Jul 2000 01:42:49 -0700 (PDT)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA14223; Tue, 18 Jul 2000 09:45:12 +0100 (BST)
Message-ID: <[email-masked]>
Date: Tue, 18 Jul 2000 09:42:58 +0100
To: [email-masked]
From: Ian Bell
Subject: Re: PGP/MIME: encoding restrictions.
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.01 M
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Sun, 16 Jul 2000, Thomas Roessler
wrote:
>On 2000-05-11 09:44:28 +0100, Ian Bell wrote:
>
>> Should the issue of binary versus text-mode signatures
>> be addressed?
>
>It should, and I believe the following would be the most
>robust solution:
>
>(1) require clients to create text mode signatures
>(2) require clients to use either quoted-printable or
> base64 for any body parts which contain trailing
> whitespace.
>
>Note that this seems to be what most clients do anyway at
>present.

[snip rationale]

This also satisfies the design objective of RFC1847 for single-pass
processing of the hashes (whether or not there are clients that rely on
that) without inventing new parameters.

I would suggest:
clients MUST create text mode signature
though clients MAY verify binary-mode signatures

However, I'm not so sure about (2). At most:

clients SHOULD use qp or base64 whenever there is significant
white space (i.e. _not_ MUST).

The cost of not using qp is that trailing whitespace is not protected,
but if clients have "good" reasons for not using qp they should be
allowed to consider that option.

For example, in draft-ietf-usefor-article-02 (USEFOR) it says "Posting
agents SHOULD NOT use the encoding method quoted-printable". Since
USEFOR articles will usually contain trailing whitespace (personal
signatures MUST be delimited by "-- "), clients will be unable to post
RFC2015bis articles to UseNet without breaking one RFC or another.

--
Ian Bell T U R N P I K E Ltd

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21141 for ietf-openpgp-bks; Mon, 17 Jul 2000 22:48:58 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21136 for ; Mon, 17 Jul 2000 22:48:55 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A33D51702A2; Tue, 18 Jul 2000 13:51:09 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 18 Jul 2000 13:40:26 +0800
To: [email-masked]
From: Erron Criddle
Subject: CFB Mode correction in 12.8?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

Regarding previous posts and block sizes etc etc, should 12.8 (part 10) read:

FROM:

10) FR is loaded with C11 to C18

TO:

10) FR is loaded with C[BS+3] to C[BS + (BS+2)]

Cheers.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27817 for ietf-openpgp-bks; Mon, 17 Jul 2000 17:22:34 -0700 (PDT)
Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27813 for ; Mon, 17 Jul 2000 17:22:34 -0700 (PDT)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA26208; Mon, 17 Jul 2000 17:23:43 -0700 (PDT)
Received: from [63.73.97.183] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA26204; Mon, 17 Jul 2000 17:23:43 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 17 Jul 2000 17:23:35 -0700
To: Tom Zerucha , [email-masked]
From: Jon Callas
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Cc: [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 7:07 PM -0400 7/17/00, Tom Zerucha wrote:

>3.6.2.1...
>
> These are followed by an 8-octet Initial Vector for the decryption of
> the secret values, if they are encrypted, and then the secret key
> values themselves.
>

Also fixed. Thank you, folks.

Jon

Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27709 for ietf-openpgp-bks; Mon, 17 Jul 2000 17:19:59 -0700 (PDT)
Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27705 for ; Mon, 17 Jul 2000 17:19:58 -0700 (PDT)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA26176; Mon, 17 Jul 2000 17:21:51 -0700 (PDT)
Received: from [63.73.97.183] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA26172; Mon, 17 Jul 2000 17:21:49 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 17 Jul 2000 17:21:28 -0700
To: "Michael Young" ,
From: Jon Callas
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 8:30 AM -0400 7/17/00, Michael Young wrote:

>This should now read "an IV of the same length as the cipher block"?
>

Fixed.

Jon

Received: by ns.secondary.com (8.9.3/8.9.3) id QAA26320 for ietf-openpgp-bks; Mon, 17 Jul 2000 16:35:35 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26316 for ; Mon, 17 Jul 2000 16:35:27 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA01170; Mon, 17 Jul 2000 16:37:39 -0700
Date: Mon, 17 Jul 2000 16:37:39 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> Do you do the CFB resets on MPI boundaries with V3 keys?

Yes.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25628 for ietf-openpgp-bks; Mon, 17 Jul 2000 16:06:03 -0700 (PDT)
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25624 for ; Mon, 17 Jul 2000 16:06:02 -0700 (PDT)
Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id TAA26169; Mon, 17 Jul 2000 19:08:16 -0400 (EDT)
Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id TAA16183; Mon, 17 Jul 2000 19:07:49 -0400
Date: Mon, 17 Jul 2000 19:07:49 -0400
From: Tom Zerucha
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[email-masked]>; from [email-masked] on Mon, Jul 17, 2000 at 09:32:05AM -0700
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, Jul 17, 2000 at 09:32:05AM -0700, [email-masked] wrote:
> > From [email-masked] Mon Jul 17 06:29:39 2000
> > From: "Michael Young"
> > Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
> >
> > Yes, I meant Twofish, not Blowfish.
> >
> > The draft I found at imc.org still says in section 5.5.3:
> > > - [Optional] If secret data is encrypted, eight-octet Initial
> > > Vector (IV).
> >
> > This should now read "an IV of the same length as the cipher block"?
>
> I suppose so.

And...

3.6.2.1...

These are followed by an 8-octet Initial Vector for the decryption of
the secret values, if they are encrypted, and then the secret key
values themselves.

Do you do the CFB resets on MPI boundaries with V3 keys? (I asked
about this in an earlier post noting all the places where the PGP-CFB
and the reset were done - I'll see if I can easily repost it).

Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18076 for ietf-openpgp-bks; Mon, 17 Jul 2000 09:29:55 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18068 for ; Mon, 17 Jul 2000 09:29:53 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA31966; Mon, 17 Jul 2000 09:32:05 -0700
Date: Mon, 17 Jul 2000 09:32:05 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> From [email-masked] Mon Jul 17 06:29:39 2000
> From: "Michael Young"
> To:
> Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
> Date: Mon, 17 Jul 2000 08:30:50 -0400
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
> List-Archive:
> List-ID:
>
> Yes, I meant Twofish, not Blowfish.
>
> The draft I found at imc.org still says in section 5.5.3:
> > - [Optional] If secret data is encrypted, eight-octet Initial
> > Vector (IV).
>
> This should now read "an IV of the same length as the cipher block"?

I suppose so.

> [Is there a more recent draft than that posted at imc.org? That one
> claims to expire June 2000.]

I don't know.

> As Werner Koch pointed out last year, this will require an implementation
> to know the block size simply in order to parse the rest of the packet.
> Given that the only material after the IV is the encrypted part, and thus
> won't be readable anyway without support for that cipher, I suppose this
> isn't all that serious. But is there any intention to make the IV size
> self-describing for future ciphers, or is this the final plan?

We already have this problem, because StringToKey structures also do not
have their length self-describing. Hitting an unknown S2K identifier
leaves you in the same boat. Luckily it never matters, as in all cases,
there is nothing left in the packet to parse if you don't know how to
decode it.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17225 for ietf-openpgp-bks; Mon, 17 Jul 2000 08:47:43 -0700 (PDT)
Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17221 for ; Mon, 17 Jul 2000 08:47:41 -0700 (PDT)
Received: from A1ba8.pppool.de (A1ba8.pppool.de [213.6.27.168]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id RAA17212; Mon, 17 Jul 2000 17:49:53 +0200 (MET DST)
Date: Mon, 17 Jul 2000 14:38:42 +0200
From: Marcel Zamzow
X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091
Reply-To: Marcel Zamzow
X-Priority: 3 (Normal)
Message-ID: <[email-masked]>
To: "L. Sassaman"
Subject: Re[2]: VPN Systems via OpenPGP
In-reply-To:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----

Hello!

Friday, July 14, 2000, 11:51:07 PM, you wrote:

LS> Both FreeS/WAN and the OpenBSD IPsec products are open sourced. Does your
LS> project require you to start from scratch, or could you take a
LS> pre-existing VPN system and integrate OpenPGP into it?
Well, I think I'll first have a close look to those
products, but generally I'd like to do it the hard
way .
My aim isn´t a complete end-user software-package,
but instead a nice technology-study.
But encryption should already be performed on the
tcp/ip level.

Best regards,
Marcel

- ---
/*
Marcel Zamzow, student of Computer Science
[University of Applied Sciences Iserlohn]
homepage : http://www.zamzow.de
mailto : [email-masked]
*/

-----BEGIN PGP SIGNATURE-----
iQIVAwUAOXL+DfPorQ0Gk425AQF4uw/9F+JZgG7tdBKbKR5wX1a8ydfuhXVfWMjh
hy+btzFb8ZR5RSWJ7Xlt+I21sSFtYhgiJzT4NDdDfjoT32aEMnptv5vS2XQjousf
99GndPmXLVvOcsPYt6+Y8Z6DR2ilKAOYKxw4scNFmSuzkoKLN1TrDDCPDJB6D2YS
bLhKBE+9GZtztt9j9PO7j2DjwjutyGKlymlfZzOPuW74CrGpYODdXf0VqQEp56DF
Svt7xdyWtnDVCYeP96oWH1aCyz8U7Eafuk7j2G0j//LNAYPBuAVtdJHvCeELAV/e
9EQyRndUwyJ7Bz6rp8cv0sQT+3ikc+9IImmSzTjq9t8J9axXhAwRZIT4ZM4//nF0
O6c4UYUFSsj/wOBc8uETVXnEwH0xOVg/UEks+k3NZxxUFiFY3IkK4Ug6xnVyBoPH
WhbS2nG6NxAiIg+0Nvntz37r/JZWw+Km47HzS26kneJ4idT5vccukVEByrJMtQEi
jTXRpgV1sleh8dSqtSZLu9zKC4ukWskFXvFhpYRch6KmPNeornGPlLAGICrgnSER
GPOxvW40763jwjW/YNs34fVynR5zVEnM+absFpUf6JSD/lqx9psHGY02mTpS3wOu
X7s3iH5XtxsRH14pdohw+em1igMl2OSDizv4f4x3+KDEwURMjzohzP7PDhg2LYpy
TULaBkjD8NE=
=ZX+L
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14402 for ietf-openpgp-bks; Mon, 17 Jul 2000 06:52:30 -0700 (PDT)
Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14398 for ; Mon, 17 Jul 2000 06:52:29 -0700 (PDT)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyfv03549; Mon, 17 Jul 2000 13:54:45 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08232; Mon, 17 Jul 00 09:50:52 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA11050; Mon, 17 Jul 2000 09:54:44 -0400
From: Paul Koning
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Mon, 17 Jul 2000 09:54:44 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
References: <[email-masked]>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

>>>>> "Michael" == Michael Young writes:

Michael> Yes, I meant Twofish, not Blowfish. The draft I found at
Michael> imc.org still says in section 5.5.3:
>> - [Optional] If secret data is encrypted, eight-octet Initial
>> Vector (IV).

Michael> This should now read "an IV of the same length as the cipher
Michael> block"?

Clearly yes. The IV always must be the same size as the blocksize for
any block cipher.

Michael> As Werner Koch pointed out last year, this will require an
Michael> implementation to know the block size simply in order to
Michael> parse the rest of the packet. Given that the only material
Michael> after the IV is the encrypted part, and thus won't be
Michael> readable anyway without support for that cipher, I suppose
Michael> this isn't all that serious. But is there any intention to
Michael> make the IV size self-describing for future ciphers, or is
Michael> this the final plan?

Can't see any reason to change that. You only need to know the IV if
you're going to decrypt. And to do that clearly you must know the
cipher, which includes knowing its blocksize.

If you're not going to decrypt, you might as well consider the IV as
part of the encrypted message, since it doesn't contain any
interesting information.

paul

Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14018 for ietf-openpgp-bks; Mon, 17 Jul 2000 06:28:03 -0700 (PDT)
Received: from djebel.gnupg.de ([email-masked] [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14013 for ; Mon, 17 Jul 2000 06:28:01 -0700 (PDT)
Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13EBG5-0002fu-00; Mon, 17 Jul 2000 15:48:33 +0200
Date: Mon, 17 Jul 2000 15:48:33 +0200
From: Werner Koch
To: [email-masked]
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Message-ID: <[email-masked]>
Mail-Followup-To: [email-masked]
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <[email-masked]>; from [email-masked] on Mon, Jul 17, 2000 at 08:30:50AM -0400
X-URL: http://www.openit.de
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, 17 Jul 2000, Michael Young wrote:

> The draft I found at imc.org still says in section 5.5.3:
> > - [Optional] If secret data is encrypted, eight-octet Initial
> > Vector (IV).
>
> This should now read "an IV of the same length as the cipher block"?

5.7. got it right.

Werner

--
Werner Koch OpenPGP key 621CC013
OpenIT GmbH http://www.OpenIT.de

Received: by ns.secondary.com (8.9.3/8.9.3) id FAA12955 for ietf-openpgp-bks; Mon, 17 Jul 2000 05:33:23 -0700 (PDT)
Received: from alpha.pit.adelphia.net (alpha.pit.adelphia.net [24.48.44.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12950 for ; Mon, 17 Jul 2000 05:33:21 -0700 (PDT)
Received: from mwyoung.transarc.com (pa-bethelpark1b-76.pit.adelphia.net [24.48.158.76]) by alpha.pit.adelphia.net (8.9.2/8.9.2) with SMTP id IAA24095 for ; Mon, 17 Jul 2000 08:35:41 -0400 (EDT)
Message-ID: <[email-masked]>
From: "Michael Young"
To:
Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7
Date: Mon, 17 Jul 2000 08:30:50 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Yes, I meant Twofish, not Blowfish.

The draft I found at imc.org still says in section 5.5.3:
> - [Optional] If secret data is encrypted, eight-octet Initial
> Vector (IV).

This should now read "an IV of the same length as the cipher block"?

[Is there a more recent draft than that posted at imc.org? That one
claims to expire June 2000.]

As Werner Koch pointed out last year, this will require an implementation
to know the block size simply in order to parse the rest of the packet.
Given that the only material after the IV is the encrypted part, and thus
won't be readable anyway without support for that cipher, I suppose this
isn't all that serious. But is there any intention to make the IV size
self-describing for future ciphers, or is this the final plan?

Thanks for the quick responses.

Received: by ns.secondary.com (8.9.3/8.9.3) id CAA06720 for ietf-openpgp-bks; Mon, 17 Jul 2000 02:03:24 -0700 (PDT)
Received: from djebel.gnupg.de ([email-masked] [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06715 for ; Mon, 17 Jul 2000 02:03:22 -0700 (PDT)
Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13E77v-0002Oz-00; Mon, 17 Jul 2000 11:23:51 +0200
Date: Mon, 17 Jul 2000 11:23:51 +0200
From: Werner Koch
To: [email-masked]
Subject: Re: Resolution on large-block ciphers (e.g., Blowfish), PGP7
Message-ID: <[email-masked]>
Mail-Followup-To: [email-masked]
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <[email-masked]>; from [email-masked] on Sun, Jul 16, 2000 at 07:14:42PM -0400
X-URL: http://www.openit.de
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Sun, 16 Jul 2000, Michael Young wrote:

> The draft makes no mention of how to encrypt secret keys. It still mentions
> an 8-byte IV. I didn't see a clear winner in the discussion: an 8-byte IV

IIRC it mention 8 byte IV only in the example. The specification
should say an IV of the the same size as the blocksize. GnuPG 1.0.2
does exactly this.

Werner

--
Werner Koch OpenPGP key 621CC013
OpenIT GmbH tel +49 211 239577-0
Birkenstr. 12 email [email-masked]
D-40233 Duesseldorf http://www.OpenIT.de

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA00972 for ietf-openpgp-bks; Sun, 16 Jul 2000 20:43:43 -0700 (PDT)
Received: from cypherspace.org ([email-masked] [24.201.22.249]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA00965 for ; Sun, 16 Jul 2000 20:43:42 -0700 (PDT)
Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id XAA01334; Sun, 16 Jul 2000 23:47:30 -0500
Date: Sun, 16 Jul 2000 23:47:30 -0500
Message-Id: <[email-masked]>
From: Adam Back
To: [email-masked]
Cc: [email-masked]
In-reply-to: <[email-masked]> (message from Ian Brown on Wed, 05 Jul 2000 11:55:43 +0100)
Subject: Re: Forward secrecy
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Section 3 describes one-time keys, that are sent with messages to
allow a the recipient to reply with immediate forward secrecy
(immediately after receipt).

I wonder if we could use a one-time key server to avoid the need for
interactive use of email (need a reply from the recipient to get a key
to reply to).

Lets say we add a new function to keyservers which is that you submit
a whole bunch of keys, and it hands them out on request, and deletes
them after they've been received.

I guess there's a pretty easy DoS there -- someone just goes and
repeatedly downloads all available keys, to deny others the ability to
obtain one-time keys.

There might be some weak approaches to resist this DoS (eg refuse to
provide more than one one-time key per time period to the same IP
address), but they are just that -- weak.

Adam

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA29002 for ietf-openpgp-bks; Sun, 16 Jul 2000 20:03:14 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28998 for ; Sun, 16 Jul 2000 20:03:12 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id UAA30732; Sun, 16 Jul 2000 20:05:20 -0700
Date: Sun, 16 Jul 2000 20:05:20 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Resolution on large-block ciphers (e.g., Blowfish), PGP7
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> The press releases for PGP version 7 from NAI says that it will include
> Blowfish support. Can someone from NAI (or a beta customer) confirm
> that they conform to the current draft? How do they deal with secret key
> encryption using Blowfish?

You mean Twofish.

PGP version 7 will use a 16 byte (128 bit) IV when encrypting secret keys
using Twofish.

Hal Finney

Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18789 for ietf-openpgp-bks; Sun, 16 Jul 2000 16:17:24 -0700 (PDT)
Received: from alpha.pit.adelphia.net (alpha.pit.adelphia.net [24.48.44.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18784 for ; Sun, 16 Jul 2000 16:17:22 -0700 (PDT)
Received: from mwyoung.transarc.com (pa-bethelpark1b-76.pit.adelphia.net [24.48.158.76]) by alpha.pit.adelphia.net (8.9.2/8.9.2) with SMTP id TAA04326 for ; Sun, 16 Jul 2000 19:19:36 -0400 (EDT)
Message-ID: <[email-masked]>
From: "Michael Young"
To:
Subject: Resolution on large-block ciphers (e.g., Blowfish), PGP7
Date: Sun, 16 Jul 2000 19:14:42 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Looking through the archives, I see discussion on how to handle ciphers
with block sizes over 8 bytes, but the resolution was not clear.

The draft has been updated regarding SE data packets (tag 9). This
appears to match the example that Werner Koch posted on April 9, 1999.
(My implementation matches that example.)

The draft makes no mention of how to encrypt secret keys. It still mentions
an 8-byte IV. I didn't see a clear winner in the discussion: an 8-byte IV
seems decidedly inadequate; having the IV length depend on the algorithm number
would require a table for parsing; using a new version number to allow a
length to be inserted wouldn't be too bad. Simply inserting a length (or making
the IV an MPI) for algorithms 6 and beyond would be workable. Was there
a resolution that I missed, and if so, will it be in an upcoming draft? If
the intention is really to stick with an 8-byte IV, can the RFC be updated
to discuss exactly how it works in this context?

The press releases for PGP version 7 from NAI says that it will include
Blowfish support. Can someone from NAI (or a beta customer) confirm
that they conform to the current draft? How do they deal with secret key
encryption using Blowfish?

Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18770 for ietf-openpgp-bks; Sun, 16 Jul 2000 16:16:25 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18765 for ; Sun, 16 Jul 2000 16:16:18 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA30461; Sun, 16 Jul 2000 16:18:21 -0700
Date: Sun, 16 Jul 2000 16:18:21 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: q re binding user id's and subkeys
Cc: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Erron Criddle writes:

> > > By binding an encryption sub key to a primary signing key, you are binding
> > > it to multiple user id's (if multiple user id's exist), however if user id
> > > (a) wants to encrypt data using sub-key (b) and user id (b) wants to
> > > encrypt data using sub-key (a), where do you actually make the bind?
> >
> >There is no way to express this in OpenPGP.
>
> Would it be hard to express that in OpenPGP? Can a signature subkey be
> added that specifies the top level id that should be linked to the subkey?
> Accordingly, if the subkey is bound to all upper level id's (as is the case
> now) then the signature subkey would simply be left blank.

Well, there is no way to express that in OpenPGP. If you are asking,
could we add a way to do that, the answer is that it would be technically
possible. The question is whether there is sufficient desire to add that.

I think if you wanted to do this, it would be better to add a way for
a given userid self-sig to say which subkey to use when that userid
was chosen as an encryption target, rather than the other way around
(subkey to point at userid).

Without this mechanism, the main use of multiple subkeys is to make
it easy to roll over your encryption keys relatively often, without
invalidating the validity of your key. That's an important piece of
functionality in itself.

We might wish to discuss whether it is worthwhile to go beyond this to
also allow the use of different subkeys for different userids. It would
add considerable complexity to the UI, and at PGP.com we are if anything
trying to simplify the UI. Most users still say encryption is too hard
to use.

Hal Finney

Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11008 for ietf-openpgp-bks; Sun, 16 Jul 2000 08:33:47 -0700 (PDT)
Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10997 for ; Sun, 16 Jul 2000 08:33:45 -0700 (PDT)
Received: from sobolev.does-not-exist.org (dialup60.ip.lu [208.161.253.60]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id RAA18499; Sun, 16 Jul 2000 17:31:24 +0200 (CEST)
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 7963A2F033; Sun, 16 Jul 2000 12:30:00 +0200 (CEST)
Date: Sun, 16 Jul 2000 12:30:00 +0200
From: Thomas Roessler
To: Ian Bell , [email-masked], Michael Elkins , Dave Del Torto
Subject: PGP/MIME: encoding restrictions.
Message-ID: <[email-masked]>
Mail-Followup-To: Ian Bell , [email-masked], Michael Elkins , Dave Del Torto
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.5i
In-Reply-To: ; from [email-masked] on Thu, May 11, 2000 at 09:44:28AM +0100
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On 2000-05-11 09:44:28 +0100, Ian Bell wrote:

> Should the issue of binary versus text-mode signatures
> be addressed?

It should, and I believe the following would be the most
robust solution:

(1) require clients to create text mode signatures
(2) require clients to use either quoted-printable or
base64 for any body parts which contain trailing
whitespace.

Note that this seems to be what most clients do anyway at
present.

Rationale: MIME has been carefully designed in a way which
makes sure that all essential information makes it through
gateways which tamper with trailing whitespace. Thus, we
should make sure that PGP/MIME signed messages don't lose
any information on such paths, either.

Not losing any information in the signed body is
guaranteed by the use of qp/base64, whenever trailing
whitespace is present.

Not unnecesarily invalidating signatures is guaranteed by
the use of text-mode signatures, since these signatures
will ignore any trailing whitespace. Note that this
trailing whitespace must be ignored by standard-conforming
decoders for qp/base64, too, and doesn't carry any meaning
in RFC822 (think about message/rfc822 attachments) or MIME
headers, so signature verification will fail if and only
if actual content has been modified.

Binary-mode signatures would also be invalidated if
trailing whitespace is tampered with, even though it
doesn't carry any meaning to the MIME encoding used.

Comments?

--
Thomas Roessler

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19323 for ietf-openpgp-bks; Sat, 15 Jul 2000 20:33:49 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19319 for ; Sat, 15 Jul 2000 20:33:46 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A07423B01D6; Sun, 16 Jul 2000 11:35:32 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 16 Jul 2000 11:24:58 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: q re binding user id's and subkeys
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hal,

At 08:11 AM 14/07/2000 -0700, [email-masked] wrote:

>Erron writes:
> > Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand
> > how one binds an encryption sub key to a particular user id and the top
> > level signing key?
>
>You can't.

> > By binding an encryption sub key to a primary signing key, you are binding
> > it to multiple user id's (if multiple user id's exist), however if user id
> > (a) wants to encrypt data using sub-key (b) and user id (b) wants to
> > encrypt data using sub-key (a), where do you actually make the bind?
>
>There is no way to express this in OpenPGP.

Would it be hard to express that in OpenPGP? Can a signature subkey be
added that specifies the top level id that should be linked to the subkey?
Accordingly, if the subkey is bound to all upper level id's (as is the case
now) then the signature subkey would simply be left blank.

If this cannot be done then I would assume that if you want different
encryption keys for various user id's /alias's, then you would have to
create two separate private keyrings that use different signing keys as
well...or can you do this somehow using the same signing key?

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01790 for ietf-openpgp-bks; Sat, 15 Jul 2000 11:10:31 -0700 (PDT)
Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01776 for ; Sat, 15 Jul 2000 11:10:29 -0700 (PDT)
Received: from woudt.nl (cudomix.ai [209.88.68.210]) by cypherpunks.ai (Postfix) with ESMTP id D154B4D for ; Sat, 15 Jul 2000 14:12:10 -0400 (AST)
Message-ID: <[email-masked]>
Date: Sat, 15 Jul 2000 14:12:07 -0400
From: Edwin Woudt
X-Mailer: Mozilla 4.73 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [email-masked]
Subject: Signature Subpacket format questions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

While implementing V4 signature support for a Java OpenPGP library, I
encountered a few things with some Signature Subpackets that were not
immediately clear to me. I would be very grateful if someone could
answer these questions:

* The format specified for both 5.2.3.18. 'Preferred key server' and
5.2.3.20. 'Policy URL' is 'String'. Is this string terminated by a
null value, like 5.2.3.14. 'Regular expression', or not?

* What is the format for 5.2.3.22. 'Signer's User ID'? A String like in
the previous question?

Edwin

--
[email-masked]
http://www.cryptix.org/products/openpgp/

Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17121 for ietf-openpgp-bks; Fri, 14 Jul 2000 14:49:16 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17111 for ; Fri, 14 Jul 2000 14:49:14 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA19015; Fri, 14 Jul 2000 14:51:14 -0700
Date: Fri, 14 Jul 2000 14:51:07 -0700 (PDT)
From: "L. Sassaman"
To: Marcel Zamzow
cc: [email-masked]
Subject: Re: VPN Systems via OpenPGP
In-Reply-To: <[email-masked]>
Message-ID:
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id OAA17112
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

On Thu, 13 Jul 2000, Marcel Zamzow wrote:

> Iserlohn, den 13.07.2000
>
> Hello everybody,
>
> currently i´m evaluating the possibility to
> implement OpenPGP into an Open-Sourced VPN System.
> Has anybody some good url´s for me pointing to
> Virtual Private Networks ? All I have found is
> only pointing to the NAI´s Produkt and is too
> unprecised.
> Moreover has somebody already heard about such an
> implementation, cause this would be my work for
> my Diploma and so it should be something new.

Both FreeS/WAN and the OpenBSD IPsec products are open sourced. Does your
project require you to start from scratch, or could you take a
pre-existing VPN system and integrate OpenPGP into it?

- --Len.

__

L. Sassaman

System Administrator | "Every window on Alcatraz has
Technology Consultant | a view of San Francisco."
icq.. 10735603 |
pgp.. finger://ns.quickie.net/rabbi | --Susanna Kaysen

-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5b4tSPYrxsgmsCmoRAjerAJ0UiVstcPKHv1Q9DJQ6UxhuvpVftgCg+rct
tqFsJiIuA1BhGCsU1JwHgO4=
=2kqu
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22602 for ietf-openpgp-bks; Fri, 14 Jul 2000 08:09:33 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22598 for ; Fri, 14 Jul 2000 08:09:29 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA24491; Fri, 14 Jul 2000 08:11:19 -0700
Date: Fri, 14 Jul 2000 08:11:19 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: q re binding user id's and subkeys
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Erron writes:
> Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand
> how one binds an encryption sub key to a particular user id and the top
> level signing key?

You can't.

> There seems to be no information contained in a sub-key packet that can
> link it to a user id. Also, the binding signature does not contain info
> regarding a user id (nor the binding signatures subpackets).

That's right.

> By binding an encryption sub key to a primary signing key, you are binding
> it to multiple user id's (if multiple user id's exist), however if user id
> (a) wants to encrypt data using sub-key (b) and user id (b) wants to
> encrypt data using sub-key (a), where do you actually make the bind?

There is no way to express this in OpenPGP.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03381 for ietf-openpgp-bks; Thu, 13 Jul 2000 23:01:37 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA03376 for ; Thu, 13 Jul 2000 23:01:34 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0182530212; Fri, 14 Jul 2000 14:03:20 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 14 Jun 2000 13:52:51 +0800
To: [email-masked]
From: Erron Criddle
Subject: q re binding user id's and subkeys
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand
how one binds an encryption sub key to a particular user id and the top
level signing key?

There seems to be no information contained in a sub-key packet that can
link it to a user id. Also, the binding signature does not contain info
regarding a user id (nor the binding signatures subpackets).

By binding an encryption sub key to a primary signing key, you are binding
it to multiple user id's (if multiple user id's exist), however if user id
(a) wants to encrypt data using sub-key (b) and user id (b) wants to
encrypt data using sub-key (a), where do you actually make the bind?

My apologies if I've (once again), misread or completely missed something.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10789 for ietf-openpgp-bks; Thu, 13 Jul 2000 15:39:52 -0700 (PDT)
Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10785 for ; Thu, 13 Jul 2000 15:39:51 -0700 (PDT)
Received: from A261a.pppool.de (A261a.pppool.de [213.6.38.26]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id AAA15786 for ; Fri, 14 Jul 2000 00:41:52 +0200 (MET DST)
Date: Thu, 13 Jul 2000 16:34:26 +0200
From: Marcel Zamzow
X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091
Reply-To: Marcel Zamzow
X-Priority: 3 (Normal)
Message-ID: <[email-masked]>
To: [email-masked]
Subject: VPN Systems via OpenPGP
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----

Iserlohn, den 13.07.2000

Hello everybody,

currently i´m evaluating the possibility to
implement OpenPGP into an Open-Sourced VPN System.
Has anybody some good url´s for me pointing to
Virtual Private Networks ? All I have found is
only pointing to the NAI´s Produkt and is too
unprecised.
Moreover has somebody already heard about such an
implementation, cause this would be my work for
my Diploma and so it should be something new.

Best regards,
Marcel

- ---
/*
Marcel Zamzow, student of Computer Science
[University of Applied Sciences Iserlohn]
homepage : http://www.zamzow.de
mailto : [email-masked]
*/

-----BEGIN PGP SIGNATURE-----
iQIVAwUAOW3TbfPorQ0Gk425AQFnlA//e73nE6eCNQcDhXGzRTHv8IRQ6ubublPH
bIP1sv29V3Xc+runIKWjpP66hur12DizD7gP2RCukLgMmcFCFTw1IDbXrJxtWmMC
HN+QWDEY1Fpy9+OeKBIBDcHauSdYMoRk0c7ad+0eGCTuxhQjDl/YDO+qoWzFyYl5
qvq2L705L4AzLiIQSZJL7mR5XdqK3ZqCikgwfMkcEvlcnI369wL7qpoWgJgCM+eQ
vDHiMlvfpF8Lm4KMiB/hTdm5SjhG/EJfsxp7KXVTBZrDh2yLuPTnjrn2d6FOa+vc
R392NDtiAsi6H4jDthknW87KMHFycwcMYlfcB3J0pF2Td2IIGvQRd0Q34DohmBxk
EdFuH7bQLNDhD72EFb2GriyVEBZC9sPt8+8BA7XeWVd3Ttr1AlWmcDGHbgmHRC9R
slVK6zyHYFwSmdAtBJZyGp/zyzr2ld7pG0xp0v6WJxsV6WWD4CYJIy1OiWbu7b68
GrIXwntAt/DQ/nSGVuU6MfvYoxgi+k9ERSSzbO3SLxxWYGZTe5SeYXD1CkYu1fCG
HpI4RM9JIGom9vF6eT+7dM92DXNPy7nBwkxXVAB6hWZ4VACoQQsuOsZWLYchMhqd
9uxsFuHwkxm9V01Ux7A1OzaFOzvKZ124qRwJGwppHV90b4XLL4ruvq6MPl5px+Z+
AUA3qrC9Pak=
=/RbR
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28806 for ietf-openpgp-bks; Thu, 13 Jul 2000 08:39:38 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28796 for ; Thu, 13 Jul 2000 08:39:36 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA20889; Thu, 13 Jul 2000 08:41:20 -0700
Date: Thu, 13 Jul 2000 08:41:20 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: V4 Sig. incomplete?
Cc: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> >Yes, this all looks fine now. The one thing I'd add is that there is no
> >need to parse out the key and subkey packets as you have done. After the
> >0x99 and two-octet length, you just hash the key or subkey packet body.
> >The specific contents of the key/subkey packet are irrelevant to the
> >signature algotihm, it's just data to feed the hash.
>
> So you're saying that (1) is OK, however in the case of 2), it would be
> best to structure it this way:

No, I didn't mean that. All I meant was that you don't have to worry
about the contents of the public key packets, the version and time and
MPIs. Just hash the key packet data as a block. It makes it much
easier to see what is going on:

header data

0x99 |
2 octet length |
key packet body data |

user id data

0xb4 |
4 octet length |
username data |

signature trailer

version field to end of hashable data |

V4 signature trailer

0x04 |
0xFF |
4 octet length |

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA04556 for ietf-openpgp-bks; Thu, 13 Jul 2000 00:02:08 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA04552 for ; Thu, 13 Jul 2000 00:02:05 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ACC772A01E6; Thu, 13 Jul 2000 15:03:51 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 13 Jun 2000 14:53:30 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: V4 Sig. incomplete?
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hal,

Nearly there (I think)...just need to clarify what you have said:

At 11:36 PM 12/07/2000 -0700, [email-masked] wrote:

>Yes, this all looks fine now. The one thing I'd add is that there is no
>need to parse out the key and subkey packets as you have done. After the
>0x99 and two-octet length, you just hash the key or subkey packet body.
>The specific contents of the key/subkey packet are irrelevant to the
>signature algotihm, it's just data to feed the hash.

So you're saying that (1) is OK, however in the case of 2), it would be
best to structure it this way:

header data

0x99 |
2 octet length |

public ElGamal keys

0x04 (version) |
4 octet time |
0x10 (for ElGamal enc. algorithm) |
MPI of ElGamal prime p |
MPI of ElGamal group generator g |
MPI of ElGamal public key value y |

signature trailer

version field to end of hashable data |

V4 signature trailer

0x04 |
0xFF |
4 octet length |

I hope this is OK...or did I totally misunderstand your response?

Thanks :)

> > 1) V4 Sig., type 0x10. Concatenate the following data then hash it for
> > input into the DSA (the data to be hashed is terminated with the | char)
> >
> > header data
> >
> > 0x99 |
> > 2 octet length |
> >
> > public DSA keys (version 4)
> >
> > 0x04 (version) |
> > 4 octet time |
> > 0x11 (for DSA signing algorithm) |
> > MPI of DSA prime p |
> > MPI of DSA grooup order q |
> > MPI of DSA group generator g |
> > MPI of DSA public key value y |
> >
> > user id data
> >
> > 0xb4 |
> > 4 octet length |
> > username data |
> >
> > signature trailer
> >
> > version field to end of hashable data |
> >
> > V4 signature trailer
> >
> > 0x04 |
> > 0xFF |
> > 4 octet length |
> >
> > All the above data is concatenated then hashed. The left 16 bits are
> > inserted into the hash check field of the signature and then the hash is
> > fed into the DSA for production of the signature.
> >
> > 2) V4 Sig., type 0x18. Concatenate the following data then hash it for
> > input into the DSA (the data to be hashed is terminated with the | char)
> >
> > header data
> >
> > 0x99 |
> > 2 octet length |
> >
> > public DSA keys (version 4)
> >
> > 0x04 (version) |
> > 4 octet time |
> > 0x11 (for DSA signing algorithm) |
> > MPI of DSA prime p |
> > MPI of DSA grooup order q |
> > MPI of DSA group generator g |
> > MPI of DSA public key value y |
> >
> > header data
> >
> > 0x99 |
> > 2 octet length |
> >
> > public ElGamal keys
> >
> > 0x04 (version) |
> > 4 octet time |
> > 0x10 (for ElGamal enc. algorithm) |
> > MPI of ElGamal prime p |
> > MPI of ElGamal group generator g |
> > MPI of ElGamal public key value y |
> >
> > signature trailer
> >
> > version field to end of hashable data |
> >
> > V4 signature trailer
> >
> > 0x04 |
> > 0xFF |
> > 4 octet length |
> >
> > Once again, all the above data is concatenated then hashed. The left 16
> > bits are inserted into the hash check field of the signature and then the
> > hash is fed into the DSA for production of the signature.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03508 for ietf-openpgp-bks; Wed, 12 Jul 2000 23:34:53 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03502 for ; Wed, 12 Jul 2000 23:34:52 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id XAA20214; Wed, 12 Jul 2000 23:36:32 -0700
Date: Wed, 12 Jul 2000 23:36:32 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: V4 Sig. incomplete?
Cc: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Yes, this all looks fine now. The one thing I'd add is that there is no
need to parse out the key and subkey packets as you have done. After the
0x99 and two-octet length, you just hash the key or subkey packet body.
The specific contents of the key/subkey packet are irrelevant to the
signature algotihm, it's just data to feed the hash.

Hal

> 1) V4 Sig., type 0x10. Concatenate the following data then hash it for
> input into the DSA (the data to be hashed is terminated with the | char)
>
> header data
>
> 0x99 |
> 2 octet length |
>
> public DSA keys (version 4)
>
> 0x04 (version) |
> 4 octet time |
> 0x11 (for DSA signing algorithm) |
> MPI of DSA prime p |
> MPI of DSA grooup order q |
> MPI of DSA group generator g |
> MPI of DSA public key value y |
>
> user id data
>
> 0xb4 |
> 4 octet length |
> username data |
>
> signature trailer
>
> version field to end of hashable data |
>
> V4 signature trailer
>
> 0x04 |
> 0xFF |
> 4 octet length |
>
> All the above data is concatenated then hashed. The left 16 bits are
> inserted into the hash check field of the signature and then the hash is
> fed into the DSA for production of the signature.
>
> 2) V4 Sig., type 0x18. Concatenate the following data then hash it for
> input into the DSA (the data to be hashed is terminated with the | char)
>
> header data
>
> 0x99 |
> 2 octet length |
>
> public DSA keys (version 4)
>
> 0x04 (version) |
> 4 octet time |
> 0x11 (for DSA signing algorithm) |
> MPI of DSA prime p |
> MPI of DSA grooup order q |
> MPI of DSA group generator g |
> MPI of DSA public key value y |
>
> header data
>
> 0x99 |
> 2 octet length |
>
> public ElGamal keys
>
> 0x04 (version) |
> 4 octet time |
> 0x10 (for ElGamal enc. algorithm) |
> MPI of ElGamal prime p |
> MPI of ElGamal group generator g |
> MPI of ElGamal public key value y |
>
> signature trailer
>
> version field to end of hashable data |
>
> V4 signature trailer
>
> 0x04 |
> 0xFF |
> 4 octet length |
>
> Once again, all the above data is concatenated then hashed. The left 16
> bits are inserted into the hash check field of the signature and then the
> hash is fed into the DSA for production of the signature.

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA03112 for ietf-openpgp-bks; Wed, 12 Jul 2000 23:26:57 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA03108 for ; Wed, 12 Jul 2000 23:26:54 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A48615501CE; Thu, 13 Jul 2000 14:28:38 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 13 Jun 2000 14:18:17 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: V4 Sig. incomplete?
Cc: [email-masked]
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hal,

Many thanks for your reply - it has certainly made things clearer :)

At 10:39 PM 12/07/2000 -0700, [email-masked] wrote:

> > This is only 5 octets...does anybody know what the 6th octet is? ...or
> is a
> > V4 signature final trailer only 5 octets?
>
>Where did you get the "or" in "0x04 or 0xFF"?

Obviously from some cross-linked neurons - sorry for the wasted b/w.

I have also rewritten my original question and answers - hopefully they are
correct this time :) :

1) V4 Sig., type 0x10. Concatenate the following data then hash it for
input into the DSA (the data to be hashed is terminated with the | char)

header data

0x99 |
2 octet length |

public DSA keys (version 4)

0x04 (version) |
4 octet time |
0x11 (for DSA signing algorithm) |
MPI of DSA prime p |
MPI of DSA grooup order q |
MPI of DSA group generator g |
MPI of DSA public key value y |

user id data

0xb4 |
4 octet length |
username data |

signature trailer

version field to end of hashable data |

V4 signature trailer

0x04 |
0xFF |
4 octet length |

All the above data is concatenated then hashed. The left 16 bits are
inserted into the hash check field of the signature and then the hash is
fed into the DSA for production of the signature.

2) V4 Sig., type 0x18. Concatenate the following data then hash it for
input into the DSA (the data to be hashed is terminated with the | char)

header data

0x99 |
2 octet length |

public DSA keys (version 4)

0x04 (version) |
4 octet time |
0x11 (for DSA signing algorithm) |
MPI of DSA prime p |
MPI of DSA grooup order q |
MPI of DSA group generator g |
MPI of DSA public key value y |

header data

0x99 |
2 octet length |

public ElGamal keys

0x04 (version) |
4 octet time |
0x10 (for ElGamal enc. algorithm) |
MPI of ElGamal prime p |
MPI of ElGamal group generator g |
MPI of ElGamal public key value y |

signature trailer

version field to end of hashable data |

V4 signature trailer

0x04 |
0xFF |
4 octet length |

Once again, all the above data is concatenated then hashed. The left 16
bits are inserted into the hash check field of the signature and then the
hash is fed into the DSA for production of the signature.

> > 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding
> into
> > the DSA (assuming DSA sig):
>
>I'm not sure what you mean by "hash then concatenate". It would make
>more sense to say "concatenate then hash", or more simply, just "hash".
>
> > public DSA keys (this line not hashed)
> >
> > 0x99 |
> > 2 octet length |
>
>At this point you hash the entire public key packet. As described
>in section 5.5.2 of RFC 2440, in addition to the MPI data below, this
>includes a version number, creation time, validity period if V3 key,
>and public key algorithm type. This is then followed by the MPI data:
>
> > MPI of DSA prime p |
> > MPI of DSA grooup order q |
> > MPI of DSA group generator g |
> > MPI of DSA public key value y |
>
>Of course a DSA signature could be over an RSA key as well.
>
> > +
> >
> > user id (this line not hashed)
> >
> > 0xb4 |
> > 4 octet length |
> > username data |
> >
> > version field to end of hashable data |
>
>Yes, of the signature packet.
>
> >
> > 0x04 |
>
>then 0xFF then
>
> > 4 octet length |
> > ? (see previous question re 5.4) |
>
>This looks correct, incorporating the changes above.
>
>
> > 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding
> into
> > the DSA (assuming DSA signature keys and ElGamal encryption keys):
> >
> > public DSA keys (this line not hashed)
> >
> > 0x99 |
> > 2 octet length |
>
>As above, other key packet information is hashed here.
>
> > MPI of DSA prime p |
> > MPI of DSA grooup order q |
> > MPI of DSA group generator g |
> > MPI of DSA public key value y |
> >
> > +
> >
> > public ElGamal keys (this line not hashed)
> >
> > 0x99 |
> > 2 octet length |
>
>Again, other subkey packet information is hashed here.
>
> > MPI of ElGamal prime p |
> > MPI of ElGamal grooup order q |
>
>Actually this is the group generator g, not the group order q.
>
> > MPI of ElGamal public key value y |
> >
> > version field to end of hashable data |
> >
> > 0x04 |
>
>As above, 0xFF goes here.
>
> > 4 octet length |
> > ? (see previous question re 5.4) |
>
>Hal Finney

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00930 for ietf-openpgp-bks; Wed, 12 Jul 2000 22:38:12 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00923 for ; Wed, 12 Jul 2000 22:38:10 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA19969; Wed, 12 Jul 2000 22:39:51 -0700
Date: Wed, 12 Jul 2000 22:39:51 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: V4 Sig. incomplete?
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> With reference to 5.4; the second last paragraph states that a version 4
> signature has a final trailer of 6 octets, being:
>
> 0x04 or 0xFF, a four octet big endian number
>
> This is only 5 octets...does anybody know what the 6th octet is? ...or is a
> V4 signature final trailer only 5 octets?

Where did you get the "or" in "0x04 or 0xFF"? The spec says,

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

I don't see an "or". It is 0x04, 0xFF, and the four octets of length.
That is six octets.

> 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding into
> the DSA (assuming DSA sig):

I'm not sure what you mean by "hash then concatenate". It would make
more sense to say "concatenate then hash", or more simply, just "hash".

> public DSA keys (this line not hashed)
>
> 0x99 |
> 2 octet length |

At this point you hash the entire public key packet. As described
in section 5.5.2 of RFC 2440, in addition to the MPI data below, this
includes a version number, creation time, validity period if V3 key,
and public key algorithm type. This is then followed by the MPI data:

> MPI of DSA prime p |
> MPI of DSA grooup order q |
> MPI of DSA group generator g |
> MPI of DSA public key value y |

Of course a DSA signature could be over an RSA key as well.

> +
>
> user id (this line not hashed)
>
> 0xb4 |
> 4 octet length |
> username data |
>
> version field to end of hashable data |

Yes, of the signature packet.

> 0x04 |

then 0xFF then

> 4 octet length |
> ? (see previous question re 5.4) |

This looks correct, incorporating the changes above.

> 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding into
> the DSA (assuming DSA signature keys and ElGamal encryption keys):
>
> public DSA keys (this line not hashed)
>
> 0x99 |
> 2 octet length |

As above, other key packet information is hashed here.

> MPI of DSA prime p |
> MPI of DSA grooup order q |
> MPI of DSA group generator g |
> MPI of DSA public key value y |
>
> +
>
> public ElGamal keys (this line not hashed)
>
> 0x99 |
> 2 octet length |

Again, other subkey packet information is hashed here.

> MPI of ElGamal prime p |
> MPI of ElGamal grooup order q |

Actually this is the group generator g, not the group order q.

> MPI of ElGamal public key value y |
>
> version field to end of hashable data |
>
> 0x04 |

As above, 0xFF goes here.

> 4 octet length |
> ? (see previous question re 5.4) |

Hal Finney

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA29771 for ietf-openpgp-bks; Wed, 12 Jul 2000 22:27:16 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29765 for ; Wed, 12 Jul 2000 22:27:14 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA19939; Wed, 12 Jul 2000 22:28:55 -0700
Date: Wed, 12 Jul 2000 22:28:55 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: q re 5.1; is it m*(y**k) or (m*y)**k ?
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> 5.1: Regarding the ElGamal keys and the *m* value, is it:
>
> a) (m*y)**k mod p
> b) m * (y**k) mod p

It is (b).

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25504 for ietf-openpgp-bks; Wed, 12 Jul 2000 21:10:40 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA25483 for ; Wed, 12 Jul 2000 21:10:32 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A49014E018E; Thu, 13 Jul 2000 12:12:16 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 13 Jun 2000 12:01:55 +0800
To: [email-masked]
From: Erron Criddle
Subject: V4 Sig. incomplete?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all concerned:

With reference to 5.4; the second last paragraph states that a version 4
signature has a final trailer of 6 octets, being:

0x04 or 0xFF, a four octet big endian number

This is only 5 octets...does anybody know what the 6th octet is? ...or is a
V4 signature final trailer only 5 octets?

TIA for the clarification.

PS: Can anyone please confirm the following (hashed data is appended by the
| symbol)

1) V4 Sig., type 0x10. Hash then concatenate the following for feeding into
the DSA (assuming DSA sig):

public DSA keys (this line not hashed)

0x99 |
2 octet length |
MPI of DSA prime p |
MPI of DSA grooup order q |
MPI of DSA group generator g |
MPI of DSA public key value y |

+

user id (this line not hashed)

0xb4 |
4 octet length |
username data |

version field to end of hashable data |

0x04 |
4 octet length |
? (see previous question re 5.4) |

2) V4 Sig., type 0x18. Hash then concatenate the following for feeding into
the DSA (assuming DSA signature keys and ElGamal encryption keys):

public DSA keys (this line not hashed)

0x99 |
2 octet length |
MPI of DSA prime p |
MPI of DSA grooup order q |
MPI of DSA group generator g |
MPI of DSA public key value y |

+

public ElGamal keys (this line not hashed)

0x99 |
2 octet length |
MPI of ElGamal prime p |
MPI of ElGamal grooup order q |
MPI of ElGamal public key value y |

version field to end of hashable data |

0x04 |
4 octet length |
? (see previous question re 5.4) |

Once again, thanks for any clarification.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22842 for ietf-openpgp-bks; Wed, 12 Jul 2000 20:41:19 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA22838 for ; Wed, 12 Jul 2000 20:41:17 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ADB012C01CE; Thu, 13 Jul 2000 11:42:56 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 13 Jun 2000 11:32:36 +0800
To: [email-masked]
From: Erron Criddle
Subject: q re 5.1; is it m*(y**k) or (m*y)**k ?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

A couple of q's re 2440:

5.1: Regarding the ElGamal keys and the *m* value, is it:

a) (m*y)**k mod p
b) m * (y**k) mod p

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

Received: by ns.secondary.com (8.9.3/8.9.3) id KAA21956 for ietf-openpgp-bks; Tue, 11 Jul 2000 10:22:31 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21948 for ; Tue, 11 Jul 2000 10:22:29 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id KAA20476; Tue, 11 Jul 2000 10:24:09 -0700
Date: Tue, 11 Jul 2000 10:24:01 -0700 (PDT)
From: "L. Sassaman"
To: Werner Koch
cc: [email-masked]
Subject: Re: Question regarding 2440:5.2.3.16
In-Reply-To: <[email-masked]>
Message-ID:
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

On Tue, 11 Jul 2000, Werner Koch wrote:

> On Mon, 10 Jul 2000, L. Sassaman wrote:
>
> > The client takes the public key block, signs it, and submits this signed
> > blob to the server. The server then verifies the signature, trims away
> > that signature, and adds the key.
>
> Don't forget that the server needs to accept unsigned requests too and
> allow to add key revocations and certicate revocations.

Yep. I figured I wouldn't bring that up again, since it looks like we're
going to be needing an I-D on keyservers, and that would fit in there. But
yes, the owner-update-only flag must be ignored on all types of
revocations.

- --Len.

__

L. Sassaman

System Administrator |
Technology Consultant | "Credo quia absurdum."
icq.. 10735603 |
pgp.. finger://ns.quickie.net/rabbi | --Tertullian

-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5a1g4PYrxsgmsCmoRAl89AJ9X6LyWrnawfETOB1Xv6w5zQEsxkQCg3yXr
CbFEAeBCXm20kfE9umyp+ks=
=X0Ae
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id DAA29622 for ietf-openpgp-bks; Tue, 11 Jul 2000 03:59:50 -0700 (PDT)
Received: from djebel.gnupg.de ([email-masked] [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29614 for ; Tue, 11 Jul 2000 03:59:47 -0700 (PDT)
Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13By3W-0000AG-00; Tue, 11 Jul 2000 13:18:26 +0200
Date: Tue, 11 Jul 2000 13:18:26 +0200
From: Werner Koch
To: [email-masked]
Subject: Re: Question regarding 2440:5.2.3.16
Message-ID: <[email-masked]>
Mail-Followup-To: [email-masked]
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: ; from [email-masked] on Mon, Jul 10, 2000 at 10:19:52AM -0700
X-URL: http://www.openit.de
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, 10 Jul 2000, L. Sassaman wrote:

> The client takes the public key block, signs it, and submits this signed
> blob to the server. The server then verifies the signature, trims away
> that signature, and adds the key.

Don't forget that the server needs to accept unsigned requests too and
allow to add key revocations and certicate revocations.

Werner

--
Werner Koch OpenPGP key 621CC013
OpenIT GmbH tel +49 211 239577-0
Birkenstr. 12 email [email-masked]
D-40233 Duesseldorf http://www.OpenIT.de

Received: by ns.secondary.com (8.9.3/8.9.3) id OAA12208 for ietf-openpgp-bks; Mon, 10 Jul 2000 14:51:04 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12204 for ; Mon, 10 Jul 2000 14:51:02 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA11574; Mon, 10 Jul 2000 14:52:45 -0700
Date: Mon, 10 Jul 2000 14:52:38 -0700 (PDT)
From: "L. Sassaman"
To: Jon Callas
cc: [email-masked], [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
In-Reply-To:
Message-ID:
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

On Wed, 5 Jul 2000, Jon Callas wrote:

> One of the things to remember about 2440 -- and stated in the document
> abstract -- is that it isn't a how-to guide for writing an application.
> It's a description of how the data is laid out, and (more or less) what it
> means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide."
>
> Lots of things are assumed in the document. For example, it's assumed you
> know what a cipher is. Many of the references to ciphers are pretty terse,
> and I know I wouldn't want to implement from it and it alone. Just last
> week, for example, someone pointed out to me that the reference for
> Triple-DES was dangling. We all looked around for a good reference to 3DES,
> and didn't come up with one! I was sure there was some RFC for it, myself,
> and there isn't. This is amusing, since 3DES is the cross-group defacto
> meta-standard algorithm in the IETF, and yet we don't have a good place to
> say, "Hey, here's how 3DES is done." I changed the 2440bis reference to
> point to Schneier, which is better than nothing, but still not great. As we
> find those things, we'll shoot them.

Use X9.52.

X9.52 is the ANSI standard for 3DES. Menezes et al. references it when
discussing 3DES, and I believe Schneier does as well.

- --Len.

__

L. Sassaman

System Administrator |
Technology Consultant | "Credo quia absurdum."
icq.. 10735603 |
pgp.. finger://ns.quickie.net/rabbi | --Tertullian

-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5akWsPYrxsgmsCmoRArBwAJ9PPMdy0D2NwMgHzNuVq4vOCnKETgCgilCC
EASEGruc+B16FO+lxwnLdc0=
=B66F
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id NAA10549 for ietf-openpgp-bks; Mon, 10 Jul 2000 13:31:04 -0700 (PDT)
Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10545 for ; Mon, 10 Jul 2000 13:30:59 -0700 (PDT)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id NAA25115; Mon, 10 Jul 2000 13:32:01 -0700 (PDT)
Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id NAA25111; Mon, 10 Jul 2000 13:31:53 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To:
References:
Date: Mon, 10 Jul 2000 13:31:48 -0700
To: "L. Sassaman" , [email-masked]
From: Jon Callas
Subject: Re: Question regarding 2440:5.2.3.16
Cc: [email-masked], [email-masked]
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 11:29 AM -0700 7/10/00, L. Sassaman wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Mon, 10 Jul 2000 [email-masked] wrote:
>
>> That seems OK, or perhaps you could use an SSL (TLS) session using the
>> PGP key to authenticate the client. In any case I don't think this
>> mechanism should be documented in 2440.
>
>That's fine, but I do think that this definately needs to be
>documented. If 2440 isn't the place, then we need to start work on a
>keyserver draft.
>

Someone should work on a key server document. RFC 2440 is OpenPGP Formats.
Key server operation is not a data format.

Jon

Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06666 for ietf-openpgp-bks; Mon, 10 Jul 2000 11:27:50 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06662 for ; Mon, 10 Jul 2000 11:27:49 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id LAA10170; Mon, 10 Jul 2000 11:29:13 -0700
Date: Mon, 10 Jul 2000 11:29:05 -0700 (PDT)
From: "L. Sassaman"
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Question regarding 2440:5.2.3.16
In-Reply-To: <[email-masked]>
Message-ID:
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

On Mon, 10 Jul 2000 [email-masked] wrote:

> That seems OK, or perhaps you could use an SSL (TLS) session using the
> PGP key to authenticate the client. In any case I don't think this
> mechanism should be documented in 2440.

That's fine, but I do think that this definately needs to be
documented. If 2440 isn't the place, then we need to start work on a
keyserver draft.

__

L. Sassaman

System Administrator |
Technology Consultant | "Credo quia absurdum."
icq.. 10735603 |
pgp.. finger://ns.quickie.net/rabbi | --Tertullian

-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5ahX4PYrxsgmsCmoRAugzAJ9kXo6sUKvSwNXccAz2neOxYK7xWwCeLeQu
rPS3ze/rL2VpE3VOMgw7HFs=
=RYem
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05150 for ietf-openpgp-bks; Mon, 10 Jul 2000 10:18:20 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05146 for ; Mon, 10 Jul 2000 10:18:19 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id KAA09686; Mon, 10 Jul 2000 10:20:00 -0700
Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT)
From: "L. Sassaman"
To: [email-masked]
cc: [email-masked]
Subject: Re: Question regarding 2440:5.2.3.16
In-Reply-To: <[email-masked]>
Message-ID:
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

On Mon, 10 Jul 2000 [email-masked] wrote:

> so you are suggesting that proof of ownership of the corresponding
> secret key (via an appropriate signature) should server this purpose,
> right?

Yes, because the owner needs to prove he has the secret key, and the
public key block that is to be added must be signed to prevent
unauthorized signatures being added during this process.

> > Werner Koch and I have been discussing this, and he suggests that we put
> > it into a clear-text signature packet. Would that be suitable?
>
> would you mind briefly describing the steps involved for the mechanism
> you are considering (in terms like "first, the client connects to the
> server. then the server responds w/..." etc.)?
>
> [ i understand what you are saying about the form a signature would
> take, but i don't see the overall flow of the process of
> authentication. ]

The client takes the public key block, signs it, and submits this signed
blob to the server. The server then verifies the signature, trims away
that signature, and adds the key.

Keys that are added unsigned should always be checked for the existance of
the "no-modify" flag, and rejected if it exists.

Furthermore, I suggest that we have a "modify" flag added to the spec, so
that, if a signature is made at a later date containing this flag, it
would superceed a preveous no-modify. But that digresses from this
discussion.

> also, is it necessary to consider replay attacks for this kind of
> scenario? alternatively, would the following scenario be of any concern:
>
> an attacker captures a session between a user and a keyserver at some
> point in time. later, after the user has made several updates to the
> keyserver, the attacker replays the captured session to set the
> state of the user's key to an earlier state.

This scenerio is only partially valid. A signed key that is added to a
server does not remove the previous key and replace it with the new
one. It is treated like and other add, and is merged with the existing
key. So, an attacker could not truly set the key to a previous state.

What an attacker *could* do, via a replay attack, is re-add signatures or
user-ids to a key on the server that the owner had later deleted. I see
this as a minor annoyance, rather than an attack, so I don't think that we
need to address it. (Though we could, through the use of server tokens or
timestamps, etc. I just think it is more work than is necessary.)

- --Len.

__

L. Sassaman

System Administrator |
Technology Consultant | "Credo quia absurdum."
icq.. 10735603 |
pgp.. finger://ns.quickie.net/rabbi | --Tertullian

-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5agW/PYrxsgmsCmoRAhJhAKCo88zWNgPDz7aQ77qGMv7wmNgVWgCdGfcs
6xQ9X0cE6PywApXO0N0FVRc=
=IpeB
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id XAA14428 for ietf-openpgp-bks; Sun, 9 Jul 2000 23:42:49 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA14423 for ; Sun, 9 Jul 2000 23:42:47 -0700 (PDT)
From: [email-masked]
Received: (qmail 16278 invoked from network); 10 Jul 2000 06:44:08 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 06:44:08 -0000
To: [email-masked]
Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs.
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Mon, 10 Jul 2000 15:44:38 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 19
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: 2.1, 2.2 and 10.2 Clarification re sigs.
Date: Sat, 10 Jun 2000 13:39:02 +0800
Message-ID: <[email-masked]>

...

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

may be this was meant to be:

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

?

for reference, looking through the openpgp packets found in pgp
messages i have received, the pattern of "literal data packet followed
by signature packet" does appear.

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA13335 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:47:46 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA13330 for ; Sun, 9 Jul 2000 22:47:43 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A6C8A0F00AC; Mon, 10 Jul 2000 13:49:12 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 10 Jun 2000 13:39:02 +0800
To: [email-masked]
From: Erron Criddle
Subject: 2.1, 2.2 and 10.2 Clarification re sigs.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

-----BEGIN SECTION REFERENCES-----

Section 2.1 (last paragraph) notes:

"First, a signature is generated for the message and attached to the
message. Then the message plus the signature is encrypted using a symmetric
session key."

Section 2.2 (item 4) notes:

"4. The binary signature is attached to the message"

Section 10.2 notes:

"One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP Message,
Corresponding Signature Packet"

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

-----END SECTION REFERENCES-----

To me, "attached" (as in 2.1 and 2.2) means you add it to the end of
something and this contradicts 10.2 explanation of a Signed Message (a
signed message implies that it is prepended, not attached).

By reading section 10.2, it seems that there are two possibilities for
signing a literal message:

1) You create a signature packet then prepend it to the literal packet

2) You create a signature packet and a One-Pass Signature Packet then
prepend the One-Pass packet to the literal packet and append the signature
packet to the literal packet.

Therefore, my final questions are:

1) Can you create a simple signature packet and attach it to the end of a
literal packet as stated in 2.1 and 2.2 and subsequently contradict 10.2
regarding the definition of a signed message and:

2) Why would you need a One-Pass Signature Packet if we conform to 10.2 and
simply prepend a normal signature packet to the literal data with a
subpacket of type 16 (key id), thus removing the need for a One-Pass packet
in the first place?

Cheers for any clarification once again :)

Regards
Comasp Ltd.
Level 2, 45
Stirling Hwy
NEDLANDS
WA 6009

http://www.comasp.com

Erron Criddle Tel: 08
9386 9534
[email-masked] Fax: 08 9386 9473

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA12612 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:08:08 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12608 for ; Sun, 9 Jul 2000 22:08:07 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA10764; Sun, 9 Jul 2000 22:09:30 -0700
Date: Sun, 9 Jul 2000 22:09:30 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: 5.1 Clarification re padding
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> > I believe I have it worked out now...after reading the "File Formats used
> > by 2.x" document, 2313 and 2437, does the m value look like this?:
> >
> > m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session
> > key) (checksum)
> >
> > The 0x0A represents the Twofish algorithm.
>
> that's reflects my current understanding.

Yes, I believe this is correct.

> to all:
>
> i've been curious about the length of the random padding octets. i
> presume none of them are allowed to 0x00 (that's what non-zero data
> means, may be?) and thus the 0x00 value preceding the
> algorithm-specifying octect can serve as a "marker" to indicate where
> the random padding ends. is that correct?

Yes.

Received: by ns.secondary.com (8.9.3/8.9.3) id WAA12499 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:00:20 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA12495 for ; Sun, 9 Jul 2000 22:00:18 -0700 (PDT)
From: [email-masked]
Received: (qmail 14102 invoked from network); 10 Jul 2000 05:01:39 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 05:01:39 -0000
To: [email-masked]
Subject: Re: 5.1 Clarification re padding
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Mon, 10 Jul 2000 14:02:09 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 39
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: Re: 5.1 Clarification re padding
Date: Sat, 10 Jun 2000 12:32:28 +0800
Message-ID: <[email-masked]>

> At 12:53 PM 10/07/2000 +0900, [email-masked] wrote:
>
>
>
>
> >to all:
> >i've been curious about the length of the random padding octets. i
> >presume none of them are allowed to 0x00 (that's what non-zero data
> >means, may be?) and thus the 0x00 value preceding the
> >algorithm-specifying octect can serve as a "marker" to indicate where
> >the random padding ends. is that correct?
>
> Yes. The doc located at:
>
> ftp.pgpi.org/pub/pgp/2.x/doc/pgformat.txt
>
> explains that in the section entitled:
>
> "Conventional Data Encryption Key (DEK) "packet""
>
> It also notes it in 2437 (with reference to Ulf's pointers to the padding
> section/s) and 2313, that you have to use NON ZERO values in the random number.

thanks for the reference!

upon closer inspection of rfc2313, i see:

The padding string PS shall consist of k-3-||D|| octets. For block
type 00, the octets shall have value 00; for block type 01, they
shall have value FF; and for block type 02, they shall be
pseudorandomly generated and nonzero. This makes the length of the
encryption block EB equal to k.

sorry for the extra traffic.

Received: by ns.secondary.com (8.9.3/8.9.3) id VAA12330 for ietf-openpgp-bks; Sun, 9 Jul 2000 21:41:23 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA12326 for ; Sun, 9 Jul 2000 21:41:19 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A72D7A700A0; Mon, 10 Jul 2000 12:42:37 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 10 Jun 2000 12:32:28 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: 5.1 Clarification re padding
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <20000708090745.A418@rho> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

At 12:53 PM 10/07/2000 +0900, [email-masked] wrote:

>to all:
>i've been curious about the length of the random padding octets. i
>presume none of them are allowed to 0x00 (that's what non-zero data
>means, may be?) and thus the 0x00 value preceding the
>algorithm-specifying octect can serve as a "marker" to indicate where
>the random padding ends. is that correct?

Yes. The doc located at:

ftp.pgpi.org/pub/pgp/2.x/doc/pgformat.txt

explains that in the section entitled:

"Conventional Data Encryption Key (DEK) "packet""

It also notes it in 2437 (with reference to Ulf's pointers to the padding
section/s) and 2313, that you have to use NON ZERO values in the random number.

Regards
Comasp Ltd.
Level 2, 45
Stirling Hwy
NEDLANDS
WA 6009

http://www.comasp.com

Erron Criddle Tel: 08
9386 9534
[email-masked] Fax: 08 9386 9473

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11691 for ietf-openpgp-bks; Sun, 9 Jul 2000 20:52:06 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11687 for ; Sun, 9 Jul 2000 20:52:04 -0700 (PDT)
From: [email-masked]
Received: (qmail 12890 invoked from network); 10 Jul 2000 03:53:25 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 03:53:25 -0000
To: [email-masked]
Subject: Re: 5.1 Clarification re padding
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20000708090745.A418@rho> <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Mon, 10 Jul 2000 12:53:56 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 24
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: Re: 5.1 Clarification re padding
Date: Sat, 10 Jun 2000 10:21:57 +0800
Message-ID: <[email-masked]>

...

> I believe I have it worked out now...after reading the "File Formats used
> by 2.x" document, 2313 and 2437, does the m value look like this?:
>
> m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session
> key) (checksum)
>
> The 0x0A represents the Twofish algorithm.

that's reflects my current understanding.

to all:

i've been curious about the length of the random padding octets. i
presume none of them are allowed to 0x00 (that's what non-zero data
means, may be?) and thus the 0x00 value preceding the
algorithm-specifying octect can serve as a "marker" to indicate where
the random padding ends. is that correct?

Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11004 for ietf-openpgp-bks; Sun, 9 Jul 2000 20:36:00 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA10999 for ; Sun, 9 Jul 2000 20:35:57 -0700 (PDT)
From: [email-masked]
Received: (qmail 12577 invoked from network); 10 Jul 2000 03:37:17 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 03:37:17 -0000
To: [email-masked]
Subject: Re: Question regarding 2440:5.2.3.16
In-Reply-To:
References:
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Mon, 10 Jul 2000 12:37:46 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 36
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: "L. Sassaman"
Subject: Question regarding 2440:5.2.3.16
Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT)
Message-ID:

> In order for keyservers to take advantage of 2440:5.2.3.16, there must be
> a way to authenticate the user submitting the add as being the owner of
> the key.

so you are suggesting that proof of ownership of the corresponding
secret key (via an appropriate signature) should server this purpose,
right?

> This can be done quite easily using an LDAPS connection, but since most
> keyservers do not support such a connection, and some clients do not
> either, I think there should be a standard data format for submitting
> signed add requests to "HKP" keyservers.
>
> Werner Koch and I have been discussing this, and he suggests that we put
> it into a clear-text signature packet. Would that be suitable?

would you mind briefly describing the steps involved for the mechanism
you are considering (in terms like "first, the client connects to the
server. then the server responds w/..." etc.)?

[ i understand what you are saying about the form a signature would
take, but i don't see the overall flow of the process of
authentication. ]

also, is it necessary to consider replay attacks for this kind of
scenario? alternatively, would the following scenario be of any concern:

an attacker captures a session between a user and a keyserver at some
point in time. later, after the user has made several updates to the
keyserver, the attacker replays the captured session to set the
state of the user's key to an earlier state.

Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07005 for ietf-openpgp-bks; Sun, 9 Jul 2000 19:30:48 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA07001 for ; Sun, 9 Jul 2000 19:30:45 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A896FECA00AC; Mon, 10 Jul 2000 10:32:06 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 10 Jun 2000 10:21:57 +0800
To: [email-masked]
From: Erron Criddle
Subject: Re: 5.1 Clarification re padding
In-Reply-To: <20000708090745.A418@rho>
References: <[email-masked]> <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Ulf, Sen and others,

> > I noticed in section 5.1 that (third last paragraph):
>
> > "This value is then padded as described in PKCS-1 block type 02 [RFC2437]
> > to form the "m" value used in the formulas above."
>
>The OpenPGP RFC refers to RFC 2313. In a later draft, Jon Callas changed
>the reference to RFC 2437, but failed to update the contents.
>
>In terms of RFC 2437, OpenPGP uses EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5.

I believe I have it worked out now...after reading the "File Formats used
by 2.x" document, 2313 and 2437, does the m value look like this?:

m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session
key) (checksum)

The 0x0A represents the Twofish algorithm.

TIA.

Regards
Comasp Ltd.
Level 2, 45
Stirling Hwy
NEDLANDS
WA 6009

http://www.comasp.com

Erron Criddle Tel: 08
9386 9534
[email-masked] Fax: 08 9386 9473

Received: by ns.secondary.com (8.9.3/8.9.3) id IAA18326 for ietf-openpgp-bks; Sat, 8 Jul 2000 08:36:03 -0700 (PDT)
Received: from tomts2-srv.bellnexxia.net (tomts2.bellnexxia.net [209.226.175.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18318 for ; Sat, 8 Jul 2000 08:36:01 -0700 (PDT)
Received: from localhost ([64.228.185.33]) by tomts2-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000708153736.UIYM8045.tomts2-srv.bellnexxia.net@localhost>; Sat, 8 Jul 2000 11:37:36 -0400
Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13AuKk-00009A-00; Sat, 8 Jul 2000 09:07:50 -0400
Date: Sat, 8 Jul 2000 09:07:46 -0400
From: =?iso-8859-1?Q?Ulf_M=F6ller?=
To: Erron Criddle
Cc: [email-masked]
Subject: Re: 5.1 Clarification re padding
Message-ID: <20000708090745.A418@rho>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[email-masked]>; from [email-masked] on Thu, Jun 08, 2000 at 02:03:58PM +0800
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Thu, Jun 08, 2000 at 02:03:58PM +0800, Erron Criddle wrote:

> I noticed in section 5.1 that (third last paragraph):

> "This value is then padded as described in PKCS-1 block type 02 [RFC2437]
> to form the "m" value used in the formulas above."

The OpenPGP RFC refers to RFC 2313. In a later draft, Jon Callas changed
the reference to RFC 2437, but failed to update the contents.

In terms of RFC 2437, OpenPGP uses EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5.

Received: by ns.secondary.com (8.9.3/8.9.3) id EAA09837 for ietf-openpgp-bks; Sat, 8 Jul 2000 04:39:02 -0700 (PDT)
Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09833 for ; Sat, 8 Jul 2000 04:39:01 -0700 (PDT)
Received: from cyphers.net (aes.cyphers.net [205.178.102.90]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id FXDMV200.K08; Sat, 8 Jul 2000 04:35:26 -0700
Message-ID: <[email-masked]>
Date: Sat, 08 Jul 2000 04:40:31 -0700
From: Will Price
Reply-To: [email-masked]
X-Mailer: Mozilla 4.73 (Macintosh; U; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Ian BROWN
CC: [email-masked]
Subject: Re: Forward secrecy
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Yes, it's a common error, but there is in fact only one correct way: IPsec.

See RFC 2401 or the working group discussion on this topic for more information.

Ian BROWN wrote:
> >IPsec is spelled "IPsec". Not "IPSEC".
>
> grepping through the messages in my ipsec WG folder, I find:
>
> IPSEC 113 times
> IPsec 104 times
> IPSec 38 times
>
> I also see that the IETF Working Group description begins:
>
> >Rapid advances in communication technology have
> >accentuated the need for security in the Internet.
> >The IP Security Protocol Working Group (IPSEC)
> >will develop mechanisms to protect client
> >protocols of IP. A security protocol in the
> >network layer will be developed to provide
> >cryptographic security services that will flexibly
> >support combinations of authentication, integrity,
> >access control, and confidentiality.

--

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08912 for ietf-openpgp-bks; Sat, 8 Jul 2000 04:06:38 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA08907 for ; Sat, 8 Jul 2000 04:06:36 -0700 (PDT)
Received: from donatello.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 8 Jul 2000 12:07:57 +0100
X-Mailer: exmh version 2.0.2
To: [email-masked]
cc: Ian BROWN , [email-masked]
Subject: Re: Forward secrecy
In-reply-to: Your message of "Fri, 07 Jul 2000 15:34:54 PDT." <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 08 Jul 2000 12:07:57 +0100
Message-ID: <[email-masked]>
From: Ian BROWN
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Will,

>IPsec is spelled "IPsec". Not "IPSEC".

grepping through the messages in my ipsec WG folder, I find:

IPSEC 113 times
IPsec 104 times
IPSec 38 times

I also see that the IETF Working Group description begins:

>Rapid advances in communication technology have
>accentuated the need for security in the Internet.
>The IP Security Protocol Working Group (IPSEC)
>will develop mechanisms to protect client
>protocols of IP. A security protocol in the
>network layer will be developed to provide
>cryptographic security services that will flexibly
>support combinations of authentication, integrity,
>access control, and confidentiality.

Ian.

Received: by ns.secondary.com (8.9.3/8.9.3) id CAA03486 for ietf-openpgp-bks; Sat, 8 Jul 2000 02:49:10 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA03480 for ; Sat, 8 Jul 2000 02:49:08 -0700 (PDT)
From: [email-masked]
Received: (qmail 18933 invoked from network); 8 Jul 2000 09:50:24 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 8 Jul 2000 09:50:24 -0000
To: [email-masked]
Subject: Re: 5.1 Clarification re padding
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Sat, 08 Jul 2000 18:50:51 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 30
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Erron Criddle
Subject: 5.1 Clarification re padding
Date: Thu, 08 Jun 2000 14:03:58 +0800
Message-ID: <[email-masked]>

> To all,
>
> I noticed in section 5.1 that (third last paragraph):
>
> -----BEGIN SECTION-----
>
> "This value is then padded as described in PKCS-1 block type 02 [RFC2437]
> to form the "m" value used in the formulas above."
>
> -----END SECTION-----

hmm, that's not what it says in my copy...ah, i see that the quoted
part if probably from one of the bis documents. i think that may be
an error.

> I have looked through RFC2437 and I cannot see any reference to a block
> type 02 or any specific details on padding.

neither can i ;-)

> Can someone please point me to a document that details the padding
> mechanism to use in 5.1 as I wouldn't have a clue at the moment :)

try rfc 2313. that's the reference made in my copy of rfc 2440, and it
does mention a block of type 2.

Received: by ns.secondary.com (8.9.3/8.9.3) id XAA26376 for ietf-openpgp-bks; Fri, 7 Jul 2000 23:12:50 -0700 (PDT)
Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA26371 for ; Fri, 7 Jul 2000 23:12:47 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A99F6380288; Sat, 08 Jul 2000 14:14:07 0800
Message-Id: <[email-masked]>
X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 08 Jun 2000 14:03:58 +0800
To: [email-masked]
From: Erron Criddle
Subject: 5.1 Clarification re padding
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

To all,

I noticed in section 5.1 that (third last paragraph):

-----BEGIN SECTION-----

"This value is then padded as described in PKCS-1 block type 02 [RFC2437]
to form the "m" value used in the formulas above."

-----END SECTION-----

I have looked through RFC2437 and I cannot see any reference to a block
type 02 or any specific details on padding.

Can someone please point me to a document that details the padding
mechanism to use in 5.1 as I wouldn't have a clue at the moment :)

TIA.

Received: by ns.secondary.com (8.9.3/8.9.3) id QAA02830 for ietf-openpgp-bks; Fri, 7 Jul 2000 16:35:52 -0700 (PDT)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02822 for ; Fri, 7 Jul 2000 16:35:49 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id QAA26450; Fri, 7 Jul 2000 16:37:19 -0700
Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT)
From: "L. Sassaman"
To: [email-masked]
cc: [email-masked]
Subject: Question regarding 2440:5.2.3.16
Message-ID:
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

Would anyone like to make a suggestion for a standard HTTP mechanism for
doing signed key adds to keyservers?

In order for keyservers to take advantage of 2440:5.2.3.16, there must be
a way to authenticate the user submitting the add as being the owner of
the key.

This can be done quite easily using an LDAPS connection, but since most
keyservers do not support such a connection, and some clients do not
either, I think there should be a standard data format for submitting
signed add requests to "HKP" keyservers.

Werner Koch and I have been discussing this, and he suggests that we put
it into a clear-text signature packet. Would that be suitable?

- --Len.

__

L. Sassaman

System Administrator |
Technology Consultant | "Credo quia absurdum."
icq.. 10735603 |
pgp.. finger://ns.quickie.net/rabbi | --Tertullian

-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE5ZmmuPYrxsgmsCmoRAli4AJ4xBu8Vfv3iUVokLY9eJbAHedgS1QCeNTIN
NHgFwERh+a6UUZ5V1xRuwes=
=NNry
-----END PGP SIGNATURE-----

Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01763 for ietf-openpgp-bks; Fri, 7 Jul 2000 15:39:18 -0700 (PDT)
Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01759 for ; Fri, 7 Jul 2000 15:39:16 -0700 (PDT)
Received: from cyphers.net (idea.cyphers.net [205.178.102.83]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id FXCMRJ00.U09; Fri, 7 Jul 2000 15:35:43 -0700
Message-ID: <[email-masked]>
Date: Fri, 07 Jul 2000 15:34:54 -0700
From: Will Price
Reply-To: [email-masked]
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Ian BROWN
CC: [email-masked]
Subject: Re: Forward secrecy
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

IPsec is spelled "IPsec". Not "IPSEC".

Ian BROWN wrote:
> I have included a new paragraph on the use ofOpenPGP keys with
> network/transport layer security services:
>
> Where OpenPGP keys are used in protocols such as IPSEC [2] or TLS

--

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23948 for ietf-openpgp-bks; Fri, 7 Jul 2000 10:01:46 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23943 for ; Fri, 7 Jul 2000 10:01:45 -0700 (PDT)
From: [email-masked]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA03684; Fri, 7 Jul 2000 10:02:52 -0700
Date: Fri, 7 Jul 2000 10:02:52 -0700
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Re: Forward secrecy
Cc: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

> Expired public encryption keys MUST be
> deleted by users and keyservers to remove information on old key
> pairs.

Does this really add enough security to be worth a MUST? An expired
public key should not significantly threaten the contents of previously
encrypted messages. Furthermore, such deletions can provide at most
"security by obscurity" since attackers could easily have made their
own archives of the public keys on the key servers.

Hal

Received: by ns.secondary.com (8.9.3/8.9.3) id JAA21141 for ietf-openpgp-bks; Fri, 7 Jul 2000 09:01:45 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA21133 for ; Fri, 7 Jul 2000 09:01:44 -0700 (PDT)
Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 7 Jul 2000 17:02:57 +0100
X-Mailer: exmh version 2.0.2
To: [email-masked]
cc: [email-masked]
Subject: Re: Forward secrecy
In-reply-to: Your message of "Thu, 06 Jul 2000 16:49:29 +0900." <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 07 Jul 2000 17:02:55 +0100
Message-ID: <[email-masked]>
From: Ian BROWN
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Thanks for the comments :)

> -this document seems to be focused on the use of openpgp for mail in
> particular. is there anything to be said for other uses? (e.g.
> openpgp key usage in ssh)

I have included a new paragraph on the use ofOpenPGP keys with
network/transport layer security services:

Where OpenPGP keys are used in protocols such as IPSEC [2] or TLS
[9], they SHOULD NOT be used to encrypt keying material that can
later be decrypted if they are compromised. Ideally, they SHOULD be
used only to authenticate a forward-secret key negotiation
protocol such as Diffie-Hellman [3]. At the least, new short-
lifetime key pairs SHOULD be generated for key encryption use.

Sound sensible?

> i think whether the key distribution should happen automatically
> should be a matter of policy. some of us have keypairs of which the
> public portion is not really made widely public, nor do we want it to
> be made so. perhaps such relevant policy can be expressed in the key
> and implementations could interpret it appropriately.

I have changed the paragraph as follows:

Key distribution can be eased by submitting new keys to key
servers, where they will be available for other users to retrieve.
Submission and retrieval of generally-available public keys (those
self-signed with an exportable signature) SHOULD be performed
automatically by software. Expired public encryption keys MUST be
deleted by users and keyservers to remove information on old key
pairs. Expired private encryption keys MUST be securely deleted to
prevent later compromise.

> -how about some "secure deletion" references in the references section?

I have something by Markus Jakobsson that can go in: we could also mention the
relevant DoD requirements.

The "revoke and redistribute" requirement on surrendered keys is tricky: as
you say, what happens if the client can't contact a keyserver? I suppose the
weak answer is that as more and more people get always-on DSL/cable modem
connections, and any one of the keyservers can be contacted, this shouldn't
happen often (as long as the police don't catch on). But I suppose we could
say something like if keyservers are unavailable, the client may queue the
revocation for later distribution then export the key.

> also, which takes precedence, the deletion of expired keys from
> keyservers or the distribution of revoked keys? is this also a matter
> of policy that could be reflected in the key?

We were thinking of revoked and expired keys as separate categories.
Keyservers certainly shouldn't delete revoked keys *until their expiry date is
reached* -- at which point they shouldn't be used anyway.

Ian :)

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA27776 for ietf-openpgp-bks; Thu, 6 Jul 2000 11:49:32 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27772 for ; Thu, 6 Jul 2000 11:49:30 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA00156; Thu, 6 Jul 2000 19:59:01 +0100
Message-ID: <[email-masked]>
Date: Thu, 06 Jul 2000 19:52:01 +0100
From: Ben Laurie
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked]
Subject: Re: Forward secrecy
References: <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

[email-masked] wrote:
>
> From: Ian Brown
> Subject: Forward secrecy
> Date: Wed, 05 Jul 2000 11:55:43 +0100
> Message-ID: <[email-masked]>
>
> > John Noerenberg suggested we publish it as an informational RFC. We would
> > be grateful for feedback from this group before we take that step.
>
> here are some comments:
>
> -this document seems to be focused on the use of openpgp for mail in
> particular. is there anything to be said for other uses? (e.g.
> openpgp key usage in ssh)

We should certainly extend it to cover other uses. Good idea.

> -section 2.1 says:
>
> Key distribution can be eased by submitting new keys to key
> servers, where they will be available for other users to retrieve.
> Submission and retrieval SHOULD be performed automatically by
> software. Expired public encryption keys MUST be deleted by users
> and keyservers to remove information on old key pairs. Expired
> private encryption keys MUST be securely deleted to prevent later
> compromise.
>
> i think whether the key distribution should happen automatically
> should be a matter of policy. some of us have keypairs of which the
> public portion is not really made widely public, nor do we want it to
> be made so. perhaps such relevant policy can be expressed in the key
> and implementations could interpret it appropriately.

It is a SHOULD rather than a MUST so a compliant implementation can
choose to not do it. However, we should probably make a specific note to
that effect. OTOH, I notice that one of the changes I intended to make
has not been: that is that it is not necessary to delete public keys,
only private ones. In fact, expired public keys may be required to check
the validity of (old) revocations.

> i wonder how much success one will have w/ convincing the
> keyserver folks that they should delete expired public keys. i would
> like the ability to be able to tell a keyserver to remove a public key
> for which i have the corresponding secret key (or may be even the
> typically existing email address), but i don't get the impression that
> it's a popular idea thing among implementors.

I have exchanged some mails with (some of) the keyserver folks, and the
widespread use of short-lifetime encryption only keys will kill the
keyservers if they do not expire them. So, I think they may well wish to
do it.

> -section 2.2 says:
>
> Before an OpenPGP client exports a private key as plaintext, the
> associated public key MUST be revoked and redistributed.
>
> i think i see a good reason for this, but i wonder whether it is
> practical. doesn't redistribution of the key require net
> access?
>
> to implement this correctly, when requested to export
> a private key as plaintext, the implementation first revokes the key,
> then redistributes the key by sending it to the keyservers, and
> then exports the private key (perhaps after confirming that the
> redistribution has been successful). if it cannot contact a keyserver
> (or verify that redistribution was successful), a correct
> implementation would not export the private key as plaintext,
> i presume. perhaps i'm nitpicking...

I guess it needs addressing.

> also, which takes precedence, the deletion of expired keys from
> keyservers or the distribution of revoked keys? is this also a matter
> of policy that could be reflected in the key?
>
> -how about saying "attackers" instead of "hackers" in section 6?

Sure.

> -how about some "secure deletion" references in the references section?

For example?

> off-topic: how about you guys write an informational rfc that suggests
> best practice methods for email message header confidentiality ;-)

I thought someone else was doing that already?

Cheers,

Ben.

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

Coming to ApacheCon Europe 2000? http://apachecon.com/

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA06930 for ietf-openpgp-bks; Thu, 6 Jul 2000 00:48:01 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA06926 for ; Thu, 6 Jul 2000 00:47:59 -0700 (PDT)
From: [email-masked]
Received: (qmail 4717 invoked from network); 6 Jul 2000 07:49:12 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jul 2000 07:49:12 -0000
To: [email-masked]
Subject: Re: Forward secrecy
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Thu, 06 Jul 2000 16:49:29 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 66
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

From: Ian Brown
Subject: Forward secrecy
Date: Wed, 05 Jul 2000 11:55:43 +0100
Message-ID: <[email-masked]>

> John Noerenberg suggested we publish it as an informational RFC. We would
> be grateful for feedback from this group before we take that step.

here are some comments:

-this document seems to be focused on the use of openpgp for mail in
particular. is there anything to be said for other uses? (e.g.
openpgp key usage in ssh)

-section 2.1 says:

Key distribution can be eased by submitting new keys to key
servers, where they will be available for other users to retrieve.
Submission and retrieval SHOULD be performed automatically by
software. Expired public encryption keys MUST be deleted by users
and keyservers to remove information on old key pairs. Expired
private encryption keys MUST be securely deleted to prevent later
compromise.

i think whether the key distribution should happen automatically
should be a matter of policy. some of us have keypairs of which the
public portion is not really made widely public, nor do we want it to
be made so. perhaps such relevant policy can be expressed in the key
and implementations could interpret it appropriately.

i wonder how much success one will have w/ convincing the
keyserver folks that they should delete expired public keys. i would
like the ability to be able to tell a keyserver to remove a public key
for which i have the corresponding secret key (or may be even the
typically existing email address), but i don't get the impression that
it's a popular idea thing among implementors.

-section 2.2 says:

Before an OpenPGP client exports a private key as plaintext, the
associated public key MUST be revoked and redistributed.

i think i see a good reason for this, but i wonder whether it is
practical. doesn't redistribution of the key require net
access?

to implement this correctly, when requested to export
a private key as plaintext, the implementation first revokes the key,
then redistributes the key by sending it to the keyservers, and
then exports the private key (perhaps after confirming that the
redistribution has been successful). if it cannot contact a keyserver
(or verify that redistribution was successful), a correct
implementation would not export the private key as plaintext,
i presume. perhaps i'm nitpicking...

also, which takes precedence, the deletion of expired keys from
keyservers or the distribution of revoked keys? is this also a matter
of policy that could be reflected in the key?

-how about saying "attackers" instead of "hackers" in section 6?

-how about some "secure deletion" references in the references section?

off-topic: how about you guys write an informational rfc that suggests
best practice methods for email message header confidentiality ;-)

Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA04085 for ietf-openpgp-bks; Wed, 5 Jul 2000 23:09:56 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA04081 for ; Wed, 5 Jul 2000 23:09:54 -0700 (PDT)
From: [email-masked]
Received: (qmail 2712 invoked from network); 6 Jul 2000 06:11:06 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jul 2000 06:11:06 -0000
To: [email-masked]
Subject: priority of clarity of specifications (was Re: OpenPGP should be called ClosedPGP)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Thu, 06 Jul 2000 15:11:23 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 95
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

thanks for the response. sorry for taking so long to reply.

From: Jon Callas
Subject: Re: OpenPGP should be called ClosedPGP
Date: Wed, 5 Jul 2000 00:21:38 -0700
Message-ID:

> One of the things to remember about 2440 -- and stated in the document
> abstract -- is that it isn't a how-to guide for writing an application.
> It's a description of how the data is laid out, and (more or less) what it
> means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide."

sure. i didn't miss out on that point.

the kinds of changes i had in mind have more to do w/ the particular
explanations, wording, order of introducing terms, etc. i found parts
of the document difficult to understand and could be made easier to
understand for others who are still struggling w/ the document and for
future readers. i have pointed out some of these things that occurred
to me already, but would it help to mention them again? some of the
points have gone unaddressed, so i can only guess as to whether the
points are irrelevant, ignored, forgotten, etc.

as a side note, on other pgp-related mailing lists, i've seen people
ask questions about pgp and they are then referred to rfc 2440. i
imagine it could be rather tough for many of these folks to understand
the rfc (it was for me, at least) -- perhaps some other document
should exist for such situations.

> Lots of things are assumed in the document. For example, it's assumed you
> know what a cipher is. Many of the references to ciphers are pretty terse,
> and I know I wouldn't want to implement from it and it alone.

that's what i found when i first went through it. after sitting down
w/ schneier's book though, i was able to make a lot more sense of the
rfc, but even w/ improved understanding, i found sections hard to
understand more because of issues such as wording.

> Just last week, for example, someone pointed out to me that the
> reference for Triple-DES was dangling. We all looked around for a
> good reference to 3DES, and didn't come up with one! I was sure
> there was some RFC for it, myself, and there isn't. This is amusing,
> since 3DES is the cross-group defacto meta-standard algorithm in the
> IETF, and yet we don't have a good place to say, "Hey, here's how
> 3DES is done."

perhaps it's time for an informational rfc for triple des then. but
may be that's an issue that is more general than for just this working
group...

> I changed the 2440bis reference to point to Schneier, which is
> better than nothing, but still not great. As we find those things,
> we'll shoot them.

out of curiosity, if schneier's book were freely available, then would
that still be a problem?

> Furthermore, there are things that we have agreed *not* to discuss here. A
> close reading of 2440 will display references to key servers, trust, and
> other things that are beyond its scope.

it might be helpful to have a list of what is and isn't in scope in
one place (say in the rfc or on among the working group web pages) --
this might make it clearer for those who weren't around for the
discussions. i assume that newcomers are not unwelcome.

> We've also discussed having implementation guides. That is also something
> that would be great to do.

i think that would be interesting and worthwhile, but i'm not
primarily concerned w/ an implementation guide at this point.

> But I don't think you should do an annotated 2440 or a re-organized
> one.

i hear you, but i guess i don't see why an annotated version would be
a bad idea. what kind of downside is there in producing such a thing?

> We want to get to Standard as quickly as possible, and there's
> already been a lot of work getting everyone to agree that what we
> have is reasonable, if not perfect.

what concerns me is that the standard that we get may be harder to
understand than necessary (i think it already is). as has been
pointed out on numerous occasions already, the format is already
fairly complex (compared to what might be produced if one were to
start from scratch -- i am not suggesting that compatibility issues be
ignored, just clarifying my statement).

i would think that particularly in an area that is so focused on
security that one would want the format to be as simple as possible
and the descriptions to be as clear as possible to prevent
misunderstandings that might lead to misuse or misimplementation and
consequently to security problems. my impression is that this does
not appear to be a high priority. am i mistaken?

Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04489 for ietf-openpgp-bks; Wed, 5 Jul 2000 03:57:14 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA04485 for ; Wed, 5 Jul 2000 03:57:13 -0700 (PDT)
Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Jul 2000 11:58:28 +0100
Message-ID: <[email-masked]>
Date: Wed, 05 Jul 2000 11:55:43 +0100
From: Ian Brown
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [email-masked]
Subject: Forward secrecy
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

I don't know how much everyone has seen of the UK government's current
attempt to legislate for access to keys, but despite extreme opposition
they seem set to push through powers for "information disclosure" orders
that allow *any public authority* to demand keys (on pain of two years'
imprisonment) and impose a gagging order that prevents you telling anyone
but your lawyer (or go to jail for five years).

Adam Back, Ben Laurie and I have been working on a draft that would allow
OpenPGP software to minimise the damage such a notice could cause to a PGP
user. It specifies mechanisms for using short-lifetime and one-time keys to
limit the amount of information that becomes vulnerable after key
compromise.

John Noerenberg suggested we publish it as an informational RFC. We would
be grateful for feedback from this group before we take that step.

The current version is at
http://www.cs.ucl.ac.uk/staff/I.Brown/openpgp-pfs.txt

Thanks!

Ian :)

Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27059 for ietf-openpgp-bks; Wed, 5 Jul 2000 02:11:11 -0700 (PDT)
Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27047 for ; Wed, 5 Jul 2000 02:11:09 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA15732; Wed, 5 Jul 2000 10:20:01 +0100
Message-ID: <[email-masked]>
Date: Wed, 05 Jul 2000 10:13:31 +0100
From: Ben Laurie
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Jon Callas
CC: [email-masked]
Subject: Re: OpenPGP should be called ClosedPGP
References: <[email-masked]> <20000628190322.A1351@rho> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Jon Callas wrote:
> This is amusing, since 3DES is the cross-group defacto
> meta-standard algorithm in the IETF, and yet we don't have a good place to
> say, "Hey, here's how 3DES is done." I changed the 2440bis reference to
> point to Schneier, which is better than nothing, but still not great. As we
> find those things, we'll shoot them.

If you are going to point at books, you should point at Menezes et al.,
too.

Cheers,

Ben.

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

Coming to ApacheCon Europe 2000? http://apachecon.com/

Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21697 for ietf-openpgp-bks; Wed, 5 Jul 2000 00:42:26 -0700 (PDT)
Received: from merrymeet.com ([email-masked] [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21689 for ; Wed, 5 Jul 2000 00:42:24 -0700 (PDT)
Received: from [63.73.97.187] (63.73.97.187) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1d11); Wed, 5 Jul 2000 00:43:39 -0700
Mime-Version: 1.0
X-Sender: [email-masked]
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20000628190322.A1351@rho> <[email-masked]> <[email-masked]>
Date: Wed, 5 Jul 2000 00:21:38 -0700
To: [email-masked], [email-masked]
From: Jon Callas
Subject: Re: OpenPGP should be called ClosedPGP
Content-Type: text/plain; charset="us-ascii"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

One of the things to remember about 2440 -- and stated in the document
abstract -- is that it isn't a how-to guide for writing an application.
It's a description of how the data is laid out, and (more or less) what it
means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide."

Lots of things are assumed in the document. For example, it's assumed you
know what a cipher is. Many of the references to ciphers are pretty terse,
and I know I wouldn't want to implement from it and it alone. Just last
week, for example, someone pointed out to me that the reference for
Triple-DES was dangling. We all looked around for a good reference to 3DES,
and didn't come up with one! I was sure there was some RFC for it, myself,
and there isn't. This is amusing, since 3DES is the cross-group defacto
meta-standard algorithm in the IETF, and yet we don't have a good place to
say, "Hey, here's how 3DES is done." I changed the 2440bis reference to
point to Schneier, which is better than nothing, but still not great. As we
find those things, we'll shoot them.

Furthermore, there are things that we have agreed *not* to discuss here. A
close reading of 2440 will display references to key servers, trust, and
other things that are beyond its scope. Trust, in particular, is something
that the working group agreed not to put into 2440. At that time, we agreed
to let people write informational RFCs on various trust models. If someone
wants to write an informational RFC, that's a good one.

We've also discussed having implementation guides. That is also something
that would be great to do. But I don't think you should do an annotated
2440 or a re-organized one. We want to get to Standard as quickly as
possible, and there's already been a lot of work getting everyone to agree
that what we have is reasonable, if not perfect.

Jon

Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22574 for ietf-openpgp-bks; Tue, 4 Jul 2000 09:20:31 -0700 (PDT)
Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA22569 for ; Tue, 4 Jul 2000 09:20:29 -0700 (PDT)
From: [email-masked]
Received: (qmail 16419 invoked from network); 4 Jul 2000 16:21:37 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 4 Jul 2000 16:21:37 -0000
To: [email-masked]
Subject: Re: Implementation doc.
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[email-masked]>
Date: Wed, 05 Jul 2000 01:21:44 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 35
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

sorry for the late response.

From: Erron Criddle
Subject: Implementation doc.
Date: Fri, 30 Jun 2000 10:26:19 +0800
Message-ID: <[email-masked]>

> Although implementation testing is very important and would require 2440bis
> to remain reasonably static for the that to happen, it may be possible to
> also implement a document in parallel that accompanies 2440 and would be
> basically targeted at the implementor. This doc could provide
> implementation guidelines in a "summarised" fashion and would refer to 2440
> for further understanding.
>
> Basically it would be targeted at implementors that are starting
> from scratch.

i am not so sure of what form the output of such a process should take
-- but how about an "annotated rfc 2440" for starters? we can use
whatever the latest document (bis or rfc) and provide annotations off
of that for clarifying matters. perhaps some of the annotations can
be merged in a future rfc if people think there are relevant points
made.

> One possible way to move ahead with this document is to make an FTP site
> available so that anybody could upload their own "summaries" or
> implementation notes. From this, we can then consolidate the information
> and create another doc that is a basic guideline for implementing OpenPGP.

i have no problem w/ the mechanism, but the "consolidator" of these
notes may have to be in a position where looking at various
implementation notes does not cause any legal difficulties (cf. the
discussion of being able to claim that one truly created an
independent implementation) -- unless some precautions are taken
w.r.t. the content of what is uploaded.