FlowerFunds - Fund Raising Program

[[e-mail]]

SendFlowersAmerica is proud to introduce FlowerFunds--

This unique new concept will provide an income flow for your 
organization for years to come.  Your organization is invited to 
explore the possibilities of participating in FlowerFunds. 
       

     $FlowerFunds is an individualized fund raising program for 
non-profit organizations and schools.

     $FlowerFunds are cash rebates that are paid to your 
organization each and every time an order is placed by your 
members and supporters.

     $The best part is that it costs your organization nothing to 
participate!!



How it works:

     1.   When your members and supporters order flowers or gifts 
through sendflowersamerica they determine the price they want to 
pay; be it $30, $40, $50 or $1000.  Since your members and 
supporters determine the price, they all can participate in this 
program.

     2.   Your organization receives 20% of the purchase price of 
the order.  Say a husband buys his wife a $50 bouquet.  Your 
organization will receive a $10 cash rebate. Nice.



This program never ends.  Each and every time there is an order 
placed by your memebers and supporters, your organization will 
receive the 20% cash rebate.  That's a lot of FlowerFunds, and 
your organization stands to benefit from a findraiser unlike any 
other fundraiser.


For more information call 1 800 SEND 123 or

http://www.sendflowersamerica.com


Imagine earning money for your organization by making someone 
smile  :-)
 
 
 
 
 
 
 
 
 
 
 
 
 



Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01660 for ietf-openpgp-bks; Wed, 30 Aug 2000 01:00:17 -0700 (PDT)
Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01619; Wed, 30 Aug 2000 01:00:02 -0700 (PDT)
From: [e-mail]
Subject: FlowerFunds - Fund Raising Program
Date: Wed, 30 Aug 2000 01:32:31
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

SendFlowersAmerica is proud to introduce FlowerFunds--

This unique new concept will provide an income flow for your 
organization for years to come.  Your organization is invited to 
explore the possibilities of participating in FlowerFunds. 
       

     $FlowerFunds is an individualized fund raising program for 
non-profit organizations and schools.

     $FlowerFunds are cash rebates that are paid to your 
organization each and every time an order is placed by your 
members and supporters.

     $The best part is that it costs your organization nothing to 
participate!!



How it works:

     1.   When your members and supporters order flowers or gifts 
through sendflowersamerica they determine the price they want to 
pay; be it $30, $40, $50 or $1000.  Since your members and 
supporters determine the price, they all can participate in this 
program.

     2.   Your organization receives 20% of the purchase price of 
the order.  Say a husband buys his wife a $50 bouquet.  Your 
organization will receive a $10 cash rebate. Nice.



This program never ends.  Each and every time there is an order 
placed by your memebers and supporters, your organization will 
receive the 20% cash rebate.  That's a lot of FlowerFunds, and 
your organization stands to benefit from a findraiser unlike any 
other fundraiser.


For more information call 1 800 SEND 123 or

http://www.sendflowersamerica.com


Imagine earning money for your organization by making someone 
smile  :-)
 
 
 
 
 
 
 
 
 
 
 
 
 


Received: by ns.secondary.com (8.9.3/8.9.3) id JAA24099 for ietf-openpgp-bks; Mon, 28 Aug 2000 09:59:02 -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 JAA24091 for <[e-mail]>; Mon, 28 Aug 2000 09:58:46 -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 MAA11379; Mon, 28 Aug 2000 12:59:24 -0400 (EDT)
Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id NAA15317; Mon, 28 Aug 2000 13:02:35 -0400
Date: Mon, 28 Aug 2000 13:02:35 -0400
From: Tom Zerucha <[e-mail]>
To: Erron Criddle <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: subkey binding sigs q
Message-ID: <[e-mail]>
References: <[e-mail]> <4.3.2.7.0.20000828153003.035592e8@203.38.66.7>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <4.3.2.7.0.20000828153003.035592e8@203.38.66.7>; from [e-mail] on Mon, Aug 28, 2000 at 03:33:25PM +0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Aug 28, 2000 at 03:33:25PM +0800, Erron Criddle wrote:
> Hal,
> 
> At 01:00 AM 25/08/2000 -0700, [e-mail] wrote:
> >Erron writes:
> >
> >
> > > PSS: Are public and secret keyrings supposed to interoperate with other
> > > versions of OpenPGP?
> >
> >No, OpenPGP does not specify keyring formats.
> 
> If OpenPGP does not specify keyring formats, then what is:
> 
> a) 11.2 related to?
> 
> b) A tag 12 Trust packet packet related to (mentions keyrings)?

It is a small but significant difference between key packet and export
format which OpenPGP *does* specify, and whatever internal
representation and storage used by the application for keyrings.

When exporting a key, it must use a specific format and if it wants to
export extra information like trust, there is a way to do that.

For example, I am working on a Palm version, and will need to prepend
indexing information in a private format and limit records to 64k -
the internal format will have packets but they won't be just the
literal key packet.

For larger apps, e.g. keyservers, it makes sense to use a real
database indexed by several query database-keys.


Received: by ns.secondary.com (8.9.3/8.9.3) id AAA06435 for ietf-openpgp-bks; Mon, 28 Aug 2000 00:45:52 -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 AAA06428 for <[e-mail]>; Mon, 28 Aug 2000 00:45:44 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ABE7307601D2; Mon, 28 Aug 2000 15:47:03 0800
Message-Id: <4.3.2.7.0.20000828153003.035592e8@203.38.66.7>
X-Sender: ejc@203.38.66.7
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 28 Aug 2000 15:33:25 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: Re: subkey binding sigs q
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal,

At 01:00 AM 25/08/2000 -0700, [e-mail] wrote:
>Erron writes:
>
> > Does a subkey binding sig only perform the hash on the subkey (incl. 0x99,
> > packet body and keys), as stated in 5.2.1 for a 0x18 signature type or:
> >
> > does the hashable data for a subkey binding sig mirror that as stated 
> in 5.2.4:
> >
> > "A subkey signature (0x18) THEN hashes the subkey..."
> >
> > I'm assuming the THEN means that you hash the main key before the subkey,
> > subsequently contradicting 5.2.1.
>
>The description in 5.2.1 is really very general:
>
>    0x18: Subkey Binding Signature
>          This signature is a statement by the top-level signing key
>          indicates that it owns the subkey. This signature is calculated
>          directly on the subkey itself, not on any User ID or other
>          packets.
>
>This is meant to convey that the signature does not cover "siblings"
>of the subkey, like other subkeys or userid packets.  The description
>in 5.2.4 is correct; the hash is over the top-level key plus the subkey.
>
> > PS: Where's the best place to insert a type 0x30 as it's not defined in
> > 11.1...before the certification sig or after...or doesn't it matter?
>
>A type 0x30 is a subkey revocation signature.  I don't think it matters
>whether it goes before or after the subkey certification sig.  I think
>we put it before.
>
> > PSS: Are public and secret keyrings supposed to interoperate with other
> > versions of OpenPGP?
>
>No, OpenPGP does not specify keyring formats.

If OpenPGP does not specify keyring formats, then what is:

a) 11.2 related to?

b) A tag 12 Trust packet packet related to (mentions keyrings)?

Cheers.

Regards


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

