Subject: Chaffing and Winnowing and OpenPGP
From: Bill Stewart <[email-masked]>
To: [email-masked]
Date: Sat, 30 May 1998 04:31:33 -0700

I've been thinking about how to integrate Ron Rivest's
Chaffing & Winnowing algorithms with PGP.  It looks like
I won't have the time to make this precise for the next
few weeks due to travel, but I'd like to bring up the topic and 
suggest some directions.  The problem can be broken into two parts:
- developing a general framework for keyed authentication protocols in OP,
	which can support C&W and other HMAC-like approaches
	so future extensions can be compliant.
- specifically implementing one or more C&W versions,
	such as the original inefficient bit-by-bit version
	or the efficient all-or-nothing block version.

While actually implementing the protocol takes a good bit of work,
it looks like the framework is fairly simple, consisting of
a public- or conventionally-encrypted session key
followed by N {one-pass signature packet, literal data, signature}
for some versions, or possibly a new "authenticated data" packet type,
plus some words up front saying that it's ok and compliant to have
those combinations of pieces.  It's a good opportunity for a section
saying "See, it's just purely authentication - these aren't
the encryption algorithms you're looking for - ".

Implementation at this stage probably should be using
user-defined algorithms rather than an official list.
The all-or-nothing version has several obvious ways to map
to PGP - either a bunch of messages, each signed,
with some of the signatures being bad, 
or one message with N blocks of signed all-or-nothing'd data, some bad.

				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Fri, 29 May 1998 23:57:18 -0700
To: Philip Zimmermann <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: Re: Proposed reason-for-revocation subpacket
Sender: [email-masked]

At 06:17 PM 5/28/98 -0700, Philip Zimmermann wrote:
>   (1 octet of revocation code, N-1 octets of reason string)
...
>   Following the initial octet is an optional string of octets which
>   gives information about the reason for revocation in human-readable
>   form.  The length of this octet string is one less than the size of
>   the subpacket.

Null-terminating the string would be a nice touch; it's not necessary,
since there's a length field, but it would probably reduce accidents,
and it also makes it convenient for tools such as "strings" to find.
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Fri, 29 May 1998 20:38:51 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

The message from Werner Koch was in PGP-MIME format signed with the following
signature:

> -----BEGIN PGP SIGNATURE-----
> Version: GNUPG v0.2.18b (GNU/Linux)
> Comment: This is an alpha version!
>
> owJ4nAFiAZ3+iQFfAwUBNW5l6wNvEbj/PqoLEANNhAUfeHwuqDBk+lqwe2pjVqlqnu8QkwG6
> EifZNeDyaQMK6UVz7/lEisGwvE1v6NXN8Nhzt2gpgH7JQ2s85LePYX7/sAhJPA+qJjzFkCC5
> CeGMWJp6pJilDwmPMWylRCYCbKaSzxv7Cx11AflnWg40t/CHYhODE3AVkr7TjIz0zik272Xt
> FYhR5LM1SuCbgrg8zBFmPZgzrWeaTMK2v2n+75Z4HmycxsIFHR6oKWnr6HKniY88v2R6KpyX
> BtGfGwaWARwdk6BUzGsArxaq1Dcgzw1UvWvEAk6ctflLhvH/my5NRmHJjGLfo6Pjq7pvowdH
> 5NknyYlJESyAlmzaOFdPkcWCsE15KDgDAe8eQ2/v8hUqipU48o+7vQWyf7bW/MhCChaj5mSA
> 8z9qhYaM+bGmEeLvAtj0wqvPcbUlVAi4z7PcgLyLFkyQ1Lq5vYMWsV6rJg==
> =8x3k
> -----END PGP SIGNATURE-----

When you convert to hex, you get:

000000 a3 02 78 9c 01 62 01 9d fe 89 01 5f 03 05 01 35
...

0xa3 is a compressed packet.  PGP-MIME messages should have a signature
packet here.  Also, there is not much point in compressing a signature
packet as it is not compressible.

BTW I saw an encrypted message on coderpunks produced with what I
think is the same software, and the length field in the tag byte of the
symmetrically encrypted packet was a binary 11, which should mean that
there are no length bytes, but in fact there were two length bytes.
Also, the message itself was followed by two spurious bytes of zeros.

Hal

Date: Fri, 29 May 1998 16:52:30 -0700
To: Christoph Moser <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Notation subpacket lengths, other things
Sender: [email-masked]

At 02:13 PM 5/29/98 +0200, Christoph Moser wrote:

   I can't see a subpacket type that could use a 5 octet length.
   
As Tom Zerucha pointed out, the 2-byte length is actually only ~8K. That's
enough for a short letter home, but there are conceivable reasons you'd
want more. In particular, the notation subpacket, which is really a
general-purpose extension subpacket could get to 8K.

I think Hal's point that we *really* need a V5 signature to solve this is
valid, and discussion-stopper to me. It's for OpenPGP V1.1. We'll pick this
up again.

However, I'd like to point out that the there is a need for arbitrarily
long signatures, and thus V5 sigs. The Standalone Signature is designed to
be used for things that are like SPKI or X.509 or PGPticket, which Vinnie
has been designing. It's conceivable that there's a use for a ticket that's
greater than 64K. In any event, I believe it would be a grave error to
*exclude* such a thing from being built solely because of not wanting the
option of a long length field.

In any event, a new signature version is a post-V1 issue.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Subject: Re: does same passphrase = same keys
Date: Fri, 29 May 1998 12:53:42 -0700
From: Noah Salzman <[email-masked]>
To: "joe harlin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

joe harlin ([email-masked]) wrote this on 5/29/98 10:54 AM:

>I am using PGP 5.5.5 freeware from Network Associates.
>
>Will using the same passphrase generate identical keys?
>
>Just as an example, if I generate a key using the passphrase "12345", 
>and then I generate another key using the same passphrase, will the keys 
>be the same?
>
>Thanks!

This is the wrong forum for this type of question.  Check out 
http://pgp.rivertown.net and look for the PGP-USERS list. But, to answer 
your question:

No, every key is different, even if they have the same passphrase.  PGP 
uses different random data each time a key is generated.  It is also 
worth pointing out that every time you encrypt some data, even if it is 
the same data each time, you will get different encrypted output.

  --Noah--

From: "joe harlin" <[email-masked]>
To: [email-masked]
Subject: does same passphrase = same keys
Date: Fri, 29 May 1998 10:54:22 PDT
Sender: [email-masked]

I am using PGP 5.5.5 freeware from Network Associates.

Will using the same passphrase generate identical keys?

Just as an example, if I generate a key using the passphrase "12345", 
and then I generate another key using the same passphrase, will the keys 
be the same?

Thanks!

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

Date: Fri, 29 May 1998 09:52:34 -0400
From: [email-masked]
To: Christoph Moser <[email-masked]>
cc: [email-masked]
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

On Fri, 29 May 1998, Christoph Moser wrote:

> But what I then don't understand : Why does the length-field in a
> subpacket uese the 1-2-5 octet length conventions ?
> 
>    Each subpacket consists of a subpacket header and a body.  The
>    header consists of:
> 
>      - the subpacket length (1,  2, or 5 octets)
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      - the subpacket type (1 octet)
>      - the subpacket specific data
> 
> 
> I can't see a subpacket type that could use a 5 octet length.

The 2 octet length only goes out to 8128.  If you had a longer chunk that
was still less than 64k, since you can't use partial length packets you
would need a 5 octet length packet.  I think a chunk of >8128 would be
abusing something, but the 5 octet packet is there for completeness more
than for practical usage.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 29 May 1998 14:13:00 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

At 15:32 28.05.98 -0400, you wrote:

>Where is the message ammending 5.2.3 which states the v4 Sig packet
>contains:

>...
>  - Hashed subpacket data. (zero or more subpackets)
>  - Two-octet scalar octet count for following unhashed subpacket
>    data.
>  - Unhashed subpacket data. (zero or more subpackets)
>...

But what I then don't understand : Why does the length-field in a
subpacket uese the 1-2-5 octet length conventions ?

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

     - the subpacket length (1,  2, or 5 octets)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     - the subpacket type (1 octet)
     - the subpacket specific data

I can't see a subpacket type that could use a 5 octet length.

    Christoph

-----------------------------------------------------------
Christoph Moser - Student of Computer Science and Business
                  University of Siegen

Email:            [email-masked]
Tel. :            +49 271 71883 
-----------------------------------------------------------
PGP-Key available on request

Date: Fri, 29 May 1998 09:38:22 +0200
From: Werner Koch <[email-masked]>
To: openpgp <[email-masked]>
Subject: Re: Notation subpacket lengths
Mail-Followup-To: openpgp <[email-masked]>
Sender: [email-masked]

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii

[email-masked] writes:

> 64K hashed and 64K unhashed is enough for any description.  If something
> has lots of little stuff exceeding 64k, just make more signature packets,

64k is perfectly okay as this allows us to parse subpackets in memory
- this can't be done for possible huge packets with a 4 byte length
header.  The code to process packets of abitrary length is already
there and implemented for literal data; where it really makes sense.

> Is it only me who thinks a signature packet should be a signature and not
> a document, certificate, or whatever with signature?

You are right.

Werner

--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature

--ikeVEW9yuYc//A+q--

From: MSovanH RelSec <[email-masked]>
To: "'William H. Geiger III'" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Jon Callas <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>
Subject: RE: Notation subpacket lengths
Date: Fri, 29 May 1998 10:52:29 +0700
Sender: [email-masked]

- -----Original Message-----
From:	William H. Geiger III [SMTP:[email-masked]]
.......
>Is it only me who thinks a signature packet should be a signature 
and not
>a document, certificate, or whatever with signature?

I was just thinking the same thing myself.

Just think about those annoying s-mime sigs that are several times 
the
size of the message they are signing due to a bunch of irrelevant 
garbage
being stuffed into them.
.....

[M Sovan H - Rel&Sec]  
I think it makes a sense if the signature packet should be a 
signature, so 
it wouldn't grow up infinitly, but then...
... I'm thinking how to authorize the signature packet itself if it 
is not signed.
Tell me if I'm wrong... 
(Im sorry if what I present here has been dropped before, 
Im new comer in this mailing list, so I didn't follow entire 
discussion that has 
been done).

>>[email-masked] : 62-22-214551 ext 516
>>PGP Fingerprint: F0AB B2B5 06B3 9DAD 2E77  0E4A B9CC 1912 C31E 8152
>>--------------------------------------------------------------------
- ------------

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 28 May 1998 20:57:54 -0500
To: "[email-masked]" <[email-masked]>
Subject: RE: PGPticket
Sender: [email-masked]

In <[email-masked]>, on 05/27/98 
   at 02:09 PM, Vinnie Moscaritolo <[email-masked]> said:

>On 5/27/98, Men from Black Helicopters forced MSovanH RelSec to write:

>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Why don't we create new email-list (milis) as this ietf-open-pgp has 
>> been maintained...
>> I think many of us are interested in your subject. But since not 
>> everybody could co-authoring you... they can know any progress of 
>> your subject.
>> Who will start this milis?
>>

>great idea!, I just did..

>send mail to [email-masked]

>subscribe ietf-pgpticket <yourname> 

Hi,

Sorry for posting this here but I am unable to send any mail to vmeng.com.

It is bouncing my mail with a message about not liking <cr><lf> for end of
line.

   ----- The following addresses had delivery problems -----
<[email-masked]>  (unrecoverable error)

   ----- Transcript of session follows -----
.... while talking to mail.vmeng.com.:
>>> DATA

<<< 500 Syntax error, <cr><lf> not used as end of line
554 <[email-masked]>... Remote protocol error

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 28 May 1998 18:10:50 -0500
To: [email-masked]
Cc: Jon Callas <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

In <[email-masked]>, on 05/28/98 
   at 06:03 PM, [email-masked] said:

>On Thu, 28 May 1998, Jon Callas wrote:

>> Hal writes:
>> 
>> Jon - Unfortunately the signature packet retains a vestige of two
>> byte lengths:

>....

>> It was a big mistake to do this but at the time we weren't anticipating
>> large signatures.  Despite several people reviewing the design no one
>> caught this.
>> 
>> The only solution I see is to define a V5 signature packet format.
>> 
>> Hal

>Actually I don't think it is a mistake.  Signature packets shouldn't be
>allowed to grow to infinity by being stuffed with data that isn't really
>part of the signature information.  Maybe a new literal type (I already
>suggested a nested literal elsewhere), 's' to join 't' and 'b' that could
>hold the information that is not part of the signature, but might be part
> of a meta-certificate.

>64K hashed and 64K unhashed is enough for any description.  If something
>has lots of little stuff exceeding 64k, just make more signature packets,
>with only the mandatory packets in common.

>Is it only me who thinks a signature packet should be a signature and not
>a document, certificate, or whatever with signature?

I was just thinking the same thing myself.

Just think about those annoying s-mime sigs that are several times the
size of the message they are signing due to a bunch of irrelevant garbage
being stuffed into them.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
---------------------------------------------------------------

Date: Thu, 28 May 1998 18:17:44 -0700
To: [email-masked]
From: Philip Zimmermann <[email-masked]>
Subject: Proposed reason-for-revocation subpacket
Cc: [email-masked]
Sender: [email-masked]

Sorry I'm so late in making a suggestion for the list, since it's in the
final call phase.

It seems to me that a key revocation is important enough that people
might want to know why it was revoked.  Especially if it was compromised,
since they might want to be put on notice that an adversary may try to
use the key.  Accordingly, I'd like to propose the following subpacket
type for inclusion in key revocation signatures.

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

Reason for revocation

   (1 octet of revocation code, N-1 octets of reason string)

   This subpacket is used only in key revocation and certification
   revocation signatures.  It describes the reason why the key or
   certificate was revoked.

   The first octet contains a machine-readable code which represents
   the reason for the revocation, from the following list:

       0x00 - No reason specified (key revocations or cert revocations)
       0x01 - Key is superceded (key revocations)
       0x02 - Key material has been compromised (key revocations)
       0x03 - Key is no longer used (key revocations)
       0x20 - User id information is no longer valid (cert revocations)

   Following the initial octet is an optional string of octets which
   gives information about the reason for revocation in human-readable
   form.  The length of this octet string is one less than the size of
   the subpacket.

Date: Thu, 28 May 1998 15:25:10 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: 
Cc: [email-masked]
Sender: [email-masked]

At 11:01 AM 5/27/98 -0400, [email-masked] wrote:
   
   5.8. Marker Packet (Obsolete Literal Packet) (Tag 10)
   
   I would modify this to read:
   
      ...
   
Sorry, we can't. The decision in Washington was that the marker packet is a
constant. You're asking for the equivalent of the "manufacturer id" that
was shot down from OpenPGP and other protocols.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 28 May 1998 18:03:24 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: openpgp <[email-masked]>, pgpticket <[email-masked]>
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

On Thu, 28 May 1998, Jon Callas wrote:

> Hal writes:
> 
> Jon - Unfortunately the signature packet retains a vestige of two
> byte lengths:

...

> It was a big mistake to do this but at the time we weren't anticipating
> large signatures.  Despite several people reviewing the design no one
> caught this.
> 
> The only solution I see is to define a V5 signature packet format.
> 
> Hal

Actually I don't think it is a mistake.  Signature packets shouldn't be
allowed to grow to infinity by being stuffed with data that isn't really
part of the signature information.  Maybe a new literal type (I already
suggested a nested literal elsewhere), 's' to join 't' and 'b' that could
hold the information that is not part of the signature, but might be part 
of a meta-certificate.

64K hashed and 64K unhashed is enough for any description.  If something
has lots of little stuff exceeding 64k, just make more signature packets,
with only the mandatory packets in common.

Is it only me who thinks a signature packet should be a signature and not
a document, certificate, or whatever with signature?

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 23 May 1998 11:07:41 +0200 (CEST)
From: Patrick Feisthammel <[email-masked]>
Reply-To: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Version 4 keystructure 
Sender: [email-masked]

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

Hi!

I'm reading the Draft 03 regarding the key structures and it seams as
if the structure of version 4 keys is not exactly defined.

In 10.1 Transferable Public Keys:

   Each Subkey packet must be followed by at least one Signature
   packet, which should be of the subkey binding signature type, issued
   by the top level key.

   Subkey and Key packets may each be followed by a revocation
   Signature packet to indicate that the key is revoked.

and in 11.1. Key Structures:

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [Subkey Primary-Key-Signature ...]

   A subkey always has a single signature after it that is issued using
   the primary key to tie the two keys together. 

11.1 contradicts 10.1 because it says there is a _single_signature after 
the subkey. But in 10.1 there is _at least one_ signature.

I'm also not sure about the revocation signature, I guess the key
structure is:

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [Subkey Primary-Key-Signature ... 
                  [Subkey revocation signature] ...] 

meaning: 

1. there can be multiple Primary-Key-Signature to a single Subkey

2. after the Primary-Key-Signatures a Subkey revocation signature can
follow.

3. This package sequence (1. and 2.) can be repeated multiple times.

Could someone correct my guess? Please note, that I assume that the
subkey revocation signatures always follow the Primary-Key-Signatures and
therefor the sequence

  Subkey 
  Primary-Key-Signature
  Subkey revocation signature
  Primary-Key-Signature 

is not allowed.

Cheers, Patrick

- ---
 PGP-KeyID: DD934139 ([email-masked])    encrypt mail with PGP if possible
 more about PGP on http://www.rubin.ch/pgp/ (english and german)
 what ist the web of trust? see http://www.rubin.ch/pgp/weboftrust.en.html
 Das Vertrauensnetz von PGP:    http://www.rubin.ch/pgp/weboftrust.de.html

Date: Thu, 28 May 1998 12:50:35 -0700
To: openpgp <[email-masked]>, pgpticket <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

Hal writes:

Date: Thu, 28 May 1998 11:50:06 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Notation subpacket lengths

Jon - Unfortunately the signature packet retains a vestige of two
byte lengths:

   The body of a version 4 Signature Packet contains:

     - One-octet version number (4).

     - One-octet signature type.

     - One-octet public key algorithm.

     - One-octet hash algorithm.

**** - Two-octet scalar octet count for following hashed subpacket
       data.

     - Hashed subpacket data. (zero or more subpackets)

**** - Two-octet scalar octet count for following unhashed subpacket
       data.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multi-precision integers comprising the signature.
       This portion is algorithm specific, as described above.

It was a big mistake to do this but at the time we weren't anticipating
large signatures.  Despite several people reviewing the design no one
caught this.

The only solution I see is to define a V5 signature packet format.

Hal

Date: Thu, 28 May 1998 15:32:53 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: Vinnie Moscaritolo <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

On Thu, 28 May 1998, Jon Callas wrote:

> It's an excellent suggestion. Until a draft or so ago, the total length of
> all subpackets was a two-octet length, so there was no reason for the
> fields here to be longer. Now that the subpacket region can be 4 gig in
> size, this should be expanded. Future generations will thank us.

