Subject: e-mail programs

From: "Matthew Sherborne" <[email-masked]>
Date: Fri, 1 Oct 1999 12:29:42 +0100

Does anyone know of any e-mail programs that incorporate PGP ?

Matthew Sherborne
Senior Programmer
Dataworks Design International

Portable e-mail for everyone -> www.eze-mail.net

Date: Fri, 1 Oct 1999 12:29:42 +0100
From: "Matthew Sherborne" <[email-masked]>
To: "Open PGP Mailing List" <[email-masked]>
Subject: e-mail programs
Sender: [email-masked]

Does anyone know of any e-mail programs that incorporate PGP ?

Matthew Sherborne
Senior Programmer
Dataworks Design International

Portable e-mail for everyone -> www.eze-mail.net

Date: Thu, 30 Sep 1999 20:01:00 -0400 (EDT)
From: Tom Zerucha <[email-masked]>
To: Carl Ellison <[email-masked]>
cc: [email-masked]
Subject: Re: Any implementation for the Pilot?
Sender: [email-masked]

http://cryptography.org/crypto/-export-control-random-/pgp/palmopgp/

Go to www.cryptography.org and follow the pgp link and the palmopgp link
after you get past the export screen.

On 30 Sep 1999, Carl Ellison wrote:

> Is anyone doing a PGP implementation for the PalmPilot?
> *** SIG ERROR
> 
> 
> +------------------------------------------------------------------+
> |Carl M. Ellison         [email-masked]     http://www.pobox.com/~cme |
> |    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
> +--Officer, officer, arrest that man. He's whistling a dirty song.-+

Date: 30 Sep 1999 01:06:24 -0700
From: "Carl Ellison" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Any implementation for the Pilot?
Sender: [email-masked]

Is anyone doing a PGP implementation for the PalmPilot?

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://www.pobox.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

Date: Wed, 22 Sep 1999 16:10:33 -0400 (EDT)
From: Tony Mione <[email-masked]>
To: [email-masked]
cc: Tony Mione <[email-masked]>
Subject: New mailing list for PGP Keyserver Synchronization protocl
Sender: [email-masked]

In Oslo, John Noerenberg requested that I create a new mailing list to
discuss PGP Keyserver synchronization protocols. If the list gets
sufficient discussion, we should request a BOF for the DC or Adelaide IETF
meeting.

The list is [email-masked]. You can subscribe by sending
email to [email-masked] and placing the commands

subscribe ietf-sync-pgp
end

in the body of the message.

Tony Mione                          Phone: +1 732-445-0605 FAX: +1 732-445-2968
Manager, TD Network Services                 W3: http://noc.rutgers.edu/~mione/
RUCS Telecommunications Division        PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall ** Rom 10:9-11 **

Date: Wed, 22 Sep 1999 07:43:49 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Encrypted Data Packet Contents
Sender: [email-masked]

"Mr. Morden" <[email-masked]> writes:

> 5.7. Symmetrically Encrypted Data Packet (Tag 9)
> 
>    The Symmetrically Encrypted Data packet contains data encrypted with
>    a symmetric-key algorithm. When it has been decrypted, it will
>    typically contain other packets (often literal data packets or
>    compressed data packets).
> ............................
> 
> What gives with *typically*? It should *always* contain other packets 
> (Signed, Compressed, Literal, whathaveyou...)

>From the RFC (10.2):
|   [...]
|   In addition, decrypting a Symmetrically Encrypted Data packet and
|   decompressing a Compressed Data packet must yield a valid OpenPGP
|   Message.

And typically you will either have a signed message, a compressed
packet or a literal packet; however you may cosse to put another
encrypted packet in it.

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

From: "Mr. Morden" <[email-masked]>
To: [email-masked]
Subject: Encrypted Data Packet Contents
Date: Tue, 21 Sep 1999 19:07:09 GMT
Sender: [email-masked]

>From the RFC so dear...
......................
5.7. Symmetrically Encrypted Data Packet (Tag 9)

   The Symmetrically Encrypted Data packet contains data encrypted with
   a symmetric-key algorithm. When it has been decrypted, it will
   typically contain other packets (often literal data packets or
   compressed data packets).
............................

What gives with *typically*? It should *always* contain other packets 
(Signed, Compressed, Literal, whathaveyou...)

Or, can arbitrary data be placed in this packet?
Does any implementation allow this?

-ted

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Wed, 15 Sep 1999 08:57:06 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: dash-escaped text (7.1)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

there is a ambiguity in the definition of cleartext signature:

|7.1. Dash-Escaped Text
| [....]
|   As with binary signatures on text documents, a cleartext signature is
|   calculated on the text using canonical <CR><LF> line endings.  The
|   line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|   SIGNATURE-----' line that terminates the signed text is not
|   considered part of the signed text.