Fax: [phone]
Tel: [phone]

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13621 for ietf-openpgp-bks; Sun, 27 Aug 2000 14:26:48 -0700 (PDT)
Received: from merrymeet.com ([e-mail] [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13617 for <[e-mail]>; Sun, 27 Aug 2000 14:26:43 -0700 (PDT)
Received: from [63.73.97.180] (63.73.97.180) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Sun, 27 Aug 2000 14:27:17 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320400b5cf336d8927@[172.20.1.38]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 27 Aug 2000 14:07:42 -0700
To: "William H. Geiger III" <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: RFC2440bis?
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 12:28 PM -0500 8/27/00, William H. Geiger III wrote:
>Anyone know what is going on with the updated draft? It is no longer
>listed on the IETF site as it is over 6mo. old without updates.
>

I'll work on releasing a new one, then.

	Jon



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA10383 for ietf-openpgp-bks; Sun, 27 Aug 2000 10:28:19 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10379 for <[e-mail]>; Sun, 27 Aug 2000 10:28:17 -0700 (PDT)
Received: from whgiii ([e-mail] [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id NAA23046 for <[e-mail]>; Sun, 27 Aug 2000 13:29:01 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Sun, 27 Aug 2000 12:28:12 -0500
To: [e-mail]
Subject: RFC2440bis?
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19zg/19zg 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Anyone know what is going on with the updated draft? It is no longer listed on the IETF site as it is over 6mo. old without updates.

tks,

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------



Received: by ns.secondary.com (8.9.3/8.9.3) id OAA05358 for ietf-openpgp-bks; Sat, 26 Aug 2000 14:55:43 -0700 (PDT)
Received: from oo.net (syr-24-164-180-90.twcny.rr.com [24.164.180.90]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA05349 for <[e-mail]>; Sat, 26 Aug 2000 14:55:42 -0700 (PDT)
Date: Sat, 26 Aug 2000 14:55:42 -0700 (PDT)
From: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=200008261745="
To: [e-mail]
X-Mailer: 4BE1F5A3.72197FEC.7dbd07624742bbf35e4ccc1b2cac4074
Subject: Fiber Optic Cable Needed !!
Organization: Wing N' A Prayer Excess Property
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=200008261745=
Content-Type: text/plain;charset=US-ASCII

If this message has reached you by error please type" remove" in the subject line and hit  return  . I will promptly remove you from any future mailings. Please accept my sincerest apologies for any inconvenience this may have caused you. 

Dear Sir(s),Ms., Mrs.,
                      I have a client looking for a large amount of Fiber optic cable for the year 2,001,starting in January . The specifications for the cable required are ; outside plant ,single mode ,single armor,single jacket,loose tube ,SMF28 or equivalent. The strand types needed are 12,24,48,72 and 96. The total fiber footage needed is over a half billion feet ! If you think you can help facilitate this order or any portion of it,please type "fiber specs" in your subject line and hit return and I will get you out the necessary information immediateley. Please feel free to call with any questions.


 Paul J. Milea jr.
Wing N' A Prayer Excess Property
3504 James Street
Syracuse,.New York ,USA 13206
ph 315 463 1287
fax [phone] 
--=200008261745=--



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA15235 for ietf-openpgp-bks; Fri, 25 Aug 2000 01:02: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 BAA15230 for <[e-mail]>; Fri, 25 Aug 2000 01:02:52 -0700 (PDT)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id BAA15512; Fri, 25 Aug 2000 01:00:46 -0700
Date: Fri, 25 Aug 2000 01:00:46 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: subkey binding sigs q
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Erron writes:

> Does a subkey binding sig only perform the hash on the subkey (incl. 0x99, 
> packet body and keys), as stated in 5.2.1 for a 0x18 signature type or:
>
> does the hashable data for a subkey binding sig mirror that as stated in 5.2.4:
>
> "A subkey signature (0x18) THEN hashes the subkey..."
>
> I'm assuming the THEN means that you hash the main key before the subkey, 
> subsequently contradicting 5.2.1.

The description in 5.2.1 is really very general:

   0x18: Subkey Binding Signature
         This signature is a statement by the top-level signing key
         indicates that it owns the subkey. This signature is calculated
         directly on the subkey itself, not on any User ID or other
         packets.

This is meant to convey that the signature does not cover "siblings"
of the subkey, like other subkeys or userid packets.  The description
in 5.2.4 is correct; the hash is over the top-level key plus the subkey.

> PS: Where's the best place to insert a type 0x30 as it's not defined in 
> 11.1...before the certification sig or after...or doesn't it matter?

A type 0x30 is a subkey revocation signature.  I don't think it matters
whether it goes before or after the subkey certification sig.  I think
we put it before.

> PSS: Are public and secret keyrings supposed to interoperate with other 
> versions of OpenPGP?

No, OpenPGP does not specify keyring formats.

> PSSS: If PSS=yes, then shouldn't we define the makeup of a private/public 
> key-ring better than that explained in 11.1 (re exact locations and order/s 
> of packets etc etc).

N/A.

Hal


Received: by ns.secondary.com (8.9.3/8.9.3) id AAA12439 for ietf-openpgp-bks; Fri, 25 Aug 2000 00:15:27 -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 AAA12428 for <[e-mail]>; Fri, 25 Aug 2000 00:15:23 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A04BE372029A; Fri, 25 Aug 2000 15:16:43 0800
Message-Id: <4.3.2.7.0.20000825143917.00b237b0@203.38.66.7>
X-Sender: ejc@203.38.66.7
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 25 Aug 2000 15:03:15 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: subkey binding sigs q
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

To all,

Does a subkey binding sig only perform the hash on the subkey (incl. 0x99, 
packet body and keys), as stated in 5.2.1 for a 0x18 signature type or:

does the hashable data for a subkey binding sig mirror that as stated in 5.2.4:

"A subkey signature (0x18) THEN hashes the subkey..."

I'm assuming the THEN means that you hash the main key before the subkey, 
subsequently contradicting 5.2.1.


PS: Where's the best place to insert a type 0x30 as it's not defined in 
11.1...before the certification sig or after...or doesn't it matter?

PSS: Are public and secret keyrings supposed to interoperate with other 
versions of OpenPGP?

PSSS: If PSS=yes, then shouldn't we define the makeup of a private/public 
key-ring better than that explained in 11.1 (re exact locations and order/s 
of packets etc etc).

Thanks for any clarifications.

Regards


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

Fax: [phone]
Tel: [phone]

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24502 for ietf-openpgp-bks; Thu, 24 Aug 2000 07:22:24 -0700 (PDT)
Received: from cypherspace.org ([e-mail] [24.201.178.228]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24498 for <[e-mail]>; Thu, 24 Aug 2000 07:22:23 -0700 (PDT)
Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id KAA01527; Thu, 24 Aug 2000 10:24:48 -0500
Date: Thu, 24 Aug 2000 10:24:48 -0500
Message-Id: <[e-mail]>
From: Adam Back <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Cc: [e-mail]
Subject: Re: Serious bug in PGP - versions 5 and 6
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ross Anderson writes on uk-crypto:
> Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
> 
> [...]
> 
> He's written a paper on his work and it's at
> 
>         http://senderek.de/security/key-experiments.html
> 
> Since NAI joined the Key Recovery Alliance, PGP has supported
> "Additional Decryption Keys" which can be added to a public key.
> 
> The sender will then encrypt the session key to these as well as to
> your main public key. The bug is that some versions of PGP respond
> to ADK subpackets in the non-signed part of the public key data
> structure.  The effect is that GCHQ can create a tampered version of
> your PGP public key containing a public key whose corresponding
> private key is also known to themselves, and circulate it. People
> who encrypt traffic to you will encrypt it to them too.

Amazing, and really unfortunate.  Those of us who invested large
amounts of effort in ensuring the ADK subpackets were not included in
the ietf openPGP standard can be pleased we succeeded -- otherwise
gnuPG and other implementations may now also have contributed to this
risk.  As it is gnuPG doesn't honor ADK requests, and all the rfc2440
says about them is:

       10 = placeholder for backward compatibility

At the time I was suggesting that if PGP really must insist on
creating software to escrow communications (the primary argument being
that people didn't want to lose access to the stored mail as opposed
to being able to have designated third parties snooping mail in
transit) they should use storage key escrow.

My main premise was that communication key escrow is too risky because
an outside attacker gets the plaintext:

	http://www.cypherspace.org/~adam/cdr/

"Keys used to encrypt email which is transmitted over the Internet are
more valuable to an attacker than keys used to encrypt stored files
because of the relative ease with which an attacker can obtain copies
of emailed ciphertext. Stored encrypted files in contrast are
protected by all the physical security systems the company is relying
on to protect it's paper files, plaintext data stored on disks, and
backup tapes. [...]"

There was also lots of political discussion of how unwise it was for
PGP to create a escrow infrastructure which could as easily be used by
governments as by SEC companies to archive their employees
communications.

And people quoting Phil Zimmermann a few years earlier complaining
about ViaCrypt's PGP4 for business variant which had "escrow" in the
form of a third party "encrypt-to-self" config file setting.

And I believe I recall the NSA or some other US government body
picking up on the CMR / ADK mechanism and holding it up as evidence
against the claim that key recover was complex ... "see PGP did it,
this works".

> It's of scientific interest because it spectacularly confirms a
> prediction made by a number of us in the paper on `The Risks of Key
> Recovery, Key Escrow, and Trusted Third-Party Encryption'
> <http://www.cdt.org/crypto/risks98/> that key escrow would make it
> much more difficult than people thought to build secure systems.

Yes.  It really highlights the truth in the statement about the
new risks introduced by adding key escrow.

Adam


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA09299 for ietf-openpgp-bks; Thu, 24 Aug 2000 02:31:32 -0700 (PDT)
Received: from elde.org (elde.org [195.204.143.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09293 for <[e-mail]>; Thu, 24 Aug 2000 02:31:26 -0700 (PDT)
Received: by elde.org (Postfix, from userid 1002) id BD1535EF47; Thu, 24 Aug 2000 11:31:24 +0200 (CEST)
Date: Thu, 24 Aug 2000 11:31:24 +0200
From: Terje Elde <[e-mail]>
To: "L. Sassaman" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 23, 2000 at 12:29:01PM -0700
X-Mailer: Mutt http://www.mutt.org/
X-Editor: Vim http://www.vim.org/
X-IRC: ircii!epic4-2000 - prevail[1214]
X-Goal: Exterminate All Rational Thought
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

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

* L. Sassaman ([e-mail]) [000823 21:29]:
> > The user *will* have to decrypt multiple secret keys if such exist. Perhaps a
> > recommendation that non-encrypted keys be tried first is an idea?
> 
> I actually would like to see the default key tried first, since that makes
> more sense in my mind... but now we're in the realm of specific
> implementation methods.

True.

Giving a few notes for authors to reflect over isn't a bad thing though, is
it?

Trying to use the default key first isn't a bad idea. It's the one that's got
the better chance of being a hit. Un-encrypted keys take no time to check
however, and you can spare the user from having to enter the passphrase.

I also thing that the places you'll be using speculative KeyID's are also the
places where the chances of encrypting to a key with no passphrase are
highest, as many will simply want to get the mail securely from sniffers, and
not have to decrypt ever single message.

Just a thought...

> > Actually, this might be of some concern. You could effectively send a email
> > using speculative KeyID, which would make the user decrypt all his key in
> > turn, thus providing a attacker with access to keyboard with passphrases to
> > *all* his KeyID's, including keys the user might have made to be extra secure,
> > and not for normal use (root keys etc).
> 
> You could automatically try the default key, and then give the user the
> list of keys remaining to try, and he can pick which ones.
> 
> And you can always have a "disable speculative key" option.

Both great ideas. :)

Terje
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE5pOtr8HLgLrwmRg0RAioDAJwIJM37UWRptyWZNal7LKwINL/tVgCglyih
yYncR/9JfUoXOJRvCiDsVeo=
=z859
-----END PGP SIGNATURE-----


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12556 for ietf-openpgp-bks; Wed, 23 Aug 2000 12:29:07 -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 MAA12544 for <[e-mail]>; Wed, 23 Aug 2000 12:29:01 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA28577; Wed, 23 Aug 2000 12:29:08 -0700
Date: Wed, 23 Aug 2000 12:29:01 -0700 (PDT)
From: "L. Sassaman" <[e-mail]>
To: Terje Elde <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

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

On Wed, 23 Aug 2000, Terje Elde wrote:

> The user *will* have to decrypt multiple secret keys if such exist. Perhaps a
> recommendation that non-encrypted keys be tried first is an idea?

I actually would like to see the default key tried first, since that makes
more sense in my mind... but now we're in the realm of specific
implementation methods.
 
> Actually, this might be of some concern. You could effectively send a email
> using speculative KeyID, which would make the user decrypt all his key in
> turn, thus providing a attacker with access to keyboard with passphrases to
> *all* his KeyID's, including keys the user might have made to be extra secure,
> and not for normal use (root keys etc).

You could automatically try the default key, and then give the user the
list of keys remaining to try, and he can pick which ones.

And you can always have a "disable speculative key" option.


- --Len.

__

L. Sassaman

Security Architect             |  "We all want many things,      
Technology Consultant          |   but some of those are bottomly
                               |   destructive of all desires."
http://sion.quickie.net        |               --Vernor Vinge

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

iD8DBQE5pCYDPYrxsgmsCmoRAvhKAKDGEWEVEeWa00nrTys363LLzaKF5gCg0djj
ZaHNWk3gnGwfDfj4dYPaWos=
=GUWm
-----END PGP SIGNATURE-----



Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29792 for ietf-openpgp-bks; Wed, 23 Aug 2000 02:22:09 -0700 (PDT)
Received: from dlt.follo.net ([e-mail] [195.204.143.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29784 for <[e-mail]>; Wed, 23 Aug 2000 02:22:07 -0700 (PDT)
Received: by dlt.follo.net (Postfix, from userid 1002) id 911315EF47; Wed, 23 Aug 2000 11:22:31 +0200 (CEST)
Date: Wed, 23 Aug 2000 11:22:31 +0200
From: Terje Elde <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 23, 2000 at 05:48:24PM +0900
X-Mailer: Mutt http://www.mutt.org/
X-Editor: Vim http://www.vim.org/
X-IRC: ircii!epic4-2000 - prevail[1214]
X-Goal: Exterminate All Rational Thought
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

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

* [e-mail] ([e-mail]) [000823 10:49]:
> > I think the only thing one can do is offer help whenever possible,
> > and view everything with a critical eye, as well as publishing
> > information about potential problems, to help lesser skilled users
> > from getting bitten.
> 
> i would hesitate to claim uniqueness ("the only thing"), but w/o too
> much further thought, i agree w/ the rest.

Obviously you're right. I should have went more along the lines of "the only
thing I can come up with".

> imo, part of "publishing information about potential problems" is to
> address such issues in relevant ID/RFC/STDs.  so, for starters, i
> think we should either create another draft or try to incoporate the
> substance of this into an existing document.

A big part in the reason why I registered openpgp.org is that I intend to try
to make it a resource for developers and users alike. One of the things I want
to focus on in addition to such basic things as pointing the visitors at other
resources is to help by providing information on best ways to solve problems,
and pointing out what the problems might be in the first place.

This will range from helping users by suggesting secure ways of avoiding loss
of keyrings (pub and priv) to helping programmers by pointing out issues such
as the bcc problem, and ways to fix it.

I hope noone at the IETF-OpenPGP working group feels offended by me
registering the domain.

Terje
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE5o5fW8HLgLrwmRg0RAtsGAJ97Rh3oznPridWWJ3Qxr5R8Hn4wEACfeUYb
XxLVcmcLRgFGfQZNoIuTiXs=
=ZNpA
-----END PGP SIGNATURE-----


Received: by ns.secondary.com (8.9.3/8.9.3) id BAA27848 for ietf-openpgp-bks; Wed, 23 Aug 2000 01:49: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 BAA27841 for <[e-mail]>; Wed, 23 Aug 2000 01:49:09 -0700 (PDT)
From: [e-mail]
Received: (qmail 23656 invoked from network); 23 Aug 2000 08:46:38 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 23 Aug 2000 08:46:38 -0000
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
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: <[e-mail]>
Date: Wed, 23 Aug 2000 17:48:24 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 36
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: Terje Elde <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Date: Wed, 23 Aug 2000 10:34:15 +0200
Message-ID: <[e-mail]>

...

> > > but it does not address the underlying problem: Implementors not
> > > understanding basic concepts of e-mail encryption.
> > 
> > i agree w/ this as well.  
> 
> The question is, how would you like to solve the problem?
>
> I don't see any quick fix for this. 

i don't see a quick fix either.

> You can't force people to not write crypto applications until
> they've been certifies in their field. You can't force people to
> want to educate themselves.

i agree.

> I think the only thing one can do is offer help whenever possible,
> and view everything with a critical eye, as well as publishing
> information about potential problems, to help lesser skilled users
> from getting bitten.

i would hesitate to claim uniqueness ("the only thing"), but w/o too
much further thought, i agree w/ the rest.

imo, part of "publishing information about potential problems" is to
address such issues in relevant ID/RFC/STDs.  so, for starters, i
think we should either create another draft or try to incoporate the
substance of this into an existing document.


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA27183 for ietf-openpgp-bks; Wed, 23 Aug 2000 01:34:19 -0700 (PDT)
Received: from dlt.follo.net ([e-mail] [195.204.143.185]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA27177 for <[e-mail]>; Wed, 23 Aug 2000 01:34:12 -0700 (PDT)
Received: by dlt.follo.net (Postfix, from userid 1002) id 4C2AA5EF47; Wed, 23 Aug 2000 10:34:15 +0200 (CEST)
Date: Wed, 23 Aug 2000 10:34:15 +0200
From: Terje Elde <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 23, 2000 at 12:16:40PM +0900
X-Mailer: Mutt http://www.mutt.org/
X-Editor: Vim http://www.vim.org/
X-IRC: ircii!epic4-2000 - prevail[1214]
X-Goal: Exterminate All Rational Thought
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

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

* [e-mail] ([e-mail]) [000823 05:17]:
> > >Why don't we make the "wild card" or "speculative" key id support a
> > >SHOULD? I at least want to see all the client's being able to properly
> > >decrypt messages that use this feature.
> > 
> > I don't have a problem with the speculative keyID support 
> 
> same here, though i think when this issue was brought up once before
> there were some valid concerns brought up.  
> 
> imo, one context in which i think speculative key ids support "SHOULD"
> exist, is one which is user-driven -- if a user receives a message
> that contains public key encrypted session key packets that contain
> speculative key ids, the user should be able to have an openpgp
> implementation attempt to decrypt the pk esk packets w/ the user's
> secret key(s).  the user shouldn't have to perform surgery on the pk
> esk's (inserting key ids) and attempting to decrypt repeatedly.

The user *will* have to decrypt multiple secret keys if such exist. Perhaps a
recommendation that non-encrypted keys be tried first is an idea?

Actually, this might be of some concern. You could effectively send a email
using speculative KeyID, which would make the user decrypt all his key in
turn, thus providing a attacker with access to keyboard with passphrases to
*all* his KeyID's, including keys the user might have made to be extra secure,
and not for normal use (root keys etc).

Recommending some way of managing this, by specifying the order in which keys
are tried, or even marking keys as not to be used with spec keyid's is a
possible fix to this problem.

> in other contexts (e.g. processing by a script on a mail gateway), i
> was given to understand that there were valid reasons (e.g. computing
> resource limitations) not to want to support the feature.

I'm one who has raised such concerns, although not in the discussion you
refer to. I don't see how the fact that use of spec keyid's isn't appropriate
in every situation should put breaks on making it a should. Sure, it'll force
admins of major mailing lists to have to think first, act later, but isn't
that always the case when you have to admin a mailing list which is using
encrypted emails to such a number of user that that's a concern?

> > but it does not address the underlying problem: Implementors not
> > understanding basic concepts of e-mail encryption.
> 
> i agree w/ this as well.  

The question is, how would you like to solve the problem?

I don't see any quick fix for this. You can't force people to not write crypto
applications until they've been certifies in their field. You can't force
people to want to educate themselves.

I think the only thing one can do is offer help whenever possible, and view
everything with a critical eye, as well as publishing information about
potential problems, to help lesser skilled users from getting bitten.

Just my $0.02

Terje
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE5o4yF8HLgLrwmRg0RAv1PAJ9Uw3k80gHFDaktuqEbHvlGQ1elTgCfWvNP
7ouIyW4piHQZLjrBoVp05yo=
=bYcM
-----END PGP SIGNATURE-----


Received: by ns.secondary.com (8.9.3/8.9.3) id BAA25207 for ietf-openpgp-bks; Wed, 23 Aug 2000 01:05:41 -0700 (PDT)
Received: from djebel.gnupg.de (djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA25202 for <[e-mail]>; Wed, 23 Aug 2000 01:05:39 -0700 (PDT)
Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13RVdO-0001Nh-00; Wed, 23 Aug 2000 10:11:42 +0200
Date: Wed, 23 Aug 2000 10:11:42 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Aug 23, 2000 at 12:07:04PM +0800
X-URL: http://www.openit.de
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]        
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Wed, 23 Aug 2000, Erron Criddle wrote:

> However, once again, I am still baffled as to where the Key ID is stored 
> for an encryption subkey :) I have looked at the tag 2 packet (sig) and I 

Key IDs are not stored but calculated from the key data like a
fingerprint.  Actually a v4 key ID is a stripped down fingerprint.
 
  Werner

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


Received: by ns.secondary.com (8.9.3/8.9.3) id WAA14421 for ietf-openpgp-bks; Tue, 22 Aug 2000 22:42:42 -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 WAA14409 for <[e-mail]>; Tue, 22 Aug 2000 22:42:40 -0700 (PDT)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA07419; Tue, 22 Aug 2000 22:40:21 -0700
Date: Tue, 22 Aug 2000 22:40:21 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Erron writes, quoting me:

> >   If you are decrypting, isn't looking up by keyid the only possibility?
>
> If you're not using speculative Key ID's and you're talking about sigs, yes.
>
> >   There is no userid to tell you which key to decrypt with.
>
> Yes; if the headers have been stripped from the email message - no; if 
> they're not :)

I see, so you use the email message headers to figure out which key
to decrypt with.  That could work, for the specific case of decrypting
email.  Even if you did pick the wrong key, you would of course not be
troubled by false decryptions, you'd know that something had gone wrong.
However adding the ability to lookup by keyid is something you might
consider, for increased flexibility and reliability of lookup.

> >No, subkeys can have keyids too.  A PKESK packet should use the keyid of
> >the specific subkey which can decrypt it.
>
> OK, here is where I am confused. For example, a tag 14 (Public Subkey 
> Packet) hasn't the facility to store the Key ID and from reading the tag 2 
> (signature packet), you cannot store the key ID's there either - either 
> within the sig. packet or a subpacket of the signature. Where exactly do 
> you store the Key ID of an encryption subkey...I am totally bamboozled!

Here is the source of your confusion.  Keyids are not stored on keys.
Rather, they are calculated from the key data, like key fingerprints.
When we read in a key, we calculate its keyid and store it alongside
the key.  We can then use this stored keyid to find the key.

In PGP 2.6, we did not store the keys in memory, but rather we calculated
the keyid as we read and parsed each key on disk (it was simple for those
old V3 RSA keys).  This was then used to match against the desired keyid.

> Sorry, I didn't clarify enough - when I refer to using User ID's, I am 
> referring to decryption, not verification. The signature Key ID's can be 
> looked up via the self sig.

I don't quite understand how this would work; how would you know that
a sig is a "self sig" except by seeing that the keyid in the sig packet
matches the calculated keyid of the parent key?  Or do you just assume
the first sig on an object is a self sig?

Hal


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA08316 for ietf-openpgp-bks; Tue, 22 Aug 2000 21:19: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 VAA08311 for <[e-mail]>; Tue, 22 Aug 2000 21:19:15 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A3F2219701A4; Wed, 23 Aug 2000 12:20:18 0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 23 Aug 2000 12:07:04 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal,

At 02:07 PM 22/08/2000 -0700, Hal wrote:

>Erron Criddle writes:
> > As far as I'm concerned the Key ID is a complete waste of time unless a
> > lookup is being made on a server that is automatically decrypting each
> > message. This is OK here because you can configure the database to store
> > the Key ID and that makes lookups easier (if there are no duplicate Key
> > ID's).
>
>I am confused about whether you are talking about decryption or
>encryption.

Decryption.

>   The OpenPGP message formats only allow for using keyids to
>indicate which key should decrypt.

Yes, I know.

>   If you are decrypting, isn't looking up by keyid the only possibility?

If you're not using speculative Key ID's and you're talking about sigs, yes.

>   There is no userid to tell you which key to decrypt with.

Yes; if the headers have been stripped from the email message - no; if 
they're not :)

> > From my understanding of the Public and Private Keyring structures,
> > you can only have a Key ID for the highest level key (self sig.) and 
> cannot
> > store the Key ID's for the subkeys.
>
>No, subkeys can have keyids too.  A PKESK packet should use the keyid of
>the specific subkey which can decrypt it.

OK, here is where I am confused. For example, a tag 14 (Public Subkey 
Packet) hasn't the facility to store the Key ID and from reading the tag 2 
(signature packet), you cannot store the key ID's there either - either 
within the sig. packet or a subpacket of the signature. Where exactly do 
you store the Key ID of an encryption subkey...I am totally bamboozled!

> > For our client software, we are not doing lookups via the Key ID (as it
> > isn't stored in the public/private keyrings), however the server version
> > will support lookups via Key ID's.
> >
> > We have found it better just to do lookups via the User ID - at least you
> > can store that within the private /public keyring structures.
> >
> > If anyone can tell me otherwise regarding the storage of Signing and
> > Encryption Key ID's within the private/public keyrings, it would be great.
>
>If you are talking about decryption, I don't see how you do it.

The type of software we are implementing will allow us to do this.

>   And what about signature verification?  Again in that case the OpenPGP 
> message
>only has the signing keyid.  Don't you have to do a lookup by keyid to
>verify the sig?

Sorry, I didn't clarify enough - when I refer to using User ID's, I am 
referring to decryption, not verification. The signature Key ID's can be 
looked up via the self sig.

However, once again, I am still baffled as to where the Key ID is stored 
for an encryption subkey :) I have looked at the tag 2 packet (sig) and I 
can only see that you can store a Key ID in a signature subpacket for a 
signing key - but what is the subpacket type to use for a Key ID? Has a new 
one been created? Can we create one for Key ID?

Regards


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

Fax: [phone]
Tel: [phone]

http://www.comasp.com
[e-mail]













Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA06871 for ietf-openpgp-bks; Tue, 22 Aug 2000 21:00:05 -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 VAA06860 for <[e-mail]>; Tue, 22 Aug 2000 21:00:02 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AF721E5801A4; Wed, 23 Aug 2000 12:01:06 0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 23 Aug 2000 11:47:52 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Cc: "William H. Geiger III" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 01:03 PM 22/08/2000 -0500, "William H. Geiger III" <[e-mail]> 
wrote:

<snip>

> >As far as I'm concerned the Key ID is a complete waste of time unless a
> >lookup is being made on a server that is automatically decrypting each
> >message. This is OK here because you can configure the database to store
> >the Key ID and that makes lookups easier (if there are no duplicate Key
> >ID's). From my understanding of the Public and Private Keyring
> >structures,  you can only have a Key ID for the highest level key (self
> >sig.) and cannot  store the Key ID's for the subkeys.
>
> >For our client software, we are not doing lookups via the Key ID (as it
> >isn't stored in the public/private keyrings), however the server version
> >will support lookups via Key ID's.
>
> >We have found it better just to do lookups via the User ID - at least you
> > can store that within the private /public keyring structures.
>
> >If anyone can tell me otherwise regarding the storage of Signing and
> >Encryption Key ID's within the private/public keyrings, it would be
> >great.
>
>
>     IMHO using the userID is *not* the way to go. While userID lookups 
> can be used the first time you are encrypting a message to a new e-mail 
> address precautions need to be made. A dialog between the user should be 
> established to verify that this is the actual key that should be used 
> (anyone can create a key with any userID, multiple keys with the same 
> userID may be present, ...ect).

Agreed that User ID's provide the encryptor (user) options as to which key 
to use for encryption.

>  Key lookups need to be based on the 64bit keyID, it's the only way to 
> insure that you are getting the correct key (for signature verifications 
> it is the only way to find the key).

A 8 octet lookup of the Key ID for sigs. is definitely the only way to go 
(you can obtain the Key ID from the self sig. of the signature key). A 
lookup via a Key ID with a PKESK is only good if you are not using 
speculative Key ID's.

>  Once a user has selected a key to use for a new e-mail address the 
> application should store the 64bit keyID & the e-mail address in a table.

Agreed.

>  For subsequent encryptions to that address the application should lookup 
> the e-mail address in the table and then extract the PGP public key from 
> the keyring using the corresponding keyID.

That's where my dilemma starts - how do you store the Key ID of encryption 
subkeys on a keyring? I think this should be made possible somehow.

>Now granted the keyID is not stored in the key itself, this is not really 
>that big of an issue. I can currently process a 1Gb keyring, calculating 
>all the keyID's, in a couple of mins. For an average size keyring the 
>processing time is less that a second. If you find your application needs 
>to work with large keyrings maintaining a simple external index on the 
>keyring by keyID will greatly improve performance.

Yes, that's what we are doing - creating an index that links key ID's to 
email addresses - it certainly speeds things up.




Regards


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

Fax: [phone]
Tel: [phone]

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id UAA03095 for ietf-openpgp-bks; Tue, 22 Aug 2000 20:17: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 UAA03089 for <[e-mail]>; Tue, 22 Aug 2000 20:17:03 -0700 (PDT)
From: [e-mail]
Received: (qmail 16985 invoked from network); 23 Aug 2000 03:14:43 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 23 Aug 2000 03:14:43 -0000
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
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: <[e-mail]>
Date: Wed, 23 Aug 2000 12:16:40 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 51
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: "William H. Geiger III" <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Date: Tue, 22 Aug 2000 13:20:19 -0500
Message-ID: <[e-mail]>

> In <[e-mail]>, on 08/22/00 
>    at 01:43 AM, "L. Sassaman" <[e-mail]> said:
> 
> >Why don't we make the "wild card" or "speculative" key id support a
> >SHOULD? I at least want to see all the client's being able to properly
> >decrypt messages that use this feature.
> 
> I don't have a problem with the speculative keyID support 

same here, though i think when this issue was brought up once before
there were some valid concerns brought up.  

imo, one context in which i think speculative key ids support "SHOULD"
exist, is one which is user-driven -- if a user receives a message
that contains public key encrypted session key packets that contain
speculative key ids, the user should be able to have an openpgp
implementation attempt to decrypt the pk esk packets w/ the user's
secret key(s).  the user shouldn't have to perform surgery on the pk
esk's (inserting key ids) and attempting to decrypt repeatedly.

in other contexts (e.g. processing by a script on a mail gateway), i
was given to understand that there were valid reasons (e.g. computing
resource limitations) not to want to support the feature.

the discussion i am referring to took place in january of this year.
it starts at:

  http://www.imc.org/ietf-openpgp/mail-archive/msg02691.html

> but it does not address the underlying problem: Implementors not
> understanding basic concepts of e-mail encryption.

i agree w/ this as well.  

i would like to have a document i could point mail client developers
at that had some kind of "official" status -- like an ID, RFC, or
standard.  i don't think RFC 2440 (or bis) is the place for it (it's
too big already).

> I came across the issue of KeyID leakage back in '96 and documented
> it at:
>
> http://www.openpgp.net/pgpemail_5.html

nice!  perhaps this can be converted into an ID or portions of it
adapted to become an ID?


Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13979 for ietf-openpgp-bks; Tue, 22 Aug 2000 14:10:13 -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 OAA13974 for <[e-mail]>; Tue, 22 Aug 2000 14:10:09 -0700 (PDT)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id OAA06552; Tue, 22 Aug 2000 14:07:46 -0700
Date: Tue, 22 Aug 2000 14:07:46 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Erron Criddle writes:
> As far as I'm concerned the Key ID is a complete waste of time unless a 
> lookup is being made on a server that is automatically decrypting each 
> message. This is OK here because you can configure the database to store 
> the Key ID and that makes lookups easier (if there are no duplicate Key 
> ID's).

I am confused about whether you are talking about decryption or
encryption.  The OpenPGP message formats only allow for using keyids to
indicate which key should decrypt.  If you are decrypting, isn't looking
up by keyid the only possibility?  There is no userid to tell you which
key to decrypt with.

> From my understanding of the Public and Private Keyring structures, 
> you can only have a Key ID for the highest level key (self sig.) and cannot 
> store the Key ID's for the subkeys.

No, subkeys can have keyids too.  A PKESK packet should use the keyid of
the specific subkey which can decrypt it.

> For our client software, we are not doing lookups via the Key ID (as it 
> isn't stored in the public/private keyrings), however the server version 
> will support lookups via Key ID's.
>
> We have found it better just to do lookups via the User ID - at least you 
> can store that within the private /public keyring structures.
>
> If anyone can tell me otherwise regarding the storage of Signing and 
> Encryption Key ID's within the private/public keyrings, it would be great.

If you are talking about decryption, I don't see how you do it.  And what
about signature verification?  Again in that case the OpenPGP message
only has the signing keyid.  Don't you have to do a lookup by keyid to
verify the sig?

Hal


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12604 for ietf-openpgp-bks; Tue, 22 Aug 2000 12:44:55 -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 MAA12595 for <[e-mail]>; Tue, 22 Aug 2000 12:44:49 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA20530; Tue, 22 Aug 2000 12:45:04 -0700
Date: Tue, 22 Aug 2000 12:44:57 -0700 (PDT)
From: "L. Sassaman" <[e-mail]>
To: "William H. Geiger III" <[e-mail]>
cc: [e-mail], [e-mail], Terje Elde <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

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

Your point is valid, but in some cases requires that the authors of the
email programs do The Right Thing as well as the authors of the OpenPGP
program/plugin. (For instance, I don't believe that the PGP Outlook plugin
could be written in such a way that multiple single recipient messages
were sent out. That's an Outlook limitation.)

The speculative key-id feature would be something over which the OpenPGP
implementors could have full control (in just about all cases).


- --Len.

On Tue, 22 Aug 2000, William H. Geiger III wrote:

> In <[e-mail]>, on 08/22/00 
>    at 01:43 AM, "L. Sassaman" <[e-mail]> said:
> 
> >Why don't we make the "wild card" or "speculative" key id support a
> >SHOULD? I at least want to see all the client's being able to properly
> >decrypt messages that use this feature.
> 
> I don't have a problem with the speculative keyID support but it does not address the underlying problem: Implementors not understanding basic concepts of e-mail encryption. I came across the issue of KeyID leakage back in '96 and documented it at:
> 
> http://www.openpgp.net/pgpemail_5.html
> 
> Automated PGP processing can be a powerfull tool but there are complex issues involved and an application developer needs to spend the time at the design stage to do it properly.
> 
> -- 
> ---------------------------------------------------------------
> William H. Geiger III      http://www.openpgp.net  
> Geiger Consulting    
> 
> Data Security & Cryptology Consulting
> Programming, Networking, Analysis
>  
> PGP for OS/2:               http://www.openpgp.net/pgp.html
> E-Secure:                   http://www.openpgp.net/esecure.html
> ---------------------------------------------------------------
> 

__

L. Sassaman

Security Architect             |  "We all want many things,      
Technology Consultant          |   but some of those are bottomly
                               |   destructive of all desires."
http://sion.quickie.net        |               --Vernor Vinge

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

iD8DBQE5otg/PYrxsgmsCmoRAqb+AKDmykHO1lauFw7QdpX+1j2leKQfngCg9vYu
Vmaa8f8K1Y34rmcOv+BM1Us=
=82Ar
-----END PGP SIGNATURE-----



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA09867 for ietf-openpgp-bks; Tue, 22 Aug 2000 11:27:04 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09863 for <[e-mail]>; Tue, 22 Aug 2000 11:27:03 -0700 (PDT)
Received: from whgiii ([e-mail] [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id OAA03394; Tue, 22 Aug 2000 14:27:12 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Tue, 22 Aug 2000 13:20:19 -0500
To: "L. Sassaman" <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail], [e-mail], Terje Elde <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19zg/19zg 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

In <[e-mail]>, on 08/22/00 
   at 01:43 AM, "L. Sassaman" <[e-mail]> said:

>Why don't we make the "wild card" or "speculative" key id support a
>SHOULD? I at least want to see all the client's being able to properly
>decrypt messages that use this feature.

I don't have a problem with the speculative keyID support but it does not address the underlying problem: Implementors not understanding basic concepts of e-mail encryption. I came across the issue of KeyID leakage back in '96 and documented it at:

http://www.openpgp.net/pgpemail_5.html

Automated PGP processing can be a powerfull tool but there are complex issues involved and an application developer needs to spend the time at the design stage to do it properly.

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------



Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA09760 for ietf-openpgp-bks; Tue, 22 Aug 2000 11:19:10 -0700 (PDT)
Received: from domains.invweb.net ([e-mail] [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09756 for <[e-mail]>; Tue, 22 Aug 2000 11:19:09 -0700 (PDT)
Received: from whgiii ([e-mail] [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id OAA02610; Tue, 22 Aug 2000 14:19:12 -0400
Message-Id: <[e-mail]>
From: "William H. Geiger III" <[e-mail]>
Date: Tue, 22 Aug 2000 13:03:23 -0500
To: Erron Criddle <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19zg/19zg 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

In <[e-mail]>, on 08/22/00 
   at 02:43 AM, Erron Criddle <[e-mail]> said:

>At 01:33 PM 22/08/2000 +0900, [e-mail] wrote:

><snip>

>>   since this means that each recipient receives a message containing a
>>   public key encrypted session key packet for each recipient, each recipient
>>   is able to tell who all of the recipients were (assuming no use of
>>   speculative key ids) -- or at least all key ids.
>>
>>   even if speculative key ids were to be used, a recipient would likely
>>   be able to tell that there were other recipients than those implied
>>   in the headers of a message.  also, afaik, nai pgp doesn't support
>>   speculative key ids, so in terms of interroperability it's not a great
>>   option at this point.

>As far as I'm concerned the Key ID is a complete waste of time unless a 
>lookup is being made on a server that is automatically decrypting each 
>message. This is OK here because you can configure the database to store 
>the Key ID and that makes lookups easier (if there are no duplicate Key 
>ID's). From my understanding of the Public and Private Keyring
>structures,  you can only have a Key ID for the highest level key (self
>sig.) and cannot  store the Key ID's for the subkeys.

>For our client software, we are not doing lookups via the Key ID (as it 
>isn't stored in the public/private keyrings), however the server version 
>will support lookups via Key ID's.

>We have found it better just to do lookups via the User ID - at least you
> can store that within the private /public keyring structures.

>If anyone can tell me otherwise regarding the storage of Signing and 
>Encryption Key ID's within the private/public keyrings, it would be
>great.


    IMHO using the userID is *not* the way to go. While userID lookups can be used the first time you are encrypting a message to a new e-mail address precautions need to be made. A dialog between the user should be established to verify that this is the actual key that should be used (anyone can create a key with any userID, multiple keys with the same userID may be present, ...ect). Key lookups need to be based on the 64bit keyID, it's the only way to insure that you are getting the correct key (for signature verifications it is the only way to find the key). Once a user has selected a key to use for a new e-mail address the application should store the 64bit keyID & the e-mail address in a table. For subsequent encryptions to that address the application should lookup the e-mail address in the table and then extract the PGP public key from the keyring using the corresponding keyID.

    Now granted the keyID is not stored in the key itself, this is not really that big of an issue. I can currently process a 1Gb keyring, calculating all the keyID's, in a couple of mins. For an average size keyring the processing time is less that a second. If you find your application needs to work with large keyrings maintaining a simple external index on the keyring by keyID will greatly improve performance.


-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------



Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02742 for ietf-openpgp-bks; Tue, 22 Aug 2000 01:56:10 -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 BAA02738 for <[e-mail]>; Tue, 22 Aug 2000 01:56:07 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A348197102A6; Tue, 22 Aug 2000 16:56:56 0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 22 Aug 2000 16:43:43 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 01:33 PM 22/08/2000 +0900, [e-mail] wrote:

<snip>

>   since this means that each recipient receives a message containing a
>   public key encrypted session key packet for each recipient, each recipient
>   is able to tell who all of the recipients were (assuming no use of
>   speculative key ids) -- or at least all key ids.
>
>   even if speculative key ids were to be used, a recipient would likely
>   be able to tell that there were other recipients than those implied
>   in the headers of a message.  also, afaik, nai pgp doesn't support
>   speculative key ids, so in terms of interroperability it's not a great
>   option at this point.

As far as I'm concerned the Key ID is a complete waste of time unless a 
lookup is being made on a server that is automatically decrypting each 
message. This is OK here because you can configure the database to store 
the Key ID and that makes lookups easier (if there are no duplicate Key 
ID's). From my understanding of the Public and Private Keyring structures, 
you can only have a Key ID for the highest level key (self sig.) and cannot 
store the Key ID's for the subkeys.

For our client software, we are not doing lookups via the Key ID (as it 
isn't stored in the public/private keyrings), however the server version 
will support lookups via Key ID's.

We have found it better just to do lookups via the User ID - at least you 
can store that within the private /public keyring structures.

If anyone can tell me otherwise regarding the storage of Signing and 
Encryption Key ID's within the private/public keyrings, it would be great.

Cheers.


Regards


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

Fax: [phone]
Tel: [phone]

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id AAA28406 for ietf-openpgp-bks; Tue, 22 Aug 2000 00:43:17 -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 AAA28388 for <[e-mail]>; Tue, 22 Aug 2000 00:43:11 -0700 (PDT)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA02398; Tue, 22 Aug 2000 00:43:23 -0700
Date: Tue, 22 Aug 2000 00:43:16 -0700 (PDT)
From: "L. Sassaman" <[e-mail]>
To: [e-mail]
cc: [e-mail], Terje Elde <[e-mail]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

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

Why don't we make the "wild card" or "speculative" key id support a
SHOULD? I at least want to see all the client's being able to properly
decrypt messages that use this feature.

On Tue, 22 Aug 2000 [e-mail] wrote:

> through some testing of existing mail clients, Terje Elde
> <[e-mail]>, other members of the [e-mail]
> mailing list, and i have noticed that bcc-ed recipient key id
> information can be leaked to non-bcc-ed recipients.
> 
> it's probably obvious what the problem is, but for the sake of clarity:
> 
>   for the purposes of sending a message to a group of recipients, some 
>   mail clients create a single encrypted message body which is sent
>   out to all recipients, including bcc-ed recipients.
> 
>   since this means that each recipient receives a message containing a 
>   public key encrypted session key packet for each recipient, each recipient
>   is able to tell who all of the recipients were (assuming no use of
>   speculative key ids) -- or at least all key ids.
> 
>   even if speculative key ids were to be used, a recipient would likely
>   be able to tell that there were other recipients than those implied
>   in the headers of a message.  also, afaik, nai pgp doesn't support
>   speculative key ids, so in terms of interroperability it's not a great
>   option at this point.
> 
> we've found 5 mail clients that suffer this problem so far, so it
> seems like it may be a common implementation "choice".
> 
> [ we have also received reports that at least a couple of mail clients
> actually encrypt to each recipient separately and thus do not suffer
> this problem. ]
> 

__

L. Sassaman

Security Architect             |  "We all want many things,      
Technology Consultant          |   but some of those are bottomly
                               |   destructive of all desires."
http://sion.quickie.net        |               --Vernor Vinge

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

iD8DBQE5oi8aPYrxsgmsCmoRAnxyAJ0bAqYcrJDUEUVwIRJ6uz4jsX56kQCgqZkn
pqNTNhWyWSduOPkPWIeWbIQ=
=XnBR
-----END PGP SIGNATURE-----



Received: by ns.secondary.com (8.9.3/8.9.3) id VAA15587 for ietf-openpgp-bks; Mon, 21 Aug 2000 21:34:38 -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 VAA15570 for <[e-mail]>; Mon, 21 Aug 2000 21:34:25 -0700 (PDT)
From: [e-mail]
Received: (qmail 27014 invoked from network); 22 Aug 2000 04:32:03 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 22 Aug 2000 04:32:03 -0000
To: [e-mail]
Cc: Terje Elde <[e-mail]>
Subject: mail client implementations problem?  bcc and encrypting to multiple recipients
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: <[e-mail]>
Date: Tue, 22 Aug 2000 13:33:57 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 28
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

through some testing of existing mail clients, Terje Elde
<[e-mail]>, other members of the [e-mail]
mailing list, and i have noticed that bcc-ed recipient key id
information can be leaked to non-bcc-ed recipients.

it's probably obvious what the problem is, but for the sake of clarity:

  for the purposes of sending a message to a group of recipients, some 
  mail clients create a single encrypted message body which is sent
  out to all recipients, including bcc-ed recipients.

  since this means that each recipient receives a message containing a 
  public key encrypted session key packet for each recipient, each recipient
  is able to tell who all of the recipients were (assuming no use of
  speculative key ids) -- or at least all key ids.

  even if speculative key ids were to be used, a recipient would likely
  be able to tell that there were other recipients than those implied
  in the headers of a message.  also, afaik, nai pgp doesn't support
  speculative key ids, so in terms of interroperability it's not a great
  option at this point.

we've found 5 mail clients that suffer this problem so far, so it
seems like it may be a common implementation "choice".

[ we have also received reports that at least a couple of mail clients
actually encrypt to each recipient separately and thus do not suffer
this problem. ]


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA07287 for ietf-openpgp-bks; Tue, 8 Aug 2000 08:25:55 -0700 (PDT)
Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07278 for <[e-mail]>; Tue, 8 Aug 2000 08:25:54 -0700 (PDT)
Received: by picard.noroff.no (Postfix, from userid 815) id 6B54122010; Tue,  8 Aug 2000 18:14:07 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id 7B9DFB3802 for <[e-mail]>; Tue,  8 Aug 2000 18:14:00 +0200 (CEST)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA27062 for [e-mail]; Tue, 8 Aug 2000 10:55:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26702 for <[e-mail]>; Tue, 8 Aug 2000 10:17:45 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03102; Tue, 8 Aug 2000 10:17:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-multsig-01.txt
Date: Tue, 08 Aug 2000 10:17:40 -0400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

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

	Title		: Multiple Signatures using Security Multiparts
	Author(s)	: D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-multsig-01.txt
	Pages		: 6
	Date		: 07-Aug-00
	
This document describes how the Security Multiparts defined in RFC
1847 [1] can be used to transport multiple digital signatures.
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  A web site containing an
archive of the list can be found at
<http://www.imc.org/ietf-openpgp>.

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

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-multsig-01.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA04725 for ietf-openpgp-bks; Tue, 8 Aug 2000 08:15:16 -0700 (PDT)
Received: from picard.noroff.no ([212.20.204.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04712 for <[e-mail]>; Tue, 8 Aug 2000 08:15:14 -0700 (PDT)
Received: by picard.noroff.no (Postfix, from userid 815) id 5F45C22010; Tue,  8 Aug 2000 18:03:27 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by picard.noroff.no (Postfix) with ESMTP id B2289B3802 for <[e-mail]>; Tue,  8 Aug 2000 18:03:24 +0200 (CEST)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA26984 for [e-mail]; Tue, 8 Aug 2000 10:45:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA26695 for <[e-mail]>; Tue, 8 Aug 2000 10:17:40 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03078; Tue, 8 Aug 2000 10:17:35 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-mime-02.txt
Date: Tue, 08 Aug 2000 10:17:35 -0400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre2 (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

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

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-02.txt
	Pages		: 12
	Date		: 07-Aug-00
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

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

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29328 for ietf-openpgp-bks; Tue, 8 Aug 2000 07:13:32 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29320 for <[e-mail]>; Tue, 8 Aug 2000 07:13:30 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03102; Tue, 8 Aug 2000 10:17:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-multsig-01.txt
Date: Tue, 08 Aug 2000 10:17:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

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

	Title		: Multiple Signatures using Security Multiparts
	Author(s)	: D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-multsig-01.txt
	Pages		: 6
	Date		: 07-Aug-00
	
This document describes how the Security Multiparts defined in RFC
1847 [1] can be used to transport multiple digital signatures.
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  A web site containing an
archive of the list can be found at
<http://www.imc.org/ietf-openpgp>.

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

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-multsig-01.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29316 for ietf-openpgp-bks; Tue, 8 Aug 2000 07:13:27 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29309 for <[e-mail]>; Tue, 8 Aug 2000 07:13:25 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03078; Tue, 8 Aug 2000 10:17:35 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-mime-02.txt
Date: Tue, 08 Aug 2000 10:17:35 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

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

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-02.txt
	Pages		: 12
	Date		: 07-Aug-00
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

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

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

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


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

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

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id PAA23393 for ietf-openpgp-bks; Fri, 4 Aug 2000 15:29:10 -0700 (PDT)
Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23389 for <[e-mail]>; Fri, 4 Aug 2000 15:29:08 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id KAA23528; Sat, 5 Aug 2000 10:32:50 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96542836932543>; Sat, 5 Aug 2000 10:32:49 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: OpenPGP as a standard
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 5 Aug 2000 10:32:49 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

[e-mail] writes:

>What about S/MIME?  It doesn't say anything about what you do when spooling
>data to disk in order to calculate a signature on it, does it? Do these people
>you know say that S/MIME shouldn't become a standard either?

S/MIME is one-pass, it wouldn't spool anything to disk unless it's badly
written (that doesn't mean it doesn't contain some serious braindamage, like
the ridiculous base64 encoding at each level to bloat up the size and provide
known plaintext for attackers, but forcing you to spool data to disk isn't one
of its problems).

Peter.



Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23014 for ietf-openpgp-bks; Fri, 4 Aug 2000 14:58: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 OAA23009 for <[e-mail]>; Fri, 4 Aug 2000 14:58:25 -0700 (PDT)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA08644; Fri, 4 Aug 2000 15:00:19 -0700
Date: Fri, 4 Aug 2000 15:00:19 -0700
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OpenPGP as a standard
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Erron Criddle writes:
>  From discussions with people who have been involved with the standards 
> process, they believe that the OpenPGP RFC has a long way to go before it 
> would be accepted as a standard because the processing requirements of 
> OpenPGP have been superficially regarded with respect to packet formats 
> such as the calculation of the length of a packet and the combined security 
> of the actual packet (ie as OpenPGP is a security standard, so NO data 
> should be spooled to disk unless it is encrypted somehow).

What about S/MIME?  It doesn't say anything about what you do when
spooling data to disk in order to calculate a signature on it, does it?
Do these people you know say that S/MIME shouldn't become a standard
either?

> For example, in order to calculate the length of a stream of literal data 
> (before it is prepended with a one pass sig and appended with a standard 
> sig, and subsequently compressed then encrypted), you have to spool the 
> data to the disk if it is a very large file. In order to maintain security, 
> the data SHOULD be encypted to disk, however when we want to build the 
> above packet, we would then have to decrypt the data so it could be 
> prepended with the 1P sig, appended with the normal sig and then compressed 
> then encrypted ONCE AGAIN...etc etc

Actually, as I think you mentioned in a later mail, OpenPGP goes to some
lengths to define data formats which will avoid this problem.  This is
why we added one-pass signatures, and why we added partial packet length
specifiers.  So your people are apparently not even that familiar with
the standard.

> This is one example I have been quoted and I cannot say there are 
> equivalent examples that "may" slow down the process of OpenPGP becoming a 
> standard.

It sounds to me like your people are looking for excuses.

The real problem I see with OpenPGP is simply that so few people implement
it.  Making it an internet standard will not suddenly make people rush to
produce implementations, any more than making it a proposed standard did.

Hal Finney


Received: by ns.secondary.com (8.9.3/8.9.3) id OAA22519 for ietf-openpgp-bks; Fri, 4 Aug 2000 14:03:09 -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 OAA22515 for <[e-mail]>; Fri, 4 Aug 2000 14:03:07 -0700 (PDT)
Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id OAA16653; Fri, 4 Aug 2000 14:06:57 -0700 (PDT)
Received: from [63.73.97.187] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id OAA16648; Fri, 4 Aug 2000 14:06:54 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p04320403b5b0a66dde79@[63.73.97.187]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 4 Aug 2000 13:59:23 -0700
To: Erron Criddle <[e-mail]>, [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: OpenPGP as a standard
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 3:49 PM +0800 8/4/00, Erron Criddle wrote:
>To all,
>
>I'm e-mailing regarding the possibility of OpenPGP becoming a standard.
>
> From discussions with people who have been involved with the standards
>process, they believe that the OpenPGP RFC has a long way to go before it
>would be accepted as a standard because the processing requirements of
>OpenPGP have been superficially regarded with respect to packet formats
>such as the calculation of the length of a packet and the combined security
>of the actual packet (ie as OpenPGP is a security standard, so NO data
>should be spooled to disk unless it is encrypted somehow).
>

Huh? Which people?

I agree with Werner. The only things that are needed are for some people to
do some interoperability testing, and buffing and polishing on the spec.
You and others have pointed out places where it's not as clear as it should
be. Lots of us have been looking at it for so long we can't tell. All of
the discussion about things lately has been great for clarifying the spec.



>For example, in order to calculate the length of a stream of literal data
>(before it is prepended with a one pass sig and appended with a standard
>sig, and subsequently compressed then encrypted), you have to spool the
>data to the disk if it is a very large file. In order to maintain security,
>the data SHOULD be encypted to disk, however when we want to build the
>above packet, we would then have to decrypt the data so it could be
>prepended with the 1P sig, appended with the normal sig and then compressed
>then encrypted ONCE AGAIN...etc etc
>
>This is one example I have been quoted and I cannot say there are
>equivalent examples that "may" slow down the process of OpenPGP becoming a
>standard.
>

You bring up an interesting issue, but it has nothing to do with OpenPGP
becoming a standard. Sorry. It's always possible that you *can* come up
with a situation where as an implementor, you have to spool data to disk
while processing it. Cope.

>Can anyone give me any information on the status of OpenPGP in becoming a
>standard as this information would definitely be helpful for those who are
>implementing the OpenPGP RFC.
>

As has been mentioned, there has to be some interoperability testing done.
That's mainly what has to be done. Then we just need to agree whether 2440
or some later draft progresses, and then push it on the line. If it's a
later draft, then that has to become an RFC.

	Jon



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA21482 for ietf-openpgp-bks; Fri, 4 Aug 2000 03:08:21 -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 DAA21478 for <[e-mail]>; Fri, 4 Aug 2000 03:08:19 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A9EB7D30188; Fri, 04 Aug 2000 18:12:11 0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 04 Aug 2000 18:00:12 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: Re: OpenPGP as a standard
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

At 05:53 PM 4/08/2000 +0900, you wrote:
>From: Erron Criddle <[e-mail]>
>Subject: OpenPGP as a standard
>Date: Fri, 04 Aug 2000 15:49:18 +0800
>Message-ID: <[e-mail]>
>
> > I'm e-mailing regarding the possibility of OpenPGP becoming a standard.
>
>i am very confused by what you mean by "becoming a standard".  would you
>mind elaborating?

When I speak about a "standard", I am talking about OpenPGP becoming an 
IETF standard.

Look at: http://www.imc.org/smime-pgpmime.html; it states:

"The charter for the OpenPGP WG states clearly that the purpose of the 
group is to create protocols based on PGP that can become IETF standards"

I have also satisfied the quoted persons concerns regarding the length 
specifier (ie OpenPGP as a standard) as OpenPGP can handle an unspecified 
length field quite nicely and thus there is no over processing required :)


Regards


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

Fax: [phone]
Tel: [phone]

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id CAA21055 for ietf-openpgp-bks; Fri, 4 Aug 2000 02:47:11 -0700 (PDT)
Received: from djebel.gnupg.de ([e-mail] [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21051 for <[e-mail]>; Fri, 4 Aug 2000 02:47:09 -0700 (PDT)
Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13Ke9x-0000sC-00; Fri, 4 Aug 2000 11:52:57 +0200
Date: Fri, 4 Aug 2000 11:52:57 +0200
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: OpenPGP as a standard
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Aug 04, 2000 at 05:53:51PM +0900
X-URL: http://www.openit.de
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:[e-mail]        
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 4 Aug 2000, [e-mail] wrote:

> i am very confused by what you mean by "becoming a standard".  would you
> mind elaborating?

Probably he wants to say:  Moving from status Proposed Standard to
Draft Standard.

Several times we started to do the needed compatibility tests, but due
to shortages of time we haven't moved any further :-(.  Frankly it
should be pretty easy do go to Draft - There are a few implemenations
and they all interoperate;  it is just that some folks sit down and do
some actual testing.

  Werner


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


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA21012 for ietf-openpgp-bks; Fri, 4 Aug 2000 02:45:57 -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 CAA21007 for <[e-mail]>; Fri, 4 Aug 2000 02:45:56 -0700 (PDT)
Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP  id <[e-mail]>; Fri, 4 Aug 2000 10:49:41 +0100
Message-ID: <[e-mail]>
Date: Fri, 04 Aug 2000 10:48:30 +0100
From: Ian Brown <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Forward secrecy
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal,

Thanks for the comments :)

We did include mechanisms for specifying the one-time pad to be used to
decrypt a given message:
--
4.2 One-time pad reference
...
     - A four-octet date when the referenced one-time pad was created.

     - A four-octet offset specifying the first octet in the referenced
       pad that should be used as key.
--
ie the creation time was meant to be a pseudo-ID.

But I am quite happy to take out the OTP section if that's what people
want: if anyone later feels they need it, they would be welcome to
cannabalise our text as the starting point for a new RFC. What are other
people's thoughts?

> One is what has recently been discussed on the ukcrypto list, which is
> to provide a mechanism in the client to surrender selected session keys
> rather than public keys, under court order.  This provides a minimal
> way of complying with the new UK laws.

I have added the following paragraph to the "Key Surrender" section:

"The least compromising key required MUST be the one surrendered. The
session key used to encrypt an individual message will often be sufficient.
Otherwise, a subkey should be surrendered before a long-term top-level key.
Signature keys should not be surrendered unless absolutely necessary."

> Another idea, which would be much harder to specify clearly, was
> something that PRZ proposed to me way back in 1992.  Similar to the
> one-use decryption keys, he proposed that communicating parties cache a
> session key to be used over a series of messages, updating it for each
> message transfer.  You could get forward secrecy by doing something like
> new_key = hash(old_key), with appropriate precautions.  This would be a
> lighter weight mechanism than the one-use decryption keys, but it would
> be more of a change to the OpenPGP standard.

This is nice, but does need a reasonable amount of work to specify. If
people feel this would be valuable, we could discuss it further.

Ian :)


Received: by ns.secondary.com (8.9.3/8.9.3) id BAA17571 for ietf-openpgp-bks; Fri, 4 Aug 2000 01:50:18 -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 BAA17560 for <[e-mail]>; Fri, 4 Aug 2000 01:50:15 -0700 (PDT)
From: [e-mail]
Received: (qmail 26713 invoked from network); 4 Aug 2000 08:52:23 -0000
Received: from localhost (127.0.0.1) by localhost with SMTP; 4 Aug 2000 08:52:23 -0000
To: [e-mail]
Subject: Re: OpenPGP as a standard
In-Reply-To: <[e-mail]>
References: <[e-mail]>
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: <[e-mail]>
Date: Fri, 04 Aug 2000 17:53:51 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines: 9
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: Erron Criddle <[e-mail]>
Subject: OpenPGP as a standard
Date: Fri, 04 Aug 2000 15:49:18 +0800
Message-ID: <[e-mail]>

> I'm e-mailing regarding the possibility of OpenPGP becoming a standard.

i am very confused by what you mean by "becoming a standard".  would you
mind elaborating?


Received: by ns.secondary.com (8.9.3/8.9.3) id AAA12238 for ietf-openpgp-bks; Fri, 4 Aug 2000 00:57:14 -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 AAA12234 for <[e-mail]>; Fri, 4 Aug 2000 00:57:11 -0700 (PDT)
Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB3D8A950210; Fri, 04 Aug 2000 16:01:17 0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 04 Aug 2000 15:49:18 +0800
To: [e-mail]
From: Erron Criddle <[e-mail]>
Subject: OpenPGP as a standard
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

To all,

I'm e-mailing regarding the possibility of OpenPGP becoming a standard.

 From discussions with people who have been involved with the standards 
process, they believe that the OpenPGP RFC has a long way to go before it 
would be accepted as a standard because the processing requirements of 
OpenPGP have been superficially regarded with respect to packet formats 
such as the calculation of the length of a packet and the combined security 
of the actual packet (ie as OpenPGP is a security standard, so NO data 
should be spooled to disk unless it is encrypted somehow).

For example, in order to calculate the length of a stream of literal data 
(before it is prepended with a one pass sig and appended with a standard 
sig, and subsequently compressed then encrypted), you have to spool the 
data to the disk if it is a very large file. In order to maintain security, 
the data SHOULD be encypted to disk, however when we want to build the 
above packet, we would then have to decrypt the data so it could be 
prepended with the 1P sig, appended with the normal sig and then compressed 
then encrypted ONCE AGAIN...etc etc

This is one example I have been quoted and I cannot say there are 
equivalent examples that "may" slow down the process of OpenPGP becoming a 
standard.

Can anyone give me any information on the status of OpenPGP in becoming a 
standard as this information would definitely be helpful for those who are 
implementing the OpenPGP RFC.

Regards


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

Fax: [phone]
Tel: [phone]

http://www.comasp.com
[e-mail]













Received: by ns.secondary.com (8.9.3/8.9.3) id RAA07501 for ietf-openpgp-bks; Thu, 3 Aug 2000 17:58: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 RAA07493 for <[e-mail]>; Thu, 3 Aug 2000 17:58:42 -0700 (PDT)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id SAA06859; Thu, 3 Aug 2000 18:00:12 -0700
Date: Thu, 3 Aug 2000 18:00:12 -0700
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Forward secrecy
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

A comment on
http://www.ietf.org/internet-drafts/draft-brown-pgp-pfs-00.txt,
"Forward Secrecy Extensions for OpenPGP".

The ideas here are good, but I object to the inclusion of the one time
pad as a new cryptographic method for OpenPGP.

Although OTPs can provide forward secrecy, this is not their main purpose
(which is to provide absolute secrecy).  And to use them primarily for
this purpose requires some care which the proposed mechanism doesn't
really address.

In particular, there is nothing in the proposal for distinguishing
multiple OTPs, or for indicating which ones should be used for a given
decryption.  Also, there is no mechanism for selectively erasing just
part of a given OTP.  The assumption seems to be that there is one OTP,
and it is used to decrypt one message, then it is deleted.  Given the
tremendous difficulty of distributing a OTP, this is not a practical
mode of operation.

But rather than fixing this up by providing OTP identifiers, storage
modes, ways to keep track of which parts of a OTP should be deleted,
etc., I think this whole section should be removed.  It goes too far
beyond the claimed scope of the document.  Adding a OTP is a whole new
area of functionality for OTP.  It doesn't belong in a document like
this, IMO.

There are some other ideas you might want to consider.

One is what has recently been discussed on the ukcrypto list, which is
to provide a mechanism in the client to surrender selected session keys
rather than public keys, under court order.  This provides a minimal
way of complying with the new UK laws.

The document proposes that when you export a private key in the clear,
it should be automatically revoked with an appropriate reason-for-
revocation flag set.  This is reasonable, although it is obviously easy
to force someone to give you their key without triggering this mechanism,
by having them export it encrypted but tell you the passphrase.

Another idea along these lines is to have a mode to export the private
part of only the subkeys, or perhaps a single subkey, while exporting
only the public part of the top level signature key.

Perhaps rather than triggering a revocation, it could set the bit in the
self-signature key flags meaning "the private component of this key
may be in the possession of more than one person".  Then you'd want to
have the clients display keys with this bit set in some special way.

Another idea, which would be much harder to specify clearly, was
something that PRZ proposed to me way back in 1992.  Similar to the
one-use decryption keys, he proposed that communicating parties cache a
session key to be used over a series of messages, updating it for each
message transfer.  You could get forward secrecy by doing something like
new_key = hash(old_key), with appropriate precautions.  This would be a
lighter weight mechanism than the one-use decryption keys, but it would
be more of a change to the OpenPGP standard.

Hal