Where is the message ammending 5.2.3 which states the v4 Sig packet
contains:

     - Two-octet scalar octet count for following hashed subpacket
       data.

     - Hashed subpacket data. (zero or more subpackets)

     - Two-octet scalar octet count for following unhashed subpacket
       data.

     - Unhashed subpacket data. (zero or more subpackets)

Unless I missed something, the hashed can be 64K-1, and unhashed the same.
Note that if you alter this scheme you will break all pgp 5.0 v4 key
signatures.

But to Vinnie Moscaritolo's point - I emailed him that if there is a lot
of data, it should be *OUTSIDE* the signature packet, possibly within a
literal packet, so it can be as long or as short and use any (internal)
format it wants. 

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 28 May 1998 11:17:21 -0700
To: Vinnie Moscaritolo <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Notation subpacket lengths
Sender: [email-masked]

At 10:56 AM 5/28/98 -0800, Vinnie Moscaritolo wrote:

   5.2.3.15. Notation Data
   
          (4 octets of flags, 2 octets of name length (M),
                              2 octets of value length (N),
                              M octets of name data,
                              N octets of value data)
   
   I would like to suggest that the 2 octets lengths be changed to support
   the 1-2-5 octet length conventions used elsewhere in the draft.
   in addition to being more consistant it would allow us to save 
   a some bytes when building up multiple ticket packets..
   
   the downside is can make packet processing a bit more complex, but 
   all implementations of PGP will have code to handle the 1-2-5 lengths
   anyways.
   
   any comments?
   
It's an excellent suggestion. Until a draft or so ago, the total length of
all subpackets was a two-octet length, so there was no reason for the
fields here to be longer. Now that the subpacket region can be 4 gig in
size, this should be expanded. Future generations will thank us.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Thu, 28 May 1998 10:56:00 -0800
From: Vinnie Moscaritolo <[email-masked]>
Subject: Notation subpacket lengths
To: openpgp <[email-masked]>, pgpticket <[email-masked]>
Sender: [email-masked]

I would like to suggest a quick change before the spec is closed.
I would like to use the Notation subpacket to hold information 
for PGPtickets. One of the things that I would like to ammend is
how the lengths work for Notation data and name values..

right now the spec says:

5.2.3.15. Notation Data

       (4 octets of flags, 2 octets of name length (M),
                           2 octets of value length (N),
                           M octets of name data,
                           N octets of value data)

I would like to suggest that the 2 octets lengths be changed to support
the 1-2-5 octet length conventions used elsewhere in the draft.
in addition to being more consistant it would allow us to save 
a some bytes when building up multiple ticket packets..

the downside is can make packet processing a bit more complex, but 
all implementations of PGP will have code to handle the 1-2-5 lengths
anyways.

any comments?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vinnie Moscaritolo
Wordwide Developer Technical Support
N&C/Hardware

Apple Computer, Inc.                      email:  [email-masked]
3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
Cupertino, CA 95014                       fax:        408.862.7602
Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Wed, 27 May 1998 15:59:20 -0800
From: Vinnie Moscaritolo <[email-masked]>
Subject: Re: PGPticket
To: "[email-masked]" <[email-masked]>
Cc: openpgp <[email-masked]>, pgpticket <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

On 5/26/98, Men from Black Helicopters forced [email-masked] to write:

> I don't think the PGPsdk does proper V4 sigs for anything other than keys. 
> Since the format below is close, but not quite the V4 key spec, I would be
> curious about what you have done or are doing, or if PGP has updated
> something in the past few weeks. 

actually I used the  1.5 sdk (part of PGP 6.0) which allows you to do low level 
crypto calls. I worked as the PGPsdk developer support guy for  while and was able
to use that to write my initial tests.  you have to form the packets yoursef.

> My implementation does V4 sigs
> correctly, but it took a long while to figure out why PGP was rejecting my
> signed messages.  FYI, my implementation is a freeware library with full
> source and is at www.cryptography.org in the new directory, moved to the
> libraries occasionally.  The current version is opgp99m, but I already
> have a patch which should appear later this week. It uses zlib and SSLeay,
> and it targeted at Unix, but it compiles for Visual C, and with patches
> for PalmOS3 (though I haven't tested it).
> 

great! this is  the other implementation that I was looking for.

> 
> If this is based on a V4 signature packet, then here and all following
> seem to be missing the subpacket length count byte(s).  This would be 0x05
> just before the 0x82.  The following comments also apply to this (and why
> create something that is 95% like a V4 sig packet but different enough as
> to require new routines)?
> 

yup.. you are correct! I just check out the spec and found the following

5.2.3.1. Signature Subpacket Specification

   The subpacket fields consist of zero or more signature subpackets.
   Each set of subpackets is preceded by a two-octet scalar count of
   the length of the set of subpackets.

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

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

     - the subpacket type (1 octet)

     - the subpacket specific data

> 
> The following byte should be moved further down.  There is a "Should"
> stating that the creation time and issuer ID occur first since these are
> non-optional fields, and it allows a quick finding of the keyid (so that
> the public key can be quickly looked up) instead of having to scan every
> field.

fair enough. 

 > 
> Why 2 octets of name length?  Also, with the (elided) subpacket length
> byte, the length of the string is known.
> 

see 5.2.3.15. Notation Data

       (4 octets of flags, 2 octets of name length (M),
                           2 octets of value length (N),
                           M octets of name data,
                           N octets of value data)

> >           - Eight-octet key ID
> >           - One-octet public key algorithm.
> >           - One octet scaler length count for public Key fingerprint
> >           - N octets public Key fingerprint data
> 
> This is not a good idea.  Keyids are not guaranteed to be unique, and are
> actually the LSBs of the fingerprint for V4 keys, so would be redundant
> here.  The keyid would have to point to the full public key somewhere
> which would have the public key algorithm.
> 

keyid is used for quick lookup of a key only, the FP is used to verify
the key. I would prefer that the fp was used only, and this is an option too.
of course the right thing to do is to transition all openpgp spec refs of keyids
to FPs..

> And why bury this in the signature packet itself?  You can do a V3 style
> sig followed by a literal or compressed, or a v4 onepass where a sig is at
> the end.  

you lost me here?

> Moreover the (entire) public key could be included which would
> eliminate some of the things here.  Though I can see that it would be
> nicer to do everything in a single packet.

this is also a great idea, but there are some cases where a tciket is used 
with a large number of subjects and it might be worth saving a few bytes  by 
not including the keys themselves....

> [protocol deleted]
> 
> If the admin doesn't really verify the key, you might get into man-in-the
> middle attacks.  I send a key request, FakeServer processes it and submits
> a request to Admin, who processes it and returns it to FakeServer.
> FakeServer creates a counterfeit auth pointing to Fakeserver.  Now
> Fakeserver pretends to be the user to the auth, and the auth to the user.
> I haven't looked at this closely, so there may be a check that cannot be
> overcome in the protocol.

agreed, the admin must verify the key before issuing a ticket against it
this is specific to the implementation.. but you are right this is a security
concern..

thanks again for all the feedback, I have enclosed the updated ticket format
below.. I would like to move this discussion to the pgpticket list at
[email-masked]

Updted pgpticket message format

   A PGPticket packet contains:
 
    - Packet Tag
   
     - One-octet version number (4).
     - One-octet  Standalone signature type (2).
     - One-octet public key algorithm.
     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket data.
   
    Certificate validity Information (first half) consisting of:
      - One-octet subpacket length  (5)
        - One-octet signature creation time subpacket type  (82)
        - Four-octet time field
        
    Certificate Issuer Information consisting of:
      - One-octet subpacket length  (9)
        - One-octet signature creation issuer key ID type  (90)
        - Eight-octet key ID

    Certificate validity Information (last half) consisting of:
         - One-octet subpacket length  (5)
        - One-octet signature expiration time subpacket type  (83)
        - Four-octet time field
        
      Certificate Authorization Information consisting of:
      - two or five-octet  subpacket length  (N + 13)
       - One-octet Notation Data subpacket type  (94)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (N),
       - 4 octets of name data    ('AUTH')
       - N octets of authorization string data   

      Certificate Subject Information consisting of:
      - two or five-octet  subpacket length  (N + 13)
       - One-octet Notation Data subpacket type  (94)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (N),
       - 4 octets of name data    ('SUBJ')
         N octets of Subject string data for each subject 
             authorized in this certifcate consisting of
          - Eight-octet key ID
          - One-octet public key algorithm.
          - One octet scaler length count for public Key fingerprint
          - N octets public Key fingerprint data

      Optional Certificate Delegation Information consisting of:
         - One-octet subpacket length  (13)
       - One-octet Notation Data subpacket type  (20)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (0),
       - 4 octets of name data    ('DELG')
    
    - Two-octet scalar octet count for following unhashed subpacket
       data.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multi-precision integers comprising the signature.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vinnie Moscaritolo
Wordwide Developer Technical Support
N&C/Hardware

Apple Computer, Inc.                      email:  [email-masked]
3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
Cupertino, CA 95014                       fax:        408.862.7602
Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Wed, 27 May 1998 15:52:29 -0700
To: Vinnie Moscaritolo <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: PGPticket
Cc: Bill Frantz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 03:25 PM 5/27/98 -0800, Vinnie Moscaritolo wrote:
>On 5/27/98, Men from Black Helicopters forced Tony Bartoletti to write:
>
>> 
>> A minor nit.  See Protocol description, paragraph 5, below.
>> 
>>> >>
>> >>   Server to Client
>> >>   5.  The server checks validity of ticket, which entails
>> >>   verifying the admin signature and expiration date of ticket.
>> >>   The server then generates a random challenge string and
>> >>   sends the challenge to the client requesting that it be
>> >>   signed by the key specified in the ticket.
>> 
>> The recent and timely thread "Key Usage for Authentication and
>> Digital Signature", although X.509-oriented, discusses a possible
>> security problem when a server is able to form a "challenge" to be
>> signed by the auth-requesting client.  Specifically, a nefarious
>> server may trick the client into signing a substantial "message"
>> rather than (say) a random challenge.  Perhaps the protocol could
>> force the challenge to incorporate data supplied, at least in part,
>> by the client as well.
>> 
>> ___tony___
>> 
>
>good point , but read the next paragraph..
>
>
>
>> >>   Client to server
>> >>   6. The client signs and returns the challenge string with a
>> >>   random nonce appended. The server then checks the clients
>> >>   signature and if successful grants access with the
>> >>   authorizations specified in the ticket
>>
>
>
>A client should never sign a challenge on it's own. the challenge should 
>have a client random nonce  appended to it, then sign that. the nonce
>can in fact be used as a counter challenge for the server to sign (whereby
>it also attaches a random nonce)

Vinnie,  You are absolutely right.  I was led astray by the wording of 6:

  "The client signs and returns the challenge string with a
  random nonce appended."

At a glance, one could interpret this to mean "signs the challenge string"
and _then_ appends a random nonce.  This would service the needs of a
counter challenge as well, but was not what you meant.  Perhaps the words

  "The client appends a random nonce to the challenge string, and then
   signs the string and returns it to the server."

would have made it more clear.

Thanks.

____tony____
 
>the Server generates a random string of bytes that are at least as long as
the 
>challenged key's hash size,  this is sent to the client along with the key
fingerprint.
>
>S: KeyFP:Challenge
>
>The client looks up it's key database to see if it has a key that matches
that fp.
>It takes a hash of the challenge string, it thens generates another random
string
> of (hash size) and continues to hash  that.. it then calculates  a
signature for 
> the hash and the given key...  the clients random string and the sig is
sent to the 
> server.
> 
>C: Counterchallenge:Sig
>
> the server takes a hash of it's original challenge, continues with the 
> nonce string and calculates a sig also. the two sigs are then compared..
> if they are valid, the server then creates another random string and
> hashes that plus the clients nonce and signs that. this is sent to the 
> cleint
> 
> S: serverNonce:serverSig
> 
> the client can then perform a check for server validity...
> 
> this is why I want to write this as a real spec..
> 
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Vinnie Moscaritolo
>Wordwide Developer Technical Support
>N&C/Hardware
>
>Apple Computer, Inc.                      email:  [email-masked]
>3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
>Cupertino, CA 95014                       fax:        408.862.7602
>Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Date: Wed, 27 May 1998 15:25:17 -0800
From: Vinnie Moscaritolo <[email-masked]>
Subject: Re: PGPticket
To: Tony Bartoletti <[email-masked]>, openpgp <[email-masked]>, pgpticket <[email-masked]>
Cc: Bill Frantz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

On 5/27/98, Men from Black Helicopters forced Tony Bartoletti to write:

> 
> A minor nit.  See Protocol description, paragraph 5, below.
> 
>> >>
> >>   Server to Client
> >>   5.  The server checks validity of ticket, which entails
> >>   verifying the admin signature and expiration date of ticket.
> >>   The server then generates a random challenge string and
> >>   sends the challenge to the client requesting that it be
> >>   signed by the key specified in the ticket.
> 
> The recent and timely thread "Key Usage for Authentication and
> Digital Signature", although X.509-oriented, discusses a possible
> security problem when a server is able to form a "challenge" to be
> signed by the auth-requesting client.  Specifically, a nefarious
> server may trick the client into signing a substantial "message"
> rather than (say) a random challenge.  Perhaps the protocol could
> force the challenge to incorporate data supplied, at least in part,
> by the client as well.
> 
> ___tony___
> 

good point , but read the next paragraph..

> >>   Client to server
> >>   6. The client signs and returns the challenge string with a
> >>   random nonce appended. The server then checks the clients
> >>   signature and if successful grants access with the
> >>   authorizations specified in the ticket
>

A client should never sign a challenge on it's own. the challenge should 
have a client random nonce  appended to it, then sign that. the nonce
can in fact be used as a counter challenge for the server to sign (whereby
it also attaches a random nonce)

to be specific:

the Server generates a random string of bytes that are at least as long as the 
challenged key's hash size,  this is sent to the client along with the key fingerprint.

S: KeyFP:Challenge

The client looks up it's key database to see if it has a key that matches that fp.
It takes a hash of the challenge string, it thens generates another random string
 of (hash size) and continues to hash  that.. it then calculates  a signature for 
 the hash and the given key...  the clients random string and the sig is sent to the 
 server.
 
C: Counterchallenge:Sig

 the server takes a hash of it's original challenge, continues with the 
 nonce string and calculates a sig also. the two sigs are then compared..
 if they are valid, the server then creates another random string and
 hashes that plus the clients nonce and signs that. this is sent to the 
 cleint
 
 S: serverNonce:serverSig
 
 the client can then perform a check for server validity...
 
 this is why I want to write this as a real spec..

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vinnie Moscaritolo
Wordwide Developer Technical Support
N&C/Hardware

Apple Computer, Inc.                      email:  [email-masked]
3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
Cupertino, CA 95014                       fax:        408.862.7602
Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Wed, 27 May 1998 14:18:01 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Algorithm preferences
Sender: [email-masked]

I have a request to amend the language in 12.1.

Here is the problem:

An implementor wants to be interoperable with PGP 2.6.x and OpenPGP. As you
know, there is a problem that arises that PGP 2.6.x is (usually) IDEA-only,
but OP mandates 3DES.

If a user wants to send a message to someone who uses OP, and 2.6, there's
a no-win there. Section 12.1 says:

   An implementation that is striving for backwards compatibility MAY
   consider a V3 key with a V3 self-signature to be an implicit
   preference for IDEA, and no ability to do TripleDES. This is
   technically non-compliant, so if an implementation is forming a
   message to be read by a V3 keyholder and a V4 keyholder that does
   not speak IDEA, the implementation must somehow break this up into
   two messages (which is relatively easy to do for email), or issue an
   error message when this is not possible.

It turns out that this is sometimes easier said than done.

Does anyone object to changing this to:

   An implementation that is striving for backwards compatibility MAY
   consider a V3 key with a V3 self-signature to be an implicit
   preference for IDEA, and no ability to do TripleDES. This is
   technically non-compliant and depredcated, but an implementation MAY 
   use either IDEA or TripleDES for interoperability in this situation.

	Jon

   

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 27 May 1998 12:25:35 -0700 (PDT)
From: Yahya Al-Salqan <[email-masked]>
Reply-To: Yahya Al-Salqan <[email-masked]>
Subject: Call for participation (FYI)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Content-MD5: SCk4v9pjCPXd6BFIFnKHgg==
Sender: [email-masked]

Today is the deadline for the early registration ... take advantage of it.

My appology if you receive this e-mail more than once!

 =================================================
                Call for Participation:

                  IEEE  WET ICE '98
            Third International Workshop
                         on
                 Enterprise Security

          Stanford University, Palo Alto, USA
                   June 17-19 1998
 =================================================

On behalf of the Workshop Program and Organizing Committees, I would like to 
invite you to participate in The 3rd IEEE International Enterprise Security 
Workshop will be held June 17-19, Stanford University, Palo Alto, California.  
The Workshop includes paper presentations, panel discussions, keynote speeches 
and invited talks covering all aspects of enterprise security.  Topics to be 
covered include: Public key infrastructure, intrusion detection, Web security, 
application security (e.g. digital library and healthcare), and access control.   

Highlights of the program:
	o Keynote speech by Dr. Li Gong, Java Security Architect, Sun 			
          Microsystems;
	o Industrial security expertise from: Microsoft NT security 		 
          group, Sun Microsystems, Entrust, Certicom, Verisign, SSH 				
          Communication security and many others.  It is an unprecedented 				
          opportunity to put all these companies in one room.  Don't miss it.
	o Participation of IETF security group leaders;  
	o Participation of NSA (National Security Agency);
	o Two panel discussions:
		- "State-of-the-art Enterprise Security: Practice and Future"
		- "Intrusion Detection: Present and Future"
	o Workshop held in conjunction with other WETICE workshops: 	
		"Web-based infrastructure for collaborative 			
		  Enterprises," 
		"Collaboration in Presence of Mobility," 
	
	o Two social events.

The Workshop Preliminary program can be found at:					
	http://www.ida.liu.se/labs/iislab/SECWK/agenda.html

The Registration form can be found at:
	http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html
	(Please mark the Enterprise Security on the registration form)
	
The Workshop main page can be found at:
	http://www.ida.liu.se/labs/iislab/SECWK/
		
I look forward to meeting you at the Workshop. 

Sincerely,

Yahya Al-Salqan, Ph.D.
Workshop General Chair
Sun Microsystems

------------- End Forwarded Message -------------

------------- End Forwarded Message -------------

Date: Wed, 27 May 1998 12:04:05 -0700
From: Kurt Stammberger <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RSA'99 Deadline
Sender: [email-masked]

Dave's NDSS note reminded me to remind y'all:

D E A D L I N E !        D E A D L I N E !

The Deadline for talk proposals for RSA'99 is SIX DAYS AWAY (June 1st). 
For more information, or to propose a talk or submit a paper for
presentation, visit www.rsa.com/conf99

Questions?  E-mailez-moi.

Kurt Stammberger
Conference Director 
RSADSI

Date: Wed, 27 May 1998 11:09:07 -0800
From: Vinnie Moscaritolo <[email-masked]>
Subject: RE: PGPticket
To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

On 5/27/98, Men from Black Helicopters forced MSovanH RelSec to write:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Why don't we create new email-list (milis) as this ietf-open-pgp has 
> been maintained...
> I think many of us are interested in your subject. But since not 
> everybody could co-authoring you... they can know any progress of 
> your subject.
> Who will start this milis?
>

great idea!, I just did..

send mail to [email-masked]

subscribe ietf-pgpticket <yourname> 

Vinnie Moscaritolo
------------------
http://www.vmeng.com/vinnie/
DSS/DH:   3F903472C3AF622D5D918D9BD8B100090B3EF042

"If ye love wealth greater than liberty, the tranquility of servitude
greater than the animating contest for freedom, go home from us in peace.
We seek not your counsel, nor your arms. Crouch down and lick the hand that
feeds you. May your chains set lightly upon you; and may posterity forget
that ye were our countrymen."    -- Samuel Adams

Date: Wed, 27 May 1998 11:01:26 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

5.8. Marker Packet (Obsolete Literal Packet) (Tag 10)

   An experimental version of PGP used this packet as the Literal
   packet, but no released version of PGP generated Literal packets
   with this tag. With PGP 5.x, this packet has been re-assigned and is
   reserved for use as the Marker packet.

   The body of this packet consists of:

     - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).

   Such a packet MUST be ignored when received.  It may be placed at
   the beginning of a message that uses features not available in PGP
   2.6.x in order to cause that version to report that newer software
   is necessary to process the message.

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