It is not clear whether this line ending is has to be added by the 
creation process and later to be removed or whether it simply does
not go into the calculation of the hash.

The problem with this is, what to do when we have to encode a message

 a) of size 0
 b) without a trailing line ending

I agree that both cases are rare but case b) happens from time to
time.  Solutions for this are:

 a) A header line telling something about the orignal text when this
    text has one of the above problems.  
    Advantage:  Compatibility to existing implementions
    Disadvantage: A extra header line in a few cases and special code
		  to handle these cases.

 b) Add the text to the RFC:
    "A newline is supposed to be added and subsequently removed".
    Advantage:  Very easy and clear definition.
    Disadvantage:  Not compatible to existing implemantations

 c) Add a RFC version number as header line and use b)
    Advantage:  Easy
    Disadvantage:  Still need the extra code for OpenPGP 1.0 and 
                   makes all signatures larger.

For compatibilty reasons I would prefer solution a)

What do you think?

   Werner

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 13 Sep 1999 10:27:21 -0500
To: Jon Callas <[email-masked]>
Cc: "John S. Bucy" <[email-masked]>, [email-masked]
Subject: Re: OpenPGP key fingerprints and stuff
Sender: [email-masked]

In <v04210118b40211aa218f@[204.179.130.203]>, on 09/12/99 
   at 07:33 PM, Jon Callas <[email-masked]> said:

>At 1:54 PM -0400 9/12/99, John S. Bucy wrote:

>>Someone else suggested that the problem of computing a key pair that has a
>>particular key ID is computationally infeasible.  I can't really speak to
>>this either way but it seems to me like 1: the probability of people
>>independentally randomly generating the same key pair (or keypairs with
>>identical fingerprints/keyIDs) is quite small and that 2: it would be
>>completely impractical for almost anyone (three-letter agencies excluded)
>>to try to exploit a system by systematically causing keyID collisions.

>Yes, it's computationally infeasible to generate a key with a given
>keyID. Or more to the point, if you can do it, you have found a flaw in
>SHA-1. Publish it, you'll get kudos.

>However, because the keyID is 64 bits long, when there are a total of 4
>billion keys (0x1 0000 0000) in the universe, there is a 50% chance that
>there is some collision of two keyIDs. These two people will be annoyed,
>because all the present implementations assume keyIDs are unique.

Actually, IIRC when I asked about keyID's long ago it was the consensus
that they were not unique and should be treated as such. I have been
coding under this assumption ever since.

>>
>>
>>As far as my particular system goes, it seems like I have two options:
>>
>>1.  Don't worry about key ID collisions.  Under most circumstances, I
>>think that this would probably be ok.
>>
>>2.  Use a "signer's key fingerprint" signature subpacket and leave the
>>keyID packet there and ignore it.  Has the working group considered an
>>extension to OpenPGP to standardize such a thing (i.e. keyID Must
>>Implement, fingerprint Should implement)?  It seems like this would be
>>preferable to me defining my own subpacket type for my specific system...
>>

>In the long term, (2) is a good idea. But it's not just signatures that
>need it. All places where a keyID is used really should move to
>fingerprints. But it's not presently in the scope of this WG to fix all
>of these.

>If you make your own fingerprint subpacket, please use a notation
>subpacket for it.

IMHO I just don't see a need for it anytime in the near future. While
there is the chance for collisions (I think it is greater than your
estimate above) it is quite remote on the client end. It seems to me that
this is mostly a server issue though the client software shouldn't choke
on it.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: OpenPGP key fingerprints and stuff
Date: 13 Sep 1999 13:36:49 GMT
Organization: IKS GmbH Jena
Lines: 7
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* John S. Bucy wrote:
>Someone else suggested that the problem of computing a key pair that has a
>particular key ID is computationally infeasible.

This was never true. Source does exist since months. Natural collisions in
64bit are known to exist.

Date: Sun, 12 Sep 1999 19:33:52 -0700
To: "John S. Bucy" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: OpenPGP key fingerprints and stuff
Cc: [email-masked]
Sender: [email-masked]

At 1:54 PM -0400 9/12/99, John S. Bucy wrote:

>Someone else suggested that the problem of computing a key pair that has a
>particular key ID is computationally infeasible.  I can't really speak to
>this either way but it seems to me like 1: the probability of people
>independentally randomly generating the same key pair (or keypairs with
>identical fingerprints/keyIDs) is quite small and that 2: it would be
>completely impractical for almost anyone (three-letter agencies excluded)
>to try to exploit a system by systematically causing keyID collisions.