I would modify this to read:

   ...

|  The body of this packet contains:

     - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
|
|  Which may be followed by other UTF-8 characters which implementations
|  MUST ignore, but MAY append for use as a comment.

   ...

The reason for this is that I don't want anyone requiring the length be
exactly 3, so this marker packet could be used to indicate which
implementation created the message or other information, e.g.

0xa8, strlen, "PGP OpenPrivacy v0.9"
0xa8, strlen, "PGP OPGP Beta 99m"

Much like ascii armor contains.

I want to leave the "PGP" at the beginning so that it functions as an
identifier, i.e. 0xa8 xx 'P' 'G' 'P' could be used to find PGP files.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Wed, 27 May 1998 08:52:07 -0400
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99)
Cc: [email-masked]
Sender: [email-masked]

--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"

--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"

	    C  A  L  L       F  O  R       P  A  P  E  R  S

			  The Internet Society
	1999 Network and Distributed System Security Symposium
			       (NDSS'99)

Where: Catamaran Resort, San Diego, California
When: February 3-5, 1999

GOAL: The symposium will foster information exchange among hardware and
  software developers of network and distributed system security
  services.  The intended audience includes those who are interested in
  the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable the
  Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium will
  be published by the Internet Society.

  Topics for the symposium include, but are not limited to, the
  following:

* Security in malleable systems: mobile code, mobile agents, active
  networks, dynamic policy updates, etc.
* Special problems: e.g. interplay between security goals and other
  goals such as efficiency, usability, reliability, interoperability,
  resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies --
  very large systems, e.g., the Internet, high-speed systems, e.g., the
  gigabit testbeds, wireless systems, personal communication systems,
  and large-scale, heterogeneous distributed systems.

* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, archie, and WAIS.
* Electronic commerce: payment services, fee-for-access, EDI, notary
  services; endorsement, licensing, bonding, and other forms of
  assurance; rights management and other forms of intellectual property
  protection
* Implementation and management of network security policy 
* Security for voice over IP
* Security for routing

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CHAIRS:
  Stephen Kent, BBN Technologies
  Gene Tsudik, USC/Information Sciences Institute

TUTORIAL CHAIR:
  Doug Maughan, National Security Agency

PROGRAM COMMITTEE:
  David Balenson, TIS Labs at Network Associates
  Steve Bellovin, AT&T Labs -- Research
  Matt Bishop, University of California at Davis
  Bob Blakley, IBM
  Doug Engert, Argonne National Laboratories
  Warwick Ford, VeriSign
  Li Gong, Sun Microsystems
  Rich Graveman, Bellcore
  Ari Juels, RSA Laboratories
  Tom Longstaff, CERT
  Doug Maughan, National Security Agency
  Dan Nessett, 3Com Corporation
  Michael Roe, Cambridge University
  Jeffrey Schiller, MIT
  Wolfgang Schneider, GMD Darmstadt
  Christoph Schuba, Purdue University
  Win Treese, Open Market
  Jonathan Trostle, Cisco

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: The committee invites technical papers and panel proposals,
  for topics of technical and general interest.  Technical papers should
  be 10-20 pages in length.  Panel proposals should be two pages and
  should describe the topic, identify the panel chair, explain the
  format of the panel, and list three to four potential panelists.
  Technical papers will appear in the proceedings.  A description of
  each panel will appear in the proceedings, and may at the discretion
  of the panel chair, include written position statements from each
  panelist.

  Each submission must contain a separate title page with the type of
  submission (paper or panel), the title or topic, the names of the
  author(s), organizational affiliation(s), telephone and FAX numbers,
  postal addresses, Internet electronic mail addresses, and must list a
  single point of contact if more than one author.  The names of authors,
  affiliations, and other identifying information should appear only on
  the separate title page.

  Submissions must be received by 31 July 1998, and must be made via
  electronic mail in either PostScript or ASCII format.  If the
  committee is unable to print a PostScript submission, it will be
  returned and hardcopy requested.  Therefore, PostScript submissions
  must arrive well before 31 July.

  All submissions and program related correspondence (only) should be
  directed to the program chair:  
	Stephen Kent
	c/o BBN Technologies
	70 Fawcett Street
	Cambridge, Mass. 02138
	Email:[email-masked]
	Phone: +1 (617) 873-1996
	FAX: +1 (617) 873-4086

  Dates, final call for papers, advance program, and registration
  information will be available at the URL: http://www.isoc.org/ndss99.

  Each submission will be acknowledged by e-mail.  If acknowledgment is
  not received within seven days, please contact the program chair as
  indicated above.  Authors and panelists will be notified of acceptance
  by 18 September 1998.  Instructions for preparing camera-ready copy
  for the proceedings will be sent at that time.  The camera-ready copy
  must be received by 16 October 1998.

--=====================_896287927==_
Content-Type: text/plain; charset="us-ascii"

----------------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363
--=====================_896287927==_--

From: MSovanH RelSec <[email-masked]>
To: "'Vinnie Moscaritolo'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: PGPticket
Date: Wed, 27 May 1998 10:31:03 +0700
Sender: [email-masked]

Why don't we create new email-list (milis) as this ietf-open-pgp has 
been maintained...
I think many of us are interested in your subject. But since not 
everybody could co-authoring you... they can know any progress of 
your subject.
Who will start this milis?

- -----Original Message-----
From:	Vinnie Moscaritolo [SMTP:[email-masked]]
Sent:	Wednesday, May 27, 1998 7:20 AM
To:	[email-masked]
Subject:	PGPticket

I am looking for someone to help me co-author the PGPticket Internet 
draft.
PGPtickets are SPKI authentication certs represented as an OpenPGP
standalone signature packets. This allows us to represent SPKI 
packets in 
a form that most PGP implemenations can process. 

The authetication certs are a powerful tool, and this might be a way 
to
get the best of the SPKI into a form that PGP users can do something 
with.

In order to test out this concept I have even built some code
with the PGPsdk that I would lov eto make public,  but would like to 
write up the message format as an ietf draft... 

being that I don't have much experience writting these documents, I
am seeking (a) partner(s) who is intersted in helping out with the 
draft. 

    PGPticket is a lightweight but very secure authorization protocol
   based on the OpenPGP Message Format and SPKI structure. PGPticket
   is designed to control access of services over a public network by
   granting and transfering user privileges through authorization 
   certificates signed with strong public key cryptography.

   A PGPticket packet contains:
 
    - Packet Tag
   
     - One-octet version number (4).
     - One-octet  Standalone signature type (2).
     - One-octet public key algorithm.
     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket 
data.
   
      Certificate validity Information consisting of:
        - One-octet signature creation time subpacket type  (82)
        - Four-octet time field
        - One-octet signature expiration time subpacket type  (83)
        - Four-octet time field
     
      Certificate Issuer Information consisting of:
        - One-octet signature creation issuer key ID type  (90)
       - Eight-octet key ID
      
      Certificate Authorization Information consisting of:
        - One-octet Notation Data subpacket type  (94)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (N),
       - 4 octets of name data    ('AUTH')
       - N octets of authorization string data   

      Certificate Subject Information consisting of:
        - One-octet Notation Data subpacket type  (94)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (N),
       - 4 octets of name data    ('SUBJ')
         N octets of Subject string data for each subject 
             authorized in this certifcate consisting of
          - Eight-octet key ID
          - One-octet public key algorithm.
          - One octet scaler length count for public Key fingerprint
          - N octets public Key fingerprint data

      Optional Certificate Delegation Information consisting of:
        - One-octet Notation Data subpacket type  (20)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (0),
       - 4 octets of name data    ('DELG')
    
    - Two-octet scalar octet count for following unhashed subpacket
       data.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multi-precision integers comprising the signature.

Below is a brief overview of the PGPticket Protocol

   1.  The user requests server access from the system admin
   (possibly a verbal request). The user either provides a copy
   of his public key or makes the key available on common
   key-server. The Admin verifies the validity of this key.

   2.  The administrator generates the PGPticket with
   appropriate authorizations and validity information, signing
   the ticket with the server admin key. The ticket is either
   posted in a public place or sent by email to the user.

   3.  The user retrieves the PGPticket and stores it in a local
   ticket database.

   Client to server
   4.  The user attempts to access a network service, the client
   searches its ticket database for any tickets pertaining to
   the server, and sends a copy of the tickets along with the
   access request.

   Server to Client
   5.  The server checks validity of ticket, which entails
   verifying the admin signature and expiration date of ticket.
   The server then generates a random challenge string and
   sends the challenge to the client requesting that it be
   signed by the key specified in the ticket.

   Client to server
   6. The client signs and returns the challenge string with a
   random nonce appended. The server then checks the clients
   signature and if successful grants access with the
   authorizations specified in the ticket

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vinnie Moscaritolo
Wordwide Developer Technical Support
N&C/Hardware

Apple Computer, Inc.                      email:  [email-masked]
3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
Cupertino, CA 95014                       fax:        408.862.7602
Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Tue, 26 May 1998 16:19:55 -0800
From: Vinnie Moscaritolo <[email-masked]>
Subject: PGPticket
To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

I am looking for someone to help me co-author the PGPticket Internet draft.
PGPtickets are SPKI authentication certs represented as an OpenPGP
standalone signature packets. This allows us to represent SPKI packets in 
a form that most PGP implemenations can process. 

The authetication certs are a powerful tool, and this might be a way to
get the best of the SPKI into a form that PGP users can do something with.

In order to test out this concept I have even built some code
with the PGPsdk that I would lov eto make public,  but would like to 
write up the message format as an ietf draft... 

being that I don't have much experience writting these documents, I
am seeking (a) partner(s) who is intersted in helping out with the draft. 

    PGPticket is a lightweight but very secure authorization protocol
   based on the OpenPGP Message Format and SPKI structure. PGPticket
   is designed to control access of services over a public network by
   granting and transfering user privileges through authorization 
   certificates signed with strong public key cryptography.

   A PGPticket packet contains:
 
    - Packet Tag
   
     - One-octet version number (4).
     - One-octet  Standalone signature type (2).
     - One-octet public key algorithm.
     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket data.
   
      Certificate validity Information consisting of:
        - One-octet signature creation time subpacket type  (82)
        - Four-octet time field
        - One-octet signature expiration time subpacket type  (83)
        - Four-octet time field
     
      Certificate Issuer Information consisting of:
        - One-octet signature creation issuer key ID type  (90)
       - Eight-octet key ID
      
      Certificate Authorization Information consisting of:
        - One-octet Notation Data subpacket type  (94)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (N),
       - 4 octets of name data    ('AUTH')
       - N octets of authorization string data   

      Certificate Subject Information consisting of:
        - One-octet Notation Data subpacket type  (94)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (N),
       - 4 octets of name data    ('SUBJ')
         N octets of Subject string data for each subject 
             authorized in this certifcate consisting of
          - Eight-octet key ID
          - One-octet public key algorithm.
          - One octet scaler length count for public Key fingerprint
          - N octets public Key fingerprint data

      Optional Certificate Delegation Information consisting of:
        - One-octet Notation Data subpacket type  (20)
       - 4 octets of flags        (0)
       - 2 octets of name length  (4)
       - 2 octets of value length (0),
       - 4 octets of name data    ('DELG')
    
    - Two-octet scalar octet count for following unhashed subpacket
       data.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multi-precision integers comprising the signature.

Below is a brief overview of the PGPticket Protocol

   1.  The user requests server access from the system admin
   (possibly a verbal request). The user either provides a copy
   of his public key or makes the key available on common
   key-server. The Admin verifies the validity of this key.

   2.  The administrator generates the PGPticket with
   appropriate authorizations and validity information, signing
   the ticket with the server admin key. The ticket is either
   posted in a public place or sent by email to the user.

   3.  The user retrieves the PGPticket and stores it in a local
   ticket database.

   Client to server
   4.  The user attempts to access a network service, the client
   searches its ticket database for any tickets pertaining to
   the server, and sends a copy of the tickets along with the
   access request.

   Server to Client
   5.  The server checks validity of ticket, which entails
   verifying the admin signature and expiration date of ticket.
   The server then generates a random challenge string and
   sends the challenge to the client requesting that it be
   signed by the key specified in the ticket.

   Client to server
   6. The client signs and returns the challenge string with a
   random nonce appended. The server then checks the clients
   signature and if successful grants access with the
   authorizations specified in the ticket

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vinnie Moscaritolo
Wordwide Developer Technical Support
N&C/Hardware

Apple Computer, Inc.                      email:  [email-masked]
3 Infinite Loop, MS: 303-2T               phone:      408.974.5560
Cupertino, CA 95014                       fax:        408.862.7602
Fingerprint:     0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Sat, 23 May 1998 11:07:41 +0200 (CEST)
From: Patrick Feisthammel <[email-masked]>
Reply-To: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Version 4 keystructure 
Sender: [email-masked]

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

Hi!

I'm reading the Draft 03 regarding the key structures and it seams as
if the structure of version 4 keys is not exactly defined.

In 10.1 Transferable Public Keys:

   Each Subkey packet must be followed by at least one Signature
   packet, which should be of the subkey binding signature type, issued
   by the top level key.

   Subkey and Key packets may each be followed by a revocation
   Signature packet to indicate that the key is revoked.

and in 11.1. Key Structures:

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [Subkey Primary-Key-Signature ...]

   A subkey always has a single signature after it that is issued using
   the primary key to tie the two keys together. 

11.1 contradicts 10.1 because it says there is a _single_signature after 
the subkey. But in 10.1 there is _at least one_ signature.

I'm also not sure about the revocation signature, I guess the key
structure is:

           Primary-Key
              [Revocation Self Signature]
              [Direct Key Self Signature...]
               User ID [Signature ...]
              [User ID [Signature ...] ...]
              [Subkey Primary-Key-Signature ... 
                  [Subkey revocation signature] ...] 

meaning: 

1. there can be multiple Primary-Key-Signature to a single Subkey

2. after the Primary-Key-Signatures a Subkey revocation signature can
follow.

3. This package sequence (1. and 2.) can be repeated multiple times.

Could someone correct my guess? Please note, that I assume that the
subkey revocation signatures always follow the Primary-Key-Signatures and
therefor the sequence

  Subkey 
  Primary-Key-Signature
  Subkey revocation signature
  Primary-Key-Signature 

is not allowed.

Cheers, Patrick

- ---
 PGP-KeyID: DD934139 ([email-masked])    encrypt mail with PGP if possible
 more about PGP on http://www.rubin.ch/pgp/ (english and german)
 what ist the web of trust? see http://www.rubin.ch/pgp/weboftrust.en.html
 Das Vertrauensnetz von PGP:    http://www.rubin.ch/pgp/weboftrust.de.html

From: "William H. Geiger III" <[email-masked]>
Date: Thu, 21 May 1998 15:25:33 -0500
To: [email-masked]
Subject: Procedures for updating RFC
Sender: [email-masked]

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

Hi,

As it seems that we are comming close to finishing the openPGP spec. I
think now is a good time to establish a mechanism for updating openPGP.

As time goes on there will be users who will wish to add support for other
algorithms. We should have a mechanism in place where ID's and reference
information on these new algorithms can be added in a painless manner.

Hopefully we can come up with a way to add new algorithms quickly without
having to go through the long process of issuing a new RFC and yet have
some type of review process to keep out the snake-oil.

A formalized paper on how a new algorithm can be added to the RFC, what
information is required, and who has the authority on approving/rejecting
application for a new algorithm.

Timelyness seems important in this matter. IMHO the adding of new
functionality should not take 6mo - 1yr to process. :)

Also has anyone though of creating a test suite that potential openPGP
integrators could use to insure that they meet the minimum requirements of
the openPGP RFC?

Such a suite should be two part:

1st part would be a collection of openPGP messages that a compliant
program would need to process.

2nd part would be a binary that would process a collection of openPGP
messages generated by the application and would pass/fail the message
generation.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: OS/2: Your brain.  Windows: Your brain on drugs.

Date: Wed, 20 May 1998 14:23:24 -0700
To: Paul Hoffman / IMC <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Specs & Planks
Cc: [email-masked]
Sender: [email-masked]

At 01:06 PM 5/20/98 -0700, Paul Hoffman / IMC wrote:
   Jon:
   
   If you want, you can send me the diff file whenever you feel like it and I
   can put it on the WG home page.
   
Thanks, Paul.

I have a question though -- how useful would diffs be, or should I just put
out another draft, say late next week (or even late this week)? Right now,
we have the cluster I did yesterday, and a couple now. I'm doing a
spell/grammar check which has gotten a few typos, a few misplaced commas, a
few awkward sentences I feel I must reword, and a number of 'which's that
should be 'that's. 

Also, would it be better to make the diffs on the source document (which is
in a markup language) or the resultant? The resultant will have false
differences the first time a page break changes, but the source doesn't
have things like section numbers in it.

This is why it might just be better to put out another draft.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 20 May 1998 13:06:40 -0700
To: Jon Callas <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Specs & Planks
Cc: [email-masked]
Sender: [email-masked]

At 03:25 PM 5/20/98 -0400, [email-masked] wrote:
>If I can make one other suggestion, tack this on to a running diff
>message, and post that once or twice a week, or upload it to the ietf
>site as drafts...03-errata or whatever.

Jon:

If you want, you can send me the diff file whenever you feel like it and I
can put it on the WG home page.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 20 May 1998 15:25:51 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Specs & Planks
Sender: [email-masked]

On Wed, 20 May 1998, Jon Callas wrote:

> At 10:18 AM 5/20/98 -0400, [email-masked] wrote:
> 
>    Shouldn't this be 17 = DSA
>    
>    Replace "V3 format" with "the V3 keyid"
>    
>    Delete.  This is not true - the "compressed" packet was on uncompressable
>    data, so appeared as "plaintext".  If you check the compressed header, it
>    says the correct number of bytes follow.
>    
>    * If an implemtation is using zlib
>    spell check implementation.
>    
> All of these are fixed. Thank you, Tom. They're simple and obvious changes,
> so I'm not sending any further diffs.

If I can make one other suggestion, tack this on to a running diff
message, and post that once or twice a week, or upload it to the ietf
site as drafts...03-errata or whatever.

If there are lots of tiny changes, they can accumulate and get lost.

Date: Wed, 20 May 1998 12:08:12 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: spelling and grammar checking
Sender: [email-masked]

I'm running a spelling/grammar checker over the draft. Thank you for not
wanting diffs sent to the list. :-)

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 20 May 1998 11:29:51 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Specs & Planks
Cc: [email-masked]
Sender: [email-masked]

At 10:18 AM 5/20/98 -0400, [email-masked] wrote:

   Shouldn't this be 17 = DSA
   
   Replace "V3 format" with "the V3 keyid"
   
   Delete.  This is not true - the "compressed" packet was on uncompressable
   data, so appeared as "plaintext".  If you check the compressed header, it
   says the correct number of bytes follow.
   
   * If an implemtation is using zlib
   spell check implementation.
   
All of these are fixed. Thank you, Tom. They're simple and obvious changes,
so I'm not sending any further diffs.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Wed, 20 May 1998 10:18:28 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Specs & Planks
Sender: [email-masked]

11.2, 
	a.3)
		d)
			..."7 = DSA"

Shouldn't this be 17 = DSA

---

14.

* PGP5.0 can read an RSA key in V4 format, but will only recognize it
  using V3 format.

Replace "V3 format" with "the V3 keyid"

---

* PGP 2.6.x and PGP 5.0 sometimes add to the beginning of a file a
  zero-length compressed data packet.

Delete.  This is not true - the "compressed" packet was on uncompressable
data, so appeared as "plaintext".  If you check the compressed header, it
says the correct number of bytes follow.

---

* If an implemtation is using zlib
spell check implementation.

Date: Tue, 19 May 1998 23:26:58 -0400
From: [email-masked]
Reply-To: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Fixes to draft 03
Sender: [email-masked]

On Tue, 19 May 1998, Jon Callas wrote:

> Do we really want to do this? Yes, it's a break with the past, but it's
> also an opportunity to really deprecate MD5.
> 
> Opinions? I'm in a quandry.
> 
> 	Jon

I like Hal Finney's reply - Depricate a lack of a Hash: header (except
for the specific case of 2.6.2 backwards compatibility, where you would
also want a V3 RSA signing key and V3 signature packet).

The problem is there are lots of old messages, e.g. archived at Deja News,
not to mention in my mail folders that are of 2.6.2 vintage.  Having a
onepass signature capability on the would be a good thing, but it would
require either doing both MD5 and SHA1 hashes when no Hash: header is
present, or trying one, and rewinding and doing the other if we picked the
wrong one.  And current implementations that I know of all use Hash: SHA1
when they mean SHA1.

Date: Tue, 19 May 1998 19:23:38 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Fixes to draft 03
Cc: [email-masked]
Sender: [email-masked]

Maybe we could deprecate the practice of not including an explicit hash
specifier in clearsigned messages.  This would then only be done by
pre-OpenPGP versions.  OpenPGP versions would always include an explicit
hash algorithm.

Then since the deprecated practice only occurs on pre openpgp versions
we could say to assume md5 in that case, for backwards compatibility,
similar to what we do with symmetrically encrypted packets.  This sends
the message that we don't want to prolong the misery of md5 while still
making it work with the old PGP messages out there.

Hal

Date: Tue, 19 May 1998 18:12:57 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Fixes to draft 03
Cc: [email-masked]
Sender: [email-masked]

At 06:38 PM 5/19/98 -0400, [email-masked] wrote:

   In short, if there are no headers, where it says
   
   	SHA-1 is used
   
   that should be changed to (for 2.6.2 style compatibility)
   
   	MD5 is assumed
   
Do we really want to do this? Yes, it's a break with the past, but it's
also an opportunity to really deprecate MD5.

Opinions? I'm in a quandry.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 19 May 1998 16:18:12 -0700
To: [email-masked] (Axel H. Horns), [email-masked]
From: Steve Schear <[email-masked]>
Subject: Re: Legal issues in implementing OpenPGP
Sender: [email-masked]

At 10:00 PM +0100 5/19/98, Axel H. Horns wrote:
>On  9 May 98 at 9:29, Steve Schear wrote:
>
>> The issue of applicable patents opens up the topic of locations
>> where these patents are and are not enforceable.  After discussions
>> with several well-known crypto developers, its my understanding that
>> a number of countries (e.g., Australia, New Zealand and South
>> Africa) do not recognize algorithmic patents.  This would seem to
>> give a considerable advanage to companies from these locations
>> fielding OpenPGP products.  This might apply whether or not their
>> customers were in countries which did recognize the patents, other
>> than major corporations which are nearly always 'good citizens',
>> since enforcement of patent infringement against end-users is
>> considered impractical.
>
>You should not misunderstand that issue. If in a particular
>jurisdiction *algortithms* cannot be subject-matter of a patent claim
>this does not mean that you can't infringe a particular patent by
>loading a piece of software into a computer.

What I'm saying is that the infringement, if there is one, will occur at
the user's end where (especially if the software is for personal use)
effectively unenforceable.  I don't believe that storing the software on a
server disk (especially in a non-executable format), not in the RAM as an
application which is in execution, is covered by U.S. and international
patents, since it not reduced to a tangible form upon which the 'hardware'
implementations are based.

--Steve

---------------------------------------------------------------------
		reply to schear - at - lvcm - dot - com ---

PGP mail preferred, see  	http://www.pgp.com and
				http://web.mit.edu/network/pgp.html

RSA fingerprint: FE90 1A95 9DEA 8D61  812E CCA9 A44A FBA9
RSA key: http://keys.pgp.com:11371/pks/lookup?op=index&search=0x55C78B0D
---------------------------------------------------------------------

Date: Tue, 19 May 1998 18:38:44 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Fixes to draft 03
Sender: [email-masked]

In section 7:

   If the "Hash" armor header is given, the specified message digest
   algorithm is used for the signature. If there are no such headers,
   SHA-1 is used. If more than one message digest is used in the
   signature, the "Hash" armor header contains a comma-delimited list
   of used message digests.

Should be changed to:

   If the "Hash" armor header is given, the specified message digest
   algorithm is used for the signature. If there are no such headers,
   MD5 is assumed. If more than one message digest is used in the
   signature, the "Hash" armor header contains a comma-delimited list
   of used message digests.

In short, if there are no headers, where it says

	SHA-1 is used

that should be changed to (for 2.6.2 style compatibility)

	MD5 is assumed

--- reply to tzeruch - at - ceddec - dot - com ---

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Legal issues in implementing OpenPGP
Reply-To: [email-masked]
Date: Wed, 20 May 1998 10:19:04 (NZST)
Sender: [email-masked]

>I did not investigate the legal situation in Australia or South Africa but
>only wanted to give a hint that in some jurisdictions you might run into
>trouble if you should ignore software-related patents despite the fact that
>algorithms or "computer programs as such" are excluded from patent protection.
 
IDEA definitely isn't patented/covered in Australia and NZ.  When someone
wanted to register it (meaning the IDEA implementation in PGP) with Ascom Tech
for personal use, they were told that it wasn't necessary because it wasn't
covered.  This probably has more to do with the fact that they never bothered
filing for a patent here than our no-software-patents policy (claiming patent
rights for NZ probably doesn't rate very highly on a products feature list :-).
 
Peter.

Comments: Authenticated sender is <[email-masked]>
Organization: Private Site
To: [email-masked]
Date: Tue, 19 May 1998 22:00:15 +0100
Subject: Re: Legal issues in implementing OpenPGP
From: [email-masked] (Axel H. Horns)
Sender: [email-masked]

On  9 May 98 at 9:29, Steve Schear wrote:

> The issue of applicable patents opens up the topic of locations
> where these patents are and are not enforceable.  After discussions
> with several well-known crypto developers, its my understanding that
> a number of countries (e.g., Australia, New Zealand and South
> Africa) do not recognize algorithmic patents.  This would seem to
> give a considerable advanage to companies from these locations
> fielding OpenPGP products.  This might apply whether or not their
> customers were in countries which did recognize the patents, other
> than major corporations which are nearly always 'good citizens',
> since enforcement of patent infringement against end-users is
> considered impractical.

You should not misunderstand that issue. If in a particular 
jurisdiction *algortithms* cannot be subject-matter of a patent claim 
this does not mean that you can't infringe a particular patent by 
loading a piece of software into a computer. 

For example, the European Patent Convention (EPC) as well as the 
German Patent Act exclude "computer programs as such" from patent 
protection. However, there is e.g. an EP 0 482 154 B1 claiming, inter 
alia, a "device for the conversion of in each case a given first 
binary digital block of a first length (N) into an associated 
second binary digital block of equal length with the use of at least 
one freely selectable binary control block, characterized [...]" .

If you load some IDEA code into your computer you effectively have a 
device as described with claim 1.

A device can be patented if it is of a "technical" nature (and, of 
course, it must be also novel and inventive). Ciphering apparatuses 
have a dedicated section in the International Patent Classification, 
giving a hint that in former times before the software age there were 
indeed complex and clumsy electro-mechanical crypto "apparatuses" 
which had been considered as being of "technical nature". Maybe that 
the patent Examiner of the EPO had this in mind when granting a patent
for a "device" performing IDEA processing. Whatever the reasons for 
granting this patent might be, the protection is in force and effective,
inter alia, in Germany. Despite the fact that both the German Patent 
Act as well as EPC exclude "computer programs" from patent protection!

I did not investigate the legal situation in Australia or South 
Africa but only wanted to give a hint that in some jurisdictions you 
might run into trouble if you should ignore software-related patents 
despite the fact that algorithms or "computer programs as such" are 
excluded from patent protection.

In general a sound discussion of patent infringement issues must be 
based in a jurisdiction-by-jurisdicion way on the particular claim 
wordings granted by the competent authority for each jurisdiction. 
With regard to OpenPGP this would mean that for every involved and 
identified patent a patent family search would have to be made. Then, 
each identified family member would have to be evaluated with regard 
to the desired OpenPGP standard. A *very* big and expensive task! I 
cannot imagine that such doing would be possible in the context of 
the IETF due to lack of resources. 

Axel H. Horns
Patentanwalt
--
Patentanwalt (German Patent Attorney) Dipl.-Phys. Axel H. Horns
D-80796 Munich  [email-masked]  http://www.horns.netplace.de
Voice: ++49.89.30630112       * * *       Fax: ++49.89.30630113
PGP fingerprint A4 5F 5F 39 B7 CC E0 32 5D B8 15 55 F3 19 78 C5 

Date: Tue, 19 May 1998 11:25:15 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Fixes to draft 03
Sender: [email-masked]

Section 5.1 (fix garbled text):

old:

Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the PKCS-1 the implementation MUST make new padding for each key.

new:

Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make new PKCS-1 padding for each key.

---

Section 4.2.2.1 (fix consistency):

old:

       bodyLen = length_octet;

new:

       bodyLen = 1st_octet;

---

Section 4.2.2.2 (fix consistency, clarify):

old:

       bodyLen = (1st_octet - 192) * 256 + (2nd_octet) + 192

new:

       bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

---

Section 5.2.3.1 (fix consistency, clarify):

old:

   The length includes the type octet but not this length. Its format
   is the same as the "new" format packet header lengths. That is:

       if the 1st octet <  192, then length is the octet value

       if the 1st octet >= 192 and < 255, then length is 2 octets and
       equal to (1st octet - 192) * 256 + (2nd octet) + 192

       if the 1st octet = 255, then the subpacket length is a
       four-octet scalar found in octets 2 through 5, as per the packet
       header length.

new:

   The length includes the type octet but not this length. Its format
   is the same as the "new" format packet header lengths. That is:

       if the 1st octet <  192, then 
           lengthOfLength = 1
           subpacketLen = 1st_octet

       if the 1st octet >= 192 and < 255, then
           lengthOfLength = 2
           subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

       if the 1st octet = 255, then 
           lengthOfLength = 5
           subpacket length = [four-octet scalar starting at 2nd_octet]

---

Section 4.2.1 (remove text):

old:

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
       is. If the packet is in a file, this means that the packet
       extends until the end of the file. With a compressed packet, the
       algorithm implicitly denotes how the end of the packet. In
       general, an implementation SHOULD NOT use indeterminate length
       packets except where the end of the data will be clear from the
       context, and even then it is better to use a definite length, or
       a new-format header. The new-format headers described below have
       a mechanism for precisely encoding data of indeterminite length.

new:

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
       is. If the packet is in a file, this means that the packet
       extends until the end of the file. In general, an implementation
       SHOULD NOT use indeterminate length packets except where the end
       of the data will be clear from the context, and even then it is
       better to use a definite length, or a new-format header. The
       new-format headers described below have a mechanism for
       precisely encoding data of indeterminite length.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-formats-03.txt
Date: Tue, 19 May 1998 09:46:07 -0400
Sender: [email-masked]

--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		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-formats-03.txt
	Pages		: 57
	Date		: 18-May-98
	
   This document is maintained in order to publish all necessary
   information needed to develop interoperable applications based on
   the OpenPGP format. It is not a step-by-step cookbook for writing an
   application. It describes only the format and methods needed to
   read, check, generate and write conforming packets crossing any
   network. It does not deal with storage and implementation questions.
   It does, however, discuss implementation issues necessary to avoid
   security flaws.
 
   Open-PGP software uses a combination of strong public-key and
   symmetric cryptography to provide security services for electronic
   communications and data storage.  These services include
   confidentiality, key management, authentication and digital
   signatures. This document specifies the message formats used in
   OpenPGP.

Internet-Drafts are 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-formats-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-openpgp-formats-03.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-formats-03.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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 18 May 1998 18:24:24 -0700
From: Hal Finney <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: CTB and Length Type 3
Sender: [email-masked]

William H. Geiger III, <[email-masked]>, writes:
> I am having a little problem in parsing signed messages following the
> draft documentation.
>
> Both PGP 2.6.x & 5.0 produce the following (output as binary file):
>
> A3 01 01 AF 00 50 FF [remained is signature block]
>
> The first packet is a compressed packet (CTB 0xA3) with a type 3 length
> (Old format). Per the docs:
> [...]
>    3 - The packet is of indeterminate length.  The header is 1 octet
>        long, and the implementation must determine how long the packet
>        is. If the packet is in a file, this means that the packet
>        extends until the end of the file. In general, an implementation
>        should not use indeterminate length packets except where the end
>        of the data will be clear from the context. The new format
>        headers described below have a mechanism for precisely encoding
>        data of indeterminite length.
>
> Obviously this is not the case as the compressed data packet does not
> cover the entire file as there is a signature packet that follows.

Actually, the comment in the spec is correct, and you are being fooled
by the structure of the compressed data packet.

What is happening here is that the compressed data packet *does* cover
the entire file.  It's just that the compression algorithm has chosen to
include a copy of the compressed data (the signature packet) as part of
its output.  Since not all data is compressible, compression algorithms
sometimes do this.  What you thought was the beginning of a new packet
is simply the 6th byte of the compressed data packet.

I see that the latest draft has added the sentence,

       With a compressed packet, the
       algorithm implicitly denotes how the end of the packet.

in section 4.2.1, based on the earlier discussion (sorry I did not comment
sooner).  I don't believe this sentence is correct, and it should be
removed.

> Also Section 10.2 does not seem accurate as:
>
> Signed Message :- Signature Packet, OP Message | One-Pass Signed Message.
>
> Seems to imply that the signature packet comes first followed by the OP
> Message (the opposite is the case with 2.6.x & 5.x).

I don't know why you say this, actually 2.6.x and 5.x put the signature
packet first.  Are you thinking of clearsigned messages?  The grammar
in section 10.2 applies to binary messages.

Hal

Date: Mon, 18 May 1998 11:11:45 -0700
To: Christoph Moser <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Armor vs. Binary
Sender: [email-masked]

At 10:36 AM 5/16/98 +0200, Christoph Moser wrote:
   Hi !
   
   Is there a difference between the binary-code generated by PGP and the
   Radix-64 equivalent ?
   I have written a program to convert the Radix-64-Code into binary-code and
   this binary-code should be the same as the one PGP generates. The first
   4 Triple-Blocks are identical, but then our result differ.
   
   Example:
   
   The result my program generates:
   
   133,1,12
   3,118,42
   25,11,104
   23,21,225
   ------------------- from then on the codes differ
   1,8,0
   142,140,4
   43,235,81
   43,190,74

   PGP-generated binary-code:
   
   133,1,12
   3,118,42
   25,11,104
   23,21,225
   -------------------
   1,7,253
   24,146,75
   220,144,71
   127,219,200
   
   I tested my program, and it works correct, but if you like I also could
   post it. But maybe there is a simple misunderstanding from my side.
   
What I suspect is happening is that you are using a signed number someplace
where you should be using an unsigned number. If you look at the first
triplet that differs, you have an eight turning into a 7, which is the sort
of thing that makes me think it's a signed/unsigned problem.

Why don't you send us 24 bytes of source binary, and we can tell you what
it's supposed to armor to?

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 18 May 1998 10:37:57 -0700
To: [email-masked], Jon Callas <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Moving forward
Cc: [email-masked]
Sender: [email-masked]

At 04:02 PM 5/17/98 -0400, [email-masked] wrote:

   I would also suggest posting any of these edits and their status
   (suggested, approved) to the ietf-open-pgp list so that everyone will know
   what the final spec will say - after final call, everyone should be able
   to derive a diff against it to determine the release.
   
Excellent idea.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 18 May 1998 13:20:43 -0400
From: [email-masked]
To: [email-masked]
Subject: opgp99k
Sender: [email-masked]

On Sun, 17 May 1998 [email-masked] wrote:

> I needed to tweak the algorithms, and make some type definition changes
> for an attempt at a PalmPilot version.  opgp99g is a stable linux-i386 or
> Alpha/axp version.  opgp99j should work, but would be wasteful of space
> since u32s will be stored in u64s.

OOPS, I was too agressive with some of my type changes.  I still have some
further fixes, but I can get the library to compile for the PalmPilot III,
and even shoved CAST and RIPEMD into PilotSSLeay2.x.  A new version (l or
m) should appear tomorrow, and I will try to add a PalmPilot
work-in-progress patch to my goodies directory. 

This is far from operational.  Now I have to create a stdio to PPOS3
stream file, and shrink some of my stack usage.  Interestingly enough, all
the pieces are there to create a PalmPilot3/OPGP (which should be called
BlackHawk, SR71, or U2 or some other neat title).  It would be neat to
beam my business card with PGP public key, and be able to verify
signatures from others, and then send and receive encrypted notes.

All this in my copious free time :).  So don't expect anything soon, but
if anyone else is in the US or Canada and interested in helping I would
appreciate it since I am very new to the PalmPilot.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 17 May 1998 16:02:57 -0400
From: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: Moving forward
Sender: [email-masked]