Yes, it's computationally infeasible to generate a key with a given keyID.
Or more to the point, if you can do it, you have found a flaw in SHA-1.
Publish it, you'll get kudos.

However, because the keyID is 64 bits long, when there are a total of 4
billion keys (0x1 0000 0000) in the universe, there is a 50% chance that
there is some collision of two keyIDs. These two people will be annoyed,
because all the present implementations assume keyIDs are unique.

>
>
>As far as my particular system goes, it seems like I have two options:
>
>1.  Don't worry about key ID collisions.  Under most circumstances, I
>think that this would probably be ok.
>
>2.  Use a "signer's key fingerprint" signature subpacket and leave the
>keyID packet there and ignore it.  Has the working group considered an
>extension to OpenPGP to standardize such a thing (i.e. keyID Must
>Implement, fingerprint Should implement)?  It seems like this would be
>preferable to me defining my own subpacket type for my specific system...
>

In the long term, (2) is a good idea. But it's not just signatures that
need it. All places where a keyID is used really should move to
fingerprints. But it's not presently in the scope of this WG to fix all of
these.

If you make your own fingerprint subpacket, please use a notation subpacket
for it.

	Jon

Date: Sun, 12 Sep 1999 13:54:29 -0400 (EDT)
From: "John S. Bucy" <[email-masked]>
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: OpenPGP key fingerprints and stuff
Sender: [email-masked]

On Sat, 11 Sep 1999, Jon Callas wrote:

> However, the reason the key ID is used is to be compatible with previous
> implementations. PGP 2 used eight-byte key ids as a handle to look up the
> proper key not only for signatures, but for encrypted data.
> 
> When we started OpenPGP, a number of us, myself included, wanted to take
> the opportunity to clean up a number of things, like existence of key IDs.
> I think that every place a key id is used, it should be a fingerprint
> instead.
> 
> But. We have to be compatible with existing versions of PGP out there. So
> we use key IDs, even though they have all the flaws you mentioned. That's
> the only reason: we do it that way because that's the way we've always done
> it.

Someone else suggested that the problem of computing a key pair that has a
particular key ID is computationally infeasible.  I can't really speak to
this either way but it seems to me like 1: the probability of people
independentally randomly generating the same key pair (or keypairs with
identical fingerprints/keyIDs) is quite small and that 2: it would be
completely impractical for almost anyone (three-letter agencies excluded)
to try to exploit a system by systematically causing keyID collisions.

As far as my particular system goes, it seems like I have two options:

1.  Don't worry about key ID collisions.  Under most circumstances, I
think that this would probably be ok.

2.  Use a "signer's key fingerprint" signature subpacket and leave the
keyID packet there and ignore it.  Has the working group considered an
extension to OpenPGP to standardize such a thing (i.e. keyID Must
Implement, fingerprint Should implement)?  It seems like this would be
preferable to me defining my own subpacket type for my specific system...

later
john

(ps I'm not on the OpenPGP WG mailing list so please cc replies to me)

-------------------------------------------
John Bucy

"My mind is going....I can feeeeeeel it..."

[email-masked]
-------------------------------------------

Date: Sat, 11 Sep 1999 17:25:54 -0700
To: "John S. Bucy" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: OpenPGP key fingerprints and stuff
Sender: [email-masked]

At 4:12 PM -0400 8/30/99, John S. Bucy wrote:

>It would make my code substantially simpler if I could have a "signer's
>key fingerprint" instead.  And as the spec stands, I have to define my own
>subpacket type for it.  Since the ID can be directly derived from the
>fingerprint and they both have distinct, fixed lengths, it seems to me
>like you could unambiguously use either one or the other in the same
>subpacket without any other indication of which it was; if the length is 8
>bytes, its the ID, if its 20 bytes, its the fingerprint. Any thoughts?

You're perceptive, and in my opinion right. I agree with you 100%.

However, the reason the key ID is used is to be compatible with previous
implementations. PGP 2 used eight-byte key ids as a handle to look up the
proper key not only for signatures, but for encrypted data.

When we started OpenPGP, a number of us, myself included, wanted to take
the opportunity to clean up a number of things, like existence of key IDs.
I think that every place a key id is used, it should be a fingerprint
instead.

But. We have to be compatible with existing versions of PGP out there. So
we use key IDs, even though they have all the flaws you mentioned. That's
the only reason: we do it that way because that's the way we've always done
it.

	Jon

From: "Peter lewis" <[email-masked]>
To: <[email-masked]>
Subject: From Firewall to IPSec VPNs
Date: Fri, 10 Sep 1999 11:45:55 +0200
Sender: [email-masked]

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure 
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm

Sorry to post this message on the list.

Thanks