On Wed, 13 May 1998, Jon Callas wrote:

> When you have comments on -03, please be explicit about what you want me to
> change. Best of all is something like: "Please change 'xxx yyy zzz' to 'xxx
> aaa bbb zzz'" because then I know exactly what you want. If you want me to
> add a paragraph, give me a suggestion, I'm more than happy to edit and
> rewrite. I've felt bad in the past because I've been slow on a number of
> perfectly reasonable requests for no other reason than I didn't understand
> the request. 
> 
> 	Jon

I would also suggest posting any of these edits and their status
(suggested, approved) to the ietf-open-pgp list so that everyone will know
what the final spec will say - after final call, everyone should be able
to derive a diff against it to determine the release.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 17 May 1998 16:00:12 -0400
From: [email-masked]
To: [email-masked]
Subject: opgp99g and j
Sender: [email-masked]

I needed to tweak the algorithms, and make some type definition changes
for an attempt at a PalmPilot version.  opgp99g is a stable linux-i386 or
Alpha/axp version.  opgp99j should work, but would be wasteful of space
since u32s will be stored in u64s.

I still need to tweak some algorithms before the final release to speed
things up, but things are settling down rapidly.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 16 May 1998 10:36:02 +0200
To: [email-masked]
From: Christoph Moser <[email-masked]>
Subject: Armor vs. Binary
Sender: [email-masked]

Hi !

Is there a difference between the binary-code generated by PGP and the
Radix-64 equivalent ?
I have written a program to convert the Radix-64-Code into binary-code and
this binary-code should be the same as the one PGP generates. The first
4 Triple-Blocks are identical, but then our result differ.

Example:

The result my program generates:

133,1,12
3,118,42
25,11,104
23,21,225
------------------- from then on the codes differ
1,8,0
142,140,4
43,235,81
43,190,74

PGP-generated binary-code:

133,1,12
3,118,42
25,11,104
23,21,225
-------------------
1,7,253
24,146,75
220,144,71
127,219,200

I tested my program, and it works correct, but if you like I also could
post it. But maybe there is a simple misunderstanding from my side.

Thanks for your help

 Christoph

-----------------------------------------------------------
Christoph Moser - Student of Computer Science and Business
                  University of Siegen

Email:            [email-masked]
Tel. :            +49 271 71883 
-----------------------------------------------------------
PGP-Key available on request

Date: Wed, 13 May 1998 12:39:10 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Moving forward
Sender: [email-masked]

I've finished up adding in all the comments about draft -02, and am buffing
and polishing draft -03. I've also added a section of implementation nits,
based upon some of the puzzlements that Tom Zerucha and Bill Geiger have had.

In talking to Tom Zerucha, he said that he's been pleased with what we have
as something to implement to. He's even compared it favorably with other
specs he has worked with. Consequently, I'm declaring -03 to be final call.

When you have comments on -03, please be explicit about what you want me to
change. Best of all is something like: "Please change 'xxx yyy zzz' to 'xxx
aaa bbb zzz'" because then I know exactly what you want. If you want me to
add a paragraph, give me a suggestion, I'm more than happy to edit and
rewrite. I've felt bad in the past because I've been slow on a number of
perfectly reasonable requests for no other reason than I didn't understand
the request. 

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

From: "Michael Shor" <[email-masked]>
To: <[email-masked]>, "Paul Lambert" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Subject: Re: Legal issues in implementing OpenPGP
Date: Wed, 13 May 1998 10:05:24 -0400
Importance: Normal
Sender: [email-masked]

Although I am not knowledgeable on this subject, what about implementations
like Pegwit and Crypto Kong?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Uri Blumenthal
> Sent: Tuesday, May 12, 1998 7:05 PM
> To: Paul Lambert
> Cc: [email-masked]; [email-masked]
> Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
> 
> 
> Paul Lambert says:
> > Here are a few comments on the discussion of Certicom's patents and some
> > ideas on how to possibly create new licensing approaches to support
> > "non-commercial" OpenPGP implementations.
> 
> It is good to see that Certicom decided to address the issue, and it
> allows me to hope that an acceptable solution will be found.
> 
> > >Likewise, I'm aware of "$1 per copy maximum license fee" message from
> > >Certicom, but haven't heard of ANY "royalty-free" offer or license.
> > 
> > ....Certicom provides very reasonable licensing of the technology.  
> 
> Possibly. I'll leave this point to others.
> 
> > To date there is no "royalty-free" offer..............
> 
> And this is precisely the source of my concern, because it effectively
> forbids freeware implementation of techlology, covered by Certicom and
> thus forces the Net to embrace alternative, non-encumbered solutions.
> 
> > Certicom is considering creating a "non-commercial use" license that
would
> > promote the wider fielding of ECC technology.  Certicom's broad range of
> > patents on ECC might limit the adoption of ECC technology in
applications
> > like OpenPGP. A "non-commercial use" licenses would be introduced to
> > promote research and implementation of ECC technology.  This would cover
> > most personal usage of OpenPGP.
> > Your comments on approaches to such a license would be appreciated.
> 
> In essence, I'd opt for a license that says something like "If you make
> money with this -  you share the loot with us, otherwise you can use it
> for free." For example, receiving purchase orders secured with ECC,over
> the Net - would be "commercial".  On the other hand, submitting such an
> order _for personal use_ (i.e. not a company buying gasoline for its
> trucks) would _not_ be "commercial". Sending secure e-mail "You
> haven't paid your bill of xx/xx/xxxx" is commercial, sending
> personal e-mail - isn't...
> 
> I think there are examples - as there are many software pieces on the
> Net that are free for personal (non-commercial) use, but cost money
> if you want to use it for your business.
> 
> It should be fairly easy to draft such a license (but I admit I'm not
> a lawyer - my training is simply to get the job done :-).
> --
> Regards,
> Uri		[email-masked]
> -=-=-=-=-=-=-
> <Disclaimer>
> 

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked] (Paul Lambert)
Date: Tue, 12 May 1998 19:04:48 -0400 (EDT)
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Paul Lambert says:
> Here are a few comments on the discussion of Certicom's patents and some
> ideas on how to possibly create new licensing approaches to support
> "non-commercial" OpenPGP implementations.

It is good to see that Certicom decided to address the issue, and it
allows me to hope that an acceptable solution will be found.

> >Likewise, I'm aware of "$1 per copy maximum license fee" message from
> >Certicom, but haven't heard of ANY "royalty-free" offer or license.
> 
> ....Certicom provides very reasonable licensing of the technology.  

Possibly. I'll leave this point to others.

> To date there is no "royalty-free" offer..............

And this is precisely the source of my concern, because it effectively
forbids freeware implementation of techlology, covered by Certicom and
thus forces the Net to embrace alternative, non-encumbered solutions.

> Certicom is considering creating a "non-commercial use" license that would
> promote the wider fielding of ECC technology.  Certicom's broad range of
> patents on ECC might limit the adoption of ECC technology in applications
> like OpenPGP. A "non-commercial use" licenses would be introduced to
> promote research and implementation of ECC technology.  This would cover
> most personal usage of OpenPGP.
> Your comments on approaches to such a license would be appreciated.

In essence, I'd opt for a license that says something like "If you make
money with this -  you share the loot with us, otherwise you can use it
for free." For example, receiving purchase orders secured with ECC,over
the Net - would be "commercial".  On the other hand, submitting such an
order _for personal use_ (i.e. not a company buying gasoline for its
trucks) would _not_ be "commercial". Sending secure e-mail "You
haven't paid your bill of xx/xx/xxxx" is commercial, sending
personal e-mail - isn't...

I think there are examples - as there are many software pieces on the
Net that are free for personal (non-commercial) use, but cost money
if you want to use it for your business.

It should be fairly easy to draft such a license (but I admit I'm not
a lawyer - my training is simply to get the job done :-).
--
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: "Paul Lambert" <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Date: Tue, 12 May 1998 15:15:56 -0700
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Sender: [email-masked]

Hello,

Here are a few comments on the discussion of Certicom's patents and some
ideas on how to possibly create new licensing approaches to support
"non-commercial" OpenPGP implementations.

First, on Rich Ankney's  and Uri's comments:

>ECDSA in particular is not patented.

Certicom has patents filed that cover aspects of ECDSA.

>Certicom has patented various
>hardware tricks to implement EC over GF(2^m).

Only a few "tricks" are patented for hardware and GF(2^m).  Most cover EC
and public key mechanisms in general.  More EC patents from Certicom seem
to cover GF(p) than GF(2^m).  It does seem that many implementors are
moving to GF(p) based on the perception that Certicom has more patents in
2^m.  This is not a good reason to move to GF(p).  GF(p) is better on
"larger" processors and GF(2^m) is better on 8-bit processors.

> Certicom also has
> a patent on the MQV variant of Diffie-Hellman which can be used over
> EC, but has granted a royalty-free license for its use.

No.  MQV is not royalty free as far as I know ...

>For example,
>it is my understanding that their Point Compression is covered
>regardless of whether you burn it in silicon or not.

Yes.  Certicom has filed a fairly broad patent on point compression
techniques.

>In fact,
>it was my understanding that Certicom was planning to release
>a software library (a-la BSAFE) that one would buy to add EC
>capabilities to his product (and to become a "legal" licensee).

Yes, Certicom sells toolkit products for a wide variety of platforms
including MS CSPs and CDSA CSPs.

>Likewise, I'm aware of "$1 per copy maximum license fee" message from
>Certicom, but haven't heard of ANY "royalty-free" offer or license.
>Care to amplify?

Yes, Certicom provides very reasonable licensing of the technology.  To
date there is no "royalty-free" offer.  Certicom's patents cover a wide
variety of ECC and public key mechanisms.  The company has worked very hard
to avoid the licensing models of other companies with public key patents.
They have largely stressed the benefits of their implementations over the
necessity to license patents.

Certicom is considering creating a "non-commercial use" license that would
promote the wider fielding of ECC technology.  Certicom's broad range of
patents on ECC might limit the adoption of ECC technology in applications
like OpenPGP. A "non-commercial use" licenses would be introduced to
promote research and implementation of ECC technology.  This would cover
most personal usage of OpenPGP.

Your comments on approaches to such a license would be appreciated.

Regards,

Paul A. Lambert
Director of Technical Marketing
Certicom Corp.
San Mateo, CA
+1-650-312-7996
______

Uri Blumenthal <[email-masked]> on 05/05/98 11:01:34 AM

Please respond to [email-masked]

To:   [email-masked] (Rich Ankney)
cc:   [email-masked] (bcc: Paul Lambert/Certicom)
Subject:  Re: Subject: Re: Legal issues in implementing OpenPGP

Rich Ankney says:
> ECDSA in particular is not patented.  Certicom has patented various
> hardware tricks to implement EC over GF(2^m).  Certicom also has
> a patent on the MQV variant of Diffie-Hellman which can be used over
> EC, but has granted a royalty-free license for its use.

I do NOT think Certicom patents are limited to hardware. For example,
it is my understanding that their Point Compression is covered
regardless of whether you burn it in silicon or not. In fact,
it was my understanding that Certicom was planning to release
a software library (a-la BSAFE) that one would buy to add EC
capabilities to his product (and to become a "legal" licensee).
Doesn't look like hardware trick to me.

Likewise, I'm aware of "$1 per copy maximum license fee" message from
Certicom, but haven't heard of ANY "royalty-free" offer or license.
Care to amplify?
--
Regards,
Uri       [email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 11 May 1998 11:09:36 -0700
To: "William H. Geiger III" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Packet Type 10 (Marker Packet)
Sender: [email-masked]

At 05:10 AM 5/9/98 -0500, William H. Geiger III wrote:
   In section 5.8:
   
   The body of this packet consists of:                                
                                                                          -
   The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8). 

   PGP 5.0 creates a marker packet of 0x50, 0x47, 0x50. PGP 5.0 will fail if
   0x60, 0x47, 0x60 is used.
   
Thank you, this is obviously an error. 0x60, 0x47, 0x60 is "`G`". 0x50 is
an upper-case P. Fixed in next release.

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 11 May 1998 13:28:00 -0400
From: [email-masked]
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked]
Subject: Re: CTB and Length Type 3
Sender: [email-masked]

It might be simpler than all that.  Note that the ZIP algorithm copies
bytes verbatim until there are enough repeated strings to allow the
creation of tags which allow for compression.  With a small and random
input like a signature and tiny literal, there may not be enough to
compress in the sense of using any tags, so the entire packet is valid
"compressed" data although no compression actually occurs.

Even gzip -9 on the extracted signature and literal packets result in most
of the text being visible.  If the data isn't really compressible, it is
passed verbatim. 

It manages to compress when I use "This is a test of this thing", which
apparently has enough repeated strings (and even "This is a t").

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sun, 10 May 1998 23:52:26 -0400
From: [email-masked]
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked]
Subject: Re: CTB and Length Type 3
Sender: [email-masked]

On Sat, 9 May 1998, William H. Geiger III wrote:

> In <[email-masked]>, on 05/09/98
>    at 07:16 PM, [email-masked] said:
> 
> >On Sat, 9 May 1998, William H. Geiger III wrote:
> 
> >I take it you compressed a zero-byte file?  The problem is a bug in PGP
> >signing zero byte files, where instead of doing something right, it does
> >what you show above, and something more (read on).
> 
> No I did not. I used a small 7 byte text file (test.txt) that contained:
> 
> hello<cr><lf>
> 
> It was signed with my 1024 RSA key0xFE68B861.

And worked (but see below):
./opgp -i test.pgp  -r geiger.pgp #your PKpacket was saved as geiger.pgp
good signature
hello

Or, to show more clearly:
./opgp -i test8.pgp  -r geiger.pgp | hd
good signature
000000 68 65 6c 6c 6f 0d 0a

> >You must inflate (to /dev/null if needed or simply dump the stuff in the
> >output buffer) as the only way to know where the compressed data ends.
> 
> So I have to dump the entire file to the Inflate() function and then
> re-parse the packets after inflation? Not a very pretty solution.

Yes, this is ugly, but generally compressed packets are standalone.
Unless the implementation is broken, which it appears to be.

> >This is a bug in PGP since if you have even one byte of data, what would
> >be compressed would be sig,literal(data).
> 
> Well I don't know if I would call it a bug since this is how both 2.6.x &
> 5.0 generate this file using RSA key for signing.

The versions I used (Linux 2.6.2 at least) didn't.  They did a compressed
packet containg a signature packet followed by a literal packet after
decompression.  I just tried it again with an earlier linux verison and it
did the same thing that yours did, i.e. tacked a null compressed packet
before a sig and a literal.

> I have attached a copy of the file here, my key is available off the
> keyservers if anyone want's to use it to verify the sig block. test.pgp is
> hello<lf><cr> signed with 2.6.3a and test8.pgp is the same file signed
> with 5.0i.

test.pgp Hexdumped:

000000 a3 01 01 af 00 50 ff  
                            89 00 95 03 05 00 35 53 e7
000010 86 8f 42 a3 59 fe 68 b8 61 01 01 ba 5b 03 fd 12
000020 08 cd 04 e4 e3 1e 04 8c c0 df 07 52 8f f6 a3 35
000030 dd 99 c2 57 86 98 17 07 fb 55 d6 a3 3f 61 44 cd
000040 92 85 3e 1c 0d 09 61 0e b3 1e 66 9e dc 77 b1 7d
000050 59 57 f2 3e 6a 1b d1 ed d2 87 06 57 bf 16 5d 57
000060 34 f3 58 39 9e c7 f9 f0 59 63 4a 34 19 20 10 0f
000070 af 1d cd 98 be 37 64 6c e9 62 39 1c 94 46 e6 cd
000080 9d e0 32 d6 cf 30 9e 1c a6 54 56 bd 4b b9 20 a7
000090 30 cb d2 7d 43 9e da 2a 8a 9c 5a 22 5d 64 95 
                                                    ac
0000a0 15 62 08 74 65 73 74 2e 74 78 74 00 00 00 00 68
0000b0 65 6c 6c 6f 0d 0a

AC (at byte 0x99) is a literal packet, 15 bytes total, of type Binary
('b'), filename is 8 bytes long: "test.txt", the time dword is zero, and
the contained text is your "hello\r\n".

Since the timestamp differs, and is hashed the two packets will have a
differing signature, but the test8.txt file has the same format.

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 09 May 98 21:38:53 -0500
To: [email-masked]
Cc: [email-masked]
Subject: Re: CTB and Length Type 3
Sender: [email-masked]

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

In <[email-masked]>, on 05/09/98 
   at 07:16 PM, [email-masked] said:

>On Sat, 9 May 1998, William H. Geiger III wrote:

>> Hi,
>> 
>> I am having a little problem in parsing signed messages following the
>> draft documentation.
>> 
>> Both PGP 2.6.x & 5.0 produce the following (output as binary file):
>> 
>> A3 01 01 AF 00 50 FF [remained is signature block]

>I take it you compressed a zero-byte file?  The problem is a bug in PGP
>signing zero byte files, where instead of doing something right, it does
>what you show above, and something more (read on).

No I did not. I used a small 7 byte text file (test.txt) that contained:

hello<cr><lf>

It was signed with my 1024 RSA key0xFE68B861.

>>    3 - The packet is of indeterminate length.  The header is 1 octet
>>        long, and the implementation must determine how long the packet
>.... 
>> Obviously this is not the case as the compressed data packet does not
>> cover the entire file as there is a signature packet that follows.

>Buried in some old 2.6.2 docs it says something different.  Functionally
>a type of 3 means that the function, i.e. algorithm can determine when
>the EOF is (which zip does).

The RFC needs to be updated to reflect this information as it is how PGP
is currently generating these messages.

>> Now the next octet (01) represents zip compression algorithm.
>> 
>> Where I am having problems is with the remaining 5 octets. I have read
>> through RFC1591 and I am still lost at decodeing the remainder of this
>> compression packet.
>> 
>> At this point I am not intrested in Inflating the data but calculating the
>> length of the compressed packet so I can find the start of the sig block
>> for sepeate processing.

>You must inflate (to /dev/null if needed or simply dump the stuff in the
>output buffer) as the only way to know where the compressed data ends.

So I have to dump the entire file to the Inflate() function and then
re-parse the packets after inflation? Not a very pretty solution.

>> Also Section 10.2 does not seem accurate as:

>This is a bug in PGP since if you have even one byte of data, what would
>be compressed would be sig,literal(data).

Well I don't know if I would call it a bug since this is how both 2.6.x &
5.0 generate this file using RSA key for signing.

>Also you might notice a trailing literal with the file type, name, and
>time, but with zero bytes.  So the actual format might be (zero byte
>compressed packet)(signature packet)(literal packet).

IMHO we need a section in the RFC outlining the format PGP is currently
using when creating a binary, signed text file as implementers will have
to be able to process these messages.

I have attached a copy of the file here, my key is available off the
keyservers if anyone want's to use it to verify the sig block. test.pgp is
hello<lf><cr> signed with 2.6.3a and test8.pgp is the same file signed
with 5.0i.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Windows: From the people who brought you EDLIN!

Date: Sat, 9 May 1998 19:36:05 -0400
From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Some spec nits and other things
Sender: [email-masked]

Actually there is one probabilistic implementation nightmare if you have
multiple passphrases.  The only way of testing validity is if the last
pair of bytes are the same as the penultimate pair.  This might happen at
random though rarely.  Technically you must try all passphrases, and if
more than one passes the header test, you need to do both and ask "which
one is right".  The new SKESKs really should also be CRCed, which would
require two very lucky collisions which should be well beyond probability. 

For intra signature packets, it would help if the implementation SHOULD
place the two MUST packets, creation time and keyid, at the beginning of
the hashed area in that order.  This would make the keyid bytes occur at a
fixed location (and the previous two bytes could be used as a check). 
Having to parse through a lot of junk to find the keyid is nasty. 

One final signature packet issue is that I don't know if it says anywhere
that you can't have duplicate or conflicting packets (e.g. two preference
packets, one saying CAST, the second IDEA, the third CAST/IDEA). 
Strictly, it should be obvious for some that they should be unique.  But
as an example, what about a V3 RSA keyid, and a V4 RSA keyid (for the
differing IDs for the same key material).  I can see this being a valid
usage.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 9 May 1998 19:16:09 -0400
From: [email-masked]
To: "William H. Geiger III" <[email-masked]>
cc: [email-masked]
Subject: Re: CTB and Length Type 3
Sender: [email-masked]

On Sat, 9 May 1998, William H. Geiger III wrote:

> Hi,
> 
> I am having a little problem in parsing signed messages following the
> draft documentation.
> 
> Both PGP 2.6.x & 5.0 produce the following (output as binary file):
> 
> A3 01 01 AF 00 50 FF [remained is signature block]

I take it you compressed a zero-byte file?  The problem is a bug in PGP
signing zero byte files, where instead of doing something right, it does
what you show above, and something more (read on).

>    3 - The packet is of indeterminate length.  The header is 1 octet
>        long, and the implementation must determine how long the packet
... 
> Obviously this is not the case as the compressed data packet does not
> cover the entire file as there is a signature packet that follows.

Buried in some old 2.6.2 docs it says something different.  Functionally a
type of 3 means that the function, i.e. algorithm can determine when the
EOF is (which zip does).

> Now the next octet (01) represents zip compression algorithm.
> 
> Where I am having problems is with the remaining 5 octets. I have read
> through RFC1591 and I am still lost at decodeing the remainder of this
> compression packet.
> 
> At this point I am not intrested in Inflating the data but calculating the
> length of the compressed packet so I can find the start of the sig block
> for sepeate processing.

You must inflate (to /dev/null if needed or simply dump the stuff in the
output buffer) as the only way to know where the compressed data ends.

> Also Section 10.2 does not seem accurate as:

This is a bug in PGP since if you have even one byte of data, what would
be compressed would be sig,literal(data).

Also you might notice a trailing literal with the file type, name, and
time, but with zero bytes.  So the actual format might be
(zero byte compressed packet)(signature packet)(literal packet).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Sat, 9 May 1998 09:29:03 -0700
To: [email-masked]
From: Steve Schear <[email-masked]>
Subject: Re: Legal issues in implementing OpenPGP
Sender: [email-masked]

The issue of applicable patents opens up the topic of locations where these
patents are and are not enforceable.  After discussions with several
well-known crypto developers, its my understanding that a number of
countries (e.g., Australia, New Zealand and South Africa) do not recognize
algorithmic patents.  This would seem to give a considerable advanage to
companies from these locations fielding OpenPGP products.  This might apply
whether or not their customers were in countries which did recognize the
patents, other than major corporations which are nearly always 'good
citizens', since enforcement of patent infringement against end-users is
considered impractical.

--Steve

---------------------------------------------------------------------
Steve Schear              | tel: (702) 658-2654
CEO                       | fax: (702) 658-2673
=46irst ECache Corporation  |
7075 West Gowan Road      |
Suite 2148                |
Las Vegas, NV 89129       | Internet: [email-masked]
---------------------------------------------------------------------

		"It's your Cache=81"

PGP mail preferred, see  	http://www.pgp.com and
				http://web.mit.edu/network/pgp.html

RSA fingerprint: FE90 1A95 9DEA 8D61  812E CCA9 A44A FBA9
RSA key: http://keys.pgp.com:11371/pks/lookup?op=3Dindex&search=3D0x55C78B0D

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 09 May 98 05:10:00 -0500
To: [email-masked]
Subject: Packet Type 10 (Marker Packet)
Sender: [email-masked]

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

Hi,

In section 5.8:

The body of this packet consists of:                                
                                                                       -
The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8). 

PGP 5.0 creates a marker packet of 0x50, 0x47, 0x50. PGP 5.0 will fail if
0x60, 0x47, 0x60 is used.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: Program call to load Windows- "Here_piggy_piggy_piggy"

From: "William H. Geiger III" <[email-masked]>
Date: Sat, 09 May 98 01:27:08 -0500
To: [email-masked]
Subject: CTB and Length Type 3
Sender: [email-masked]

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

Hi,

I am having a little problem in parsing signed messages following the
draft documentation.

Both PGP 2.6.x & 5.0 produce the following (output as binary file):

A3 01 01 AF 00 50 FF [remained is signature block]

The first packet is a compressed packet (CTB 0xA3) with a type 3 length
(Old format). Per the docs:

4.2.1. Old-Format Packet Lengths

   The meaning of the length-type in old-format packets is:

   0 - The packet has a one-octet length. The header is 2 octets long.

   1 - The packet has a two-octet length. The header is 3 octets long.

   2 - The packet has a four-octet length. The header is 5 octets long.

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
       is. If the packet is in a file, this means that the packet
       extends until the end of the file. In general, an implementation
       should not use indeterminate length packets except where the end
       of the data will be clear from the context. The new format
       headers described below have a mechanism for precisely encoding
       data of indeterminite length.

Obviously this is not the case as the compressed data packet does not
cover the entire file as there is a signature packet that follows.

Now the next octet (01) represents zip compression algorithm.

Where I am having problems is with the remaining 5 octets. I have read
through RFC1591 and I am still lost at decodeing the remainder of this
compression packet.

At this point I am not intrested in Inflating the data but calculating the
length of the compressed packet so I can find the start of the sig block
for sepeate processing.

Also Section 10.2 does not seem accurate as:

Signed Message :- Signature Packet, OP Message | One-Pass Signed Message.

Seems to imply that the signature packet comes first followed by the OP
Message (the opposite is the case with 2.6.x & 5.x).

Perhaps a section on the binary format of signed messages would be
helpfull for anyone that will be using this document to implement OpenPGP
in the future.

In Section 7:

  If the "Hash" armor header is given, the specified message digest                    

  algorithm is used for the signature. If there are no such headers,                   

  SHA-1 is used. If more than one message digest is used in the                        

  signature, the "Hash" armor header contains a comma-delimited list                   

  of used message digests.                                                             

SHA-1 should be replaced with MD5.

Well I think that's it for right now. If someone can help out with the
compression packet it would be appreciated.

Thanks,

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
 
Tag-O-Matic: It's OS/2, Jim, but not OS/2 as we know it.

From: Andrew Bromage <[email-masked]>
Subject: Re: Compression levels
To: [email-masked]
Date: Sat, 9 May 1998 09:55:35 +1000 (EST)
Sender: [email-masked]

G'day all.

[email-masked] writes:

> It seems that most versions of PGPlib use some derivative of the zip
> algorithm that offers different compression levels, e.g. gzip defaults to
> 6.  PGP 5.0 defaults to 1.  Is there any level that SHOULD be used?
> 6 (default) is much better than 1, but slower.

I don't see any a priori reason to recommend a specific compression
level since it doesn't affect decompression in any way, nor should it
affect security to any great degree (remember that actually performing
compression is only a MAY; its purpose is to speed up encryption and
decryption as well as to "randomise" the cleartext bit stream).
Recommending a level which implementations SHOULD use seems like overkill.

Also keep in mind that RFC1951 doesn't actually specify what a "level"
means even in its description of the reference implementation.

Cheers,
Andrew Bromage

Date: Fri, 8 May 1998 17:04:22 -0400
From: [email-masked]
To: [email-masked]
Subject: opgp99f.tgz uploaded, with a pgp50i patch for V4 sigs (on data)
Sender: [email-masked]

It should roll into the new directory.

The patch is a horrible kluge, but does allow me to test V4 sigs.  The
only real error (other than some checks I #ifdef-ed away instead of
really fixing) is that keyids are always at the same place with my opgp
test suite, so instead of parsing the new sig format, I just go to the Nth
byte, but there is a comment to that effect.  I also included the ElGamal
sig enabling (and some definitions for PKalg20 which don't work yet), and
the fix to the conventional algorithm.

I fixed a few issues with lookup and punzip compatibility with the latest
zlib (since I am using an undocumented feature, it does strange things
at the end of the stream which I need to compensate for).

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Fri, 08 May 1998 11:13:42 -0300
To: [email-masked], [email-masked]
From: [email-masked] (Paulo Barreto)
Subject: Re: Compression levels
Sender: [email-masked]

At 05:19 PM 98/05/07 -0400, [email-masked] wrote:

>It seems that most versions of PGPlib use some derivative of the zip
>algorithm that offers different compression levels, e.g. gzip defaults to
>6.  PGP 5.0 defaults to 1.  Is there any level that SHOULD be used?
>6 (default) is much better than 1, but slower.

The zlib implementation of deflate groups the nine compression levels in
two functions: a fast one for levels 1 to 3, and a slow (but not too slow)
one for levels 4 to 9.  I believe either 3 or 4 will provide an equilibrium
between speed and compression (the default level 6 tends to better
compression, roughly equivalent to PKZIP in normal level).

Paulo Barreto.

Date: Thu, 7 May 1998 17:19:06 -0400
From: [email-masked]
To: [email-masked]
Subject: Compression levels
Sender: [email-masked]

It seems that most versions of PGPlib use some derivative of the zip
algorithm that offers different compression levels, e.g. gzip defaults to
6.  PGP 5.0 defaults to 1.  Is there any level that SHOULD be used?
6 (default) is much better than 1, but slower.

--- reply to tzeruch - at - ceddec - dot - com ---

Date: Thu, 07 May 1998 14:17:41 -0300
To: [email-masked]
From: [email-masked] (Paulo Barreto)
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Cc: [email-masked]
Sender: [email-masked]

At 01:16 PM 98/05/07 -0400, Uri Blumenthal wrote:

>1. And how can I get that manuscript?

I haven't the faintest idea.  The reference is listed in the bibliography
of the latest X9.62 draft.

>2. This sounds like a form of compression. If I were to file a patent,
>   I'd try to cover the whole concept. Giving Certicom the credit of
>   being at least as smart, I strongly suspect that the HP method
>   would be infringing. Just a conjecture, mind you.

I don't mind.  In fact, I share your suspect.

Cheers,

Paulo.

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked] (Paulo Barreto)
Date: Thu, 7 May 1998 13:16:17 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Paulo Barreto says:
> >1. I am not aware of the HP proposal.
> 
> Just for reference:
> 
> G. Seroussi, "Compact representation of elliptic curve points over F(2^n)",
> Research Manuscript, Hewlett-Packard Laboratories, April 1998.

1. And how can I get that manuscript?

2. This sounds like a form of compression. If I were to file a patent,
   I'd try to cover the whole concept. Giving Certicom the credit of
   being at least as smart, I strongly suspect that the HP method
   would be infringing. Just a conjecture, mind you.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Thu, 07 May 1998 13:35:52 -0300
To: [email-masked]
From: [email-masked] (Paulo Barreto)
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Cc: [email-masked]
Sender: [email-masked]

At 09:57 PM 98/05/05 -0400, Uri Blumenthal wrote:

>> What about the new HP proposal for
>> "point compression"?  I haven't done any research as to patent
>> status etc.
>
>1. I am not aware of the HP proposal.

Just for reference:

G. Seroussi, "Compact representation of elliptic curve points over F(2^n)",
Research Manuscript, Hewlett-Packard Laboratories, April 1998.

Regards,

Paulo Barreto.

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: MQV Patent
Date: Wed, 6 May 1998 16:29:43 -0400
Sender: [email-masked]

Uri,

Here's what I got from Don.  It obviously applies to X9, but
I suspect all IETF needs to do is ask for the same treatment.
Bear in mind 1-pass MQV requires 2 key pairs for the sender
(but 1 per recipient) so it may not be useful for OpenPGP
anyway.

Regards,
Rich

----------
> From: Don Johnson <[email-masked]>
> To: [email-masked]
> Subject: Re: MQV Patent
> Date: Wednesday, May 06, 1998 2:12 PM
> 
> Rich,
> 
> Certicom committed to grant a royalty-free license for ANSI X9 financial
> institution use.  There would probably also be some words about we 
> would do this for those that are fair to us and that respect our other
IP, etc.
> Don J.
> 
> 
> 

Date: Wed, 06 May 1998 14:37:07 -0300
To: "Rich Ankney" <[email-masked]>, "Jim Gillogly" <[email-masked]>, <[email-masked]>
From: [email-masked] (Paulo Barreto)
Subject: Re: Legal issues in implementing OpenPGP
Sender: [email-masked]

At 01:00 PM 98/05/05 -0400, Rich Ankney wrote:

>> Hitachi claims to have a patent covering SHA1.
>
>This seems rather odd.  Is it on a particular hardware implementation 
>of SHA1?  Do you have a patent number for this?

I'm not completely sure, but it seems to be US patent 5465299: "Electronic
document processing system and method of forming digital signature"; in
fact, Hitachi claims to have no less than three patents that might cover SHA1.

For more information about crypto-related patents, take a look at
<http://grouper.ieee.org/groups/1363/patents.html>.

Regards,

Paulo Barreto.

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked] (Rich Ankney)
Date: Tue, 5 May 1998 21:57:44 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Rich Ankney says:
> Sorry; I get your point now.

(:-) (:-(

> What about the new HP proposal for
> "point compression"?  I haven't done any research as to patent
> status etc.

1. I am not aware of the HP proposal.
2. Depending on what exactly Certicom patent claim is, whatever this
   HP proposal is (or any other proposal, or maybe even dropping the
   second coordinate completely) may still fall under the Certicom
   patent coverage (i.e. infringing).

> OK.  I Emailed Don Johnson about this.  I'll try to get info on all of
> the standards bodies they've sent letters to.

Well, well, well. Please let us know what the results are.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, "Paulo Barreto" <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Date: Tue, 5 May 1998 18:34:20 -0400
Sender: [email-masked]

----------
> From: Paulo Barreto <[email-masked]>
> To: Rich Ankney <[email-masked]>; [email-masked]
> Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
> Date: Tuesday, May 05, 1998 3:39 PM
> 
> At 01:00 PM 98/05/05 -0400, Rich Ankney wrote:
> 
> >> Hitachi claims to have a patent covering SHA1.
> >
> >This seems rather odd.  Is it on a particular hardware implementation 
> >of SHA1?  Do you have a patent number for this?
> 
> No, but you could look up the IBM patent server.  The Hitachi patent was
> mentioned in a thread of the P1363 discussion list.  I'll notify you if I
> discover the patent number and/or its exact claims.
> 
> >I don't think it ever went to court, but no one seems to be getting sued
> >for using DSA...
> 
> So it was settled before going to court; someone (possibly Schnorr
himself,
> but I'm not sure) did raise the issue of patent coverage
(unsuccessfully).
>
I don't think there was ever any lawsuit (i.e. RSADSI never sued
anyone).  So I wouldn't say it is settled yet.  OTOH, in te US,
Schnorr is claiming infringement on a dependent claim (vs. an
independent claim), which seems a little weak.  Of course
IANAL.

> >ECDSA in particular is not patented.  Certicom has patented various
> >hardware tricks to implement EC over GF(2^m).  Certicom also has
> >a patent on the MQV variant of Diffie-Hellman which can be used over
> >EC, but has granted a royalty-free license for its use.
> 
> I wouldn't be so sure about this.  A fully compliant implementation must
> support point compression, and Certicom has filed a patent on this.
> 
> As for the royalty-free license, Don Johnson of Certicom sent me personal
> mail saying that there is a "small" fee to be paid for the set of
Certicom
> patents (one dollar per copy of the product using any of them).  This
> includes the MQV scheme.
>
This is a change from what I thought I heard.  Oh well.
 
> Cheers,
> 
> Paulo barreto.
> 

Thanks,
Rich

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Date: Tue, 5 May 1998 18:37:49 -0400
Sender: [email-masked]

> From: Uri Blumenthal <[email-masked]>
> To: Rich Ankney <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
> Date: Tuesday, May 05, 1998 3:56 PM
> 
> Rich Ankney says:
> > You are, of course, correct.  I should have said "implementation
tricks."
> 
> "Implementation trick" won't cut it either. "Implementation trick" would
> be something that takes input A, produces output B, but does that 
> differently, saving time, memory, etc. But one would be able
> to do a "straightforward unoptimized" implementation that
> would take the same A and output the same B, possibly
> spending twic as many seconds. Easy.
> 
> In this case however, we are talking about the DATA FORMATS. So if 
> the "licensed" product uses point compression, and your freeware
> does not ('cause it's patented) - you'd have sweet time trying
> to interoperate.
> 
> Do you see my concern?

Sorry; I get your point now.  What about the new HP proposal for
"point compression"?  I haven't done any research as to patent
status etc.

> 
> 
> > I'll try to track down the letter ANSI got from Certicom about MQV.
> 
> Please!!
> --

OK.  I Emailed Don Johnson about this.  I'll try to get info on all of
the standards bodies they've sent letters to.
 
> Regards,
> Uri		[email-masked]
> -=-=-=-=-=-=-
> <Disclaimer>

Regards,
Rich

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked] (Paulo Barreto)
Date: Tue, 5 May 1998 18:17:14 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Paulo Barreto says:
> As for the royalty-free license, Don Johnson of Certicom sent me personal
> mail saying that there is a "small" fee to be paid for the set of Certicom
> patents (one dollar per copy of the product using any of them).  This
> includes the MQV scheme.

Which translates to: "No freeware possible".
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked] (Rich Ankney)
Date: Tue, 5 May 1998 15:56:47 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Rich Ankney says:
> You are, of course, correct.  I should have said "implementation tricks."

"Implementation trick" won't cut it either. "Implementation trick" would
be something that takes input A, produces output B, but does that 
differently, saving time, memory, etc. But one would be able
to do a "straightforward unoptimized" implementation that
would take the same A and output the same B, possibly
spending twic as many seconds. Easy.

In this case however, we are talking about the DATA FORMATS. So if 
the "licensed" product uses point compression, and your freeware
does not ('cause it's patented) - you'd have sweet time trying
to interoperate.

Do you see my concern?

> I'll try to track down the letter ANSI got from Certicom about MQV.

Please!!
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked]
Date: Tue, 5 May 1998 15:48:25 -0400 (EDT)
Reply-To: [email-masked]
Sender: [email-masked]

Uri Blumenthal says:
> it was my understanding that Certicom was planning to release
> a software library (a-la BSAFE) that one would buy to add EC
    ^^^^^^^^^^^^^^^^                             ^^^
> capabilities to his product (and to become a "legal" licensee).
> Doesn't look like hardware trick to me.

I hate when I have to correct myself, but... Oh well...

That software library that Certicom was going to make available,
was NOT to be sold, but to be given away - TO THE LICENSEES.

If there's anybody from Certicom on this list who'd care to
comment - it would be appreciated.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Disposition-Notification-To: <[email-masked]>
Date: Tue, 05 May 1998 16:39:39 -0300
To: "Rich Ankney" <[email-masked]>, [email-masked]
From: [email-masked] (Paulo Barreto)
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Sender: [email-masked]

At 01:00 PM 98/05/05 -0400, Rich Ankney wrote:

>> Hitachi claims to have a patent covering SHA1.
>
>This seems rather odd.  Is it on a particular hardware implementation 
>of SHA1?  Do you have a patent number for this?

No, but you could look up the IBM patent server.  The Hitachi patent was
mentioned in a thread of the P1363 discussion list.  I'll notify you if I
discover the patent number and/or its exact claims.

>I don't think it ever went to court, but no one seems to be getting sued
>for using DSA...

So it was settled before going to court; someone (possibly Schnorr himself,
but I'm not sure) did raise the issue of patent coverage (unsuccessfully).

>ECDSA in particular is not patented.  Certicom has patented various
>hardware tricks to implement EC over GF(2^m).  Certicom also has
>a patent on the MQV variant of Diffie-Hellman which can be used over
>EC, but has granted a royalty-free license for its use.

I wouldn't be so sure about this.  A fully compliant implementation must
support point compression, and Certicom has filed a patent on this.

As for the royalty-free license, Don Johnson of Certicom sent me personal
mail saying that there is a "small" fee to be paid for the set of Certicom
patents (one dollar per copy of the product using any of them).  This
includes the MQV scheme.

Cheers,

Paulo barreto.

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Date: Tue, 5 May 1998 15:22:19 -0400
Sender: [email-masked]

> From: Uri Blumenthal <[email-masked]>
> To: Rich Ankney <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
> Date: Tuesday, May 05, 1998 2:01 PM
> 
> Rich Ankney says:
> > ECDSA in particular is not patented.  Certicom has patented various
> > hardware tricks to implement EC over GF(2^m).  Certicom also has
> > a patent on the MQV variant of Diffie-Hellman which can be used over
> > EC, but has granted a royalty-free license for its use.
> 
> I do NOT think Certicom patents are limited to hardware. For example,
> it is my understanding that their Point Compression is covered
> regardless of whether you burn it in silicon or not. In fact,
> it was my understanding that Certicom was planning to release
> a software library (a-la BSAFE) that one would buy to add EC
> capabilities to his product (and to become a "legal" licensee).
> Doesn't look like hardware trick to me.
>

You are, of course, correct.  I should have said "implementation tricks."
 
> Likewise, I'm aware of "$1 per copy maximum license fee" message from
> Certicom, but haven't heard of ANY "royalty-free" offer or license.
> Care to amplify?
> -- 

I'll try to track down the letter ANSI got from Certicom about MQV.

> Regards,
> Uri		[email-masked]

Regards,
Rich

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked] (Rich Ankney)
Date: Tue, 5 May 1998 14:01:34 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Rich Ankney says:
> ECDSA in particular is not patented.  Certicom has patented various
> hardware tricks to implement EC over GF(2^m).  Certicom also has
> a patent on the MQV variant of Diffie-Hellman which can be used over
> EC, but has granted a royalty-free license for its use.

I do NOT think Certicom patents are limited to hardware. For example,
it is my understanding that their Point Compression is covered
regardless of whether you burn it in silicon or not. In fact,
it was my understanding that Certicom was planning to release
a software library (a-la BSAFE) that one would buy to add EC
capabilities to his product (and to become a "legal" licensee).
Doesn't look like hardware trick to me.

Likewise, I'm aware of "$1 per copy maximum license fee" message from
Certicom, but haven't heard of ANY "royalty-free" offer or license.
Care to amplify?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

From: "Rich Ankney" <[email-masked]>
To: "Jim Gillogly" <[email-masked]>, <[email-masked]>, "Paulo Barreto" <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Date: Tue, 5 May 1998 13:00:40 -0400
Sender: [email-masked]

> From: Paulo Barreto <[email-masked]>
> To: Jim Gillogly <[email-masked]>; [email-masked]
> Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
> Date: Tuesday, May 05, 1998 7:59 AM
> 
> At 12:55 PM 98/05/04 -0700, Jim Gillogly wrote:
> 
> >SHA1 was designed by NSA and has no intellectual property restrictions.
> 
> Hitachi claims to have a patent covering SHA1.

This seems rather odd.  Is it on a particular hardware implementation 
of SHA1?  Do you have a patent number for this?
> 
> >HAVAL's reference implementation is copyrighted; no charge for use, but
> >  the algorithm author would like to be notified.
> 
> My corrected public domain implementation is now available at
> <http://www.nw.com.br/users/pbarreto/haval.zip>, but I think it's a good
> idea to notify Dr. Zheng of uses of Haval.  On the other hand, there's no
> published analysis of this hashing function (yet), so I'd be somewhat
> reluctant in using it.
> 
> >DSA may probably be used freely, but [Schnorr claim??].
> 
> This issue seems to have been already settled in court; DSA may be freely
> used.

I don't think it ever went to court, but no one seems to be getting sued
for using DSA...

> 
> >Elliptic Curve [??]
> >ECDSA [??]
> 
> There are endless patents regarding elliptic curves (sigh); take a look
at
> the P1363 site <http://grouper.ieee.org/groups/1363/index.html>
>

ECDSA in particular is not patented.  Certicom has patented various
hardware tricks to implement EC over GF(2^m).  Certicom also has
a patent on the MQV variant of Diffie-Hellman which can be used over
EC, but has granted a royalty-free license for its use.

Regards,
Rich

From: "Flanigan, Bill" <[email-masked]>
To: Jon Callas <[email-masked]>, "Flanigan, Bill" <[email-masked]>, Tim Dierks <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Legal issues in implementing OpenPGP?
Date: Tue, 5 May 1998 10:03:30 -0400 
Sender: [email-masked]

Way to go, Jon!

Bill

> -----Original Message-----
> From:	Jon Callas [SMTP:[email-masked]]
> Sent:	Monday, May 04, 1998 5:40 PM
> To:	Flanigan, Bill; Tim Dierks
> Cc:	[email-masked]'
> Subject:	RE: Legal issues in implementing OpenPGP?
> 
> At 08:34 AM 5/4/98 -0400, Flanigan, Bill wrote:
>    Tim,
>    
>    	I am familiar with this message which is, in part, why I asked my
>    questions.  "(I)intends" and a seven-month old message just doesn't do
> it
>    for me.
>    
> Not to worry -- I got the change control issues sorted out last Friday. 
> 
> 	Jon
> 
> 
> 
> -----
> Jon Callas                                  [email-masked]
> CTO, Total Network Security                 4200 Bohannon Drive
> Network Associates, Inc.                    Menlo Park, CA 94025
> (650) 473-2860                              
> Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
>               665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Tue, 05 May 1998 08:59:15 -0300
To: Jim Gillogly <[email-masked]>, [email-masked]
From: [email-masked] (Paulo Barreto)
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Sender: [email-masked]

At 12:55 PM 98/05/04 -0700, Jim Gillogly wrote:

>SHA1 was designed by NSA and has no intellectual property restrictions.

Hitachi claims to have a patent covering SHA1.

>HAVAL's reference implementation is copyrighted; no charge for use, but
>  the algorithm author would like to be notified.

My corrected public domain implementation is now available at
<http://www.nw.com.br/users/pbarreto/haval.zip>, but I think it's a good
idea to notify Dr. Zheng of uses of Haval.  On the other hand, there's no
published analysis of this hashing function (yet), so I'd be somewhat
reluctant in using it.

>DSA may probably be used freely, but [Schnorr claim??].

This issue seems to have been already settled in court; DSA may be freely
used.

>Elliptic Curve [??]
>ECDSA [??]

There are endless patents regarding elliptic curves (sigh); take a look at
the P1363 site <http://grouper.ieee.org/groups/1363/index.html>

>-------

Didn't someone suggest the Square block cipher yet?  A short description
was published in the Oct'97 issue of Dr. Dobb's Journal, and full
information is available at
<http://www.esat.kuleuven.ac.be/~rijmen/square/index.html>

Paulo Bareto.

Date: Tue, 5 May 1998 09:04:14 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Jim Gillogly <[email-masked]> writes:

> RIPEM-D [??]

 * RIPEMD-160 is not patented, see (as of 25.10.97)
 *   http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html

 TIGER is also not patented.

> RSA is patented in the USA, but not elsewhere.  The patent runs out on

 Sep 20th, 2000

> Diffie-Hellman (X9.42) [??]

The Diffie Hellman key agreement has run out on Apr 29th, 1997.

> IDEA is patented [with expiration ??/??/??, and permission must be

2010 (but I'm not sure)

> CAST5 is patented [patent applied for?] but Nortel and/or Entrust have
> said
>   it may be used for commercial and non-commercial applications.

See RFC2144.

Werner

Date: Mon, 04 May 1998 14:40:27 -0700
To: "Flanigan, Bill" <[email-masked]>, Tim Dierks <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: RE: Legal issues in implementing OpenPGP?
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 08:34 AM 5/4/98 -0400, Flanigan, Bill wrote:
   Tim,
   
   	I am familiar with this message which is, in part, why I asked my
   questions.  "(I)intends" and a seven-month old message just doesn't do it
   for me.
   
Not to worry -- I got the change control issues sorted out last Friday. 

	Jon

-----
Jon Callas                                  [email-masked]
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Date: Mon, 4 May 1998 17:44:49 -0400
From: [email-masked]
To: [email-masked]
Subject: opgp99b2.tgz uploaded
Sender: [email-masked]

I am trying to finish things off.  This file has been uploaded to
www.cryptography.org and should be in the new directory by tomorrow
morning.

I added signature checking to my lookup program.  I think I made the last
change to the library interface itself.  Any further changes should be
bugfixes.  I even was able to get some things working under visual C.

--- reply to tzeruch - at - ceddec - dot - com ---

From: Uri Blumenthal <[email-masked]>
Subject: Re: Subject: Re: Legal issues in implementing OpenPGP
To: [email-masked] (Jim Gillogly)
Date: Mon, 4 May 1998 16:26:56 -0400 (EDT)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Jim Gillogly says:
> Elliptic Curve [??]
> ECDSA [??]

Certicom has some patent claims, I couldn't find out what those are
exactly. Probably - something to do with point compression...

There's a rumor that even some CURVES have been patented by somebody.

So the method is very promising technically, and probably hopeless
"politically".

[Why was I so stupid not to patent a few prime numbers, say - all the
primes between 10^3 and 10^150, for cryptographic purposes? :-]

> Diffie-Hellman (X9.42) [??]

I'd like to know the "final" status of DH myself. Anybody?

> DES/SK [??]

Not patented. Can be used freely.  

If you burn it in chips, you may (but don't have to) send me a sample (:-).

> And so on... isn't this done in some other IETF docs?

Should be (:-).
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

Date: Mon, 04 May 1998 12:55:04 -0700
From: Jim Gillogly <[email-masked]>
Organization: Banzai Institute
To: [email-masked]
Subject: Subject: Re: Legal issues in implementing OpenPGP
Sender: [email-masked]

While it's worth getting an explicit statement from Network Associates
that they will honor PGP Inc's commitment to leave change authority
for OpenPGP with IETF, there's no reason to believe it wouldn't be
forthcoming.

That's not the only intellectual property issue that needs to be
addressed, though: I think there should be a section that says things
like the following (which is off the top of my head and should be
verified rather than included wholesale).
-------
SHA1 was designed by NSA and has no intellectual property restrictions.
MD5 may be used freely; if the RSA Labs sample code is used, their
copyright
  statement must be retained in the source.
RIPEM-D [??]
HAVAL's reference implementation is copyrighted; no charge for use, but
  the algorithm author would like to be notified.
MD2 [??]
-------
ZIP was carefully chosen to avoid patent restrictions and may be used
freely;
 the zLib library implements a patent-safe version of the algorithm.
-------
RSA is patented in the USA, but not elsewhere.  The patent runs out on
[date].
  [Special conditions if you use RSAREF in the US?]
ElGamal's patent has run out, so it may be used freely.
DSA may probably be used freely, but [Schnorr claim??].
Elliptic Curve [??]
ECDSA [??]
Diffie-Hellman (X9.42) [??]
--------
IDEA is patented [with expiration ??/??/??, and permission must be
obtained
  from ASCOM AG [address?].
Triple-DES may be used freely in all applications.
CAST5 is patented [patent applied for?] but Nortel and/or Entrust have
said
  it may be used for commercial and non-commercial applications.
Blowfish may be used freely in all applications.
SAFER-SK128 [??]
DES/SK [??]
-------
And so on... isn't this done in some other IETF docs?
-- 
	Jim Gillogly
	Sterday, 13 Thrimidge S.R. 1998, 19:37
	12.19.5.2.13, 13 Ben 6 Uo, Eighth Lord of Night

Date: Mon, 4 May 1998 12:58:55 -0400
From: [email-masked]
To: Anonymous <[email-masked]>
cc: [email-masked]
Subject: Re: Section 6.6 again
Sender: [email-masked]

On Mon, 4 May 1998, Anonymous wrote:

> Actually, no.  That was the example message from the first version
> of the draft.  Please repeat your analysis (with which I'm in
> agreement) with the message from the most recent -02.txt draft:
> 
>    -----BEGIN PGP MESSAGE-----
>    Version: OpenPGP 1.0
> 
>    yCoBc07MUy9RSMyrzM9LVchOTS1QSFQoTk0uSgUKFuWX5qUoZKQWpdpzAQA=
>    =jYsF
>    -----END PGP MESSAGE-----

This one dearmors to:

000000 c8 2a 01 73 4e cc 53 2f 51 48 cc ab cc cf 4b 55
000010 c8 4e 4d 2d 50 48 54 28 4e 4d 2e 4a 05 0a 16 e5
000020 97 e6 a5 28 64 a4 16 a5 da 73 01 00
00002c

which is 0x2c bytes total, so there are exactly 0x2a bytes following the
0x2a (final-)packet-length byte.

> This is the one I claim doesn't decompress to a valid OP packet.

You are correct.  Decompression yields plaintext instead of a literal.

I think it was made with a version of my library demo program that can do
each step individually, and the enliteraling step was omitted.

A corrected version (using _CONSOLE as the name):

From: "Flanigan, Bill" <[email-masked]>
To: Tim Dierks <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Legal issues in implementing OpenPGP?
Date: Mon, 4 May 1998 08:34:25 -0400 
Sender: [email-masked]

Tim,

	I am familiar with this message which is, in part, why I asked my
questions.  "(I)intends" and a seven-month old message just doesn't do it
for me.

Bill 

> -----Original Message-----
> From:	Tim Dierks [SMTP:[email-masked]]
> Sent:	Friday, May 01, 1998 9:34 PM
> To:	Flanigan, Bill
> Cc:	[email-masked]'
> Subject:	RE: Legal issues in implementing OpenPGP?
> 
> At 4:30 PM -0400 5/1/98, Flanigan, Bill wrote:
> >This is a very "interesting" question.  I've pondered things in this
> >area myself.  I believe the over-riding question, however, is:  Does
> >the IETF have change control here?  Anyone know one way or the other?
> >
> >Bill
> 
> You may want to take a look at <ftp://ietf.org/ietf/IPR/PGP-openpgp>,
> which
> says:
> 
> >Extracted from an email message sent September 18, 1997
> >From: Charles Breed <[email-masked]>
> >
> >Subject: Change Control
> >Just to make things 'crystal clear', let it be known that...
> >
> >"PGP Inc. intends to turn change control of the PGP key and messages
> >formats over to the IETF in a similar way to the way Sun Microsystems
> >turned over RPC in RFC1790."
> >
> >Charles Breed
> >Senior Director fo PGP technologies
> 
>  - Tim
> 
> Tim Dierks - [email-masked] - www.consensus.com
>   Director of Engineering - Consensus Development
>   Developer of SSL Plus: SSL 3.0 Integration Suite
> 

Date: Mon, 4 May 1998 10:18:42 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: GPG killing PGP?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Bill Stewart <[email-masked]> writes:

> Yow!  I tried importing this into PGP 5.5.3 QU2, using the
> Eudora 3.0.5 PGP plugin, and it crashed with a dialog box saying
> 	This program has performed an illegal operation
> 	and will be shot down.
> I tried saving the key in a file and importing into PGP,
> and it also died with the same kind of dialog box.

This is a listing of the key.

:compressed packet: algo=2

Maybe this is the problem.  Compress algo 2 is standard zlib
compression - what about adding this to OpenPGP?  And while doing
that, isn't it worth to add an identifier for bzip2.

:public key packet:
        version 3, created 894195413, valid for 0 days
        elg p: [1024 bits]
        elg g: [3 bits]
        elg y: [1020 bits]
:OpenPGP draft comment packet: "#created by GNUPG v0.2.16 (Linux)"
:user id packet: "Neva Remailer <[email-masked]>"
:signature packet: keyid 303BEDD769760438
        version 3, created 894195413, md5len 5, sigclass 13
        digest algo 3, begin of digest 92 2d
        elg a: [1023 bits]
        elg b: [1023 bits]
pub  1024G/69760438 1998-05-03 Neva Remailer <[email-masked]>
sig        69760438 1998-05-03   Neva Remailer <[email-masked]>

It is RFC1991 with an OpenPGP packet of type 16 used for the comment. 
You cannot expect that PGP understands this - but it should not
SIGSEGV.

Werner

Date: Sun, 03 May 1998 22:43:08 -0700
To: "C. James" <[email-masked]>, [email-masked]
From: Bill Stewart <[email-masked]>
Subject: GPG killing PGP?
Cc: [email-masked]
Sender: [email-masked]

Yow!  I tried importing this into PGP 5.5.3 QU2, using the
Eudora 3.0.5 PGP plugin, and it crashed with a dialog box saying
	This program has performed an illegal operation
	and will be shot down.
I tried saving the key in a file and importing into PGP,
and it also died with the same kind of dialog box.

At 05:45 AM 5/3/98 -0700, C. James wrote, 
to [email-masked]
>Neva remailer is now pgponly and supports GPG encrypted messages.
>
>pub  1024G/69760438 1998-05-03 Neva Remailer <[email-masked]>
>
>-----BEGIN PGP PUBLIC KEY BLOCK-----
>Version: GNUPG v0.2.16 (Linux)
>Comment: This is an alpha version!
>
>owJ4nAFyAo39mQEPAzVMVtUAABAEAJM++R4Zj7y6Jao/BKYzd2j8lF3p3KpL8xR3nNquCzcT
>gjlzo8R/vENt5RECpZZQcNdvfG1CEM1HdksOQ+5zjiStf0V+/4d6mZiNZggS+LPF69Wvxgo+
>a0HeHV0j+DSA7fFqQTkvD8FLaSFRMwR47upx3e2r8vvg+RWSQsolf1F/AAMFA/wLEnNPinsj
>mFrIMMGaLgjMr6Wq6z7g3g5SnOPznViTwSPBMotpd+yJXV3kL1Lotx8QtxwFqNOz7f83VWLe
>xKyROfzh7YgVMFC+t1bvjZbLWOZN2Qszzcy4dawEg9Y+uXTiEEciybOlRoQMV8hyko0YPdWl
>h45/I9Eq6P5fvusEb9AhI2NyZWF0ZWQgYnkgR05VUEcgdjAuMi4xNiAoTGludXgptCFOZXZh
>IFJlbWFpbGVyIDxyZW1haWxlckBuZXZhLm9yZz6JARcDBRM1TFbVMDvt12l2BDgQA5ItA/94
>IGUIkodJ1SOlJTYaQz+wlB1sBqTKqRdmkuJ2sV1JJHhFxwC22sHfv3FJ/3QSzhlS5yYXskG3
>0142hSqMhhjGSGUHWuQ94VLjzjlSnsZoM6dh6my54Ns6RDjQm4jVVBwupB07Cw19DX2s0QgS
>xfb1jASTvuPSGC8ykRPJcS/a1gP/UreSvxQ6xQwhW3SP+iBtRh6rwATQz5YqvElIM+SOn4+8
>pw6+uRg3AZAFOi3AxGTPJ/eCOxnvT2KwM0h0zxYTa41jcLx8ee4g94pmaIt65ZykH3R8nLQc
>p67tQ09wUyBe9VIHwNpiH7m7PwbU3b/46feLNgu2nW/ZhGhzjbv6MhabOR5+
>=2CxI
>-----END PGP PUBLIC KEY BLOCK-----
>
>
>Casey James <[email-masked]>
>Key fingerprint = 4A D2 32 9F F0 08 F4 1E  E5 EF 35 21 8A 7F B7 82
>
>
>
				Thanks! 
					Bill
Bill Stewart, [email-masked]
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Date: Mon, 4 May 1998 06:45:12 +0200
From: Anonymous <[email-masked]>
Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at <[email-masked]>.
Subject: Re: Section 6.6 again
To: [email-masked]
Sender: [email-masked]

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

Hal Finney writes:
>The example message is:
>
> -----BEGIN PGP MESSAGE-----
> Version: OpenPGP V0.0
>
> owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn
> l6UWpabo8XIBAA==
> =3m1o
> -----END PGP MESSAGE-----

Actually, no.  That was the example message from the first version
of the draft.  Please repeat your analysis (with which I'm in
agreement) with the message from the most recent -02.txt draft:

   -----BEGIN PGP MESSAGE-----
   Version: OpenPGP 1.0

   yCoBc07MUy9RSMyrzM9LVchOTS1QSFQoTk0uSgUKFuWX5qUoZKQWpdpzAQA=
   =jYsF
   -----END PGP MESSAGE-----

This is the one I claim doesn't decompress to a valid OP packet.

Thanks.

	Salvo Salasio
	KeyID 0xFFFFFFFF

Date: Sun, 3 May 1998 16:04:32 -0700
From: Hal Finney <[email-masked]>
To: [email-masked]
Subject: Re: Section 6.6 again
Sender: [email-masked]

> Much as I hate to harp on the same example, I'm still dubious about
> the example ASCII armoured message in 6.6; this time for two different
> reasons.

The example message is:

 -----BEGIN PGP MESSAGE-----
 Version: OpenPGP V0.0

 owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn
 l6UWpabo8XIBAA==
 =3m1o
 -----END PGP MESSAGE-----

Dearmoring produces the following data:

 a3 01 5b c7 c0 c0 60 54 c2 5a 5c 92 92 99 07 64
 32 84 14 25 e6 15 e7 66 16 17 67 e6 e7 29 64 a7
 56 16 2b f8 86 06 87 28 f8 f9 87 28 14 a5 26 e7
 97 a5 16 a5 a6 e8 f1 72 01 00

The first byte, a3, is binary 10100011, which is an old-style CTB, tag
binary 1000 or decimal 8 which is a compressed packet, and the low two
bits being binary 11 means that there is no length field, but that the
entire length of the file is used.  (See section 4.2.1.)

Decompressing this packet's data produces:

 ae 00 00 00 32 74 05 73 74 64 69 6e 00 00 00 00
 54 72 61 6e 73 6d 69 73 73 69 6f 6e 20 6b 65 79
 73 20 4d 55 53 54 20 4e 4f 54 20 72 65 63 6f 76
 65 72 65 64 2e 0d 0a

The first byte is ae, binary 10101110, an old-style CTB with tag binary
1011 or decimal 11 which is a literal packet.  The low two bits being
binary 10 means that there is a four byte length, which is hex 00000032
or decimal 50.  This is followed by the literal header, then the body
of data, which is the text:

 Transmission keys MUST NOT recovered.

Hal

Date: Sun, 3 May 1998 17:58:50 +0200
From: Werner Koch <[email-masked]>
To: [email-masked], [email-masked]
Subject: FYI: comment packets
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> The comment packet is gone at the area director's request. The uses you
> give for it are good ones, but other protocols with similar features have
> also had them removed. However, if you want to carry meta-data in a
> pipeline, there's no reason why you can't use packets 60-63 for this. They
> are specifically reserved for private or experimental use. 

Okay I changed it:  GNUPG now puts comments into a packet of type 61.
Comment packets of type 16 are still recognized. The first character
of all GNUPG generated comments is a ´#´.

Werner

Date: 2 May 1998 15:43:24 -0000
From: Secret Squirrel <[email-masked]>
Comments: Please report problems with this automated remailing service to <[email-masked]>. The message sender's identity is unknown, unlogged, and not replyable.
Subject: Section 6.6 again
To: [email-masked]
Sender: [email-masked]

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

Congratulations to Jon & Co. on the new draft.  Much good bumf added.

Much as I hate to harp on the same example, I'm still dubious about
the example ASCII armoured message in 6.6; this time for two different
reasons.

First, isn't the count wrong?  This time it's a new-style packet that
claims to be 42 bytes long (familiar number, there), but there is
only one byte of compression type followed by 40 bytes of data, so
it seems to me the count should be 41 (41 shall be the number of
the counting. 42 is straight out).

Second, unlike the example this one replaces, the compressed data
decompresses to straight text rather than to a valid literal packet.
Section 10.2 says decompressing a Compressed Data packet must yield a
valid OpenPGP Message, and this one doesn't.  Am I misunderstanding the
spec here?  It also differs from the original example in that it has an
explicit length rather than an old-style arbitrary length... is that the
difference, and, if so, should this different behaviour be documented?

	Salvo Salasio <[email-masked]>
	Key ID = 0xFFFFFFFF

Date: Fri, 1 May 1998 18:34:17 -0700
To: "Flanigan, Bill" <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject: RE: Legal issues in implementing OpenPGP?
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 4:30 PM -0400 5/1/98, Flanigan, Bill wrote:
>This is a very "interesting" question.  I've pondered things in this
>area myself.  I believe the over-riding question, however, is:  Does
>the IETF have change control here?  Anyone know one way or the other?
>
>Bill

You may want to take a look at <ftp://ietf.org/ietf/IPR/PGP-openpgp>, which
says:

>Extracted from an email message sent September 18, 1997
>From: Charles Breed <[email-masked]>
>
>Subject: Change Control
>Just to make things 'crystal clear', let it be known that...
>
>"PGP Inc. intends to turn change control of the PGP key and messages
>formats over to the IETF in a similar way to the way Sun Microsystems
>turned over RPC in RFC1790."
>
>Charles Breed
>Senior Director fo PGP technologies

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

From: "Chris Bartram" <[email-masked]>
Organization: 3k Associates
Reply-To: [email-masked]
Date: Fri,  1 May 1998 17:37:26 -0400
Subject: Re[2]: Legal issues in implementing OpenPGP?
To: [email-masked]
Sender: [email-masked]

 In <[email-masked]> [email-masked] writes:

> This is a very "interesting" question.  I've pondered things in this
> area myself.  I believe the over-riding question, however, is:  Does
> the IETF have change control here?  Anyone know one way or the other?

Whether it does or not, since the intent of the standard is to allow people
to implement it, it would at least seem "neighborly" ;-) to include pointers
to or references regarding the legal issues involved. Perhaps just a note
for each algorithm indicating if there are potential patent issues and if so
the company name/address(URL?) to contact?

Import/export issues are too specific/variable to bother including in the
spec, but I would think that legal/patent issues would affect a majority of
the users/organizations considering implementing the spec.

I was under the impression from reading in Applied Cryptography that there
were at least claims of patents affecting all public-key encryption schemes.?

PKP's patent on Diffie-Hellman (and related claims on ElGamal) expired last
year; any others to worry about?

            -Chris Bartram

(remove 'nospam' from address to reply)

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Cc: [email-masked]
Reply-To: [email-masked]
Date: Sat, 2 May 1998 09:28:04 (NZST)
Sender: [email-masked]

>Note that to apply for an OID, you have to be one of the players ISO
>recognizes (i.e. MD5 = 1.2.840.113549.2.5 meaning:
>ISO.Member_body.US.RSADSI.PKCS#2.MD5 If IETF, IMC, or Network Associates
>desires to use ASN1 OIDs, I think it would be useful for them to get an OID
>for their company or organization (or add one just for OpenPGP) so they will
>be recognized in the hierarchy.  Then we can drop in the extra algorithms
>under that number.
 
It's possible for anyone to issue OIDs with a bit of trickery.  If it's really
necessary to have an OID for Haval and whatnot I could issue one, but I'd
prefer to try and avoid the currently problem of there being 20 different OID's
for each algorithm - there are a few European initiatives who are assigning
OID's for some of the newer algorithms, the Teletrust project has them for
RIPEMD up to 256 (which I didn't know existed except outside a proposal in the
RIPEMD-128/160 paper), there may be Haval OIDs somewhere as well.
 
I've been waiting, and asking around, for about a year now for ripemd160WithXXX
OID's, if these don't appear from another source I'll issue them myself,
provided someone actually uses them - if PGP were to go with them I'd be quite
happy to issue OID's for whatever you need (there are already xxxWithElgamal
and elgamalEncryption OID's defined), I just don't want to end up polluting the
OIDspace with another set of unused values.
 
>For an online guide to object IDs (from someone active in the IETF) see
>http://www.alvestrand.no/objectid
 
I've found it rather hard to find things on that site because of the amount of
data there, for a list speficically of crypto-related OID's, have a look at
dumpasn1, http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c|cfg} (the cfg file
has the OIDs).
 
Peter.

From: "Flanigan, Bill" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Legal issues in implementing OpenPGP?
Date: Fri, 1 May 1998 16:30:09 -0400 
Sender: [email-masked]

This is a very "interesting" question.  I've pondered things in this 
area myself.  I believe the over-riding question, however, is:  Does 
the IETF have change control here?  Anyone know one way or the other?

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
Defense Information Systems Agency      DSN:                      653
Strategic Planning Office (JEBA)        Fax:            (703)735-3255
10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
Reston, VA 20191-4357              Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Chris Bartram [SMTP:[email-masked]]
> Sent:	Thursday, April 30, 1998 9:06 PM
> To:	[email-masked]
> Subject:	Legal issues in implementing OpenPGP?
> 
> 
> Forgive the rather basic questions, but;
> 
> If one wants to implement a *commercial* implementation that supports the
> OpenPGP standard, are there *ANY* patent/licensing issues we have to deal
> with:
> 
>   1) Assuming we implement just the "MUST" algorithms?
>   (Isn't generic "public key encryption" technology still patented? If so,
>    what steps does one have to take to use it? Who must be contacted?)
> 
>   2) For the other "SHOULD" algorithms? An appendix listing some info/
>     contact details on who one should contact would certainly make
>     implementing the spec much easier.
> 
> We're a U.S. based company (if that matters), but I suspect contact info
> would
> also be useful to organizations in many other countries as well.
> 
> Thanks!
>                      -Chris Bartram
>                       3k Associates, Inc.
> 
> (remove "nospam" from return address for direct replies)

From: "Flanigan, Bill" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Legal issues in implementing OpenPGP?
Date: Fri, 1 May 1998 16:25:38 -0400 
Sender: [email-masked]

This is a very "interesting" question.  I've pondered things in this 
area myself.  I believe the over-riding question, however, is:  Does 
the IETF have change control here?  Anyone know one way or the other?

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
Defense Information Systems Agency      DSN:                      653
Strategic Planning Office (JEBA)        Fax:            (703)735-3255
10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
Reston, VA 20191-4357              Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Chris Bartram [SMTP:[email-masked]]
> Sent:	Thursday, April 30, 1998 9:06 PM
> To:	[email-masked]
> Subject:	Legal issues in implementing OpenPGP?
> 
> 
> Forgive the rather basic questions, but;
> 
> If one wants to implement a *commercial* implementation that supports the
> OpenPGP standard, are there *ANY* patent/licensing issues we have to deal
> with:
> 
>   1) Assuming we implement just the "MUST" algorithms?
>   (Isn't generic "public key encryption" technology still patented? If so,
>    what steps does one have to take to use it? Who must be contacted?)
> 
>   2) For the other "SHOULD" algorithms? An appendix listing some info/
>     contact details on who one should contact would certainly make
>     implementing the spec much easier.
> 
> We're a U.S. based company (if that matters), but I suspect contact info
> would
> also be useful to organizations in many other countries as well.
> 
> Thanks!
>                      -Chris Bartram
>                       3k Associates, Inc.
> 
> (remove "nospam" from return address for direct replies)

From: "Chris Bartram" <[email-masked]>
Organization: 3k Associates
Reply-To: [email-masked]
Date: Thu, 30 Apr 1998 21:05:42 -0400
Subject: Legal issues in implementing OpenPGP?
To: [email-masked]
Sender: [email-masked]

Forgive the rather basic questions, but;

If one wants to implement a *commercial* implementation that supports the
OpenPGP standard, are there *ANY* patent/licensing issues we have to deal
with:

  1) Assuming we implement just the "MUST" algorithms?
  (Isn't generic "public key encryption" technology still patented? If so,
   what steps does one have to take to use it? Who must be contacted?)

  2) For the other "SHOULD" algorithms? An appendix listing some info/
    contact details on who one should contact would certainly make
    implementing the spec much easier.

We're a U.S. based company (if that matters), but I suspect contact info would
also be useful to organizations in many other countries as well.

Thanks!
                     -Chris Bartram
                      3k Associates, Inc.

(remove "nospam" from return address for direct replies)

Date: Fri, 1 May 1998 10:33:32 -0400
From: [email-masked]
Reply-To: [email-masked]
To: Jon Callas <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt
Sender: [email-masked]

On Thu, 30 Apr 1998, Jon Callas wrote:

> Rot-N is gone. There is an algorithm identifier for Elgamal
> encrypt-and-sign keys. I have a question on this -- we wanted to deprecate
> the usage-types on RSA keys (i.e. separate algorithm numbers for, but the
> issues surrounding Elgamal signatures make it apparent that it's good to
> have a separate algorithm ID for an encrypt-and-sign Elgamal key. See the
> algorithm notes for details. Does this mean, then, that we should
> de-deprecate the RSA usage-types? I'd just as soon keep them deprecated
> because there are real cryptographic reasons for a separate Elgamal ID.

I would keep the RSA extras depricated.  It may also be a good idea to
suggest a switch to the stronger E&S ElGamal keys even if they are never
used for signing (and that implementations MUST accept them for
encryption, otherwise I have to create duplicate keys that differ only
in the algorithm number).

> I added in MD2 as a hash algorithm. There are people who want to do
> PGP/X.509 interoperability, and they need an identifier for MD2.

The material hashed will never be the same, so MD2 won't work *directly*. 
The only other possibility I can see is to add to a PGP signature packet a
special hashed material packet with an identifer that means "Hash *ONLY*
this extra material" which would be duplicated from what X509 signs. 

> We still don't have an OID for HAVAL. Can someone get one? Having HAVAL in
> there is nice, but I'm a lazy SOB and it's easier for me to remove HAVAL
> than to get it an OID. I also think that if having HAVAL is important to
> the community, then there oughta be one person who would stand up and take
> it upon themself to get an OID.

Or for TIGER.  Actually, the PKCS1 padding with ASN1 OID is only important
for RSA and ElGamal signatures, and only to insure interoperability with
RSAref in the former case.  Actually not even that since the decryption
(signature check) simply returns the entire buffer and it is only if you
use higher level routines that it would matter.  I have been using an ASN1
octet-string of "HAVAL" in place of an OID and everything works. 

Unless you really want to limit PGP to only use things with approved
object numbers, I would strongly suggest using the octet string of the
hash (which you have defined for clear signatures anyway) as an
alternative to an OID.  Then this issue disappears.  So if I see the ASN1
OBJECT, I look it up in the OID table, but if I see an octet string in the
same place, I match on the string.  So [OID]1.2.840.113549.2.5 and
[Octet-string]3,"MD5" would be synonymous.

[While I am near the subject, I would like a number for the TIGER hash -
Werner Koch is implementing it, and it would be easier if it had an
official Algorithm ID, I would suggest the next available one: 6]

Note that to apply for an OID, you have to be one of the players ISO
recognizes (i.e. MD5 = 1.2.840.113549.2.5 meaning:
	ISO.Member_body.US.RSADSI.PKCS#2.MD5 If IETF, IMC, or Network
Associates desires to use ASN1 OIDs, I think it would be useful for them
to get an OID for their company or organization (or add one just for
OpenPGP) so they will be recognized in the hierarchy.  Then we can drop in
the extra algorithms under that number.

For an online guide to object IDs (from someone active in the IETF) see
http://www.alvestrand.no/objectid

> I'm going to go over comments on this draft over the next week or three and
> produce a last-call draft. Early revisions will go to the usual gang. If
> you have something you really, really want done, let me know. I'll make
> sure you get an early revision. I want last call to be quiet, so we can
> call this a wrap and then get on to the *real* discussions of what's good
> to have in OpenPGP.

--- reply to tzeruch - at - ceddec - dot - com ---